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 {{k3}} 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 permission subpermission certificate authority add, delete, modify tls profiles add enable these permissions in the role editor window on the permissions tab create an x 509 certificate container on the {{k3}} , 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 {{k3}} 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 generate a self signed root ca certificate the {{k3}} 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 {{k3}} 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 issuance policies an issuance policy on the {{k3}} 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 for the root ca tree you can create issuance policies for each certificate tree that resides in a x 509 certificate container on the {{k3}} administrators can individualize each policy for the specific needs of any given issuing ca to create an issuance policy log in to the {{k3}} 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 manage x 509 v3 extension profiles 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 add x 509 extension profile to add an x 509 extension profile log in to the {{k3}} 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 {{k3}} 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 {{k3}} to configure issuance policies that place restrictions on the dn information that the certificate request needs to contain add x 509 dn profile to add an x 509 dn profile log in to the {{k3}} 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 issuer certificate management 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 generate intermediate or issuer certificates from kmes generated keys log in to the {{k3}} 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 generate intermediate or issuer certificates from a csr log in to the {{k3}} 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 export the intermediate or issuer certificates as a pkcs #12 file this option is only available if the keys were generated on the {{k}} 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 certificate renewal 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 renew an x 509 certificate to renew an x 509 certificate, perform the following steps log in to the {{k3}} 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 certificate revocation and crls the {{k3}} 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) create a crl to create a crl log in to the {{k3}} 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 revoke certificates to revoke an x 509 certificate, perform the following steps log in to the {{k3}} 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 export crls to export a crl log in to the {{k3}} 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 exporting the offline root ca key 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 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 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 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