Certificate Authority (CA) workflow

the {{k3}} 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 {{k}} typically, you host the root ca on a separate device or service from the issuing ca (that is, another offline {{k}} 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 {{k3}} root ca certificate management issuing ca certificate creation certificate renewal certificate revocation and crls root ca certificate management 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 {{k}} 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 create an x 509 certificate container on the {{k3}} , 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 {{k3}} application interface using an identity 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 according to your requirements additionally, you can select \[ permissions ] and grant permissions to specific roles select \[ ok ] to finish creating the certificate container import an externally hosted root ca certificate 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 {{k3}} 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 generate a root ca perform the following steps to generate a self signed root ca certificate directly on the {{k}} 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 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 issue ca certificate creation 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 sign the issuer ca certificate perform the steps in this section to use an externally hosted root ca to sign the issuer ca certificate from a csr 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 {{k}} , skip to generate the issuing ca certificate generate a key pair perform the following steps to generate a key pair for the issuing ca on the {{k}} 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 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 export a csr perform the following steps to export a certificate signing request (csr) for the issuing ca log in to the {{k3}} 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 take the csr to the external root ca to sign the issuer ca certificate the specific steps required for this task vary depending on the external root ca being used (such as another {{k}} device, digicert, and so on) after you have the signed issuer ca certificate, proceed to the next section import the ca certificate perform the following steps to import the signed issuer ca certificate into the {{k}} log in to the {{k3}} 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 {{k}} the status of the issuing ca should show as valid now generate the issuing ca certificate if you created a self signed root ca certificate directly on the {{k}} , perform the following steps to generate the issuing ca certificate from {{k}} 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 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 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 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 perform the following steps to create an issuance policy for the issuing ca certificate log in to the {{k3}} 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 unique, non admin identities must enter approvals in the allowed hashes drop down menu, select the allowed hashes if you want to require ldap login , select the checkbox select a notifications option this option notifies 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 expire 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 {{k3}} 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 then, specify http and ldap endpoints x 509 v3 extensions the {{k3}} 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 manage x 509 v3 extension profiles 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 create a new profile perform the following steps to create a new 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 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 that the profile you use to add data to in the future (optional) select the allow user defined extensions checkbox to enable users to modify or add their extensions when adding the profile to a csr select \[ add ] 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 whether 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 based on permitted use oids identify permitted uses 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, enter 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, enter 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, 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, 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, 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 manage dn profiles 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 {{k3}} to configure issuance policies that restrict the dn information that the certificate request must contain add an x 509 dn profile perform the following steps to add an x 509 dn profile log in to the {{k3}} 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 certificate renewal and revocation 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 renew x 509 certificates perform the following steps to renew an x 509 certificate 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 ] 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 revoke x 509 certificates perform the following steps to revoke an x 509 certificate 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 revoke and select crl > revoke 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