OCPP 2.0.1 Edition 4 Section A

Security Flows - CSMS Developer Guide

Based on OCPP 2.0.1 Edition 4 Specification (Part 2), Section A (pages 16–42). This guide covers all security flows (A01–A05) from the CSMS (Charging Station Management System) perspective.

8 Sections

5 Security Flows

A01 - A05

1. Overview

Introduction

Section A specifies the security mechanisms for OCPP 2.0.1 communication between the Charging Station (CS) and the CSMS. This covers credential management, certificate lifecycle, security event logging, and security profile upgrades.

A01 — Credential Management

The CSMS updates the HTTP Basic Authentication password on a Charging Station.

A02 — Certificate Lifecycle (CSMS-initiated)

The CSMS triggers the Charging Station to renew its client-side TLS certificate.

A03 — Certificate Lifecycle (CS-initiated)

The Charging Station autonomously initiates a certificate renewal and the CSMS processes the CSR.

A04 — Security Event Logging

The Charging Station reports security-relevant events to the CSMS.

A05 — Security Profile Upgrade

The CSMS upgrades a Charging Station from a lower security profile to a higher one.

OCPP Message Direction Convention

Direction	Meaning
`CS → CSMS`	Charging Station sends a CALL (request) to the CSMS
`CSMS → CS`	CSMS sends a CALL (request) to the Charging Station

A01, A02, A05 are CSMS-initiated — the CSMS starts the flow by sending a request to the Charging Station.
A03 is CS-initiated — the Charging Station sends a SignCertificateRequest to the CSMS (possibly triggered by CSMS via A02, or autonomously when its certificate is about to expire).
A04 is CS-initiated — the Charging Station sends a SecurityEventNotificationRequest to the CSMS.

Messages Used in Security Flows

Message	Direction	Used In
`SetVariablesRequest / SetVariablesResponse`	CSMS → CS	`A01, A05`
`TriggerMessageRequest / TriggerMessageResponse`	CSMS → CS	`A02`
`SignCertificateRequest / SignCertificateResponse`	CS → CSMS	`A02, A03`
`CertificateSignedRequest / CertificateSignedResponse`	CSMS → CS	`A02, A03`
`SecurityEventNotificationRequest / SecurityEventNotificationResponse`	CS → CSMS	`A04`
`InstallCertificateRequest / InstallCertificateResponse`	CSMS → CS	`A05`

2. Security Profiles Background

Configuration

OCPP 2.0.1 defines three security profiles. The CSMS must know which profile is in use per Charging Station because it determines authentication mechanisms and TLS requirements.

Profile	No.	CS Authentication	CSMS Authentication	Communication Security
Unsecured Transport with Basic Authentication	1	HTTP Basic Auth (username/password)	None	None
TLS with Basic Authentication	2	HTTP Basic Auth (username/password)	TLS server certificate	TLS
TLS with Client Side Certificates	3	TLS client certificate	TLS server certificate	TLS

Profile 1 — Unsecured Transport with Basic Authentication

Validate that the CS identity (from WebSocket URL path) and the Basic Auth password match the Authorization header in the HTTP upgrade request (A00.FR.207).

Warning: Only use on trusted networks (e.g., VPN). No transport-level encryption.

Profile 2 — TLS with Basic Authentication

Act as TLS server (A00.FR.306). Present CSMS certificate as server-side certificate (A00.FR.307).
Validate Basic Auth credentials: CS identity + password from Authorization header (A00.FR.324).
Support TLS v1.2+ only (A00.FR.313). Terminate connection on older TLS/SSL (A00.FR.315).
Do NOT use TLS compression (A00.FR.321). Terminate if CS only supports deprecated cipher suites (A00.FR.322).

Required cipher suites (A00.FR.318):

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384

Profile 3 — TLS with Client Side Certificates

Act as TLS server (A00.FR.409). Present CSMS certificate (A00.FR.410).
Verify the CS's client certificate certification path (A00.FR.403, RFC 5280 Section 6).
Verify certificate ownership: O (organizationName) RDN must contain the CSO name (A00.FR.404).
Verify certificate identity: CN (commonName) RDN must contain the unique serial number of the Charging Station (A00.FR.405).
Log InvalidChargingStationCertificate security event when rejecting (A00.FR.408).
Same TLS version and cipher suite requirements as Profile 2 (A00.FR.416–A00.FR.426).

Exception (A00.FR.429): If the CS certificate has expired AND the CSMS is explicitly configured to accept expired certificates from this specific CS, the CSMS MAY accept the CS in a Pending boot state and immediately execute A02 to renew the certificate.

CSMS Certificate Requirements

Req ID	Requirement
`A00.FR.510`	Subject CN must match the CSMS server's FQDN
`A00.FR.509`	Subject O must contain the organization name
`A00.FR.507`	All certificates in X.509 format, PEM encoded
`A00.FR.502`	RSA keys ≥ 2048 bits
`A00.FR.503`	EC keys ≥ 224 bits
`A00.FR.506`	SHA256 for hash values
`A00.FR.505`	RSA-PSS or ECDSA for signing
`A00.FR.701`	Use fast expiration for CSMS certificate (< 24 hours recommended)
`A00.FR.702`	Use online verification (OCSP) for Charging Station certificates
`A00.FR.705`	Verify CS certificate validity with Certificate Authority server

Basic Auth Credential Format (Profiles 1 & 2)

The WebSocket upgrade request includes the Authorization header:

Authorization: Basic <Base64(ChargePointId:AuthorizationKey)>

Username

Charging Station identity (the identifying string from the OCPP-J connection URL). Must NOT contain : (A00.FR.204).

Password

Value of BasicAuthPassword configuration variable. Sent as UTF-8 string (A00.FR.205). Min 16 chars, max at least 40, at most 64 chars.

3. A01 — Update Charging Station Password for HTTP Basic Authentication

CSMS-Initiated

The CSMS updates the BasicAuthPassword on a Charging Station by sending a SetVariablesRequest. After the CS accepts the new password, it disconnects and reconnects using the new credentials.

Applicable to: Security Profile 1 (Unsecured Transport with Basic Auth) and Profile 2 (TLS with Basic Auth).

Flow Sequence

Sequence Diagram (CSMS perspective)

CSMS                                           Charging Station
  |                                                   |
  |  SetVariablesRequest(BasicAuthPassword)           |
  |  [ComponentName=SecurityCtrlr,                    |
  |   VariableName=BasicAuthPassword,                 |
  |   attributeValue=<new_password>]           -----> |
  |                                                   |
  |  SetVariablesResponse                             |
  |  [attributeStatus=Accepted]               <------ |
  |                                                   |
  |                                 [CS disconnects]  |
  |                                                   |
  |  [CS reconnects with new password]        <------ |
  |                                                   |

Step 1: Send SetVariablesRequest

The CSMS sends a SetVariablesRequest with: component.name = "SecurityCtrlr", variable.name = "BasicAuthPassword", and the new password string as attributeValue.

Step 2: Handle SetVariablesResponse

Response attributeStatus	CSMS Action
`Accepted`	Password change successful. CSMS SHALL update stored credentials. SHALL no longer accept old password (A01.FR.03).
`Rejected / UnknownComponent / UnknownVariable / NotSupportedAttributeType`	Password NOT changed. CSMS SHALL keep accepting old credentials (A01.FR.04). Optionally restrict CS functionality.
`RebootRequired`	Variable accepted but requires a reboot. Wait for CS to reboot and reconnect with new password.

Step 3: Await Reconnection

After Accepted, the CS will disconnect and reconnect using the new password. The CSMS must be ready to accept the new credentials on the next connection attempt.

SetVariablesRequest (CSMS sends)

// OCPP CALL: [2, "<messageId>", "SetVariables", { ... }]
{
  "setVariableData": [
    {
      "component": {
        "name": "SecurityCtrlr"
      },
      "variable": {
        "name": "BasicAuthPassword"
      },
      "attributeValue": "<new_password>",
      "attributeType": "Actual"
    }
  ]
}

SetVariablesResponse (CS responds)

// OCPP CALLRESULT: [3, "<messageId>", { ... }]
{
  "setVariableResult": [
    {
      "component": { "name": "SecurityCtrlr" },
      "variable": { "name": "BasicAuthPassword" },
      "attributeStatus": "Accepted",
      "attributeType": "Actual",
      "attributeStatusInfo": {
        "reasonCode": "...",
        "additionalInfo": "..."
      }
    }
  ]
}

CSMS Implementation Requirements

Req ID	Requirement
`A01.FR.02`	To set a CS's BasicAuthPassword, the CSMS SHALL send a SetVariablesRequest with the BasicAuthPassword Configuration Variable.
`A01.FR.03`	On Accepted response, the CSMS SHALL assume the password change was successful and no longer accept the old credentials.
`A01.FR.04`	On non-Accepted response, the CSMS SHALL assume the password has NOT changed and keep accepting old credentials.
`A01.FR.05`	On failure, the CSMS MAY restrict functionality (e.g., BootNotification Pending state) to retry updating credentials.
`A01.FR.06`	Different passwords SHOULD be used for different Charging Stations.
`A01.FR.07`	Passwords SHOULD be generated randomly with sufficient entropy.
`A01.FR.08`	The CSMS SHOULD only store salted password hashes, not the passwords themselves.
`A01.FR.09`	The CSMS SHOULD NOT put passwords in clear-text in log files or debug information.

Error Scenarios

Scenario	CSMS Behavior
CS responds with Rejected	Keep old password. Optionally put CS into Pending state to retry later.
CS responds with UnknownComponent or UnknownVariable	CS does not support SecurityCtrlr.BasicAuthPassword. This CS may not support password changes via OCPP.
No response (timeout)	Assume password NOT changed. Keep old credentials. Retry later.
CS disconnects but never reconnects with new password	Keep both old and new password valid for a grace period, then escalate.

4. A02 — Update Charging Station Certificate by Request of CSMS

CSMS-Initiated

The CSMS initiates a certificate renewal for the Charging Station's client-side TLS certificate. This is a multi-step flow involving the CSMS, the CS, and an external Certificate Authority (CA) server.

SignChargingStationCertificate

Renew the OCPP connection certificate (CS ↔ CSMS)

SignV2GCertificate

Renew the ISO 15118 SECC certificate (CS ↔ EV)

Applicable to: Security Profile 3 (TLS with Client Side Certificates). Also used when upgrading from Profile 2 to Profile 3.

Sequence — SignChargingStationCertificate

Sequence Diagram (CSMS perspective)

CSMS                          Charging Station              Certificate Authority
  |                                  |                              |
  |  TriggerMessageRequest           |                              |
  |  [requestedMessage=              |                              |
  |   SignChargingStation            |                              |
  |   Certificate]            -----> |                              |
  |                                  |                              |
  |  TriggerMessageResponse          |                              |
  |  [status=Accepted]       <------ |                              |
  |                                  |                              |
  |                    [CS generates new key pair]                  |
  |                                  |                              |
  |  SignCertificateRequest          |                              |
  |  [csr=<PEM-encoded CSR>,         |                              |
  |   certificateType=               |                              |
  |   ChargingStationCertificate]    |                              |
  |                          <------ |                              |
  |                                  |                              |
  |  SignCertificateResponse         |                              |
  |  [status=Accepted]        -----> |                              |
  |                                  |                              |
  |  [Forward CSR to CA]     ---------------------------------->    |
  |                                  |                              |
  |  [CA signs certificate]  <----------------------------------    |
  |                                  |                              |
  |  CertificateSignedRequest        |                              |
  |  [certificateChain=<PEM>,        |                              |
  |   certificateType=               |                              |
  |   ChargingStationCertificate]    |                              |
  |                           -----> |                              |
  |                                  |                              |
  |  CertificateSignedResponse       |                              |
  |  [status=Accepted]       <------ |                              |
  |                                  |                              |

Sequence — SignV2GCertificate

Prerequisite: For SignV2GCertificate, the variable ISO15118CtrlrSeccId must be set. The CSMS first queries GetReportRequest for component ISO15118Ctrlr variable SeccId to discover SECC IDs.

Sequence Diagram — Per-EVSE V2G Certificate

CSMS                          Charging Station              Certificate Authority
  |                                  |                              |
  |  [1. GetReportRequest for        |                              |
  |   ISO15118Ctrlr.SeccId]  ----->  |                              |
  |                                  |                              |
  |  [NotifyReportResponse with      |                              |
  |   unique SeccId values]  <------ |                              |
  |                                  |                              |
  |  [2. For each unique SeccId:]    |                              |
  |                                  |                              |
  |  TriggerMessageRequest           |                              |
  |  [requestedMessage=              |                              |
  |   SignV2GCertificate,            |                              |
  |   evse={id:evseId}]    ----->    |                              |
  |                                  |                              |
  |  TriggerMessageResponse          |                              |
  |  [status=Accepted]       <------ |                              |
  |                                  |                              |
  |  SignCertificateRequest          |                              |
  |  [csr=<PEM CSR>,                 |                              |
  |   certificateType=               |                              |
  |   V2GCertificate]                |                              |
  |                          <------ |                              |
  |                                  |                              |
  |  [Same as above: sign & deliver] |                              |
  |  ...                             |                              |

CSMS Actions — Step by Step

Step 1: Send TriggerMessageRequest

{
  "requestedMessage": "SignChargingStationCertificate"
  // OR "SignV2GCertificate" (with optional "evse" for per-EVSE V2G certs)
}

Step 2: Handle TriggerMessageResponse

Response status	CSMS Action
`Accepted`	Wait for the CS to send a SignCertificateRequest.
`Rejected`	CS cannot process the trigger. Retry later or investigate.
`NotImplemented`	CS does not support this trigger message type.

Step 3: Receive SignCertificateRequest (CS → CSMS)

The CS sends a CSR (Certificate Signing Request) in PEM format.

Field	Type	Required	Description
`csr`	string (max 5500)	Required	PEM-encoded PKCS#10 CSR (RFC 2986)
`certificateType`	enum	Optional	ChargingStationCertificate or V2GCertificate. When omitted, the certificate is for both 15118 and OCPP connection.

Step 4: Respond with SignCertificateResponse

{
  "status": "Accepted"   // or "Rejected"
}

Step 5: Forward CSR to Certificate Authority

This is an out-of-band operation between the CSMS and the CA. The CSMS forwards the CSR to the CA, the CA signs the certificate, and returns the signed certificate (+ optional intermediate CA certs) to the CSMS.

Step 6: Send CertificateSignedRequest to CS

{
  "certificateChain": "<PEM-encoded signed certificate + sub-CA chain>",
  "certificateType": "ChargingStationCertificate"  // or "V2GCertificate"
}

Order: leaf certificate first, followed by intermediate CAs. Max size configurable via MaxCertificateChainSize.

Step 7: Handle CertificateSignedResponse

Response status	CSMS Action
`Accepted`	Certificate successfully installed on the CS. The CS will use the new certificate on its next TLS connection.
`Rejected`	Certificate installation failed. The CS discarded the new certificate. Investigate and potentially re-run A02.

CSMS Implementation Requirements

Req ID	Requirement
`A02.FR.01`	The CSMS SHALL send a TriggerMessageRequest with requestedMessage set to SignChargingStationCertificate to request the CS to update its certificate.
`A02.FR.02`	Upon receiving SignCertificateRequest, the CSMS SHALL respond with SignCertificateResponse with status Accepted (if it can process the CSR).
`A02.FR.03`	The CSMS SHALL forward the CSR to the Certificate Authority.
`A02.FR.04`	After the CA signs the certificate, the CSMS SHALL send CertificateSignedRequest containing the signed certificate chain.
`A02.FR.05`	The CSMS SHALL include intermediate CA certificates in the certificateChain when needed for path validation.
`A02.FR.07`	If the CA is unreachable or the CSR is rejected by the CA, the CSMS SHALL notify the CSO operator to investigate.

Error Handling

Scenario	CSMS Behavior
TriggerMessageResponse = Rejected or NotImplemented	CS cannot generate a CSR for this message type. Log and alert operator.
SignCertificateRequest never received (timeout)	CS failed to generate key pair or CSR. Retry TriggerMessageRequest.
CA is unreachable	Cannot sign certificate. Notify operator. CS continues with current certificate. Re-run A02 when resolved.
CA rejects the CSR	Notify operator. CS CSR may be malformed. Investigate.
CertificateSignedResponse = Rejected	CS rejected the signed certificate. Investigate and re-run A02.

5. A03 — Update Charging Station Certificate Initiated by the Charging Station

CS-Initiated

The Charging Station autonomously initiates a certificate renewal — typically when its current certificate is about to expire. The CSMS receives the CSR, forwards it to the CA, and delivers the signed certificate back. The message flow from Step 3 onward is identical to A02.

Applicable to: Security Profile 3 (TLS with Client Side Certificates). The standard configuration variable "OrganizationName" MUST be set on the CS.

Flow Sequence

Sequence Diagram (CSMS perspective)

CSMS                          Charging Station              Certificate Authority
  |                                  |                              |
  |                   [CS cert nearing expiry]                      |
  |                   [CS generates new key pair]                   |
  |                                  |                              |
  |  SignCertificateRequest          |                              |
  |  [csr=<PEM-encoded CSR>,         |                              |
  |   certificateType=               |                              |
  |   ChargingStationCertificate]    |                              |
  |                          <------ |                              |
  |                                  |                              |
  |  SignCertificateResponse         |                              |
  |  [status=Accepted]        -----> |                              |
  |                                  |                              |
  |  [Forward CSR to CA]     ---------------------------------->    |
  |                                  |                              |
  |  [CA signs certificate]  <----------------------------------    |
  |                                  |                              |
  |  CertificateSignedRequest        |                              |
  |  [certificateChain=<PEM>,        |                              |
  |   certificateType=               |                              |
  |   ChargingStationCertificate]    |                              |
  |                           -----> |                              |
  |                                  |                              |
  |  CertificateSignedResponse       |                              |
  |  [status=Accepted]       <------ |                              |
  |                                  |                              |

Step 1: Receive SignCertificateRequest (CS → CSMS)

The CS sends a CSR without any prior trigger from the CSMS.

{
  "csr": "<PEM-encoded PKCS#10 CSR>",        // REQUIRED, max 5500 chars
  "certificateType": "ChargingStationCertificate"  // optional
}

Step 2: Respond with SignCertificateResponse

Respond Accepted if the CSMS can process and forward the CSR. Respond Rejected if the CSMS cannot process it (e.g., unknown CS, or the CSMS does not support this flow).

{
  "status": "Accepted"   // or "Rejected"
}

Steps 3–5: Same as A02

Forward CSR to CA, receive signed certificate, send CertificateSignedRequest to CS, and handle CertificateSignedResponse — same as A02 Steps 5–7.

CSMS Implementation Requirements

Req ID	Requirement
`A03.FR.01`	Upon receiving a SignCertificateRequest from a CS, the CSMS SHALL respond with SignCertificateResponse.
`A03.FR.02`	The CSMS SHALL forward the CSR to the Certificate Authority for signing.
`A03.FR.03`	After the CA returns the signed certificate, the CSMS SHALL send CertificateSignedRequest with the certificate chain.
`A03.FR.07`	If the CA cannot be reached or rejects the CSR, the CSMS SHALL notify the CSO operator.

A02 vs A03 Comparison

Aspect	A02	A03
Who initiates	CSMS (via TriggerMessageRequest)	Charging Station (autonomously)
First message	CSMS → CS: TriggerMessageRequest	CS → CSMS: SignCertificateRequest
Remaining flow	Identical from SignCertificateRequest onward	Same
Use case	Proactive renewal by operator	CS detects its certificate is expiring

6. A04 — Security Event Notification

CS-Initiated

The Charging Station reports security-relevant events to the CSMS. The CSMS receives, logs, and optionally acts upon these events.

Applicable to: All security profiles.

Flow Sequence

Sequence Diagram (CSMS perspective)

CSMS                                           Charging Station
  |                                                  |
  |                         [security event occurs]  |
  |                                                  |
  |  SecurityEventNotificationRequest                |
  |  [type=<event_type>,                             |
  |   timestamp=<ISO8601>,                           |
  |   techInfo=<optional_details>]           <------ |
  |                                                  |
  |  SecurityEventNotificationResponse               |
  |  [empty body]                             -----> |
  |                                                  |

Step 1: Receive SecurityEventNotificationRequest (CS → CSMS)

Field	Type	Required	Description
`type`	string (max 50)	Required	Security event type identifier.
`timestamp`	dateTime (RFC 3339)	Required	When the event occurred.
`techInfo`	string (max 255)	Optional	Additional technical details about the event.

Step 2: Respond with SecurityEventNotificationResponse

The response has an empty body. Simply acknowledge receipt:

SecurityEventNotificationRequest (CS sends)

// OCPP CALL: [2, "<messageId>", "SecurityEventNotification", { ... }]
{
  "type": "TamperDetectionActivated",
  "timestamp": "2025-01-15T10:30:00Z",
  "techInfo": "Enclosure opened"
}

SecurityEventNotificationResponse (CSMS responds)

// OCPP CALLRESULT: [3, "<messageId>", {}]
{}

Step 3: Log and Process the Event

Log the event persistently with the CS identity, event type, timestamp, and techInfo.
Evaluate criticality — some events are critical and require immediate action.
Alert operators for critical security events.

Security Event Types

Event Type	Critical	Description	CSMS Action
`FirmwareUpdated`	No	New firmware was successfully installed	Log. Verify firmware version matches expected update.
`FailedToAuthenticateAtCsms`	No	CS failed to authenticate with the CSMS	Log. Check if CSMS credentials/certificates are correctly configured.
`CsmsFailedToAuthenticate`	No	CS could not verify the CSMS's identity	Log. Check CSMS certificate validity.
`SettingSystemTime`	No	CS system time was set/changed	Log. Verify time is correct (important for certificate validation).
`StartupOfTheDevice`	No	CS has started/rebooted	Log.
`ResetOrReboot`	No	CS was reset or rebooted	Log.
`SecurityLogWasCleared`	No	The security log on the CS was cleared	Log. Investigate if unexpected.
`ReconfigurationOfSecurityParameters`	No	Security configuration was changed	Log. Verify change was authorized.
`MemoryExhaustion`	No	CS running low on memory	Log. May affect CS stability.
`InvalidMessages`	No	CS received invalid OCPP messages	Log. May indicate protocol issues or attack attempts.
`AttemptedReplayAttacks`	No	CS detected a potential replay attack	Log and alert. Investigate source.
`TamperDetectionActivated`	Critical	Physical tampering detected	Alert immediately. Investigate physical security.
`InvalidFirmwareSignature`	Critical	Firmware signature validation failed	Alert immediately. Potential supply chain attack. Do NOT allow the firmware to be used.
`InvalidFirmwareSigningCertificate`	Critical	Firmware signing certificate is invalid	Alert immediately. Potential compromised signing chain.
`InvalidCsmsCertificate`	Critical	CS detected an invalid CSMS certificate	Alert immediately. Check CSMS certificate. May indicate MITM attack.
`InvalidChargingStationCertificate`	Critical	CS certificate is invalid	Alert immediately. Renew CS certificate via A02.
`InvalidTLSVersion`	Critical	TLS version mismatch detected	Alert immediately. Upgrade TLS configuration.
`InvalidTLSCipherSuite`	Critical	Unsupported/deprecated cipher suite detected	Alert immediately. Update cipher suite configuration.

CSMS Implementation Requirements

Req ID	Requirement
`A04.FR.01`	The CSMS SHALL respond with SecurityEventNotificationResponse to acknowledge receipt.
`A04.FR.02`	The CSMS SHALL log all security events with full context (CS identity, type, timestamp, techInfo).
`A04.FR.03`	For critical security events, the CSMS SHOULD alert operators immediately.
`A04.FR.04`	The CSMS SHOULD have an automated system to detect patterns of security events (e.g., repeated InvalidMessages may indicate an attack).

7. A05 — Upgrade Charging Station Security Profile

CSMS-Initiated

The CSMS upgrades a Charging Station from a lower security profile to a higher one (e.g., Profile 1 → 2, Profile 2 → 3, or Profile 1 → 3). This involves installing certificates and/or setting network connection parameters.

Note: Downgrading is generally NOT allowed. The CS SHALL only allow downgrade from Profile 3 to Profile 2 if AllowSecurityProfileDowngrade is set to true. Downgrade from Profile 2 or 3 to Profile 1 is never allowed via OCPP (A00.FR.005).

Sequence — Upgrade from Profile 1 to Profile 2

Sequence Diagram (CSMS perspective)

CSMS                                           Charging Station
  |                                                  |
  |  [1. Install CSMS root certificate]              |
  |  InstallCertificateRequest                       |
  |  [certificateType=CSMSRootCertificate,           |
  |   certificate=<PEM>]                      -----> |
  |                                                  |
  |  InstallCertificateResponse                      |
  |  [status=Accepted]                       <------ |
  |                                                  |
  |  [2. Set new security profile in                 |
  |   NetworkConnectionProfile]                      |
  |  SetVariablesRequest                             |
  |  [SecurityProfile=2]                      -----> |
  |                                                  |
  |  SetVariablesResponse                            |
  |  [status=Accepted]                       <------ |
  |                                                  |
  |                            [CS disconnects]      |
  |                                                  |
  |  [CS reconnects with TLS + Basic Auth]   <------ |
  |                                                  |

Sequence — Upgrade from Profile 2 to Profile 3

Sequence Diagram (CSMS perspective)

CSMS                                           Charging Station
  |                                                  |
  |  [1. Trigger CS to generate certificate]         |
  |  TriggerMessageRequest                           |
  |  [requestedMessage=                              |
  |   SignChargingStationCertificate]         -----> |
  |                                                  |
  |  TriggerMessageResponse [Accepted]       <------ |
  |                                                  |
  |  [2-6. Complete A02 certificate signing flow]    |
  |  (see A02 above for full sequence)               |
  |                                                  |
  |  [7. Set new security profile]                   |
  |  SetVariablesRequest                             |
  |  [SecurityProfile=3]                      -----> |
  |                                                  |
  |  SetVariablesResponse                            |
  |  [status=Accepted]                       <------ |
  |                                                  |
  |                            [CS disconnects]      |
  |                                                  |
  |  [CS reconnects with TLS +                       |
  |   Client Side Certificate]               <------ |
  |                                                  |

Sequence — Upgrade from Profile 1 to Profile 3

This combines both upgrade paths. The CSMS must:

Install CSMS root certificate (InstallCertificateRequest)
Execute A02 (trigger certificate signing flow) to give the CS a client certificate
Set SecurityProfile to 3 via SetVariablesRequest

CSMS Actions — Step by Step

Step 1: Install CSMS Root Certificate (for Profile 1 → 2 or 1 → 3)

If upgrading from Profile 1 (no TLS), the CS needs the CSMS root CA certificate to validate the CSMS's server certificate.

InstallCertificateRequest (CSMS sends)

// OCPP CALL: [2, "<messageId>", "InstallCertificate", { ... }]
{
  "certificateType": "CSMSRootCertificate",
  "certificate": "-----BEGIN CERTIFICATE-----\nMIID...base64...==\n-----END CERTIFICATE-----"
}

InstallCertificateResponse (CS responds)

// OCPP CALLRESULT: [3, "<messageId>", { ... }]
{
  "status": "Accepted",
  "statusInfo": {
    "reasonCode": "...",
    "additionalInfo": "..."
  }
}

Response status	CSMS Action
`Accepted`	Root certificate installed. Proceed to next step.
`Rejected`	CS rejected the certificate. Investigate (e.g., wrong format, storage full).
`Failed`	Installation failed. Retry or investigate.

Step 2: Execute A02 Certificate Signing (for upgrade to Profile 3)

If the target profile is 3, the CS needs a client-side certificate. Run the full A02 flow: send TriggerMessageRequest, receive SignCertificateRequest, forward to CA, send CertificateSignedRequest, verify response is Accepted.

Step 3: Update Security Profile

SetVariablesRequest — Update SecurityProfile

{
  "setVariableData": [
    {
      "component": {
        "name": "SecurityCtrlr"
      },
      "variable": {
        "name": "SecurityProfile"
      },
      "attributeValue": "2"    // or "3"
    }
  ]
}

Step 4: Handle Reconnection

After the CS accepts the new security profile, it will disconnect and reconnect using the new security profile settings. The CSMS must be ready to accept the connection on the appropriate port/endpoint:

Profile 2

TLS + Basic Auth

Profile 3

TLS + Client Certificate

CSMS Implementation Requirements

Req ID	Requirement
`A05.FR.01`	Before upgrading the security profile, the CSMS SHALL ensure all necessary certificates are installed on the CS.
`A05.FR.02`	For upgrade to Profile 2, the CSMS SHALL install the CSMS root certificate via InstallCertificateRequest before setting the new profile.
`A05.FR.03`	For upgrade to Profile 3, the CSMS SHALL execute A02 to provision a client certificate before setting the new profile.
`A05.FR.04`	The CSMS SHALL send SetVariablesRequest with the new SecurityProfile value as the last step.
`A05.FR.05`	The CSMS MAY operate different ports for different security profiles (A00.FR.006).
`A05.FR.06`	If the CS responds with Rejected to the SetVariablesRequest for SecurityProfile, the CSMS SHALL keep the current security profile.
`A05.FR.07`	If the CS disconnects but fails to reconnect on the new profile, the CSMS SHOULD still accept connections on the old profile as a fallback for a configurable grace period.

Error Scenarios

Scenario	CSMS Behavior
InstallCertificateResponse = Rejected or Failed	Cannot proceed with upgrade. Fix certificate issue first.
CS does not reconnect after profile change	Keep old profile port/endpoint available. Alert operator after timeout.
CS reconnects but on old profile	The CSMS SHALL terminate the connection if the CS connects with a different profile than the CSMS is using (A00.FR.002).

8. Message Schema Reference

Protocol

8.1 SetVariablesRequest (CSMS → CS)

Used in A01 to update the BasicAuthPassword and in A05 to update the SecurityProfile.

CSMS --> Charging Station

SetVariablesRequest

{
  "setVariableData": [
    {
      "attributeType": "Actual | Target | MinSet | MaxSet",
      "attributeValue": "string (max 1000)",
      "component": {
        "name": "string (max 50)",
        "instance": "string (max 50, optional)",
        "evse": {
          "id": "integer",
          "connectorId": "integer (optional)"
        }
      },
      "variable": {
        "name": "string (max 50)",
        "instance": "string (max 50, optional)"
      }
    }
  ]
}
// Required: setVariableData (array, minItems 1)
// Per item: attributeValue, component.name, variable.name

SetVariablesResponse

{
  "setVariableResult": [
    {
      "attributeType": "Actual | Target | MinSet | MaxSet",
      "attributeStatus": "Accepted | Rejected | UnknownComponent
                        | UnknownVariable
                        | NotSupportedAttributeType | RebootRequired",
      "attributeStatusInfo": {
        "reasonCode": "string (max 20)",
        "additionalInfo": "string (max 512, optional)"
      },
      "component": { "name": "string (max 50)" },
      "variable": { "name": "string (max 50)" }
    }
  ]
}
// Required: setVariableResult (array, minItems 1)
// Per item: attributeStatus, component.name, variable.name

8.2 TriggerMessageRequest (CSMS → CS)

Used in A02 to request the CS to generate a CSR, and in A05 to trigger certificate generation before a profile upgrade.

CSMS --> Charging Station

TriggerMessageRequest

{
  "requestedMessage":
    "BootNotification | LogStatusNotification
    | FirmwareStatusNotification | Heartbeat
    | MeterValues | SignChargingStationCertificate
    | SignV2GCertificate | StatusNotification
    | TransactionEvent | SignCombinedCertificate
    | PublishFirmwareStatusNotification",
  "evse": {
    "id": "integer",
    "connectorId": "integer (optional)"
  }
}
// Required: requestedMessage
// evse: optional, used for per-EVSE V2G certificate triggers

TriggerMessageResponse

{
  "status": "Accepted | Rejected | NotImplemented",
  "statusInfo": {
    "reasonCode": "string (max 20)",
    "additionalInfo": "string (max 512, optional)"
  }
}
// Required: status

8.3 SignCertificateRequest (CS → CSMS)

Sent by the CS in A02 (after TriggerMessage) and A03 (autonomously). Contains the Certificate Signing Request (CSR) for the CSMS to forward to the CA.

Charging Station --> CSMS

SignCertificateRequest

{
  "csr": "string (max 5500, PEM-encoded CSR)",
  "certificateType":
    "ChargingStationCertificate | V2GCertificate"
}
// Required: csr
// certificateType: optional — when omitted, cert is for
// both 15118 and OCPP connection

SignCertificateResponse

{
  "status": "Accepted | Rejected",
  "statusInfo": {
    "reasonCode": "string (max 20)",
    "additionalInfo": "string (max 512, optional)"
  }
}
// Required: status

8.4 CertificateSignedRequest (CSMS → CS)

Sent by the CSMS in both A02 and A03 after the CA signs the certificate. Delivers the signed certificate chain to the Charging Station.

CSMS --> Charging Station

CertificateSignedRequest

{
  "certificateChain":
    "string (max 10000, PEM-encoded certificate chain)",
  "certificateType":
    "ChargingStationCertificate | V2GCertificate"
}
// Required: certificateChain
// certificateType: required when the original
// SignCertificateRequest included a type AND both
// 15118 and OCPP connections are implemented

CertificateSignedResponse

{
  "status": "Accepted | Rejected",
  "statusInfo": {
    "reasonCode": "string (max 20)",
    "additionalInfo": "string (max 512, optional)"
  }
}
// Required: status

8.5 SecurityEventNotificationRequest (CS → CSMS)

Sent by the CS in A04 to report a security-relevant event.

Charging Station --> CSMS

SecurityEventNotificationRequest

{
  "type": "string (max 50)",
  "timestamp": "dateTime (RFC 3339)",
  "techInfo": "string (max 255, optional)"
}
// Required: type, timestamp

SecurityEventNotificationResponse

{}
// Empty object. No fields required.

8.6 InstallCertificateRequest (CSMS → CS)

Used in A05 to install the CSMS root certificate on a Charging Station before upgrading its security profile to Profile 2 or 3.

CSMS --> Charging Station

InstallCertificateRequest

{
  "certificateType":
    "V2GRootCertificate | MORootCertificate
    | CSMSRootCertificate
    | ManufacturerRootCertificate",
  "certificate":
    "string (max 5500, PEM-encoded X.509 certificate)"
}
// Required: certificateType, certificate

InstallCertificateResponse

{
  "status": "Accepted | Rejected | Failed",
  "statusInfo": {
    "reasonCode": "string (max 20)",
    "additionalInfo": "string (max 512, optional)"
  }
}
// Required: status