Configure offline Root CA functionality
The information contained in this section outlines the following items related to the creation and management of offline root CAs on the :
- Create a self-signed root CA tree
- Issuer certificate management
- Certificate Renewal
- Certificate Revocation and CRLs
- Exporting the offline root CA key
To create a self-signed root CA tree, you must assign the logged-in identity with a role that has the following permissions:
Permission
Subpermission
Certificate Authority
Add, Delete, Modify
TLS Profiles
Add
Enable these permissions in the Role Editor window on the Permissions tab.
On the , 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:
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.
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.
Select [ OK ] to finish creating the certificate container.
The 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.
To create a root CA certificate:
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 selection 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.
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 root CA certificate with all the settings that 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.
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 root CA certificate that you created and select Issuance Policy > Add.
On the Issuance Policy editor window, enter the appropriate Alias.
Next to Approvals, select the required number of Approvers to issue a certificate. This option designates the amount of approvals needed to issue a certificate.
On the X.509 tab, check the box for each option that applies to your use case.
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.
Configure details in the remaining tabs as required and select [ OK ] to save.
The RA's X.509 Extension Profiles tab enables you to add information onto 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.
To add an X.509 extension profile:
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. T will appear.
On the X.509 v3 Extension Profile window, enter the desired Name for the profile. This can reflect the type of document which the profile uses to add data to in the future.
(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.
Select [ Add ]. T will open.
In the X.509 v3 Extension OID window, select the extension type to add and select [ OK ].
Under the X.509 v3 Extension Profile line, the extension appears. 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 cannot edit the extension value, but inclusion is optional.
Required
Extension is always present, and the value is editable.
Fixed Value
Extension is always present, and the value is not editable.
Restricted
You cannot add the extension to the request.
Uploaded
Uploaded by using a CSR or manually added when creating a certificate request.
OID: The object identifier, which specifies the type of extension used:
Object identifier
Description
Authority Information Access
Enables 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 Constraints
Identifies 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 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, select [ Remove ] 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 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 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 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 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, 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-Check
Defines 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 Constraints
Specifies 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 Mappings
Specifies 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 Name
Establishes 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 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 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 extensions
The 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.
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 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.
Navigate to PKI > X.509 DN Profiles.
Select [ Add ] at the bottom of the page.
In the X.509 DN Profile editor window, enter the desired Name for the profile.
Select [ New ] to add X.509 attributes to the profile.
Select [ OK ] to save the X.509 DN Profile.
To manage issuer certificates, assign the logged-in identity a role with the following permissions:
Permission
Sub permission
Certificate Authority
Add, Delete, Modify, Export
TLS Profiles
Add
Note: These permissions can be enabled 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.
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 created 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 Intermediate.
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 all your configured settings.
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 created and select Add Certificate > From Request.
In the file browser, select the CSR you want to upload and select [ Open ].
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.
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 all your configured settings.
This option is only available if the keys were generated on the .
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.
Go to PKI > Certificate Authorities.
Right-click the Intermediate certificate, and select Export > PKCS#12 Batch.
Ensure that you select the Export Selected option and specify a unique name for the export file. Then, select [ Next ].
Input a file password of your choosing, and select [ Next ].
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.
To perform certificate renewal tasks, 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, perform the following steps:
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 ].
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.
Select [ OK ] to proceed with the certificate renewal or re-signing operation.
The supports the management and export of Certificate Revocation Lists (CRLs). Use these lists manage single or mass certificates that you need to revoke for various reasons, including those defined by third-party Certificate Authorities (CAs).
To create a CRL:
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click the certificate for which you want to create a CRL and select CRL > Create.
On the Create CRL window, modify the CRLs information per your requirements.
Select [ OK ] to save.
To revoke an X.509 certificate, perform the following steps:
Log in to the application interface with an identity assigned the required permissions.
Go to PKI > Certificate Authorities.
Right-click on the certificate you want to revoke and select CRL > Revoke.
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 righthand section.
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 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.
Select [ Finish ].
In the Certificate Authorities menu, the status for your revoked certificate should show as Revoked.
To export a CRL:
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 export the CRL for and select CRL > Export.
On the CRL Export window, set the desired CRL Period, Encoding, Format, and file save location.
Select [ OK ] to initiate the CRL export.
At the highest point within a Public Key Infrastructure (PKI) hierarchy, the root CA is trusted by all an organization's 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's 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 CAs used to sign subordinate CAs is kept in a dedicated offline network.
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 retreive or parse data without PIN entry, 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.
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.