Certificate Manager Service

Certificate Manager solution delivered by Ability Platform consist of three main software components:

• Certificate Manager Service exposing set of REST APIs
• Certificate Manager Portal
• a client reference architecture for Factory Proxy

Certificate Manager Service is cloud service co-located along with GIG service in the Ability Platform Global Plane and shares the same API Management instance and URL.

The Service is designed to act as single point of contact for activities related to Ability PKI management and defines four new roles:

• PKI Admin (person) - An internal, Ability administrator role, responsible for PKI management
• Production Admin (person) - A business production administrator, responsible for managing the specific PKI profile interactions
• Revocation Admin (person) - Person responsible for certificate revocation
• Factory Proxy (system) - Business line owned system (Certificate Manager Service client) that automates devices production process

Architecture

Certificate Manager Service context is presented on the following diagram:

The service provides an abstraction for its client for underlying services:

• GIG service - for ID generation / uniqueness check
• PKI profile service (for seat/enrollment and certificate management)

Service clients (both users and systems) are authenticated using ABB Azure AD.

Features

Certificate manager services provides the following set of features for each user / system roles.

Factory Proxy client

• Management of enrollment process

  Enables automated management of enrollments - set of pairs (device id, enrollment code) - identified by operationId. Enrolment can use both pre-generated device ids or the proxy can use Certificate Manager service for device id generation.

  The service exposes the API for

  • Creating new enrollments (for a specified set size)
  • Listing the enrollments identifiers (operationIds)
  • Controlling enrolment status (checking enrollment pairs set by operationId)

• Additional certificate signing channel

  Enables CSR based enrollment to be executed via the API. Depending on the use case, it could be a replacement for existing SCEP based interactions or DPCM edge service.

Production Admin

A single place for management the software systems in Factory Proxy role.

Certificate Manager Service exposes API for:

• Creating new factory proxy
• Managing factory proxy authorization
• Managing factory proxy configuration
• Managing factory proxy secrets
• Deprovision of the proxy

The user with Production Admin role could manage only subset of factory proxies. Access is limited to the proxies created for the PKI profile accessible to the user.

Revocation Admin

Certificate Manager Service exposes API for certificate revocation. The revocation request will make the corresponding certificate no longer valid and it is irreversible operation.

The user with Revocation Admin role could revoke only subset of certificates. Access is limited to the certificates created via Certificate Manager and only by the the PKI profile accessible to the user. The role is provided to the PKI Team only.

PKI Admin

Certificate Manager Service exposes also set of API for internal Ability PKI Administrators. Administrator can use the API to automate PKI Profile management:

• Create new profiles
• Manage the profile access rights (list of Production and Revocation admins for the profile)

Example use

The following example presents main use case for Certificate Manager Service - creation of new enrolment:

Certificate Manager service is contacted by Factory Proxy authenticated previously in ABB Azure AD with a request to create new set of enrolment pairs. The set is identified by unique identifier (operationId) generated by the client which is later on used to track request status. Certificate manager responds for the request with 202 Accepted HTTP response code and start to process the request.

Certificate Manager service then executes GIG device ID generations and contacts PKI Profile service to create a seat identified by the device id. Each seat represents one device. For each seat PKI profile service creates a unique enrollment code.

Factory proxy should periodically pull the current status of the enrolment (using the same operationId) to get finally notified when the enrolment became 'generated'.

Once the enrolment status is 'generated', the whole set of pairs is ready to use.