Apply Manual Production Process

TIP

There is an article describing the ServiceNow system used commonly with Ability PKI requests.

Production checklist

1. Create a ServiceNow ticket to be validated as an authorized requester (Approval request).
2. Create a ServiceNow ticket for the profile creation request.
3. Generate a CSV file containing the DeviceIDs and enrollment codes and deliver it to the Ability PKI team for uploading to the system through the ServiceNow ticket.
4. Prepare the scripts for DeviceID-enrollment code pair distribution to the Edge devices.
5. Produce devices.
6. Maintain the list of DeviceIDs of the produced devices.

Approval request

Before being authorized to request any changes related to Ability PKI, you need to be onboarded. To do that create a ServiceNow ticket in the category: ABB Ability PKI; subcategory: ABB Ability PKI - Onboarding request. Include in the description the following details about your product and organization:

• Organizational Unit - shall follow the notation: Product Group Designation / Product Group Location / Product Group Country, e.g. PG2877/Bangalore/IN
• Product name or Ability environment (if for the Ability Platform itself)
• A brief description of the use cases/purpose
• Ask whether the product fulfills the MCSR for internet-facing products or if it has an approved exception
• Product manager (if not the requestor)
• Manufacturing location (factory external/internal)
• Name and email of the manufacturer contact person
• Point of contact
  • First name
  • Last name
  • Email address
  • Phone number
  • Best a group mailbox

Requesting profile creation

To request a new profile, you need to issue a ticket on the ServiceNow platform. Please use the category: ABB Ability PKI and subcategory: ABB Ability PKI - new certificate profile request.

Type of certificate: IdevID (Evergreen Certificate) or LDevID.

In the case of LDevID, make sure to include the following details in your request:

• Certificate Validity Period: How long should the certificate be issued for (max. 3 years)?
• Certificate Renewal Window: How far before the expiration date can I renew the certificate (max. 90 days)?
• Enrollment Code Validity: How long do I want my CSV file to be valid for (max. 30 days)?
• Expired Certificate Renewal: Yes/No

Device enrollment request

In the Ability PKI solution, on the production and testing environment you can request a certificate for a common name matching one of the preconfigured DeviceIDs. To set the list of allowed DeviceIDs you have to generate a CSV file constructed with two columns. The first column is the list of the DeviceIDs and the second column is the corresponding enrollment code. After that create a ticket in ServiceNow choosing Device enrollment request[csv] as subcategory with CSV file attachment. Please provide in the description the expected manufacturing start and end date.

The sample content of the file can look like below.

*Seat ID	Passcode
A7143F17-16AC-44D3-AEF2-BE5093D813D9	AAAaaa123
E7C5E895-B8C4-42E6-BEF4-B3BA470E2C3B	BBBbbb456
F46CA871-DF4D-42A3-ABE2-C882B155F2F4	CCCccc789

We recommend that the DeviceIDs are generated with a tool meeting the RFC 4122 standard (e.g. uuidgen). Passcodes must be between 9 and 32 characters in length, and should include a mixture of, upper- and lower-case letters and numbers. You can download a sample script written in Python by clicking here.

DPCM configuration

For the DPCM to work with the Ability PKI profile correctly, there is a need to modify the configuration files accordingly. The configuration associated with the certificate enrollment process is located in two files and their parameters:

/etc/dpcm.config:

• PKI_CERTIFICTE_OU
• PKI_RA_SERVER_ADDRESS
• PKI_CA_AUTH_HASH
• PKI_ENROLL_PASWD
• IDServiceURL

/var/ability/config/edge.env:

• DEVICE_ID

The full configuration of the Edge is described here.

In production, there is a need to set the DEVICE_ID in /var/ability/config/edge.env file and the enrollment code in /etc/dpcm.config file for each device before enrollment. This is usually done as a step of the bootstrapping script that is run after the golden image is flashed on the device.

DeviceIDs storage

The DeviceIDs generated by the script and uploaded to the Ability PKI platform are used by the devices in the Ability Platform as primary identifiers. It is crucial to store them in a database for future use. The 19.09 version of the Ability Platform introduced the multitenancy feature. As a consequence, before the device connects to the platform, it has to be associated with the appropriate tenant. This can be done either by the BL operations, or by the customer himself through a portal developed by the BL. Either way, there must be identification of the device. Considering the self-registration of the device by the customer, it can be accomplished for example by printing the DeviceID on the device itself or by storing the DeviceID in a database correlated with the serial number and providing only the serial number on the box. If the members of the BLs team are to register the devices in Principal Manager for the customer, there is a need of keeping track of which device is delivered to which customer.