generated: '2026-07-27' method: searched source: https://www.jemena.com.au/siteassets/asset-folder/documents/electricity/embedded-generation/jen-oem-technical-guide_handbook_v1.0.1-final.pdf docs: https://www.jemena.com.au/electricity/solar-connections/victoria-emergency-backstop-mechanism/emergency-backstop-mechanism-documents/ api: jemena:jemena-csip-aus-utility-server note: >- Jemena publishes no OpenAPI, so this profile is harvested from the prose contract in the public JEN OEM Technical Guide Handbook (v1.0, 12 June 2025) rather than derived from securitySchemes. There is no bearer token, no API key and no OAuth surface anywhere on the JEN Utility Server: identity is a Jemena-signed X.509 client certificate presented in a mutually-authenticated TLS handshake, and the on-the-wire device identity is the LFDI hashed from that certificate. summary: types: - mutualTLS api_key_in: [] oauth2_flows: [] self_serve: false gate: application-approval schemes: - name: IEEE 2030.5 client certificate (mTLS) type: mutualTLS description: >- All client communication to the JEN Utility Server requires a certified PKI certificate to authenticate and identify the client. Certificates are unique per client AND per environment — a staging certificate does not work in production. The handbook documents a native IEEE 2030.5 root CA device certificate profile (Section C1.1) and an intermediate Manufacturer Certificate Authority (MCA) certificate profile (Section C1.2). source: handbook Section 10 Certificate Public Key Infrastructure (PKI) pki: root: SERCA (Smart Energy Root Certificate Authority) intermediate: MCA / MICA (Manufacturer Certificate Authority) — direct-connected device model issuer: Jemena Electricity Networks (JEN) signs the client CSR evidence: >- Anonymous GET https://sep2.aws.jemena.com.au:8443/sep2/dcap on 2026-07-27 completes the TLS handshake against a private-PKI certificate (curl ssl_verify_result=19, self-signed certificate in chain — expected for the SEP2 SERCA/MICA hierarchy) and returns HTTP 500 from nginx with verification disabled, because no client certificate was presented. Handbook FAQ 8.7.1 confirms the failure mode: "the remote end closed connection without response" means the request did not include a valid PKI certificate. - name: Source IP allow-listing type: network description: >- A network-layer control applied in addition to mTLS. Clients submit the IP addresses to be whitelisted alongside their Certificate Signing Request. The handbook states IP access restriction is implemented in the non-production/staging environment for onboarding testing, and asks for 7 business days advance notice of any IP change. source: handbook Section 7.1.1 step 2 identity: device_identifier: LFDI (Long Form Device Identifier) lfdi_definition: >- 40 hexadecimal characters, alphanumeric only, no special characters, derived by hashing the device X.509 certificate. Handbook FAQ 8.3.1 publishes the generation command verbatim: openssl x509 -outform der -in client-cert.pem | sha256sum | head -c 40 | tr '[a-f]' '[A-F]' direct_device_model: >- Device LFDI is the certificate fingerprint left-truncated to 160 bits (20 octets), expressed as 40 hexadecimal digits in groups of four. aggregator_model: >- One certificate represents many downstream sites. Virtual LFDIs are minted by the aggregator: first 32 hex digits are a unique identifier, last 8 hex digits are the provider's IANA Private Enterprise Number (PEN) with leading zeros. Each LFDI and its associated SFDI must be unique. secondary_identifier: SFDI (Short Form Device Identifier), String(12), numeric only site_identifier: >- ConnectionPointID — the 10-digit NMI (National Metering Identifier) plus 1 checksum digit, validated against the JEN NMI database. An invalid ConnectionPointID returns HTTP 403. registration: in_band: supported: true scope: aggregator model only note: >- Jemena states in-band registration is supported only for aggregator-model clients and is still under test; additional onboarding tests are required before production use. A 204 No Content on GET /sep2/edev/{x}/rg means the Registration PIN is null/blank/empty and the client should proceed without PIN-based validation. out_of_band: supported: true note: Default path; recommended where the client cannot support the in-band behaviour above. registration_pin: required: false note: >- Optional. Jemena publishes both environment PINs in the public handbook (Section 7.1.1 step 3 and FAQ 8.4). The staging value is recorded in sandbox/jemena-sandbox.yml; the production value is left in the source document rather than mirrored here. onboarding: self_serve: false contact: emergency.backstop@jemena.com.au steps: - Be an inverter OEM, gateway manufacturer or aggregator whose product is on the Clean Energy Council list of AS/NZS 4777.2:2020 CSIP-AUS compliant inverters. - Generate a private key. - Submit a Certificate Signing Request plus the IP addresses to whitelist (aggregator model), or an MCA intermediate-CA CSR plus a CA Naming Form (direct-connected device model), by email or file share to emergency.backstop@jemena.com.au. - Receive the JEN-signed certificate, the aggregator LFDI and the registration PIN. - Pass the connectivity test, device registration, discovery test and out-of-band functional tests in the staging environment. - Repeat certificate issuance and testing in the production environment. - Jemena adds the client to its public CSIP-AUS Approved Listing; from 1 July 2025 inverters not on that listing cannot connect or commission. key_custody_warning: >- "Client must keep their Private Key and JEN issued Certificate in a safe place. If it is lost, client must notify JEN to reapply for the certificate. Additional cost will incurred here, up to $3000 USD. The client is responsible for this fee." (handbook Sections 7.1.1 and 7.1.2) not_present: oauth2: No OAuth 2.0 authorization server is published or referenced. openid_connect: >- GET https://www.jemena.com.au/.well-known/openid-configuration returned 404 and https://myportal.jemena.com.au/.well-known/openid-configuration returned 403 on 2026-07-27. api_key: No API key scheme is documented anywhere on the JEN Utility Server. scopes: >- No OAuth scope surface exists, so scopes/ is intentionally absent. Authorisation is expressed as certificate validity plus LFDI-to-resource binding — handbook FAQ 8.7.5 documents HTTP 403 as an LFDI mismatch and FAQ 8.7.3 documents HTTP 404 as "existence confirmation is withheld" for an unauthorised certificate.