Jemena Authentication

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.