1.11 Registration Authority

As a PKI provider, verifying the identity associated with the Common Name is a critical part of the certificate issuance process.

To ensure a smooth and secure certificate signing experience, we require that Common Names be registered in our certificate authority. This registration process is essential as it allows us to conduct thorough checks and validation, ensuring that certificates are only issued to the rightful owners. If a Common Name is not registered in our certificate authority, the request for signing a certificate may be denied, thus maintaining a robust security posture.

Getting ready

We adhere to ISO requirements, which dictate that different roles must have specific IDs attached to their Common Names. The first components of these IDs are attached to the credential used to access the endpoints, so it needs to be set beforehand:

1. Mobility Operators (MO) are identified by their EMAID (e-Mobility Account Identifier). The first five characters of the Common Name represent the country code and provider ID and are attached to the credentials used to access the endpoints.
2. Charge Point Operators (CPO) are distinguished by their EVSE/SECC ID (Electric Vehicle Supply Equipment/Supply Equipment Communication Controller). The first five characters of the Common Name represent the country code and operator ID. This is attached to the credential.
3. Original Equipment Manufacturers (OEM) are identified by their PCID (Provisioning Certificate Identifier). The first three characters of the Common Name represent the WMI (World Manufacturer Identifier) of the manufacturer. It's attached to the credential.

Typically, during the initial onboarding process, the credentials are configured, incorporating the aforementioned components. However, it is crucial to keep us informed in the event of any changes or additions to the ProviderID, OperatorID, or WMI. This ensures that we can promptly update the used credentials and avoid potential blockages of certificate signing requests.

For Charge Point Operators (CPO) the initial step is to share all relevant operator IDs with the onboarding team. Once these Operator IDs are recorded from Hubject, the CPO may use the Registration Authority APIs to register their common names.

In the future, in the event of any newly added Operator IDs to the CPO network (i.e such as a subCPO), all new Operator IDs, their EVSE IDs, and relevant security information, such as the hardware used must be shared as soon as possible. This information must be sent to the Plug & Charge team via email at support@pnc.hubject.com. The common name registration may follow afterwards.

Our Registration Authority endpoints have been purposefully implemented to streamline the registration process. With these endpoints, users can easily register, verify, and manage their EVSE/SECC IDs. This user-friendly approach enhances the overall experience and simplifies certificate management, ensuring secure and efficient deployment for all stakeholders.

Access to the APIs is granted to the relevant endpoints with the daily environment bearer access token authorization. 

By adhering to these rigorous identity verification processes and implementing user-friendly tools, we strive to maintain the highest standards of security and user satisfaction as a trusted PKI provider.

Interfaces

In total five interfaces are available for the process:

PutCpo

This endpoint allows registration of the common names at the Hubject PKI Gateway for a specific role by passing the common names in an array of string objects.

PUT Request at {{envURL}}/v1/vra/cpo/endEntities

Seven attributes are required in the body of the call: 

{ 
  "commonName": "string",
  "manufacture": "string",
  "deviceName": "string",
  "deviceSWVersion": "string"
  "evseSerialNumber": "string"
  "evseID": array["string"]
  "evseISOversion": "string"
  "ocppVersion": "string"
  "chargeBoxSerialNumber": "string"
}

^(([a-zA-Z]{2}\-?[a-zA-z0-9]{3}\-?[S]\-?[a-zA-Z0-9]{32,59})\-?[0-9]?|([a-zA-Z]{2}\*?[a-zA-Z0-9]{3}\*?[E][a-zA-Z0-9*]{1,59}))$

With a successful response you will receive the following attributes:

{ 
  "commonName": "string", 
  "registeredDate": "string", 
  "userName": "string",
  "ca": "string", 
  "stage": "string",
  "manufacture": "string",
  "deviceName": "string",
  "deviceSWVersion": "string"
  "evseSerialNumber": "string"
  "evseID": array["string"]
  "evseISOversion": "string"
  "ocppVersion": "string"
  "chargeBoxSerialNumber": "string"
}

GetAllCpoByUserName

DeleteCpo

Error Handling

Error Response Schema:

• Properties: 
  • errorMessages Array(string): An array of error messages
  • traceId (string, UUID format): A unique identifier for tracing the error.

Responses:

• 200: OK
  • Schema: Registration response;
• 400: Bad Request
  • Schema: Error;
  • Description: Invalid request or parameters;
• 401: Unauthorised
  • Schema: Error;
  • Description: Invalid token was presented;
• 500: Internal Server Error
  • An internal error occurred in the server.

The interface above mentioned can be found in the Postman collection available here.