The Hubject Plug&Charge PKI Services includes all necessary components of a PKI infrastructure with the following components:
- Certificate Manager
- Hardware Security Module (HSM)
- OCSP responder
- CRL distribution point
- Hubject MO CA
These components are setup for a QA and PROD environments.
Hubject also publishes a certificate policy (CP) on https://www.hubject.com/pki
These services provide interfaces to CPOs, MOs and OEMs for issuing/signing certificates and also request certificate statuses.
Hubject MO CA
The Hubject MO CA service is a part of Hubject Plug&Charge PKI Services and provides interfaces for MOs to manage their contract certificates without the need for any own PKI. This service creates certificates and performs all needed cryptographic operations for MOs with its own certificate software and hardware secure module (HSM).
Pool Management
The Hubject PKI Services are integrating with the PnC Ecosystem. Certificates are automatically managed in the certificate pools. This means the following actions are chained together:
- Creating a certificate makes it available in the pools automatically.
- Revoking a certificate removes it in regular checks from pools.
- Expired certificates will also be removed by regular batch jobs.
- Cleanup of CCP if the regarding Provisioning Certificate got removed from the PCP.
EST Interface
EST interface receives Certificate Signing Requests (CSRs) from CPOs, MOs or OEMs, signs them and delivers an ISO 15118 leaf certificate. The Hubject Certificate Manager creates the leaf certificates from Sub 2 CA of the respective part of the V2G Root CA.
This interface can create certificates for CPOs (EVSE leaf certificate), MOs (contract leaf certificate) and OEMs (OEM provisioning certificates)
A valid authentication to the Hubject PnC services is necessary to use this interface. EST interface is a standard implementation, which is described in the RFC7030.
Operations and their corresponding URIs:
| Operation | Operation Path | Details in RFC |
| Distribution of CA Certificates | /cacerts | RFC Section 4.1 |
| Enrollment of Clients | /simpleenroll | RFC Section 4.2 |
The EST interface of the Hubject Plug&Charge PKI Services is fully compliant with RFC7030. For the implementation of an EST client, you can use the open source library libest from CISCO or the EST package from BouncyCastle.
EVSE Leaf Certificates (SECC Certificate)
By means of the charge point certificate, the charge point provides its authentication to the vehicle. During a TLS handshake, the charge point establishes a TLS connection to the vehicle. In doing so, it provides its authentication to the vehicle by sending its charge point certificate and the CPO sub-CA certificates. This certificate chain has been derived from a V2G root CA. The associated private key of a charge point certificate is stored in the charge point.
The EVSE leaf certificate contains its EVSE ID as common name, the structure of which is defined in the identifier description section.
Contract Leaf Certficiates
The contract certificate is used in the case of the Plug & Charge authentication and authorization modes at a charge point, in contrast to external identification means (EIM). It shall be assigned to a valid contractual relationship between the vehicle user (or owner) and Mobility Operator and shall be saved in the vehicle together with the private key that is associated with this contract certificate.
The electric vehicle accesses this digital certificate in order to prove the existence of a valid charging contract to the charge point. Contract certificates are derived – via intermediate sub-CAs – from MO root CAs or V2G root CAs.
The MO contract certificate contains an EMAID as a common name, the structure of which is defined in the identifier description chapter.
OEM Provisioning Certificates
An OEM provisioning certificate is derived from the OEM root CA or a V2G root CA via a chain of OEM sub-CAs and is issued individually for and saved in each electric vehicle. The MO uses the certificate to verify the identity of the vehicle when provisioning a contract certificate.
It shall be possible to renew the provisioning certificate in the vehicle if it is revoked. The process of renewing the certificate is specific to each OEM and can be carried out by a workshop or by means of an online process using the OEM backend and telematics link of the EV.
The OEM provisioning certificate contains a PCID as a common name, the structure of which is defined in the identifier description chapter.
Certificate Signing Request
CSR or Certificate Signing Request is a block of encoded text that is given to a Certificate Authority when applying for a digital Certificate. It is usually generated on the server/end-device where the certificate will be installed and contains information that will be included in the certificate such as the organisation name, common name (domain name), locality, and country. It also contains the public key that will be included in the certificate. A private key is usually created at the same time that you create the CSR, making a key pair. A CSR is generally encoded using ASN.1 according to the PKCS #10 specification.
A certificate authority will use a CSR to create your digital certificate, but it does not need your private key. You need to keep your private key secret. The certificate created with a particular CSR will only work with the private key that was generated with it. So if you lose the private key, the certificate will no longer work.
OCSP Service
The OCSP responder of the Hubject Plug&Charge PKI Services publishes the status information of the certificates, which are created by Hubject. This endpoint does not require authentication. OCSP interface is a standard implementation, which is described in RFC6960.