Skip to main content
The information contained in this section outlines the following items related to the creation and management of offline root CAs on the KMES Series 3:
  • Create a self-signed root CA tree
  • Issuer certificate management
  • Certificate Renewal
  • Certificate Revocation and CRLs
  • Exporting the offline root CA key

​
Create a self-signed Root CA tree

To create a self-signed root CA tree, you must assign the logged-in identity with a role that has the following permissions:
PermissionSubpermission
Certificate AuthorityAdd, Delete, Modify
TLS ProfilesAdd
Enable these permissions in the Role Editor window on the Permissions tab.

​
Create an X.509 certificate container

On the KMES Series 3, you must create certificate trees within a certificate container. Thus, creating a new certificate container is a prerequisite before generating the root and intermediate 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.
To create a new X.509 certificate container, perform the following steps:
1
Log in to the KMES Series 3 application interface with an identity that is assigned the required permissions.
2
Go to PKI > Certificate Authorities and select [ Add CA ] at the bottom of the page.
3
In the Certificate Authority window, enter a name for the CA Container and select X.509 in the Type drop-down menu. You can use the default values in the Host and Owner group fields, or you can set them per your requirements. Additionally, you can select [ Permissions ] and grant permissions to specific roles.
4
Select [ OK ] to finish creating the certificate container.

​
Generate a self-signed root CA certificate

The KMES Series 3 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. Under the root CA certificate, an intermediate CA certificate is generated and used 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. For instance, TLS/SSL server and client certificates, email certificates, code signing certificates, and qualified certificates are all types of leaf certificates.
Perform the following steps to create a root CA certificate:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > Certificate Authorities, right-click the appropriate certificate container, and select Add Certificate > New Certificate.
3
On the Subject DN tab of the Create X.509 Certificate window, change the Preset drop-down selection to Classic and, as a minimum requirement, specify a Common Name for the certificate, such as Root.
4
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.
5
On the V3 Extensions tab, select the Certificate Authority profile in the drop-down menu.
6
Select [ OK ] to generate the root CA certificate with all the settings that you configured.

​
Issuance policies

An issuance policy on the KMES Series 3 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.

​
Create an issuance policy

You can create issuance policies for each certificate tree that resides in an X.509 Certificate Container on the KMES Series 3. Administrators can individualize each policy for the specific needs of any given issuing CA. To create an issuance policy for the root CA tree, perform the following steps:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > Certificate Authorities.
3
Right-click the root CA certificate that you created and select Issuance Policy > Add.
4
On the Issuance Policy editor window, enter the appropriate Alias.
5
Next to Approvals, select the required number of Approvers to issue a certificate. This option designates the number of approvals needed to issue a certificate.
6
On the X.509 tab, check the box for each option that applies to your use case.
7
On the Object Signing tab, if you require the ability for code signing, you can select the Allow object signing checkbox and the desired Padding algorithms.
8
Configure details in the remaining tabs as required and select [ OK ] to save.

​
Manage X.509 v3 extension profiles

The RA X.509 Extension Profiles tab enables you to add information to certificates, either through the eight example profiles enabled by default or through additional profiles you added and configured. You can use this section as a reference to manage X.509 extension profiles.

​
Add X.509 extension profile

Perform the following steps to add an X.509 extension profile:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > X.509 Extensions.
3
Select [ Add ] at the bottom of the page.
4
In the X.509 v3 Extension Profile window, enter the desired Name for the profile. This can reflect the type of document that the profile uses to add data in the future.
5
(Optional) Use the checkbox next to Allow User-Defined Extensions to allow users to modify or add their own extensions when adding the profile to a CSR.
6
Select [ Add ].
7
In the X.509 v3 Extension OID window, select the extension type to add and select [ OK ]*.
8
Under the X.509 v3 Extension Profile line, the extension appears. The information provided for each extension is as follows:Mode: The rules guiding whether the extension is presented and if it is editable:
RuleDescription
OptionalYou cannot edit the extension value, but inclusion is optional.
RequiredExtension is always present, and the value is editable.
Fixed ValueExtension is always present, and the value is not editable.
RestrictedYou cannot add the extension to the request.
UploadedUploaded by using a CSR or manually added when creating a certificate request.
OID: The object identifier, which specifies the type of extension used:
Object identifierDescription
Authority Information AccessEnables you 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 you 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 ConstraintsIdentifies the subject of a certificate as a CA. Using the up-down arrows (from 0 to 99), specify the maximum valid certificate paths contained within the certificate.
CRL Distribution PointsEstablishes 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, select [ Remove ] on the right side of the window.
Certificate PoliciesProvides 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 ExtensionA 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 UsageDesignates one or more of the following extended key usage options in the respective checkboxes:
  • 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 NameProvides 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 UsageDesignates one or more of the following key usage options in the respective checkboxes:
  • Digital Signature
  • Non-Repudiation
  • Key Encipherment
  • Data Encipherment
  • Key Agreement
  • Certificate Sign
  • CRL Sign
  • Encipher Only
  • Decipher Only
MS Application PoliciesApplications 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 NameUse 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 ConstraintsSpecifies restrictions for the data’s name. Enter the OID. Then, enter 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-CheckDefines an OCSP server that checks if certificates have been revoked. Enter the OID. Then, enter 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.
Policy ConstraintsSpecifies constraints for certificate policy. Enter the OID. Then, enter 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.
Policy MappingsSpecifies maps for certificate policy. Enter the OID. Then, enter 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 NameEstablishes an alias for the subject. Select [ Add ] to enter a new alternate name. To delete an alternate name, select [ Remove ] on the right side of the window.
Subject Key IdentifierSpecifies 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 ExtensionDescription N/A
CustomEnables you 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.
Custom v3 extensionsThe KMES Series 3 enables you to define X.509 V3 certificate extensions. These extension fields permit you to include any quantity of additional fields in the certificate being created or issued. X.509 V3 extensions enable you to assign usage restrictions and other additional information, such as alternative subject names, to certificates.If you want to deploy client-side authentication TLS certificates, you can define the Key Usage OID to allow only Key Agreement and Key Encipherment. In contrast, code-signing users should include the Code Signing Extended Key Usage.

​
Manage DN profiles

Every certificate requested or used to issue a certificate contains identifying information in the form of a Distinguished Name (DN). The DN can contain various details depending on what the issuing CA requires for the certificate to be issued. You can use the KMES Series 3 to configure issuance policies that place restrictions on the DN information that the certificate request needs to contain.

​
Add X.509 DN profile

Perform the following steps to add an X.509 DN profile:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > X.509 DN Profiles.
3
Select [ Add ] at the bottom of the page.
4
In the X.509 DN Profile editor window, enter the desired Name for the profile.
5
Select [ New ] to add X.509 attributes to the profile.
6
Select [ OK ] to save the X.509 DN Profile.

​
Issuer certificate management

To manage issuer certificates, assign the logged-in identity a role with the following permissions:
PermissionSub permission
Certificate AuthorityAdd, Delete, Modify, Export
TLS ProfilesAdd
Enable these permissions in the Role Editor window in the Permissions tab.
The most commonly used terms for issuer CA certificates are issuer certificate, intermediate certificate, or sub-CA certificate. This guide considers these synonymous.

​
Generate certificates

Perform the following steps to generate intermediate or issuer certificates from KMES-generated keys:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > Certificate Authorities.
3
Right-click the root CA certificate that you created and select Add Certificate > New Certificate.
4
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 Intermediate.
5
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.
6
On the V3 Extensions tab, select the Certificate Authority profile in the drop-down menu.
7
Select [ OK ] to generate the issuer CA certificate with all your configured settings.

​
Generate certificates

Perform the following steps to generate intermediate or issuer certificates from a CSR:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > Certificate Authorities.
3
Right-click the root CA certificate that you created and select Add Certificate > From Request.
4
In the file browser, select the CSR you want to upload and select [ Open ].
5
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 Intermediate.
6
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.
7
On the V3 Extensions tab, select the Certificate Authority profile in the drop-down menu.
8
Select [ OK ] to generate the issuer CA certificate with all your configured settings.

​
Export the certificates

This option is only available if the keys were generated on the KMES.
To export the intermediate or issuer certificate as a PKCS #12 file, you must go to Administration > Configuration > Options and enable the Allow export of certificates using passwords setting. Then, perform the following steps:
1
Go to PKI > Certificate Authorities.
2
Right-click the Intermediate certificate, and select Export > PKCS#12 Batch.
3
Ensure that you select the Export Selected option and specify a unique name for the export file. Then, select [ Next ].
4
Input a file password of your choosing, and select [ Next ].
5
Select [ Finish ], and in the file browser, choose the directory location where you want to save the PKCS #12 file. Select [ Choose ] to start the export.

​
Certificate renewal

To perform certificate renewal tasks, assign the logged-in identity a role with the following permissions:
PermissionSubpermission
Certificate AuthorityAdd, Delete, Modify
TLS Profiles Add
Enable these permissions on the Permissions tab of the Role Editor window.

​
Renew an X.509 certificate

To renew an X.509 certificate, perform the following steps:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions
2
Go to PKI > Certificate Authorities.
3
Right-click the certificate you want to renew and select [ Re-sign ].
4
On 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.
5
Select [ OK ] to proceed with the certificate renewal or re-signing operation.

​
Certificate revocation and CRLs

The KMES Series 3 supports the management and export of Certificate Revocation Lists (CRLs). Use these lists to manage single or mass certificates that you need to revoke for various reasons, including those defined by third-party Certificate Authorities (CAs).

​
Create a CRL

Perform the following steps to create a CRL:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > Certificate Authorities.
3
Right-click the certificate for which you want to create a CRL and select CRL > Create.
4
On the Create CRL window, modify the CRL information per your requirements.
5
Select [ OK ] to save.

​
Revoke certificates

To revoke an X.509 certificate, perform the following steps:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > Certificate Authorities.
3
Right-click the certificate you want to revoke and select CRL > Revoke.
4
In the Revoke Certificate Wizard, select the certificate to revoke from the list on the left side of the window and select [ >> ].
This moves the certificate to the right-hand section.
Then, select [ Next ].
5
Configure the Revocation Options, optionally select the Export checkbox, and specify the Type, Encoding, and Output directory. Then, select [ Next ].
6
Select the revoke CRL from the list on 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 that the CRLs were successfully updated.
7
Select [ Finish ].
In the Certificate Authorities menu, the status for your revoked certificate should show as Revoked.

​
Export CRLs

Perform the following steps to export a CRL:
1
Log in to the KMES Series 3 application interface with an identity assigned the required permissions.
2
Go to PKI > Certificate Authorities.
3
Right-click the certificate you want to export the CRL for and select CRL > Export.
4
On the CRL Export window, set the desired CRL Period, Encoding, Format, and file save location.
5
Select [ OK ] to initiate the CRL export.

​
Exporting the Offline Root CA Key

At the highest point within a Public Key Infrastructure (PKI) hierarchy, the root CA is trusted by all the organization users. As such, it is critical to securely maintain the root private key to prevent unauthorized use. For comprehensive risk reduction, you should keep the Root CA private key offline within a FIPS 140-2 Level 3 and PCI HSM-validated Secure Cryptographic Device. This solution satisfies PCI PIN and P2PE requirements that dictate that you keep CAs used to sign subordinate CAs in a dedicated offline network.

​
Using the Futurex USB Backup HSM

The USB Backup HSM enables you to safely back up your device data by using PIN protection and AES-256 encryption. You can unlock the device by entering the PIN into the device keypad before plugging it into a USB port and performing data operations. After you finish, the device automatically locks when you withdraw the device from the USB port. You cannot retrieve or parse data without entering the PIN, offering an additional layer of protection for sensitive backup or key information. See the USB Backup HSM User Guide for details on using it as an export option for the offline root CA key.

​
Using the Vectera Plus

The Vectera Plus hardware security module (HSM) handles cryptographic processing and key management for various general-purpose-related use cases. Our HSMs protect data in transit, in use, and at rest through various physical and logical security measures. The HSM is validated under FIPS 140-2 Level 3 and PCI HSM standards and complies with all relevant regulatory requirements for financial transaction processing, including those set out by Accredited Standards Committee X9. The Secure Cryptographic Device (SCD) contained within the Vectera Plus HSM handles all sensitive operations and supports common algorithms used in the payments industry, such as 3DES, AES, RSA, and ECC. It also supports a range of key derivation and wrapping methods, message authentication algorithms, and more. See the Vectera Plus User Guide for details on using it as an export option for the offline root CA key.