Migration Guide 2.0.1 → 2.1 Section M

Certificate Management — Migration Guide

Use cases M01–M07 and related security flows A02/A03. Covers all changes to the Certificate Management functional block between OCPP 2.0.1 (Edition 4) and OCPP 2.1 (Edition 2). Perspective: CSMS Developer.

14 Sections
7 Use Cases
M01 – M07 + A02/A03

Created by tzi.app — your guide to migrating from OCPP 2.0.1 to OCPP 2.1.

1. Summary of Changes

Area Change Type Description
M07 New use case Get Vehicle Certificate Chain Revocation Status (OCSP + CRL batch checking)
M01/M02 Enhanced ISO 15118-20 multi-contract support (maximumContractCertificateChains, prioritizedEMAIDs, remainingContracts)
M01/M02 Field length exiRequest max: 5600 → 11000; exiResponse max: 5600 → 17000
M03 Enum added OEMRootCertificate added to GetCertificateIdUseEnum
M04 New requirements Cannot delete CS certificate (FR.06); must match hash algorithm (FR.07); cascading child deletion (FR.08)
M05 Enum added OEMRootCertificate added to InstallCertificateUseEnum
M05 Field length certificate max: 5500 → 10000
M05 New requirements Detailed CSMS Root Certificate Rotation rules (FR.09–FR.17)
M06 Field lengths responderURL max: 512 → 2000; ocspResult max: 5500 → 18000
A02/A03 New fields hashRootCertificate and requestId added to SignCertificateRequest and CertificateSignedRequest
A02/A03 Enum added V2G20Certificate added to CertificateSigningUseEnum
Shared types Field length StatusInfoType.additionalInfo max: 512 → 1024
Config New variables Configurable field lengths via OCPPCommCtrlr.FieldLength, CertificateEntries.maxLimit, AdditionalRootCertificateCheck

2. New Use Case: M07 — Get Vehicle Certificate Chain Revocation Status

Entirely new in OCPP 2.1. Required by ISO 15118-20 during the TLS handshake. Allows the Charging Station to check the revocation status of multiple certificates in a chain in a single request, using either OCSP or CRL as the validation source.

New Messages

Message Direction
GetCertificateChainStatusRequest CS → CSMS
GetCertificateChainStatusResponse CSMS → CS

Key Differences from M06

Aspect M06 (GetCertificateStatus) M07 (GetCertificateChainStatus)
Certificates per request 1 Up to 4
Validation source OCSP only OCSP or CRL
Response format Raw OCSP result (Base64-encoded DER) Structured status (Good/Revoked/Unknown/Failed) + nextUpdate
Certificate target V2G Charging Station certificate chain Vehicle (EV) certificate chain

Request Structure

GetCertificateChainStatusRequest 
{
  "certificateStatusRequests": [
    {
      "certificateHashData": {
        "hashAlgorithm": "SHA256",
        "issuerNameHash": "...",
        "issuerKeyHash": "...",
        "serialNumber": "..."
      },
      "source": "OCSP",
      "urls": ["https://ocsp.responder.example.com"]
    },
    {
      "certificateHashData": { ... },
      "source": "CRL",
      "urls": ["https://crl.example.com/revoked.crl"]
    }
  ]
}

Response Structure

GetCertificateChainStatusResponse 
{
  "certificateStatus": [
    {
      "certificateHashData": { ... },
      "source": "OCSP",
      "status": "Good",
      "nextUpdate": "2025-02-01T12:00:00Z"
    },
    {
      "certificateHashData": { ... },
      "source": "CRL",
      "status": "Good",
      "nextUpdate": "2025-02-01T12:00:00Z"
    }
  ]
}

New Data Types

Type Fields
CertificateStatusRequestInfoType certificateHashData, source (CRL|OCSP), urls (array, max 5, maxLength 2000 each)
CertificateStatusType certificateHashData, source, status (Good|Revoked|Unknown|Failed), nextUpdate (ISO 8601)

CSMS Implementation Requirements

ID Requirement
M07.FR.01 For source = OCSP: CSMS SHALL perform OCSP request to one of the provided URLs.
M07.FR.02 If OCSP request fails: CSMS SHALL set status = Failed.
M07.FR.03 If OCSP request succeeds: CSMS SHALL use the OCSP status (Good/Revoked/Unknown).
M07.FR.04 For source = CRL: CSMS SHALL retrieve the CRL from one of the provided URLs.
M07.FR.05 If CRL download fails: CSMS SHALL set status = Failed.
M07.FR.06 If CRL downloaded and serial number IS in the CRL: set status = Revoked.
M07.FR.07 If CRL downloaded and serial number is NOT in the CRL: set status = Good.
M07.FR.08 CSMS SHALL respond with results for all requested certificates.

CSMS Action Required

  • Implement the GetCertificateChainStatusRequest handler.
  • Support both OCSP and CRL validation sources.
  • Implement caching (results may be cached for up to one week).
  • Support FTP URLs in addition to HTTP/HTTPS for CRL distribution points.

3. New Certificate Types

OCPP 2.1 adds two new certificate types to the type tables:

New Type Description Impact
OEMRootCertificate Root certificate from the car manufacturer (OEM). Used for PnC authentication. Added to GetCertificateIdUseEnum (M03) and InstallCertificateUseEnum (M05).
V2GIntermediateCertificate Intermediate certificates between V2GChargingStationCertificate and V2GRootCertificate. Documented in type tables and referenced in A02/A03 and M03/M04. Not a new enum value — was implicit in 2.0.1's V2GCertificateChain.

CSMS Action Required

  • Support OEMRootCertificate in GetInstalledCertificateIdsRequest (M03) when querying certificate types.
  • Support OEMRootCertificate in InstallCertificateRequest (M05) when installing certificates.
  • Update any local certificate inventory/storage to accommodate the new type.

4. M01/M02 — ISO 15118-20 Multi-Contract Support

New Fields in Get15118EVCertificateRequest

Field Type Required Description
maximumContractCertificateChains integer (≥ 0) Conditional ABSENT during ISO 15118-2. REQUIRED during ISO 15118-20. Maximum number of contract certificates the EV wants to install.
prioritizedEMAIDs array of string (max 8, maxLength 255) No ABSENT during ISO 15118-2. OPTIONAL during ISO 15118-20. EMAIDs for which contract certificates must be requested first.

New Field in Get15118EVCertificateResponse

Field Type Required Description
remainingContracts integer (≥ 0) Conditional Used for ISO 15118-20 multi-contract flow. Number of remaining contracts that can be retrieved with additional requests.

ISO 15118-20 Multi-Contract Flow

In OCPP 2.0.1, each Get15118EVCertificateRequest handled a single certificate. In OCPP 2.1 with ISO 15118-20:

  1. The CS sends a request with maximumContractCertificateChains indicating how many contracts the EV wants.
  2. The CSMS fetches all available contracts from the certificate pool(s).
  3. The CSMS returns the first contract in exiResponse and sets remainingContracts to totalAvailable - 1.
  4. The CS sends additional requests as long as remainingContracts > 0.
  5. Each subsequent response MUST decrease remainingContracts by 1 (M01.FR.07).

M02 — ISO 15118-20 Behavior Change: ISO 15118-20 does not differentiate between Install and Update. When the CS receives a CertificateUpdateReq from an EV using ISO 15118-20, it SHALL act according to M01 (req M02.FR.02), not M02.

Field Length Increases

Field 2.0.1 2.1 Configurable
exiRequest 5600 11000 Yes, via OCPPCommCtrlr.FieldLength
exiResponse 5600 17000 Yes, via OCPPCommCtrlr.FieldLength

CSMS Action Required

  • Add handling for maximumContractCertificateChains field — its presence signals an ISO 15118-20 session.
  • Implement the multi-contract flow: track remaining contracts across sequential requests and decrement remainingContracts per response.
  • Respect prioritizedEMAIDs ordering when fetching contracts from certificate pools.
  • Increase buffer/validation limits for exiRequest (11000) and exiResponse (17000).
  • For M02 with ISO 15118-20: route through M01 logic instead of separate update handling.

5. M03 — Retrieve Installed Certificates

Enum Change

GetCertificateIdUseEnum gains a new value:

2.0.1 Values 2.1 Addition
V2GRootCertificate, MORootCertificate, CSMSRootCertificate, V2GCertificateChain, ManufacturerRootCertificate OEMRootCertificate

CSMS Action Required

  • Accept and handle OEMRootCertificate in responses from GetInstalledCertificateIdsResponse.
  • Update any enum validation to include the new value.

6. M04 — Delete Certificate

New Requirements

ID Requirement Impact
M04.FR.06 If certificateHashData refers to the Charging Station Certificate itself, the CS SHALL respond status = Failed. CSMS must NOT attempt to delete the CS's own certificate via DeleteCertificateRequest.
M04.FR.07 CSMS SHALL use the same hashAlgorithm as the CS uses to report the certificate in M03 response. Always use the hash algorithm from the M03 response — do not substitute a different algorithm.
M04.FR.08 When the deleted certificate is a sub-CA or root, the CS MAY also delete all child certificates. CSMS should be aware that deleting a root/sub-CA may cascade-delete child certificates.

CSMS Action Required

  • Add a pre-check to prevent sending delete requests for the Charging Station Certificate.
  • Ensure hash algorithm consistency by storing and reusing the algorithm from M03 responses.
  • Account for potential cascading deletions when deleting root or sub-CA certificates — refresh the certificate inventory (M03) after deletion.

7. M05 — Install CA Certificate

Enum Change

InstallCertificateUseEnum gains a new value:

2.0.1 Values 2.1 Addition
V2GRootCertificate, MORootCertificate, CSMSRootCertificate, ManufacturerRootCertificate OEMRootCertificate

Field Length Increase

Field 2.0.1 2.1
certificate 5500 10000

New CSMS Root Certificate Rotation Requirements

OCPP 2.1 adds detailed requirements for rotating the CSMS Root Certificate when AdditionalRootCertificateCheck = true on the Charging Station.

ID Requirement
M05.FR.09 Only one CSMSRootCertificate (plus a temporary fallback) allowed at a time.
M05.FR.10 The new CSMS Root Certificate SHALL replace the old one AND MUST be signed by the old Root Certificate.
M05.FR.11 If the new cert is NOT signed by the old root → CS responds Rejected.
M05.FR.12 If the new cert IS signed by the old root → CS installs new, keeps old as fallback, responds Accepted.
M05.FR.13 After CS successfully reconnects using the new cert → CS removes the old (fallback) certificate.
M05.FR.14 If CS cannot verify CSMS server cert with new root → CS tries the old (fallback) root certificate.
M05.FR.17 If a certificate is already present in the trust store → CS SHALL replace it and respond Accepted.

CSMS Action Required

  • Support OEMRootCertificate as a valid certificate type.
  • Increase validation limits for certificate field to 10000 characters.
  • When rotating CSMS Root Certificates: ensure the new certificate is signed by the old root (cross-signed) to satisfy AdditionalRootCertificateCheck.
  • After installing a new CSMS Root Certificate, ensure the CSMS server certificate is signed by the new root before the CS attempts to reconnect.

8. M06 — Get Certificate Status

Field Length Increases

Field 2.0.1 2.1 Configurable
OCSPRequestDataType.responderURL 512 2000 No
GetCertificateStatusResponse.ocspResult 5500 18000 Yes, via OCPPCommCtrlr.FieldLength

New/Clarified Requirements

ID Requirement
M06.FR.07 After a CS certificate update, the CS SHALL refresh OCSP data for the new certificate and intermediates.
M06.FR.08 OCSP response SHALL be formatted per IETF RFC 6960 and ASN.1 [X.680].
M06.FR.09 OCSP response data SHALL be DER encoded.
M06.FR.10 CS SHOULD refresh cached OCSP data at least once a week.

CSMS Action Required

  • Increase buffer/validation limits for responderURL (2000) and ocspResult (18000).
  • Ensure OCSP responses are correctly formatted per RFC 6960 / ASN.1 and DER-encoded.

9. A02/A03 — Sign Certificate & Certificate Signed

New Fields in SignCertificateRequest

Field Type Required Description
hashRootCertificate CertificateHashDataType No Hash of the root certificate the new certificate should be signed by. Helps the CSMS select the correct CA.
requestId integer No Request ID to correlate with the subsequent CertificateSignedRequest.

New Field in CertificateSignedRequest

Field Type Required Description
requestId integer No Request ID to correlate with the originating SignCertificateRequest.

New Enum Value: V2G20Certificate

CertificateSigningUseEnum gains a new value:

2.0.1 Values 2.1 Addition
ChargingStationCertificate, V2GCertificate V2G20Certificate

This is used when the CSR is for an ISO 15118-20 specific certificate.

CSMS Action Required

  • When receiving SignCertificateRequest, use hashRootCertificate (if present) to select the correct Certificate Authority for signing.
  • Store the requestId from SignCertificateRequest and echo it back in the corresponding CertificateSignedRequest.
  • Support V2G20Certificate as a valid certificate type in both SignCertificateRequest and CertificateSignedRequest.

10. Field Length Changes

All field length changes at a glance:

Message / Field 2.0.1 2.1 Configurable
Get15118EVCertificateRequest.exiRequest 5600 11000 Yes
Get15118EVCertificateResponse.exiResponse 5600 17000 Yes
InstallCertificateRequest.certificate 5500 10000 No
OCSPRequestDataType.responderURL 512 2000 No
GetCertificateStatusResponse.ocspResult 5500 18000 Yes
StatusInfoType.additionalInfo 512 1024 No

CSMS Action Required

  • Update all validation rules, buffer sizes, and database column sizes to accommodate the increased limits.
  • Support configurable field lengths via OCPPCommCtrlr.FieldLength where applicable.

11. Shared Data Type Changes

StatusInfoType

Field 2.0.1 2.1
additionalInfo maxLength 512 1024

No structural changes — only the max length increased.

12. Enum Changes

New Enum Values Added to Existing Enums

Enum New Value(s) in 2.1
GetCertificateIdUseEnum OEMRootCertificate
InstallCertificateUseEnum OEMRootCertificate
CertificateSigningUseEnum V2G20Certificate

New Enums (for M07)

Enum Values Used In
CertificateStatusSourceEnum CRL, OCSP GetCertificateChainStatusRequest/Response
CertificateStatusEnum Good, Revoked, Unknown, Failed GetCertificateChainStatusResponse

13. New Configuration Variables

Variable Description Relevant To
OCPPCommCtrlr.FieldLength["Get15118EVCertificateRequest.exiRequest"] Max supported length for exiRequest if > 11000 M01, M02
OCPPCommCtrlr.FieldLength["Get15118EVCertificateResponse.exiResponse"] Max supported length for exiResponse if > 17000 M01, M02
OCPPCommCtrlr.FieldLength["GetCertificateStatusResponse.ocspResult"] Max supported length for ocspResult if > 18000 M06
MaxCertificateChainSize Limits the maximum size of certificateChain in CertificateSignedRequest A02, A03
CertificateEntries.maxLimit Maximum number of certificates that can be stored on the Charging Station M05
AdditionalRootCertificateCheck When true, new CSMS Root cert must be signed by old one M05

CSMS Action Required

  • Query these configuration variables (via GetVariablesRequest / GetReportRequest) before performing operations that depend on configurable limits.
  • Respect MaxCertificateChainSize when building CertificateSignedRequest.
  • Check CertificateEntries.maxLimit before attempting to install certificates to preempt Rejected responses.
  • Check AdditionalRootCertificateCheck before CSMS Root Certificate rotation to ensure the new cert is properly cross-signed.

14. CSMS Action Items Checklist

Must Implement (Breaking / New Functionality)

  • M07 handler: Implement GetCertificateChainStatusRequest handler with OCSP and CRL support.
  • ISO 15118-20 multi-contract flow: Handle maximumContractCertificateChains, prioritizedEMAIDs, and remainingContracts in M01/M02.
  • V2G20Certificate: Support in SignCertificateRequest and CertificateSignedRequest.
  • OEMRootCertificate: Support in M03 (GetInstalledCertificateIds) and M05 (InstallCertificate).
  • requestId correlation: Store requestId from SignCertificateRequest and echo back in CertificateSignedRequest.
  • hashRootCertificate: Use to select the correct CA when processing SignCertificateRequest.

Must Update (Field Lengths / Validation)

  • Increase exiRequest limit to 11000 (or configurable value).
  • Increase exiResponse limit to 17000 (or configurable value).
  • Increase certificate (InstallCertificateRequest) limit to 10000.
  • Increase responderURL limit to 2000.
  • Increase ocspResult limit to 18000 (or configurable value).
  • Increase StatusInfoType.additionalInfo limit to 1024.

Should Implement (Best Practices / Robustness)

  • M04 pre-check: Prevent deletion of the Charging Station Certificate.
  • M04 hash algorithm consistency: Always use the hash algorithm from M03 responses.
  • M04 cascade awareness: Refresh certificate inventory after deleting root/sub-CA certs.
  • M05 Root Rotation: Support AdditionalRootCertificateCheck logic for CSMS Root Certificate rotation.
  • Configuration variable queries: Read MaxCertificateChainSize, CertificateEntries.maxLimit, AdditionalRootCertificateCheck from Charging Stations before relevant operations.
  • CRL support: Implement CRL download and parsing (required for M07).
  • M07 caching: Cache certificate chain revocation status for up to one week.

OCPP 2.1 Certificate Management Migration Guide — Section M (Use Cases M01–M07) + Security Flows A02/A03 — CSMS Developer Perspective