Summary
#186 ships the inbound half of OCPP 1.6 Security Whitepaper §4.13 SignCertificate: the gateway accepts the charger's CSR, persists it to pending_certificate_signings, emits a cp.csr_submitted Kafka event, and replies Accepted.
This issue tracks the outbound half: actually signing the CSR and delivering the resulting cert chain back to the charger via CertificateSigned.req (Security Whitepaper §4.2).
Open questions
- Where is the signing authority?
- In-house backend service (existing CA infra)?
- AWS Private CA (or equivalent managed PCA)?
- Manual operator-driven queue with offline signing?
- Trust posture — do we auto-sign for known chargers, or always require operator approval?
- Cert lifetime / renewal cadence — what does the charger fleet need?
- Failure handling — CA outage, rejected CSR, expired pending requests.
Scope (when this lands)
- Operator-facing UI / API to review and approve / reject pending rows.
- Integration with the chosen signing backend.
- Outbound
CertificateSigned.req dispatch (proto + REST + gRPC surface; mirrors the existing SendLocalList / InstallCertificate outbound shape).
- Retry / replay semantics for charger-side delivery.
Until then
The pending_certificate_signings table accumulates rows. Operators can read them via direct DB query; chargers will see no CertificateSigned reply, which they treat as "request lost — retry later" per spec.
Refs #186.
Summary
#186 ships the inbound half of OCPP 1.6 Security Whitepaper §4.13 SignCertificate: the gateway accepts the charger's CSR, persists it to
pending_certificate_signings, emits acp.csr_submittedKafka event, and repliesAccepted.This issue tracks the outbound half: actually signing the CSR and delivering the resulting cert chain back to the charger via
CertificateSigned.req(Security Whitepaper §4.2).Open questions
Scope (when this lands)
CertificateSigned.reqdispatch (proto + REST + gRPC surface; mirrors the existingSendLocalList/InstallCertificateoutbound shape).Until then
The
pending_certificate_signingstable accumulates rows. Operators can read them via direct DB query; chargers will see noCertificateSignedreply, which they treat as "request lost — retry later" per spec.Refs #186.