Deep dive · In the raw · optional

The two certificate chains of one session

About 12 min · 3 questions ·

Friday
The situation

Stops 03 and 04 explained the certificates in words. This is what they look like: the chain the car presented at 11:20:03, printed the way a certificate tool prints it, the four checks the charger's backend ran on it, and the charger's own certificate from the TLS handshake a second earlier.

Names and dates are composed; the structure is that of the X.509 certificates ISO 15118 uses.

The questionWhere in the chain is the contract, where is the trust, and what does the charger actually check before it starts?

Guess firstThe car sends three certificates, but the chain has four links. Which one is missing, and why?RevealHide

The root certificate. It is never sent; the charger must already hold it in its trust store. A root that arrived with the chain would prove nothing.

What you are looking at

ISO 15118-2 builds on X.509 certificates, the same kind that secure websites: a subject, an issuer, a validity period, a public key and a signature by the issuer. The car's chains up through the provider's sub-CAs to a root; the charger's certificate chains up through the operator's sub-CAs, ideally to the same root. The Open Charge Alliance's application note describes how the charger forwards the chain to its backend for the checks, and how certificates are installed and renewed through the charger.

Select the lines to read each field as the backend does.

Printed by a certificate tool, 11:20:03The contract certificate chain, and its checks

Three certificates as the car sent them, then the backend's four checks. The root is not in the message.

  2. Line 1What the car sends

    Three certificates in one message: the contract certificate and the two sub-CA certificates above it. The root is not sent; the charger must already hold it.

  3. [0] Contract certificate
  9. Signature: ecdsa-with-SHA256, by NOR MO Sub-CA 2
  10. [1] NOR MO Sub-CA 2
  11. Subject: CN=NOR MO Sub-CA 2, O=NOR Mobility GmbH, C=DE
  12. Issuer: CN=NOR MO Sub-CA 1, O=NOR Mobility GmbH, C=DE
  14. Basic constraints: CA=true, pathlen=0
  15. [2] NOR MO Sub-CA 1
  16. Subject: CN=NOR MO Sub-CA 1, O=NOR Mobility GmbH, C=DE
  18. Validity: Not Before 2024-03-01, Not After 2034-02-28
  19. Basic constraints: CA=true, pathlen=1
  22. chain verifies to V2G Root CA G2 ............ OK (root in trust list, entry 3 of 5)
  23. validity at 2026-10-09 09:20:04 UTC ......... OK
  26. eMAID DE-NOR-C8A2B3C4D-2 ..................... accepted, session 2026-10-09-1120-3256
contract-chain-DE-NOR-C8A2B3C4D-2.txt: the whole file, to copy
CONTRACT CERTIFICATE CHAIN, presented by the car at 11:20:03
[0] Contract certificate
    Subject:      CN=DENORC8A2B3C4D2, O=NOR Mobility GmbH
    Issuer:       CN=NOR MO Sub-CA 2, O=NOR Mobility GmbH, C=DE
    Validity:     Not Before 2026-07-14 09:00:00 UTC, Not After 2028-07-13 09:00:00 UTC
    Public key:   EC, curve secp256r1 (P-256)
    Key usage:    digitalSignature, nonRepudiation, keyEncipherment, keyAgreement
    Signature:    ecdsa-with-SHA256, by NOR MO Sub-CA 2
[1] NOR MO Sub-CA 2
    Subject:      CN=NOR MO Sub-CA 2, O=NOR Mobility GmbH, C=DE
    Issuer:       CN=NOR MO Sub-CA 1, O=NOR Mobility GmbH, C=DE
    Validity:     Not Before 2025-11-01, Not After 2030-10-31
    Basic constraints: CA=true, pathlen=0
[2] NOR MO Sub-CA 1
    Subject:      CN=NOR MO Sub-CA 1, O=NOR Mobility GmbH, C=DE
    Issuer:       CN=V2G Root CA G2, O=European V2G Root Services, C=DE
    Validity:     Not Before 2024-03-01, Not After 2034-02-28
    Basic constraints: CA=true, pathlen=1

CHECKS by the charger's backend, 11:20:04
    chain verifies to V2G Root CA G2 ............ OK (root in trust list, entry 3 of 5)
    validity at 2026-10-09 09:20:04 UTC ......... OK
    OCSP status of contract certificate ......... GOOD (responder of NOR, 11:20:04)
    challenge signed by the car ................. OK
    eMAID DE-NOR-C8A2B3C4D-2 ..................... accepted, session 2026-10-09-1120-3256

A composed chain in the structure ISO 15118-2 specifies for contract certificates: leaf, two sub-CAs, a root held by the charger. The checks follow the OCA application note: chain and validity, status request to the provider, challenge signed by the car. The validity periods, two years at most for the contract and two to three months for the charger, are those of the standard's certificate profiles, which CharIN's certificate policy for the V2G PKI repeats; the contract ID carries the check digit of the eMAID format.

From the TLS handshake, 11:20:02The charger's own certificate

What the car checked before it presented anything.

  2. Line 1The charger goes first

    Before the car shows its contract, the charger proves itself in the TLS connection. The car checks this certificate against the roots it carries, the mirror of the check above (stop 03).

  6. Public key: EC, curve secp256r1 (P-256)
  7. Key usage: digitalSignature

The charger's certificate chains through the operator's sub-CAs to a V2G root; trust lists decide which roots a car and a charger accept.

Four checks, four failures that each stop a session

  • Chain. Every signature verifies with the key of the certificate above, up to a root on the . Fails when the car's root is unknown to the charger: the trust problem of stop 06.
  • Validity. No certificate in the chain has expired. Fails when the car missed its renewal, often after months without a session.
  • Status. The provider's responder says the contract is not revoked. Fails for ended contracts and stolen cars; offline, the charger decides by its local list.
  • Possession. The car signs the charger's challenge with the private key. Fails for a copied certificate; this is the check that makes the certificate a key and not a password.

All four passed at 11:20:04, and the session started. At 2:10 PM, at the other operator, the first check failed and the card took over (stop 06).

What never travels

Two things are missing from both printouts, and that is the point. The private keys stay where they were made: in the car's secure hardware and in the charger. And the driver's payment details stay with the provider; the chain names a contract, not a bank account (stop 03). The same certificates let the car speak the newer ISO 15118-20 as well, which Bidirectional charging, deep dive shows in a home session.

Check your understanding

3 questions. Answer all of them to complete this stop. Each answer explains itself.

01Question 1 of 3

What stands in the subject of the contract certificate?

02Question 2 of 3

Why does the car not send the root certificate with the chain?

03Question 3 of 3

Which of the four checks defeats a copied certificate?

Further in other paths

  1. Bidirectional charging · Deep diveOne evening of messages between car and wallboxThe evening of this path as the car and the wallbox negotiated it over the cable: the ISO 15118-20 messages that select bidirectional transfer, state the limits in both directions, carry the owner's frame and then report the power as the wallbox drives it, decoded from the binary into readable form.
  2. OCPP in depth · Stop 07How is the connection secured?Three security profiles, from basic authentication to client certificates: how charger and backend prove who they are, and why the choice matters.
  1. ISO: ISO 15118-2:2014, Vehicle-to-Grid Communication Interface, Part 2: Network and application protocol requirements. https://www.iso.org/standard/55366.html. Checked 09 Oct 2026.
  2. Open Charge Alliance: Using ISO 15118 Plug & Charge with OCPP 1.6, application note v1.0, 2020. https://openchargealliance.org/wp-content/uploads/2025/05/ocpp_1_6_ISO_15118_v10-3.pdf. Checked 09 Oct 2026. Licence: CC BY-ND 4.0.
  3. ISO: ISO 15118-2:2014, Vehicle-to-Grid Communication Interface, Part 2: Network and application protocol requirements. https://www.iso.org/standard/55366.html. Checked 09 Oct 2026.
  4. Open Charge Alliance: Using ISO 15118 Plug & Charge with OCPP 1.6, application note v1.0, 2020. https://openchargealliance.org/wp-content/uploads/2025/05/ocpp_1_6_ISO_15118_v10-3.pdf. Checked 09 Oct 2026. Licence: CC BY-ND 4.0.
  5. CharIN e.V.: Position paper: Certificate policy for the ISO 15118 V2G PKI, 6 August 2020 (validity periods of V2G certificates). https://www.charin.global/media/pages/technology/knowledge-base/78d6267a93-1615552579/charin_cp_for_iso_15118_v2g_pki.pdf. Checked 11 Oct 2026.
  6. Benelux IDRO: E-mobility ID-codes: the purpose of IDs, ID usage and ID format, November 2023, with Annex 1 on the contract ID check digit. https://benelux-idro.eu/sites/default/files/2024-03/IDRR-Emobility%20ID%20Format%20and%20Syntax_November%202023.pdf. Checked 11 Oct 2026.
  7. CharIN: Plug & Charge at CharIN: standardised and interoperable. https://www.charin.global/technology/plug-charge/. Checked 09 Oct 2026.
Was this helpful?