Certificate Authority (CA) workflow
The device enables you to build an enterprise-level PKI and deploy CAs by using a custom-defined CA hierarchy system. The CA hierarchy begins with a root CA certificate, which you can generate directly on the . Typically, you host the root CA on a separate device or service from the issuing CA (that is, another offline or another CA entirely). Then, under the root CA certificate, you create and use an issuing CA certificate to issue all leaf certificates in the certificate tree. The issuing CA can define the enterprise CA security parameters such as the certificate approvers, certificate validity, certificate renewal, and so on.
A leaf or end-entity certificate is any certificate that cannot sign other certificates, such as TLS/SSL server and client certificates, email certificates, code signing certificates, and qualified certificates are all types of leaf certificates.
This section outlines the following items related to the creation and management of issuing CAs on the :
- Root CA certificate management
- Issuing CA certificate creation
- Certificate Renewal
- Certificate Revocation and CRLs
The root CA is typically a separate device or service from the issuing CA. However, you can generate a self-signed root CA directly on the . The following sections provide instructions for both of these methods.
To perform the steps in this section related to root CA certificate management, the logged-in identity must be assigned a role with the following permissions:
Permission
Subpermission
Certificate Authority
Add, Delete, Modify
TLS Profiles
Add
Enable these permissions in the Role Editor window in the Permissions tab.
On the , you must create certificate trees in a certificate container. This means that creating a new certificate container is a prerequisite before generating the root and issuing CA certificates.
The certificate container includes identifying information, which resides in the Distinguished Name (DN) attached to it. If required, you can define the DN to include security restrictions while creating the certificate container.
Perform the following steps to create a new X.509 certificate container:
Log in to the application interface with an identity that is assigned the required permissions.
Go to PKI > Certificate Authorities, and select [ Add CA ] at the bottom of the page.
On the Certificate Authority window, enter a name for the CA container and select X.509 in the Type drop-down menu. Use the default values in the Host and Owner group fields or set them per your requirements. Additionally, you can select [ Permissions ] and grant permissions to specific roles.
Select [ OK ] to finish creating the certificate container.
If you are using a root CA hosted on a separate device or service from the issuing CA, follow the steps outlined in this section. If you plan to generate a self-signed root CA directly on the KMES, skip to the next subsection.
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click the appropriate certificate container and select Import > Certificate(s).
On the Import Certificates window, select [ Add ] and then select the externally-hosted root CA certificate.
The root CA certificate should be listed now in the Verified section.
Select [ OK ] to finish importing.
To generate a self-signed root CA certificate directly on the , follow the steps below:
Log in to the application interface with an identity assigned the required permissions
Go to PKI > Certificate Authorities.
Right-click the appropriate certificate container and select Add Certificate > New Certificate.
On the Subject DN tab of the Create X.509 Certificate window, change the Preset drop-down option to Classic and, as a minimum requirement, specify a Common Name for the certificate, such as Root.
On the Basic Info tab, you can leave the default values set or modify them per your specific requirements.
Define the validity dates for the certificate in the PKI Date Validity section. The default validity period is one year.
On the V3 Extensions tab, select the Certificate Authority profile in the drop-down menu.
Select [ OK ] to generate the root CA certificate with all the settings you configured.
To manage issuing CA certificates, you must assign the logged-in identity a role with the following permissions:
Permission
Subpermission
Certificate Authority
Add, Delete, Modify, Export
TLS Profiles
Add
Enable these permissions in the Role Editor window on the Permissions tab.
The most commonly used terms for issuing CA certificates are issuing certificate, intermediate certificate, or sub-CA certificate. For the purpose of this guide, consider these synonymous.
If you are using a root CA hosted on a separate device or service from the issuing CA, follow the steps outlined in this section. If you generated a self-signed root CA directly on the , skip to Generate the issuing CA certificate from KMES-generated keys
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click the root CA certificate you created, and select Add Certificate > Pending.
On the Subject DN tab, change the Preset drop-down option to Classic and, as a minimum requirement, specify a Common Name for the certificate, such as Issuing.
On the Basic Info tab, you can leave the default values set or modify them per your specific requirements.
The validity dates for the certificate are defined in the PKI Date Validity section. The default validity period is one year.
On the V3 Extensions tab, select the Certificate Authority profile in the drop-down menu.
Select [ OK ] to generate the issuing CA key pair and the CSR with the settings you configured.
You should see the Issuing certificate listed under the Root certificate with the status of the issuing CA as Pending/Invalid.
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click the Pending/Invalid issuing CA certificate and select Export > Signing Request.
On the Subject DN tab, change the Preset drop-down option to Classic and, as a minimum requirement, specify a Common Name for the certificate, such as Issuing.
On the V3 Extensions tab, select the Certificate Authority profile in the drop-down menu.
On the PKCS #10 Info tab, select [ Browse ] and specify a save location for the CSR.
Select [ OK ] to finish generating the CSR for the issuing CA.
The specific steps required for this step will vary depending on the external root CA being used (e.g., another KMES device, DigiCert, etc.). Once you have the signed issuer CA certificate, proceed to the next section.
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click the Pending/Invalid issuing CA certificate and select Replace > With Signed Certificate.
On the Import Certificates window, select [ Add ] and select the signed issuing CA certificate in the file browser. Then, select [ Open ].
You should see the issuing CA certificate listed under the root CA certificate in the Verified section.
If you see the issuing CA certificate listed in the Unverified section, review the preceding steps and repeat the process.
Select [ OK ] to finish associating the signed issuing CA certificate with its corresponding private key stored on the .
The status of the issuing CA should show as Valid now.
Perform the following steps if you created a self-signed root CA certificate directly on the .
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click the root CA certificate that you imported and select Add Certificate > New Certificate.
In the Subject DN tab of the Create X.509 Certificate window, change the Preset drop-down option to Classic and, as a minimum requirement, specify a Common Name for the certificate, such as Issuing.
On the Basic Info tab, you can leave the default values set or modify them per your specific requirements
Define the validity dates for the certificate in the PKI Date Validity section. The default validity period is one year.
On the V3 Extensions tab, select the Certificate Authority profile in the drop-down menu.
Select [ OK ] to generate the issuer CA certificate with the settings you configured.
An issuance policy on the defines and limits the parameters under which you can issue leaf certificates under a given CA tree. This includes the number of approvers needed to issue a certificate, the ability to define the validity period of the issued certificate, and the allowance of renewals.
You can create issuance policies for each certificate tree that resides in a X.509 certificate container on the . Administrators can individualize each policy for the specific needs of any given issuing CA.
Perform the following steps to create an issuance policy:
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click the issuing CA certificate, and select Issuance Policy > Add.
On the Basic Info tab of the Issuance Policy editor, perform the following steps:
- In the Alias field, enter a name for the issuance policy.
- Use the up-down arrows to specify the number of Approvals (0-5) that are required for CSRs listed under this Issuance Policy. Approvals must be entered by unique, non-Admin identities.
- In the Allowed hashes drop-down menu, select the allowed hashes.
- If you want to Require LDAP login, select the checkbox.
- Notifications: This option messages users when CSRs upload. (To have identities with approve permissions receive notifications when CSRs upload, you must assign an email address to their identity.)
- Notify upload: Messages users when CSRs are uploaded.
- Notify approve: Messages users when CSRs are approved.
- Notify deny: Messages users when CSRs are denied.
- Notify expired: Messages users when certificates are expired.
- In the Emails field, specify all of the email addresses you want to receive notifications.
- Use the up-down arrows to specify the number of days before expiration to notify users.
On the X.509 tab, perform the following steps:
- Select the Allow CSR uploads checkbox to enable the ability to upload a certificate signing request for approval.
- Select the Allow renewals checkbox to allow signatures to be renewed.
- Select the Allow PKI generation checkbox to enable the ability to request PKI signatures.
- (Optional) Select the Save certificate checkbox.
- Select the Allow self approval checkbox if you want to allow the same role both to submit and approve CSRs.
- Select [ Select ] and select a Default approval group.
- Use the up and down arrows and the drop-down menu to select the Max validity period in days, weeks, months, or years (the default).
- Select the Expiration date you want to apply to issued certificates.
- In the Renewal validity drop-down menu, select either Same as original or Max validity. (This option is available only if you select the Allow renewals checkbox.)
- Under PKI Types, select either RSA or ECC and select the minimum and maximum bit sizes, defaulting to 2048/2048 for RSA and 384/521 for ECC. Add another type using the [ + ] button. Delete a type using the [ - ] button.
- Under Extension Profiles, select [ Add ] to add one of the pre-defined X.509 v3 Extension Profiles.
On the Object Signing tab, perform the following steps:
- Select the Allow object signing checkbox to enable the ability to upload object-signing requests.
- Select the Padding algorithm to use for padding the object-signing requests.
On the LDAP Binding Info tab, perform the following steps:
Lightweight Directory Access Protocol (LDAP) is a software protocol that enables you to enroll people, places, and resources in a network for quick reference. You can register a remote LDAP server against which you can authenticate certificates.
- Press [ Select ] to choose the directory of a defined remote LDAP server. Refer to the Remote LDAP Servers section of the User Guide for more information.
- Under User Settings, define the Base DN. This determines where to store users in the LDAP database. For example, use ou to store users in the user directory of the LDAP database.
- Define the User attribute identifier for user settings. For example, cn is common name.
- Define the Password attribute identifier. The default is userPassword.
- Under the Group Permission Settings, begin by defining the Base DN. This determines where to store groups in the LDAP database. For example, use ou to store groups in the user directory of the LDAP database.
- Define the Group attribute identifier for group permission settings. For example, cn is common name.
- Define the Group name identifier for group permission settings. The default is Admin Group.
- Select the Use memberOf checkbox to change the Member attribute field from member to memberOf.
- Under Authentication, select the Authentication type you want to use in the drop-down menu.
- If you selected the SASL Bind in the Authentication type drop-down menu, select the SASL mechanism you want to use in the drop-down menu.
On the AIA and CRL DP tab, perform the following steps:
- (Optional) Select the Authority Information Access checkbox.
- If you enabled Authority Information Access, select the Only insert if extension is being used, Replace existing values, and Critical checkboxes according to your use case, and specify HTTP, LDAP, and OCSP endpoints.
- (Optional) Select the CRL Distribution Points checkbox.
- If you enabled CRL Distribution Points, select the Only insert if extension is being used, Replace existing values, and Critical checkboxes according to your use case, and specify HTTP, and LDAP endpoints.
The offers the ability to define X.509 V3 certificate extensions. These extension fields permit any quantity of additional fields to be included in the certificate being created or issued. X.509 V3 extensions enable you to assign usage restrictions and additional information such as alternative subject names to certificates.
If you want to deploy client-side authentication TLS certificates, you might want to define the Key Usage OID to only permit Key Agreement and Key Encipherment. Code signing users should include the Code Signing Extended Key Usage.
In the PKI > X.509 Extensions menu, you can see the eight example profiles enabled by default. You can also create new X.509 v3 extension profiles. This section shows you how to manage X.509 extension profiles
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > X.509 Extensions.
Select [ Add ] at the bottom of the page.
In the Name field of the X.509 v3 Extension Profile window, enter the desired name for the profile. This can reflect the type of document which the profile you use to add data to in the future.
(Optional) zselect the Allow User-Defined Extensions checkbox to allow users to modify or add their own extensions when adding the profile to a CSR.
Select [ Add ]. T will open.
In the X.509 v3 Extension OID window, select the extension type to add and select [ OK ].
The extension appears under the X.509 v3 Extension Profile line.
The information provided for each extension is as follows:
Mode: The rules guiding if the extension is presented and if it is editable:
Rule
Description
Optional
You can include but not edit the extension value.
Required
Extension is always present, and you can edit the value.
Fixed Value
Extension is always present, but you cannot edit it.
Restricted
You cannot add the extension to the request.
Uploaded
Upload it by using a CSR, or manually add it when creating a certificate request.
OID: The object identifier, which specifies the type of extension used:
Object identifier
Description
Authority Information Access
Enables users to specify an OID and various HTTP, LDAP, or OCSP URLs. Authority Information Access (AIA) is a special extension in SSL certificates that contains information about the issuer of the certificate. This extension helps fetch intermediate certificates from the issuing certification authority.
Authority Key Identifier:
Enables users to specify an OID and a hash value. The Authority Key Identifier is an extension that identifies the public key corresponding to the private key used to sign the certificate. The default hash algorithm is SHA-256. The other supported algorithms are MD5, RIPEMD-160, SHA-1, SHA-224, SHA-384, and SHA-512.
Basic Constraints
Identifies the subject of a certificate as a CA. Specify the maximum valid certificate paths contained within the certificate using the up-down arrows (from 0 to 99).
CRL Distribution Points
Establishes how to gather certificate revocation list information. Select [ Add ] to define location information. From the drop-down menu, select either LDAP or HTTP. To delete additional CRL Distribution Points, use the [ Remove ] buttons on the right side of the window.
Certificate Policies
Provides information on certificate policies. Enter the OID. Then, type in the octet string in hexadecimal format, or select [ Load ] to open the Import Hex window. The window updates to show the formatted ASN.1 structure.
Certificate Template Extension
A certification authority (CA) processes each certificate request by using a defined set of rules. you can customize certificate templates with a number of extensions that regulate their use.
Extended Key Usage
Designates the extended key usage options (multiple options can be selected) in the respective checkboxes, from the following:
- TLS Web Server Authentication
- TLS Web Client Authentication
- Code Signing
- E-mail Protection
- Time Stamping
- Microsoft Individual Code Signing
- Microsoft Commercial Code Signing
- Microsoft Trust List Signing
- Microsoft Server Gated Crypto
- Microsoft Encryption File System
- Netscape Server Gated Crypto
- OCSP Signing
Issuer Alternate Name
Provides an alias for the issuer. Enter the OID. Then, type in the octet string in hexadecimal format, or select [ Load ] to open the Import Hex window. The window updates to show the formatted ASN.1 structure.
Key Usage
Designates the key usage options (multiple options can be selected) in the respective checkboxes, from the following:
- Digital Signature
- Non-Repudiation
- Key Encipherment
- Data Encipherment
- Key Agreement
- Certificate Sign
- CRL Sign
- Encipher Only
- Decipher Only
MS Application Policies
Applications can use the Microsoft application policies extension to filter certificates on the basis of permitted use. Permitted uses are identified by OIDs. This extension is similar to the Enhanced Key Usage extension but with stricter semantics applied to the parent CA. The extension is Microsoft-specific.
MS Template Name
Use the template name extension to identify the version 1 template to use when issuing or renewing a certificate. The extension value contains the name of the template. The extension is Microsoft-specific.
Name Constraints
Specifies restrictions for the data’s name. Enter the OID. Then, type in the octet string in hexadecimal format, or select [ Load ] to open the Import Hex window. The window updates to show the formatted ASN.1 structure.
OCSP No-Check
Defines an OCSP server that checks if certificates have been revoked. Enter the OID. Then, type in the desired octet string in hexadecimal format, or select [ Load ] to open the Import Hex window. The window updates to show the formatted ASN.1 structure.
Policy Constraints
Specifies constraints for certificate policy. Enter the desired OID. Then, type in the desired octet string in hexadecimal format, or select [ Load ] to open the Import Hex window. The window updates to show the formatted ASN.1 structure.
Policy Mappings
Specifies maps for certificate policy. Enter the OID. Then, type in the octet string in hexadecimal format, or select [ Load ] to open the Import Hex window. The window updates to show the formatted ASN.1 structure.
Subject Alternate Name
Establishes an alias for the subject. Select [ Add ] to enter a new alternate name. To delete an alternate name, use the [ Remove ] buttons on the right side of the window.
Subject Key Identifier
Specifies a subject key. The default algorithm is SHA-256. The other supported algorithms are MD5, RIPEMD-160, SHA-1, SHA-224, SHA-384, and SHA-512.
Verifone Log Extension
Description N/A
Custom
Enables the user to add a custom extension. Enter the OID. Then, type in the octet string in hexadecimal format, or select [ Load ] to open the Import Hex window. The window updates to show the formatted ASN.1 structure.
Every certificate that you request or use to issue a certificate contains identifying information in the form of a Distinguished Name (DN). The DN can contain differing information depending on what the issuing CA requires for the certificate to be issued.
You can use the to configure issuance policies that place restrictions on the DN information that the certificate request needs to contain.
To add an X.509 DN profile:
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > X.509 DN Profiles.
Select [ Add ] at the bottom of the page.
In the Name field of the X.509 DN Profile editor, enter the desired name for the profile.
Select [ New ] to add X.509 attributes to the profile.
After you add all the desired attributes, select [ OK ] to save the X.509 DN Profile.
To perform certificate renewal tasks, you must assign the logged-in identity a role with the following permissions:
Permission
Subpermission
Certificate Authority
Add, Delete, Modify
TLS Profiles
Add
Enable these permissions on the Permissions tab of the Role Editor window.
To renew an X.509 certificate:
Log in to the application interface with an identity assigned the required permissions
Go to PKI > Certificate Authorities.
Right-click the certificate you want to renew and select [ Re-sign ].
In the Certificate Data tab of the Re-sign Existing Certificate window, set new validity dates for the certificate in the Not valid before and Not valid after fields.
Select [ OK ] to proceed with the certificate renewal/re-signing operation.
To revoke an X.509 certificate:
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click the certificate you want to revoke and select CRL > Revoke. This will open .
In the Revoke Certificate Wizard, select the certificate to revoke from the list in the left side of the window, and select the [ >> ].
This moves the certificate to the right side of the window.
Then, select [ Next ].
Configure the Revocation Options, optionally select the Export checkbox, and specify the Type, Encoding, and Output directory. Then, select [ Next ].
Select the revoke CRL from the list in the left side of the window and select [ >> ].
This moves the CRL to the right side of the window.
Then select [ Next ].
A message displays stating that the CRLs were successfully updated.
Select [ Finish ].
In the Certificate Authorities menu, the status for the certificate you revoked should show as Revoked.