Chapter 9. The Certificate System Configuration Files The primary configuration file for every subsystem is its CS.cfg file. This chapter covers basic information about and rules for editing the CS.cfg file. This chapter also describes some other useful configuration files used by the subsystems, such as password and web services files. 9.1. File and directory locations for Certificate System subsystems Certificate System servers consist of an Apache Tomcat instance, which contains one or more subsystems. Each subsystem consists of a web application, which handles requests for a specific type of PKI function. The available subsystems are: CA, KRA, OCSP, TKS, and TPS. Each instance can contain only one of each type of a PKI subsystem. A subsystem can be installed within a particular instance using the pkispawn command. 9.1.1. Instance-specific information For instance information for the default instance ( pki-tomcat , if you have not specified pki_instance_name when running pkispawn), see Table 2.2, "Tomcat instance information" Table 9.1. Certificate server port assignments (default) Port Type Port Number Notes Secure port 8443 Main port used to access PKI services by end-users, agents, and admins over HTTPS. Insecure port 8080 Used to access the server insecurely for some end-entity functions over HTTP. Used for instance to provide CRLs, which are already signed and therefore need not be encrypted. AJP port 8009 Used to access the server from a front end Apache proxy server through an AJP connection. Redirects to the HTTPS port. Tomcat port 8005 Used by the web server. 9.1.2. CA subsystem information This section contains details about the CA subsystem, which is one of the possible subsystems that can be installed as a web application in a Certificate Server instance. Table 9.2. CA subsystem information for the default instance (pki-tomcat) Setting Value Main directory /var/lib/pki/pki-tomcat/ca/ Configuration directory /var/lib/pki/pki-tomcat/ca/conf/ [a] Configuration file /var/lib/pki/pki-tomcat/ca/conf/CS.cfg Subsystem certificates CA signing certificate OCSP signing certificate (for the CA's internal OCSP service) TLS server certificate Audit log signing certificate Subsystem certificate [b] Security databases /var/lib/pki/pki-tomcat/alias/ [c] Log files /var/lib/pki/pki-tomcat/ca/logs/ [d] Install log /var/log/pki/pki-ca-spawn. date .log Uninstall log /var/log/pki/pki-ca-destroy. date .log Audit logs /var/log/pki/pki-tomcat/ca/logs/signedAudit/ Profile files /var/lib/pki/pki-tomcat/ca/profiles/ca/ Email notification templates /var/lib/pki/pki-tomcat/ca/emails/ Web services files [e] Agent services: /usr/share/pki/ca/webapps/ca/agent/ Admin services: /usr/share/pki/ca/webapps/ca/admin/ End user services: /usr/share/pki/ca/webapps/ca/ee/ [a] Aliased to /etc/pki/pki-tomcat/ca/ [b] The subsystem certificate is always issued by the security domain so that domain-level operations that require client authentication are based on this subsystem certificate. [c] Note that all subsystem certificates are stored in the instance security database or the associated HSM, if so dictated at instance creation. [d] Aliased to /var/lib/pki/pki-tomcat/ca [e] Instead of instance-specific webapp files as with in the past, there are now webapp descriptors that point to the webapp location. E.g. in /var/lib/pki/rhcs10-RSA-SubCA/conf/Catalina/localhost/ca.xml: <Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true"> 9.1.3. KRA subsystem information This section contains details about the KRA subsystem, which is one of the possible subsystems that can be installed as a web application in a Certificate Server instance. Table 9.3. KRA subsystem information for the default instance (pki-tomcat) Setting Value Main directory /var/lib/pki/pki-tomcat/kra/ Configuration directory /var/lib/pki/pki-tomcat/kra/conf/ [a] Configuration file /var/lib/pki/pki-tomcat/kra/conf/CS.cfg Subsystem certificates Transport certificate Storage certificate TLS server certificate Audit log signing certificate Subsystem certificate [b] Security databases /var/lib/pki/pki-tomcat/alias/ [c] Log files /var/lib/pki/pki-tomcat/kra/logs/ Install log /var/log/pki/pki-kra-spawn- date .log Uninstall log /var/log/pki/pki-kra-destroy- date .log Audit logs /var/log/pki/pki-tomcat/kra/logs/signedAudit/ Web services files [d] Agent services: /usr/share/pki/kra/webapps/kra/agent/ Admin services: /usr/share/pki/kra/webapps/kra/admin/ [a] Linked to /etc/pki/pki-tomcat/kra/ [b] The subsystem certificate is always issued by the security domain so that domain-level operations that require client authentication are based on this subsystem certificate. [c] Note that all subsystem certificates are stored in the instance security database or the associated HSM, if so dictated at instance creation. [d] Instead of instance-specific webapp files as with in the past, there are now webapp descriptors that point to the webapp location. E.g. in /var/lib/pki/rhcs10-RSA-SubCA/conf/Catalina/localhost/ca.xml: <Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true"> 9.1.4. OCSP subsystem information This section contains details about the OCSP subsystem, which is one of the possible subsystems that can be installed as a web application in a Certificate Server instance. Table 9.4. OCSP subsystem information for the default instance (pki-tomcat) Setting Value Main directory /var/lib/pki/pki-tomcat/ocsp/ Configuration directory /var/lib/pki/pki-tomcat/ocsp/conf/ [a] Configuration file /var/lib/pki/pki-tomcat/ocsp/conf/CS.cfg Subsystem certificates Transport certificate Storage certificate TLS server certificate Audit log signing certificate Subsystem certificate [b] Security databases /var/lib/pki/pki-tomcat/alias/ [c] Log files /var/lib/pki/pki-tomcat/ocsp/logs/ Install log /var/log/pki/pki-ocsp-spawn- date .log Uninstall log /var/log/pki/pki-ocsp-destroy- date .log Audit logs /var/log/pki/pki-tomcat/ocsp/logs/signedAudit/ Web services files [d] Agent services: /var/lib/pki/pki-tomcat/ocsp/webapps/ocsp/agent/ Admin services: /var/lib/pki/pki-tomcat/ocsp/webapps/ocsp/admin/ [a] Linked to /etc/pki/pki-tomcat/ocsp/ [b] The subsystem certificate is always issued by the security domain so that domain-level operations that require client authentication are based on this subsystem certificate. [c] Note that all subsystem certificates are stored in the instance security database or the associated HSM, if so dictated at instance creation. [d] Instead of instance-specific webapp files as with in the past, there are now webapp descriptors that point to the webapp location. E.g. in /var/lib/pki/rhcs10-RSA-SubCA/conf/Catalina/localhost/ca.xml: <Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true"> 9.1.5. TKS subsystem information This section contains details about the TKS subsystem, which is one of the possible subsystems that can be installed as a web application in a Certificate Server instance. Table 9.5. Every time a subsystem is created either through the initial installation or creating additional instances with (pki-tomcat) Setting Value Main directory /var/lib/pki/pki-tomcat/tks/ Configuration directory /var/lib/pki/pki-tomcat/tks/conf/ [a] Configuration file /var/lib/pki/pki-tomcat/tks/conf/CS.cfg Subsystem certificates Transport certificate Storage certificate TLS server certificate Audit log signing certificate Subsystem certificate [b] Security databases /var/lib/pki/pki-tomcat/alias/ [c] Log files /var/lib/pki/pki-tomcat/tks/logs/ Install log /var/log/pki/pki-tks-spawn- date .log Uninstall log /var/log/pki/pki-tks-destroy- date .log Audit logs /var/log/pki/pki-tomcat/tks/logs/signedAudit/ Web services files [d] Agent services: /usr/share/pki/tks/webapps/tks/agent/ Admin services: /usr/share/pki/tks/webapps/tks/admin/ [a] Linked to /etc/pki/pki-tomcat/tks/ [b] The subsystem certificate is always issued by the security domain so that domain-level operations that require client authentication are based on this subsystem certificate. [c] Note that all subsystem certificates are stored in the instance security database or the associated HSM, if so dictated at instance creation. [d] Instead of instance-specific webapp files as with in the past, there are now webapp descriptors that point to the webapp location. E.g. in /var/lib/pki/rhcs10-RSA-SubCA/conf/Catalina/localhost/ca.xml: <Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true"> 9.1.6. TPS subsystem information This section contains details about the TPS subsystem, which is one of the possible subsystems that can be installed as a web application in a Certificate Server instance. Table 9.6. TPS subsystem information for the default instance (pki-tomcat) Setting Value Main directory /var/lib/pki/pki-tomcat/tps Configuration directory /var/lib/pki/pki-tomcat/tps/conf/ [a] Configuration file /var/lib/pki/pki-tomcat/tps/conf/CS.cfg Subsystem certificates Transport certificate Storage certificate TLS server certificate Audit log signing certificate Subsystem certificate [b] Security databases /var/lib/pki/pki-tomcat/alias/ [c] Log files /var/lib/pki/pki-tomcat/tps/logs/ Install log /var/log/pki/pki-tps-spawn- date .log Uninstall log /var/log/pki/pki-tps-destroy- date .log Audit logs /var/log/pki/pki-tomcat/tps/logs/signedAudit/ Web services files [d] Agent services: /usr/share/pki/tps/webapps/tps/agent/ Admin services: /usr/share/pki/tps/webapps/tps/admin/ [a] Linked to /etc/pki/pki-tomcat/tps/ [b] The subsystem certificate is always issued by the security domain so that domain-level operations that require client authentication are based on this subsystem certificate. [c] Note that all subsystem certificates are stored in the instance security database or the associated HSM, if so dictated at instance creation. [d] Instead of instance-specific webapp files as with in the past, there are now webapp descriptors that point to the webapp location. E.g. in /var/lib/pki/rhcs10-RSA-SubCA/conf/Catalina/localhost/ca.xml: <Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true"> 9.1.7. Shared Certificate System subsystem file locations There are some directories used by or common to all Certificate System subsystem instances for general server operations, listed in Table 9.7, "Subsystem file locations" . Table 9.7. Subsystem file locations Directory Location Contents /var/lib/pki/ instance_name Contains the main instance directory, which is the location for instance-specific directory locations and customized configuration files, profiles, certificate databases, and other files for the subsystem instance. /usr/share/java/pki Contains Java archive files shared by the Certificate System subsystems. /usr/share/pki Contains common files and templates used to create Certificate System instances. Along with shared files for all subsystems, there are subsystem-specific files in subfolders: pki/ca/ (CA) pki/kra/ (KRA) pki/ocsp/ (OCSP) pki/tks/ (TKS) pki/tps (TPS) /usr/bin /usr/sbin Contains the pki command line scripts and tools (Java, native, and security) shared by the Certificate System subsystems. 9.2. CS.cfg files The runtime properties of a Certificate System subsystem are governed by a set of configuration parameters. These parameters are stored in a file that is read by the server during startup, CS.cfg . The CS.cfg , an ASCII file, is created and populated with the appropriate configuration parameters when a subsystem is first installed. The way the instance functions are modified is by making changes through the subsystem console, which is the recommended method. The changes made in the administrative console are reflected in the configuration file. It is also possible to edit the CS.cfg configuration file directly, and in some cases this is the easiest way to manage the subsystem. 9.2.1. Locating the CS.cfg file Each instance of a Certificate System subsystem has its own configuration file, CS.cfg . The contents of the file for each subsystem instance is different depending on the way the subsystem was configured, additional settings and configuration (like adding new profiles or enabling self-tests), and the type of subsystem. The CS.cfg file is located in the configuration directory for the instance. For example: 9.2.2. Editing the configuration file WARNING Do not edit the configuration file directly without being familiar with the configuration parameters or without being sure that the changes are acceptable to the server. The Certificate System fails to start if the configuration file is modified incorrectly. Incorrect configuration can also result in data loss. Therefore, it is highly recommended to save a backup of the configuration file before making any changes. To modify the CS.cfg file: Stop the subsystem instance. OR if using the Nuxwdog watchdog: The configuration file is stored in the cache when the instance is started. Any changes made to the instance through the Console are changed in the cached version of the file. When the server is stopped or restarted, the configuration file stored in the cache is written to disk. Stop the server before editing the configuration file or the changes will be overwritten by the cached version when the server is stopped. Open the /var/lib/pki/instance_name/subsystem_type/conf directory. Open the CS.cfg file in a text editor. Edit the parameters in the file, and save the changes. Start the subsystem instance. OR if using the Nuxwdog watchdog: 9.2.3. Overview of the CS.cfg configuration file Each subsystem instances has its own main configuration file, CS.cfg , which contains all of the settings for the instance, such as plugins and Java classes for configuration. The parameters and specific settings are different depending on the type of subsystem, but, in a general sense, the CS.cfg file defines these parts of the subsystem instance: Basic subsystem instance information, like its name, port assignments, instance directory, and hostname Logging Plug-ins and methods to authenticate to the instance's user directory (authorization) The security domain to which the instance belongs Subsystem certificates Other subsystems used by the subsystem instance Database types and instances used by the subsystem Settings for PKI-related tasks, like the key profiles in the TKS, the certificate profiles in the CA, and the required agents for key recovery in the KRA Many of the configuration parameters (aside from the ones for PKI tasks) are very much the same between the CA, OCSP, KRA, and TKS because they all use a Java-based console, so configuration settings which can be managed in the console have similar parameters. The CS.cfg file a basic parameter=value format. In the CS.cfg file, many of the parameter blocks have descriptive comments, commented out with a pound (#) character. Comments, blank lines, unknown parameters, or misspelled parameters are ignored by the server. Parameters that configure the same area of the instance tend to be grouped together into the same block. Example 9.1. Logging settings in the CS.cfg file Some areas of functionality are implemented through plugins, such as self-tests, jobs, and authorization to access the subsystem. For those parameters, the plugin instance has a unique identifier (since there can be multiple instances of even the same plugin called for a subsystem), the implementation plugin name, and the Java class. Example 9.2. Subsystem authorization settings NOTE The values for configuration parameters must be properly formatted, so they must obey two rules: The values that need to be localized must be in UTF8 characters. The CS.cfg file supports forward slashes (/) in parameter values. If a back slash (\) is required in a value, it must be escaped with a back slash, meaning that two back slashes in a row must be used. The following sections are snapshots of CS.cfg file settings and parameters. These are not exhaustive references or examples of CS.cfg file parameters. Also, the parameters available and used in each subsystem configuration file is very different, although there are similarities. 9.2.3.1. Basic subsystem settings Basic settings are specific to the instance itself, without directly relating to the functionality or behavior of the subsystem. This includes settings for the instance name, root directory, the user ID for the process, and port numbers. Many of the settings assigned when the instance is first installed or configured are prefaced with pkispawn . Example 9.3. Basic Instance Parameters for the CA: pkispawn file ca.cfg Important While information like the port settings is included in the CS.cfg file, it is not set in the CS.cfg . The server configuration is set in the server.xml file. The ports in CS.cfg and server.xml must match for a working RHCS instance. 9.2.3.2. Logging settings There are several different types of logs that can be configured, depending on the type of subsystem. Each type of log has its own configuration entry in the CS.cfg file. For example, the CA has this entry for signed audit logs, which allows log rotation, buffered logging, log signing, and log levels, among other settings: For more information about these parameters and their values, see Section 13.1, "Log settings" . As long as audit logging is enabled, these values do not affect compliance. 9.2.3.3. Authentication and authorization settings The CS.cfg file sets how users are identified to access a subsystem instance (authentication) and what actions are approved (authorization) for each authenticated user. A CS subsystem uses authentication plugins to define the method for logging into the subsystem. The following example shows an authentication instance named SharedToken that instantiates a JAVA plugin named SharedSecret . For some authorization settings, it is possible to select an authorization method that uses an LDAP database to store user entries, in which case the database settings are configured along with the plugin as shown below. For more information on securely configuring LDAP and an explanation of parameters, refer to Section 7.13.13, "Enabling TLS mutual authentication from CS to DS" . The parameters paths differ than what is shown there, but the same names and values are allowed in both places. The CA also has to have a mechanism for approving user requests. As with configuring authorization, this is done by identifying the appropriate authentication plugin and configuring an instance for it: 9.2.3.4. Subsystem certificate settings Several of the subsystems have entries for each subsystem certificate in the configuration file. 9.2.3.5. Settings for required subsystems At a minimum, each subsystem depends on a CA, which means that the CA (and any other required subsystem) has to be configured in the subsystem's settings. Any connection to another subsystem is prefaced by conn. and then the subsystem type and number. The following is an example "conn" section from a TPS instance's CS.cfg : 9.2.3.6. Database settings All of the subsystems use an LDAP directory to store their information. This internal database is configured in the internaldb parameters. Here is an example of the internaldb section from a CA's CS.cfg : In addition to the internaldb parameter, TPS introduces the tokendb parameters to contain more configuration settings relating to the smartcard tokens. For further information on securely configuring LDAP and an explanation of parameters, refer to Section 7.13.13, "Enabling TLS mutual authentication from CS to DS" . No additional configuration is necessary outside of what is done as part Section 7.13.13, "Enabling TLS mutual authentication from CS to DS" . 9.2.3.7. Enabling and configuring a publishing queue Part of the enrollment process includes publishing the issued certificate to any directories or files. This, essentially, closes out the initial certificate request. However, publishing a certificate to an external network can significantly slow down the issuance process -which leaves the request open. To avoid this situation, administrators can enable a publishing queue . The publishing queue separates the publishing operation (which may involve an external LDAP directory) from the request and enrollment operations, which uses a separate request queue. The request queue is updated immediately to show that the enrollment process is complete, while the publishing queue sends the information at the pace of the network traffic. The publishing queue sets a defined, limited number of threads that publish generated certificates, rather than opening a new thread for each approved certificate. Procedure Enabling the publishing queue by editing the CS.cfg file allows administrators to set other options for publishing, like the number of threads to use for publishing operations and the queue page size. Stop the CA server, so that you can edit the configuration files. Open the CA's CS.cfg file. Set the ca.publish.queue.enable to true. If the parameter is not present, then add a line as follows: Set other related publishing queue parameters: ca.publish.queue.maxNumberOfThreads sets the maximum number of threads that can be opened for publishing operations. The default is 3. ca.publish.queue.priorityLevel sets the priority for publishing operations. The priority value ranges from -2 (lowest priority) to 2 (highest priority). Zero (0) is normal priority and is also the default. ca.publish.queue.pageSize sets the maximum number of requests that can be stored in the publishing queue page. The default is 40. ca.publish.queue.saveStatus sets the interval to save its status every specified number of publishing operations. This allows the publishing queue to be recovered if the CA is restarted or crashes. The default is 200, but any non-zero number will recover the queue when the CA restarts. Setting this parameter to 0 disables queue recovery. TIP Setting ca.publish.queue.enable to false and ca.publish.queue.maxNumberOfThreads to 0 disables both the publishing queue and using separate threads for publishing issued certificates. Restart the CA server. 9.2.3.8. Settings for PKI tasks The CS.cfg file is used to configure the PKI tasks for every subsystem. The parameters are different for every single subsystem, without any overlap. For example, the KRA has settings for a required number of agents to recover a key. Review the CS.cfg file for each subsystem to become familiar with its PKI task settings; the comments in the file are a decent guide for learning what the different parameters are. The CA configuration file lists all of the certificate profiles and policy settings, as well as rules for generating CRLs. The TPS configures different token operations. The TKS lists profiles for deriving keys from different key types. The OCSP sets key information for different key sets. 9.2.3.9. Changing DN attributes in CA-issued certificates In certificates issued by the Certificate System, DNs identify the entity that owns the certificate. In all cases, if the Certificate System is connected with a Directory Server, the format of the DNs in the certificates should match the format of the DNs in the directory. It is not necessary that the names match exactly; certificate mapping allows the subject DN in a certificate to be different from the one in the directory. In the Certificate System, the DN is based on the components, or attributes, defined in the X.509 standard. Table 9.8, "Allowed characters for value types" lists the attributes supported by default. The set of attributes is extensible. Table 9.8. Allowed characters for value types Attribute Value Type Object Identifier cn DirectoryString 2.5.4.3 ou DirectoryString 2.5.4.11 o DirectoryString 2.5.4.10 c PrintableString , two-character 2.5.4.6 l DirectoryString 2.5.4.7 st DirectoryString 2.5.4.8 street DirectoryString 2.5.4.9 title DirectoryString 2.5.4.12 uid DirectoryString 0.9.2342.19200300.100.1.1 mail IA5String 1.2.840.113549.1.9.1 dc IA5String 0.9.2342.19200300.100.1.2.25 serialnumber PrintableString 2.5.4.5 unstructuredname IA5String 1.2.840.113549.1.9.2 unstructuredaddress PrintableString 1.2.840.113549.1.9.8 By default, the Certificate System supports the attributes identified in Table 9.8, "Allowed characters for value types" . This list of supported attributes can be extended by creating or adding new attributes. The syntax for adding additional X.500Name attributes, or components, is as follows: The value converter class converts a string to an ASN.1 value; this class must implement the netscape.security.x509.AVAValueConverter interface. The string-to-value converter class can be one of the following: netscape.security.x509.PrintableConverter converts a string to a PrintableString value. The string must have only printable characters. netscape.security.x509.IA5StringConverter converts a string to an IA5String value. The string must have only IA5String characters. netscape.security.x509.DirStrConverter converts a string to a DirectoryString . The string is expected to be in DirectoryString format according to RFC 2253. netscape.security.x509.GenericValueConverter converts a string character by character in the following order, from the smallest characterset to the largest: PrintableString IA5String BMPString Universal String An attribute entry looks like the following: 9.2.3.9.1. Adding new or custom attributes To add a new or proprietary attribute to the Certificate System schema, do the following: Stop the Certificate Manager. Open the /var/lib/pki/cs_instance/conf/ directory. Open the configuration file, CS.cfg . Add the new attributes to the configuration file. For example, to add three proprietary attributes, MYATTR1 that is a DirectoryString , MYATTR2 that is an IA5String , and MYATTR3 that is a PrintableString , add the following lines at the end of the configuration file: Save the changes, and close the file. Restart the Certificate Manager. Reload the enrollment page and verify the changes; the new attributes should show up in the form. To verify that the new attributes are in effect, request a certificate using the manual enrollment form. Enter values for the new attributes so that it can be verified that they appear in the certificate subject names. For example, enter the following values for the new attributes and look for them in the subject name: Open the agent services page, and approve the request. When the certificate is issued, check the subject name. The certificate should show the new attribute values in the subject name. 9.2.3.9.2. Changing the DER-encoding order It is possible to change the DER-encoding order of a DirectoryString , so that the string is configurable since different clients support different encodings. The syntax for changing the DER-encoding order of a DirectoryString is as follows: The possible encoding values are as follows: PrintableString IA5String UniversalString BMPString UTF8String For example, the DER-encoding ordered can be listed as follows: To change the DirectoryString encoding, do the following: Stop the Certificate Manager. Open the /var/lib/pki/cs_instance/conf/ directory. Open the CS.cfg configuration file. Add the encoding order to the configuration file. For example, to specify two encoding values, PrintableString and UniversalString , and the encoding order is PrintableString first and UniversalString , add the following line at the end of the configuration file: Save the changes, and close the file. Start the Certificate Manager. To verify that the encoding orders are in effect, enroll for a certificate using the manual enrollment form. Use John_Doe for the cn . Open the agent services page, and approve the request. When the certificate is issued, use the dumpasn1 tool to examine the encoding of the certificate. The cn component of the subject name should be encoded as a UniversalString . Create and submit a new request using John Smith for the cn . The cn component of the subject name should be encoded as a PrintableString . 9.2.3.10. Setting a CA to use a different certificate to sign CRLs A Certificate Manager uses the key pair corresponding to its OCSP signing certificate for signing certificates and certificate revocation lists (CRLs). To use a different key pair to sign the CRLs that the Certificate Manager generates, then a CRL signing certificate can be created. The Certificate Manager's CRL signing certificate must be signed or issued by itself. To enable a Certificate Manager to sign CRLs with a different key pair, do the following: Request and install a CRL signing certificate for the Certificate Manager using CMC. For details about requesting a system certificate, see Section 5.3.2.1 Obtaining system and server certificates in the Administration Guide (Common Criteria Edition) . Note that the profile used to obtain the certificate must use the keyUsageExtDefaultImpl class id and the corresponding keyUsageCrlSign parameter set to true : After you have generated the CRL signing certificate, install the certificate in the Certificate Manager's crypto module database. If using a HSM, follow Section 10.4, "Hardware Security Module" If you are not using a HSM, follow Section 10.5, "Importing a certificate into an NSS database" But instead of PKICertImport use the certutil command as described in Section 10.1.3, " certutil common commands" . Stop the Certificate Manager. Update the Certificate Manager's configuration to recognize the new key pair and certificate. Change to the Certificate Manager instance configuration directory. Open the CS.cfg file and add the following lines: nickname is the name assigned to the CRL signing certificate. instance_ID is the name of the Certificate Manager instance. If the installed CA is a RSA-based CA, signing_algorithm can be SHA256withRSA , SHA384withRSA , or SHA512withRSA . If the installed CA is an EC-based CA, signing_algorithm can be SHA256withEC , SHA384withEC , SHA512withEC . token_name is the name of the token used for generating the key pair and the certificate. If the internal/software token is used, use Internal Key Storage Token as the value. For example, the entries might look like this: Save the changes, and close the file. Restart the Certificate Manager. Now the Certificate Manager is ready to use the CRL signing certificate to sign the CRLs it generates. 9.2.3.11. Configuring CRL generation from cache in CS.cfg The CRL cache is a simple mechanism that allows cert revocation information to be taken from a collection of revocation information maintained in memory. For best performance, it is recommended that this feature be enabled, which already represents the default behavior. The following configuration information (which is the default) is presented for information purposes or if changes are desired. Stop the CA server. Open the CA configuration directory. Edit the CS.cfg file, setting the enableCRLCache and enableCacheRecovery parameters to true: Start the CA server. 9.2.3.12. Configuring update intervals for CRLs in CS.cfg The following describes how to configure the CRL system flexibly to reflect desired behavior. The goal is to configure CRL updates according to some schedule of two types. One type allows for a list of explicit times and the other consists of a length of time interval between updates. There is also a hybrid scenario where both are enabled to account for drift. The Note entry just below actually represents the default out of the box scenario. The default scenario is listed as follows: Deviate from this only when a more detailed and specific update schedule is desired. The rest of the section will talk about how that is accomplished. Configuring the settings for full and delta CRLs in the CS.cfg file involves editing parameters. Table 9.9. CRL extended interval parameters Parameter Description Accepted Values updateSchema Sets the ratio for how many delta CRLs are generated per full CRL An integer value enableDailyUpdates Enables and disables setting CRL updates based on set times true or false enableUpdateInterval Enables and disables setting CRL updates based on set intervals true or false dailyUpdates Sets the times the CRLs should be updated A comma-delimited list of times autoUpdateInterval Sets the interval in minutes to update the CRLs An integer value autoUpdateInterval.effectiveAtStart Allows the system to attempt to use the new value of auto update immediately instead of waiting for the currently scheduled nextUpdate time true or false nextUpdateGracePeriod Adds the time in minutes to the CRL validity period to ensure that CRLs remain valid throughout the publishing or replication period An integer value refreshInSec Sets the periodicity in seconds of the thread on the clone OCSP to check LDAP for any updates of the CRL An integer value Important The autoUpdateInterval.effectiveAtStart parameter requires a system restart in order for a new value to apply. The default value of this parameter is false, it should only be changed by users who are sure of what they are doing. Procedure: How to configure CRL update intervals in CS.cfg Stop the CA server. Change to the CA configuration directory. Edit the CS.cfg file, and add the following line to set the update interval: The default interval is 1, meaning a full CRL is generated every time a CRL is generated. The updateSchema interval can be set to any integer. Set the update frequency, either by specifying a cyclical interval or set times for the updates to occur: Specify set times by enabling the enableDailyUpdates parameter, and add the desired times to the dailyUpdates parameter: This field sets a daily time when the CRL should be updated. To specify multiple times, enter a comma-separated list of times, such as 01:50,04:55,06:55 . To enter a schedule for multiple days, enter a comma-separated list to set the times within the same day, and then a semicolon separated list to identify times for different days. For example, set 01:50,04:55,06:55;02:00,05:00,17:00 to configure revocation on Day 1 of the cycle at 1:50am, 4:55am, and 6:55am and then Day 2 at 2am, 5am, and 5pm. Specify intervals by enabling the enableUpdateInterval parameter, and add the required interval in minutes to the autoUpdateInterval parameter: Set the following parameters depending on your environment: If you run a CA without an OCSP subsystem, set: If you run a CA with an OCSP subsystem, set: The ca.crl.MasterCRL.nextUpdateGracePeriod parameter defines the time in minutes, and the value must be big enough to enable the CA to propagate the new CRL to the OCSP. You must set the parameter to a non-zero value. If you additionally have OCSP clones in your environment, also set: The ocsp.store.defStore.refreshInSec parameter sets the frequency in seconds with which the clone OCSP instances are informed of CRL updates through LDAP replication updates from the master OCSP instance. See Table 9.9, "CRL extended interval parameters" for details on the parameters. Restart the CA server. NOTE Schedule drift can occur when updating CRLs by interval. Typically, drift occurs as a result of manual updates and CA restarts. To prevent schedule drift, set both enableDailyUpdates and enableUpdateInterval parameters to true, and add the required values to autoUpdateInterval and dailyUpdates : Only one dailyUpdates value will be accepted when updating CRLs by interval. The interval updates will resynchronize with the dailyUpdates value every 24 hours preventing schedule drift. 9.2.3.13. Changing the access control settings for the subsystem By default, access control rules are applied by evaluating deny rules first and then by evaluating allow rules. To change the order, change the authz.evaluateOrder parameter in the CS.cfg . Additionally, access control rules can be evaluated from the local web.xml file (basic ACLs) or more complex ACLs can be accessed by checking the LDAP database. The authz.sourceType parameter identifies what type of authorization to use. Note Always restart the subsystem after editing the CS.cfg file to load the updated settings. 9.2.3.14. Configuring ranges for requests and serial numbers When random serial numbers are not used, in case of cloned systems, administrators could specify the ranges Certificate System will use for requests and serial numbers in the /etc/pki/instance_name/subsystem/CS.cfg file: Note Certificate System supports BigInteger values for the ranges. 9.2.3.15. Setting requirement for pkiconsole to use TLS client certificate authentication Note pkiconsole is being deprecated and will be replaced by a new browser-based UI in a future major release. Although pkiconsole will continue to be available until the replacement UI is released, we encourage using the command line equivalent of pkiconsole at this time, as the pki CLI will continue to be supported and improved upon even when the new browser-based UI becomes available in the future. Edit the CS.cfg file of each subsystem, search for the authType parameter and set it as follows: 9.2.3.16. Changing the signing algorithms The signing algorithms for various PKI objects (certificates, CRLs, and OCSP responses) are first set at the time of installation via the pkispawn configuration file. It is then possible to change these settings post-installation, by editing the CS.cfg file of the instance involved, as follows: CA: default signing algorithm for signing certificates Open the CA's CS.cfg , and edit ca.signing.defaultSigningAlgorithm to assign the desired signing algorithm. For example: ca.signing.defaultSigningAlgorithm=SHA256withRSA CA: default signing algorithm for signing CRLs Open the CA's CS.cfg , and edit ca.crl.MasterCRL.signingAlgorithm to assign the desired signing algorithm. For example: ca.crl.MasterCRL.signingAlgorithm=SHA256withRSA CA: default signing algorithm for signing OCSP responses Open the CA's CS.cfg , and edit ca.ocsp_signing.defaultSigningAlgorithm to assign the desired signing algorithm. For example: ca.ocsp_signing.defaultSigningAlgorithm=SHA256withRSA OCSP: default signing algorithm for signing OCSP responses Open the OCSP's CS.cfg , and edit ocsp.signing.defaultSigningAlgorithm to assign the desired signing algorithm. For example: ocsp.signing.defaultSigningAlgorithm=SHA256withRSA Make sure to stop the CS instance before editing its CS.cfg file, and to restart it once you are done with the changes. Note Please see Section 3.3, "Allowed hash functions" . 9.2.3.17. Disabling the direct CA-OCSP CRL publishing When configuring the OCSP manager to use an LDAP directory, you need to disable the direct CA->OCSP CRL publishing method : Stop the SubCA: Edit the CA's CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg ) and set the following to false : For example: Start the CA for the configuration change to take effect: 9.2.3.18. Enabling client certificate verification using latest CRL within OCSP Note This is an alternative method for enabling revocation checks in an OCSP subsystem. The preferred method is detailed in Section 7.13.10.2, "Enabling OCSP for the CA / KRA / TKS / TPS" . When set up correctly, the OCSP system has the advantage of having the latest CRL internally to verify its own clients. To do so, you need to enable both the ocsp.store.ldapStore.validateConnCertWithCRL and auths.revocationChecking.enabled parameters. Edit the OCSP's CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-OCSP-subca/ca/conf/CS.cfg ) and set the following: In addition to enabling these two parameters in the CS.cfg , the enableOCSP parameter should remain set to false in /var/lib/pki/<ocsp instance directory>/conf/server.xml . 9.2.3.19. Enabling client certificate and CRL publishing for the CA Red Hat Certificate System enables certificate authorities to publish certificates and, certificate revocation lists (CRLs). To configure the Certificate Authority (CA) settings for publishing certificates or Certificate Revocation Lists (CRLs) in the CS.cfg configuration file, follow this example: Example of CA's CS.cfg file with certificate and CRL publishing enabled: Example of CA's CS.cfg file with Certificate publishing disabled: Example of CA's CS.cfg file with CRL publishing disabled: 9.3. Managing system passwords As explained in Section 2.3.10, "Passwords and watchdog (nuxwdog)" , Certificate System uses passwords bind to servers or to unlock tokens when the server starts. The password.conf file stores system passwords in plain text. However, some administrators prefer to remove the password file entirely to allow nuxwdog to prompt for manual entry of each password initially and store for auto-restart in case of an unplanned shutdown. When a Certificate System instance starts, the subsystem automatically checks for the password.conf file. If the file exists, then it uses those passwords to connect to other services, such as the internal LDAP database. If that file does not exist, then the watchdog daemon prompts for all of the passwords required by the PKI server to start. Note If the password.conf file is present, the subsystem assumes that all the required passwords are present and properly formatted in clear text. If any passwords are missing or wrongly formatted, then the system fails to start correctly. The required passwords are listed in the cms.passwordlist parameter in the CS.cfg file: Note The cms.password.ignore.publishing.failure parameter allows a CA subsystem to start up successfully even if it has a failed connection to one of its LDAP publishing directories. For the CA, KRA, OCSP, and TKS subsystems, the default expected passwords are: internal for the NSS database internaldb for the internal LDAP database replicationdb for the replication password Any passwords to access external LDAP databases for publishing (CA only) Note If a publisher is configured after the password.conf file is removed, nothing is written to the password.conf file. Unless nuxwdog is configured, the server will not have access to the prompts for the new publishing password the time that the instance restarts. Any external hardware token passwords For the TPS, this prompts for three passwords: internal for the NSS database tokendbpass for the internal LDAP database Any external hardware token passwords This section describes the two mechanisms provided for Certificate System to retrieve these passwords: password.conf file (the default) nuxwdog (watchdog) 9.3.1. Configuring the password.conf file Note This section is here for reference only. Correct and secure operation must involve using the nuxwdog watchdog. Please refer to Section 9.3.2, "Using the Certificate System watchdog service" to enable nuxwdog , as it is required for full compliance. By default, passwords are stored in a plain text file, password.conf , in the subsystem conf/ directory. Therefore, it is possible to modify them simply through a text editor. The list of passwords stored in this file includes the following: The bind password used by the Certificate System instance to access and update the internal database. The password to the HSM The bind password used by the Certificate System instance to access the authentication directory, in case of CMC Shared Token. The bind password used by the subsystem to access and update the LDAP publishing directory; this is required only if the Certificate System instance is configured for publishing certificates and CRLs to an LDAP-compliant directory. the bind password used by the subsystem to access its replication database. For a TPS instance, the bind password used to access and update the token database. The password.conf file also contains the token passwords needed to open the private keys of the subsystem. The name and location password file to use for the subsystem is configured in the CS.cfg file: The internal password store and replication database have randomly-generated PINs which were set when the subsystem was installed and configured; the internal LDAP database password was defined by the administrator when the instance was configured. The password entries in the password.conf file are in the following format: For example: In cases where an HSM token is required, use the following format: For example: Example content of a password.conf file: 9.3.2. Using the Certificate System watchdog service In Certificate System, the watchdog service is used to start services which require passwords to access the security database in order to start. In case there is a requirement not to store the unencrypted passwords on the system, the watchdog service: prompts for the relevant passwords during server startup and caches them. uses cached passwords in case of a failure when the server is automatically restarted due to a crash. 9.3.2.1. Enabling the watchdog service To enable the watchdog service: If you also want to use the Shared Secret feature on this host, enable the Shared Secret feature as described in Section 9.6.3, "Enabling the CMC Shared Secret feature" . Backup the server.xml and password.conf files from the /var/lib/pki/instance_name/conf/ directory. For example: Stop and disable the Certificate System instance's service: If you use a Hardware Security Module (HSM), enable the watchdog service to prompt for the password of the hardware token: Display the name of the hardware token: The highlighted string in the example is the hardware token name. Add the cms.tokenList parameter to the /var/lib/pki/instance_name/conf/ca/CS.cfg file and set it to the name of the hardware token. For example: Enable the watchdog configuration for the instance: Alternatively, enable the watchdog for all instances: For further details, see the pki-server-nuxwdog(8) man page. By default, nuxwdog starts the server as the user configured in the TOMCAT_USER variable in the /etc/sysconfig/pki-tomcat file. Optionally, to modify the user and group: Copy the watchdog systemd unit file of the instance to the /etc/systemd/system/ directory: Note Unit files in the /etc/systemd/system/ directory have a higher priority and are not replaced during updates. Add the following entries to the [Service] section in the /etc/pki/instance_name/nuxwdog.conf file: Reload the systemd configuration: Enable the Certificate System service that uses the watchdog: Optionally: See Section 9.3.2.3, "Verifying that the Certificate System watchdog service is enabled" . To start the Certificate System instance, run the following command and enter the prompted passwords: 9.3.2.2. Starting and stopping Certificate System with the watchdog enabled For information how to manage a Certificate System instance refer to Section 2.2.3, "Execution management (systemctl)" . 9.3.2.3. Verifying that the Certificate System watchdog service is enabled To verify that the watchdog service is enabled: Verify that the pki-tomcatd-nuxwdog service is enabled: Verify that the pki-tomcatd service is disabled: In the /etc/pki/instance_name/server.xml file: verify that the passwordFile parameter refers to the CS.cfg file. For example: verify that the passwordClass parameter is set to com.netscape.cms.tomcat.NuxwdogPasswordStore : 9.3.2.4. Disabling the watchdog service To disable the watchdog service: Stop and disable the Certificate System instance's service that uses the watchdog: Enable the regular service without watch dog for the instance: Disable the watchdog configuration for the instance: For further details, see the pki-server-nuxwdog(8) man page. Restore the password.conf file to its original location. For example: Start the Certificate System instance: 9.4. Configuration files for the tomcat engine and web services All of the user and administrative (administrators, agents, and auditors) services for the subsystems are accessed over web protocols. This section discusses the two major sets of configuration files that apply to all Red Hat Certificate System subsystems (CA, KRA, OCSP, TKS, and TPS): /var/lib/pki/instance_name/conf/server.xml provides the configuration for the Tomcat engine. /usr/share/pki/subsystem_type/webapps/WEB-INF/web.xml provides the configuration for the web services offered by this instance. 9.4.1. Tomcatjss Note The later subsections include important configuration information on required changes to parameter values. Ensure they are followed for strict compliance. The following configuration in the server.xml file found in the example pki-tomcat/conf directory can be used to explain how Tomcatjss fits into the entire Certificate System ecosystem. Portions of the Connector entry for the secure port and its corresponding SSLHostConfig parameters are shown below. In the server.xml configuration file for the Tomcat engine, there is this Connector configuration element that contains the pointer to the tomcatjss implementation, which can be plugged into the sslImplementation property of this Connector object. Each key parameter element is explained in the subsections below. 9.4.1.1. TLS cipher configuration Red Hat Certificate System supports TLS 1.2 cipher suites. These are defined in the instance's server.xml when the CS instance acts as a server, and in CS.cfg when the CS instance acts as a client. If you need to configure the ciphers, refer to the corresponding post-installation section in Section 7.13.11, "Update the ciphers list" . For information on the supported ciphers, refer to Section 3.1.1, "Supported cipher suites" 9.4.1.2. Enabling automatic revocation checking on the CA Revocation checks are supported/enabled in the CA in the same way as all other RHCS subsystems (see Section 9.4.1.3, "Enabling certificate revocation checking for RHCS subsystems" ). In general, RHCS recommends OCSP for more efficient certificate revocation checks. However, one thing that sets the CA apart from the other CS subsystems is that the CAs are the creators of the CRLs for the certificates they issue, and therefore are the sources of the CRLs that are needed by the OCSP subsystems. For this reason, they need to be able to start up independently before the OCSP or other RHCS subsystems. In the case when the CA's own internal LDAP server-cert is issued by the CA itself, it is very important that the CRL Distribution Point extension is used instead of the AIA (OCSP) so as not to fall victim to the chicken and egg issue during startup of the CA. 9.4.1.2.1. Configure support for CRL Distribution Point For the purpose of mitigating propagation and reducing storage of large CRLs, it is important to note that RHCS recommends partitioning of the CRL to allow the certificates that utilize the CRL Distribution Point to be grouped into a smaller subset. See Section 7.3.8, "Configure support for CRL Distribution Point" for information on how to set up the CA to support partitioned CRL for server-certs that are issued using the CRL Distribution Point certificate enrollment profile. 9.4.1.3. Enabling certificate revocation checking for RHCS subsystems Certificate revocation check is a vital part of certificate validation in a PKI environment. RHCS provides two types of certificate revocation validation methods: OCSP and CRL by means of detecting/processing either the AIA (OCSP) or the CRL Distribution Point extension of its peer certificate. RHCS recommends OCSP for more efficient certificate revocation checks. Note The usage of CRL Distribution Point is unavoidable in cases when the use of OCSP is not plausible. Such a case can be exemplified in Section 9.4.1.2, "Enabling automatic revocation checking on the CA" above. Applications (in this case, PKI subsystems) adopting OCSP need to know how to contact the OCSP system in order to verify the certificates in question. The PKI subsystems do not have OCSP checking enabled by default. You can enable OCSP checking for a PKI subsystem by editing its server.xml file. NOTE If you have configured the subsystem to use an SSL/TLS connection with its internal database, then the SSL/TLS server certificate of the LDAP internal database must be recognized by the OCSP responder. If the OCSP responder does not recognize the LDAP server certificate, then the subsystem will not start properly. This configuration is covered in the Red Hat Certificate System Planning, Installation and Deployment Guide , since subsystem-LDAP SSL/TLS server connections are configured as part of the subsystem setup. The following procedure aims to configure your PKI subsystem instances to verify its peer certificates according to their AIA extensions using OCSP. This method of OCSP certificate verification is more flexible than the default static OCSP responder URL. Procedure Stop the instance: Edit the /var/lib/pki/<instance_name>/conf/server.xml file to configure the Connector name="Secure" section: Set the enableOCSP parameter to true Make sure you remove these two parameters and their assigned values: ocspResponderURL ocspResponderCertNickname For example: Start the instance: Note By default, all PKI system certificates created during installation are generated with an AIA (Authority Information Access) extension pointing to its issuing CA's internal OCSP service. If you follow the steps in Section 9.4.1.4, "Adding an AIA extension to a certificate" , to point to the external OCSP prior to installing PKI subsystems, then all their certificates (and all other certificates issued by its CA thereon) should bear the correct AIA pointing to the external OCSP instead. 9.4.1.3.1. Setting trust of the OCSP signing certificate Each OCSP signing certificate must chain up to a trusted root in the Certificate System's NSS database. In RHCS, during validation, each OCSP response includes the OCSP signer certificate chain. Therefore, the following consideration is required. If the OCSP responder being used has been configured to provide the entire certificate chain of the OCSP signing certificate with each OCSP response, as is the default case for RHCS OCSP services, then no further action is required. NSS knows how to validate this chain from the given information. If on the other hand the OCSP is known to not return the full chain, you then need to import the chain manually during installation setup. For details, see Section 10.5.3, "Importing an OCSP responder" . The Certificate System OCSP responder already includes the chain with every response. This includes the Certificate System external OCSP responder and the internal OCSP service that comes with each CA. This behavior is by default and cannot be changed. 9.4.1.3.2. OCSP parameters for server.xml The following table provides information on each parameter relevant to certificate revocation checks (that is, OCSP and CRL) in the server.xml file. Table 9.10. OCSP parameters for server.xml Parameter Description enableRevocationCheck (also known as enableOCSP) Enables (or disables) revocation checking for the subsystem. ocspResponderURL Sets the URL where the OCSP requests are sent. For an OCSP Manager, this can be another OCSP service in another OCSP or in a CA. For a TKS or KRA, this always points to an external OCSP service in an OCSP or a CA. ocspResponderCertNickname Sets the nickname of the signing certificate for the responder, either the OCSP signing certificate or the CA's OCSP signing certificate. The certificate must be imported into the subsystem's NSS database and have the appropriate trust settings set. ocspCacheSize Sets the maximum number of cache entries. ocspMinCacheEntryDuration Sets minimum seconds before another fetch attempt can be made. For example, if this is set to 120, then the validity of a certificate cannot be checked again until at least 2 minutes after the last validity check. ocspMaxCacheEntryDuration Sets the maximum number of seconds to wait before making the fetch attempt. This prevents having too large a window between validity checks. ocspTimeout Sets the timeout period, in seconds, for the OCSP request. NOTE If a nextUpdate field is sent with the OCSP response, it can affect the fetch time with ocspMinCacheEntryDuration and ocspMaxCacheEntryDuration as follows: If the value in nextUpdate has been reached before the value set in ocspMinCacheEntryDuration , the fetch will not be started until the value set in ocspMinCacheEntryDuration has been reached. If ocspMinCacheEntryDuration has been reached, the server checks if the value in nextUpdate has been reached. If the value has been reached, the fetch will happen. Regardless of the value in nextUpdate , if the setting in ocspMaxCacheEntryDuration has been reached, the fetch will happen. NOTE Due to the underlying SSL/TLS session caches kept by NSS, which follows the industry standard to prevent very expensive full handshakes as well as provide stronger privacy, OCSP requests are only made when NSS determines that a validation is required. The SSL/TLS session caches are independent of the OCSP status cache. Once NSS determines that an OCSP request is to be made, the request will be made and the response received will be kept in the OCSP certificate status cache. Due to the SSL/TLS session caches, these OCSP cache parameters only come into play when allowed by NSS. 9.4.1.4. Adding an AIA extension to a certificate By default, unless explicitly specified, the CA issues certificates with an AIA (Authority Information Access) extension pointing to the CA's own internal OCSP. Once you have set up an OCSP instance, you can configure the CA to start issuing certificates with an AIA extension that points to the OCSP instance instead. Prerequisite You are logged in as root user. Procedure Stop the CA: Edit the CA's CS.cfg and set the ca.defaultOcspUri variable to point to the OCSP. For example: Start the CA: Note The OCSP URL of each subsystem (e.g. KRA) is set in its server.xml file by default. When enabled, this directs the RHCS instance to use the static URL when looking up a certificate status, instead of the AIA extension embedded in the peer certificate. For more information on using the AIA extension, refer to Section 9.4.1.3, "Enabling certificate revocation checking for RHCS subsystems" . 9.4.1.5. Adding a CRL Distribution Point extension to a certificate To add the CRL Distribution Point extension to a certificate, you need to use a certificate enrollment profile equipped with the CRL Distribution Point extension. To enable a certificate enrollment profile, see Section 7.3.8.3, "CA's enrollment profile configuration with CRL Distribution Points" . Note that the CA needs to be configured to handle CRL Distribution Points for such profiles to work. See Section 7.3.8, "Configure support for CRL Distribution Point" . 9.4.2. Session timeout When a user connects to PKI server through a client application, the server will create a session to keep track of the user. As long as the user remains active, the user can execute multiple operations over the same session without having to re-authenticate. Session timeout determines how long the server will wait since the last operation before terminating the session due to inactivity. Once the session is terminated, the user will be required to re-authenticate to continue accessing the server, and the server will create a new session. There are two types of timeouts: TLS session timeout HTTP session timeout Due to differences in the way clients work, the clients will be affected differently by these timeouts. Note Certain clients have their own timeout configuration. For example, Firefox has a keep-alive timeout setting. For details, see http://kb.mozillazine.org/Network.http.keep-alive.timeout . If the value is different from the server's setting for TLS Session Timeout or HTTP Session Timeout, different behavior can be observed. 9.4.2.1. TLS session timeout A TLS session is a secure communication channel over a TLS connection established through TLS handshake protocol. PKI server generates audit events for TLS session activities. The server generates an ACCESS_SESSION_ESTABLISH audit event with Outcome=Success when the connection is created. If the connection fails to be created, the server will generate an ACCESS_SESSION_ESTABLISH audit event with Outcome=Failure . When the connection is closed, the server will generate an ACCESS_SESSION_TERMINATED audit event. TLS session timeout (that is TLS connection timeout) is configured in the keepAliveTimeout parameter in the Secure Connector element in the /etc/pki/instance/server.xml file: By default the timeout value is set to 300000 milliseconds (that is 5 minutes). To change this value, edit the /etc/pki/instance/server.xml file and then restart the server. Note Note that this value will affect all TLS connections to the server. A large value may improve the efficiency of the clients since they can reuse existing connections that have not expired. However, it may also increase the number of connections that the server has to support simultaneously since it takes longer for abandoned connections to expire. 9.4.2.2. HTTP session timeout An HTTP session is a mechanism to track a user across multiple HTTP requests using HTTP cookies. PKI server does not generate audit events for the HTTP sessions. Note For the purpose of auditing consistency, set the session-timeout value in this section to match the keepAliveTimeout value in Section 9.4.2.1, "TLS session timeout" . For example if keepAliveTimeout was set to 300000 (5 minutes), then set session-timeout to 30 . The HTTP session timeout can be configured in the session-timeout element in the /etc/pki/instance/web.xml file: By default the timeout value is set to 30 minutes. To change the value, edit the /etc/pki/instance/web.xml file and then restart the server. Note Note that this value affects all sessions in all web applications on the server. A large value may improve the experience of the users since they will not be required to re-authenticate or view the access banner again so often. However, it may also increase the security risk since it takes longer for abandoned HTTP sessions to expire. 9.4.2.3. Session timeout for PKI Web UI PKI Web UI is an interactive web-based client that runs in a browser. Currently it only supports client certificate authentication. When the Web UI is opened, the browser may create multiple TLS connections to a server. These connections are associated to a single HTTP session. To configure a timeout for the Web UI, see Section 9.4.2.2, "HTTP session timeout" . The TLS session timeout is normally irrelevant since the browser caches the client certificate so it can recreate the TLS session automatically. When the HTTP session expires, the Web UI does not provide any immediate indication. However, the Web UI will display an access banner (if enabled) before a user executes an operation. 9.4.2.4. Session timeout for PKI Console PKI Console is an interactive standalone graphical UI client. It supports username/password and client certificate authentication. When the console is started, it will create a single TLS connection to the server. The console will display an access banner (if enabled) before opening the graphical interface. Unlike the Web UI, the console does not maintain an HTTP session with the server. To configure a timeout for the console, see Section 9.4.2.1, "TLS session timeout" . The HTTP session timeout is irrelevant since the console does not use HTTP session. When the TLS session expires, the TLS connection will close, and the console will exit immediately to the system. If the user wants to continue, the user will need to restart the console. 9.4.2.5. Session timeout for PKI CLI PKI CLI is a command-line client that executes a series of operations. It supports username/password and client certificate authentication. When the CLI is started, it will create a single TLS connection to the server and an HTTP session. The CLI will display an access banner (if enabled) before executing operations. Both timeouts are generally irrelevant to PKI CLI since the operations are executed in sequence without delay and the CLI exits immediately upon completion. However, if the CLI waits for user inputs, is slow, or becomes unresponsive, the TLS session or the HTTP session may expire and the remaining operations fail. If such delay is expected, see Section 9.4.2.1, "TLS session timeout" and Section 9.4.2.2, "HTTP session timeout" to accommodate the expected delay. 9.4.3. Removing unused interfaces from web.xml (CA only) Several legacy interfaces (for features like bulk issuance or the policy framework) are still included in the CA's web.xml file. However, since these features are deprecated and no longer in use, then they can be removed from the CA configuration to increase security. Procedure Stop the CA. OR if using the Nuxwdog watchdog: Open the web files directory for the CA. For example: Back up the current web.xml file. Edit the web.xml file and remove the entire <servlet> entries for each of the following deprecated servlets: caadminEnroll cabulkissuance cacertbasedenrollment caenrollment caProxyBulkIssuance For example, remove the caadminEnroll servlet entry: After removing the servlet entries, remove the corresponding <servlet-mapping> entries. Remove three <filter-mapping> entries for an end-entity request interface. Start the CA again. OR if using the Nuxwdog watchdog: 9.4.4. Customizing Web Services All of the subsystems (with the exception of the TKS) have some kind of a web-based services page for agents and some for other roles, like administrators or end entities. These web-based services pages use basic HTML and JavaScript, which can be customized to use different colors, logos, and other design elements to fit in with an existing site or intranet. 9.4.4.1. Customizing subsystem web applications Each PKI subsystem has a corresponding web application, which contains: HTML pages containing texts, JavaScript codes, page layout, CSS formatting, and so on A web.xml file, which defines servlets, paths, security constraints, and other Links to PKI libraries. The subsystem web applications are deployed using context files located in the /var/lib/pki/pki-tomcat/conf/Catalina/localhost/ directory, for example, the ca.xml file: The docBase points to the location of the default web application directory, /usr/share/pki/ . To customize the web application, copy the web application directory into the instance's webapps directory: Then change the docBase to point to the custom web application directory relative from the webapps directory: The change will be effective immediately without the need to restart the server. To remove the custom web application, simply revert the docBase and delete the custom web application directory: 9.4.4.2. Customizing the Web UI theme The subsystem web applications in the same instance share the same theme, which contains: CSS files, which determine the global appearance Image files including logo, icons, and other Branding properties, which determine the page title, logo link, title color, and other. The Web UI theme is deployed using the pki.xml context file in the /var/lib/pki/pki-tomcat/conf/Catalina/localhost/ directory: The docBase points to the location of the default theme directory, /usr/share/pki/ . To customize the theme, copy the default theme directory into the pki directory in the instance's webapps directory: Then change the docBase to point to the custom theme directory relative from the webapps directory: The change will be effective immediately without the need to restart the server. To remove the custom theme, simply revert the docBase and delete the custom theme directory: 9.4.4.3. Customizing TPS token state labels The default token state labels are stored in the /usr/share/pki/tps/conf/token-states.properties file and described in Section 2.5.2.4.1.4, "Token state and transition labels" . To customize the labels, copy the file into the instance directory: The change will be effective immediately without the need to restart the server. To remove the customized labels, simply delete the customized file: 9.5. Using an access banner In Certificate System, Administrators can configure a banner with customizable text. The banner will be displayed in the following situations: Application When the banner is displayed PKI Console Before the console is displayed. After the session has expired. Web interface When you connect to the web interface. After the session expired. pki command-line utility Before the actual operation proceeds. You can use the banner to display important information to the users before they can use Certificate System. The user must agree to the displayed text to continue. Example 9.4. When the access banner is displayed The following example shows when the access banner is displayed if you are using the pki utility: 9.5.1. Enabling an access banner To enable the access banner, create the /etc/pki/instance_name/banner.txt file and enter the text to displayed. Important The text in the /etc/pki/instance_name/banner.txt file must use the UTF-8 format. To validate, see Section 9.5.4, "Validating the banner" . 9.5.2. Disabling an access banner To disable the access banner, either delete or rename the /etc/pki/instance_name/banner.txt file. For example: 9.5.3. Displaying the banner To display the currently configured banner: 9.5.4. Validating the banner To validate that the banner does not contain invalid characters: 9.6. Configuration for CMC This section describes how to configure Certificate System for Certificate Management over CMS (CMC). 9.6.1. Understanding how CMC works Before configuring CMC, read the following documentation to learn more about the subject: Section 2.4.1.1.2.2, "Enrolling with CMC" 5.3 Requesting and receiving certificates using CMC in the Administration Guide (Common Criteria Edition) . Chapter 3 Making Rules for Issuing Certificates (Certificate Profiles) in the Administration Guide (Common Criteria Edition) . 9.6.2. Enabling the PopLinkWitnessV2 feature For a high-level security on the Certificate Authority (CA), enable the following option in the /var/lib/pki/instance_name/ca/conf/CS.cfg file: 9.6.3. Enabling the CMC Shared Secret feature To enable the shared token feature in a Certificate Authority (CA): If the watchdog service is enabled on the host, temporarily disable it. See Section 9.3.2.4, "Disabling the watchdog service" . Add the shrTok attribute to Directory Server's schema: If the system keys are stored on a Hardware Security Module (HSM), set the cmc.token parameter in the /var/lib/pki/instance_name/ca/conf/CS.cfg file. For example: Enable the shared token authentication plugin by adding the following settings into the /var/lib/pki/instance_name/ca/conf/CS.cfg file: Set the nickname of an RSA issuance protection certificate in the ca.cert.issuance_protection.nickname parameter in the /var/lib/pki/instance_name/ca/conf/CS.cfg file. For example: This step is: Optional if you use an RSA certificate in the ca.cert.subsystem.nickname parameter. Required if you use an ECC certificate in the ca.cert.subsystem.nickname parameter. Important If the ca.cert.issuance_protection.nickname parameter is not set, Certificate System automatically uses the certificate of the subsystem specified in the ca.cert.subsystem.nickname . However, the issuance protection certificate must be an RSA certificate. Restart Certificate System: When the CA starts, Certificate System prompts for the LDAP password used by the Shared Token plugin. If you temporarily disabled the watchdog service at the beginning of this procedure, re-enable it. See Section 9.3.2.1, "Enabling the watchdog service" . Note For information on how to use the CMC Shared Token, see 8.4 "CMC SharedSecret authentication" in the Administration Guide (Common Criteria Edition) . 9.6.4. Enabling CMCRevoke for the Web User Interface As described in 6.2.1 "Performing a CMC Revocation" in the Administration Guide (Common Criteria Edition) , there are two ways to submit CMC revocation requests. In cases when you use the CMCRevoke utility to create revocation requests to be submitted through the web UI, add the following setting to the /var/lib/pki/instance_name/ca/conf/CS.cfg file:

Commands:
/var/lib/pki/instance_name/subsystem_type/conf
/var/lib/pki/instance_name/ca/conf
pki-server stop instance_name
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
pki-server start instance_name
systemctl start pki-tomcatd-nuxwdog@instance_name.service
#comment parameter=value
log.instance.SignedAudit._000=## log.instance.SignedAudit._001=## Signed Audit Logging log.instance.SignedAudit._002=## log.instance.SignedAudit._003=## To list available audit events: log.instance.SignedAudit._004=## USD pki-server ca-audit-event-find log.instance.SignedAudit._005=## log.instance.SignedAudit._006=## To enable/disable audit event: log.instance.SignedAudit._007=## USD pki-server ca-audit-event-enable/disable <event name> log.instance.SignedAudit._008=## log.instance.SignedAudit.bufferSize=512 log.instance.SignedAudit.enable=true log.instance.SignedAudit.events=ACCESS_SESSION_ESTABLISH,ACCESS_SESSION_TERMINATED,AUDIT_LOG_SIGNING,AUDIT_LOG_STARTUP,AUTH,AUTHORITY_CONFIG,AUTHZ,CERT_PROFILE_APPROVAL,CERT_REQUEST_PROCESSED,CERT_SIGNING_INFO,CERT_STATUS_CHANGE_REQUEST,CERT_STATUS_CHANGE_REQUEST_PROCESSED,CLIENT_ACCESS_SESSION_ESTABLISH,CLIENT_ACCESS_SESSION_TERMINATED,CMC_REQUEST_RECEIVED,CMC_RESPONSE_SENT,CMC_SIGNED_REQUEST_SIG_VERIFY,CMC_USER_SIGNED_REQUEST_SIG_VERIFY,CONFIG_ACL,CONFIG_AUTH,CONFIG_CERT_PROFILE,CONFIG_CRL_PROFILE,CONFIG_ENCRYPTION,CONFIG_ROLE,CONFIG_SERIAL_NUMBER,CONFIG_SIGNED_AUDIT,CONFIG_TRUSTED_PUBLIC_KEY,CRL_SIGNING_INFO,DELTA_CRL_GENERATION,FULL_CRL_GENERATION,KEY_GEN_ASYMMETRIC,LOG_PATH_CHANGE,OCSP_GENERATION,OCSP_SIGNING_INFO,PROFILE_CERT_REQUEST,PROOF_OF_POSSESSION,RANDOM_GENERATION,ROLE_ASSUME,SCHEDULE_CRL_GENERATION,SECURITY_DOMAIN_UPDATE,SELFTESTS_EXECUTION,SERVER_SIDE_KEYGEN_REQUEST,SERVER_SIDE_KEYGEN_REQUEST_PROCESSED log.instance.SignedAudit.expirationTime=0 log.instance.SignedAudit.fileName=/var/lib/pki/rhcs10-ECC-SubCA/logs/ca/signedAudit/ca_audit log.instance.SignedAudit.filters.CMC_SIGNED_REQUEST_SIG_VERIFY=(Outcome=Failure) log.instance.SignedAudit.filters.CMC_USER_SIGNED_REQUEST_SIG_VERIFY=(Outcome=Failure) log.instance.SignedAudit.filters.DELTA_CRL_GENERATION=(Outcome=Failure) log.instance.SignedAudit.filters.FULL_CRL_GENERATION=(Outcome=Failure) log.instance.SignedAudit.filters.OCSP_GENERATION=(Outcome=Failure) log.instance.SignedAudit.filters.RANDOM_GENERATION=(Outcome=Failure) log.instance.SignedAudit.flushInterval=5 log.instance.SignedAudit.level=1 log.instance.SignedAudit.logSigning=true log.instance.SignedAudit.maxFileSize=2000 log.instance.SignedAudit.pluginName=file log.instance.SignedAudit.rolloverInterval=2592000 log.instance.SignedAudit.signedAudit=_002=## log.instance.SignedAudit.signedAuditCertNickname=NHSM-CONN-XC:auditSigningCert cert-rhcs10-ECC-SubCA CA log.instance.SignedAudit.type=signedAudit
authz.impl._000=## authz.impl._001=## authorization manager implementations authz.impl._002=## authz.impl.BasicAclAuthz.class=com.netscape.cms.authorization.BasicAclAuthz authz.instance.BasicAclAuthz.pluginName=BasicAclAuthz
[DEFAULT] pki_admin_password=Secret.123 pki_client_pkcs12_password=Secret.123 pki_ds_password=Secret.123 Optionally keep client databases pki_client_database_purge=False Separated CA instance name and ports pki_instance_name=pki-ca pki_http_port=18080 pki_https_port=18443 This Separated CA instance will be its own security domain pki_security_domain_https_port=18443 Separated CA Tomcat ports pki_ajp_port=18009 pki_tomcat_server_port=18005
log.instance.SignedAudit._000=## log.instance.SignedAudit._001=## Signed Audit Logging log.instance.SignedAudit._002=## log.instance.SignedAudit._003=## To list available audit events: log.instance.SignedAudit._004=## USD pki-server ca-audit-event-find log.instance.SignedAudit._005=## log.instance.SignedAudit._006=## To enable/disable audit event: log.instance.SignedAudit._007=## USD pki-server ca-audit-event-enable/disable <event name> log.instance.SignedAudit._008=## log.instance.SignedAudit.bufferSize=512 log.instance.SignedAudit.enable=true log.instance.SignedAudit.events=ACCESS_SESSION_ESTABLISH,ACCESS_SESSION_TERMINATED,AUDIT_LOG_SIGNING,AUDIT_LOG_STARTUP,AUTH,AUTHORITY_CONFIG,AUTHZ,CERT_PROFILE_APPROVAL,CERT_REQUEST_PROCESSED,CERT_SIGNING_INFO,CERT_STATUS_CHANGE_REQUEST,CERT_STATUS_CHANGE_REQUEST_PROCESSED,CLIENT_ACCESS_SESSION_ESTABLISH,CLIENT_ACCESS_SESSION_TERMINATED,CMC_REQUEST_RECEIVED,CMC_RESPONSE_SENT,CMC_SIGNED_REQUEST_SIG_VERIFY,CMC_USER_SIGNED_REQUEST_SIG_VERIFY,CONFIG_ACL,CONFIG_AUTH,CONFIG_CERT_PROFILE,CONFIG_CRL_PROFILE,CONFIG_ENCRYPTION,CONFIG_ROLE,CONFIG_SERIAL_NUMBER,CONFIG_SIGNED_AUDIT,CONFIG_TRUSTED_PUBLIC_KEY,CRL_SIGNING_INFO,DELTA_CRL_GENERATION,FULL_CRL_GENERATION,KEY_GEN_ASYMMETRIC,LOG_PATH_CHANGE,OCSP_GENERATION,OCSP_SIGNING_INFO,PROFILE_CERT_REQUEST,PROOF_OF_POSSESSION,RANDOM_GENERATION,ROLE_ASSUME,SCHEDULE_CRL_GENERATION,SECURITY_DOMAIN_UPDATE,SELFTESTS_EXECUTION,SERVER_SIDE_KEYGEN_REQUEST,SERVER_SIDE_KEYGEN_REQUEST_PROCESSED log.instance.SignedAudit.expirationTime=0 log.instance.SignedAudit.fileName=/var/lib/pki/rhcs10-ECC-SubCA/logs/ca/signedAudit/ca_audit log.instance.SignedAudit.filters.CMC_SIGNED_REQUEST_SIG_VERIFY=(Outcome=Failure) log.instance.SignedAudit.filters.CMC_USER_SIGNED_REQUEST_SIG_VERIFY=(Outcome=Failure) log.instance.SignedAudit.filters.DELTA_CRL_GENERATION=(Outcome=Failure) log.instance.SignedAudit.filters.FULL_CRL_GENERATION=(Outcome=Failure) log.instance.SignedAudit.filters.OCSP_GENERATION=(Outcome=Failure) log.instance.SignedAudit.filters.RANDOM_GENERATION=(Outcome=Failure) log.instance.SignedAudit.flushInterval=5 log.instance.SignedAudit.level=1 log.instance.SignedAudit.logSigning=true log.instance.SignedAudit.maxFileSize=2000 log.instance.SignedAudit.pluginName=file log.instance.SignedAudit.rolloverInterval=2592000 log.instance.SignedAudit.signedAudit=_002=## log.instance.SignedAudit.signedAuditCertNickname=NHSM-CONN-XC:auditSigningCert cert-rhcs10-ECC-SubCA CA log.instance.SignedAudit.type=signedAudit
auths.impl.SharedToken.class=com.netscape.cms.authentication.SharedSecret auths.instance.SharedToken.pluginName=SharedToken auths.instance.SharedToken.dnpattern= auths.instance.SharedToken.ldap.basedn=ou=People,dc=example,dc=org auths.instance.SharedToken.ldap.ldapauth.authtype=BasicAuth auths.instance.SharedToken.ldap.ldapauth.bindDN=cn=Directory Manager auths.instance.SharedToken.ldap.ldapauth.bindPWPrompt=Rule SharedToken auths.instance.SharedToken.ldap.ldapauth.clientCertNickname= auths.instance.SharedToken.ldap.ldapconn.host=server.example.com auths.instance.SharedToken.ldap.ldapconn.port=636 auths.instance.SharedToken.ldap.ldapconn.secureConn=true auths.instance.SharedToken.ldap.ldapconn.version=3 auths.instance.SharedToken.ldap.maxConns= auths.instance.SharedToken.ldap.minConns= auths.instance.SharedToken.ldapByteAttributes= auths.instance.SharedToken.ldapStringAttributes= auths.instance.SharedToken.shrTokAttr=shrTok
authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz authz.instance.DirAclAuthz.ldap=internaldb authz.instance.DirAclAuthz.pluginName=DirAclAuthz authz.instance.DirAclAuthz.ldap._000=## authz.instance.DirAclAuthz.ldap._001=## Internal Database authz.instance.DirAclAuthz.ldap._002=## authz.instance.DirAclAuthz.ldap.basedn=dc=server.example.com-pki-ca authz.instance.DirAclAuthz.ldap.database=server.example.com-pki-ca authz.instance.DirAclAuthz.ldap.maxConns=15 authz.instance.DirAclAuthz.ldap.minConns=3 authz.instance.DirAclAuthz.ldap.ldapauth.authtype=SslClientAuth authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP Database authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname= authz.instance.DirAclAuthz.ldap.ldapconn.host=localhost authz.instance.DirAclAuthz.ldap.ldapconn.port=11636 authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=true authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false
auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents auths.instance.AgentCertAuth.pluginName=AgentCertAuth
ca.sslserver.cert=MIIDmDCCAoCgAwIBAgIBAzANBgkqhkiG9w0BAQUFADBAMR4wHAYDVQQKExVSZWR ca.sslserver.certreq=MIICizCCAXMCAQAwRjEeMBwGA1UEChMVUmVkYnVkY29tcHV0ZXIgRG9tYWluMSQwIgYDV ca.sslserver.nickname=Server-Cert cert-pki-ca ca.sslserver.tokenname=Internal Key Storage Token
conn.ca1.clientNickname=subsystemCert cert-pki-tps conn.ca1.hostadminport=server.example.com:8443 conn.ca1.hostagentport=server.example.com:8443 conn.ca1.hostport=server.example.com:9443 conn.ca1.keepAlive=true conn.ca1.retryConnect=3 conn.ca1.servlet.enrollment=/ca/ee/ca/profileSubmitSSLClient conn.ca1.servlet.renewal=/ca/ee/ca/profileSubmitSSLClient conn.ca1.servlet.revoke=/ca/subsystem/ca/doRevoke conn.ca1.servlet.unrevoke=/ca/subsystem/ca/doUnrevoke conn.ca1.timeout=100
internaldb._000=## internaldb._000=## internaldb._001=## Internal Database internaldb._002=## internaldb.basedn=o=pki-tomcat-ca-SD internaldb.database=pki-tomcat-ca internaldb.maxConns=15 internaldb.minConns=3 internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.clientCertNickname=HSM-A:subsystemCert pki-tomcat-ca internaldb.ldapconn.host=example.com internaldb.ldapconn.port=11636 internaldb.ldapconn.secureConn=true internaldb.multipleSuffix.enable=false
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
vim /var/lib/pki/instance_name/ca/conf/CS.cfg
ca.publish.queue.enable=true
ca.publish.queue.maxNumberOfThreads=1 ca.publish.queue.priorityLevel=0 ca.publish.queue.pageSize=100 ca.publish.queue.saveStatus=200
systemctl start pki-tomcatd-nuxwdog@instance_name.service
kra.noOfRequiredRecoveryAgents=1
X500Name.NEW_ATTRNAME.oid=n.n.n.n X500Name.NEW_ATTRNAME.class=string_to_DER_value_converter_class
X500Name.MY_ATTR.oid=1.2.3.4.5.6 X500Name.MY_ATTR.class=netscape.security.x509.DirStrConverter
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
X500Name.attr.MYATTR1.oid=1.2.3.4.5.6 X500Name.attr.MYATTR1.class=netscape.security.x509.DirStrConverter X500Name.attr.MYATTR2.oid=11.22.33.44.55.66 X500Name.attr.MYATTR2.class=netscape.security.x509.IA5StringConverter X500Name.attr.MYATTR3.oid=111.222.333.444.555.666 X500Name.attr.MYATTR3.class=netscape.security.x509.PrintableConverter
systemctl start pki-tomcatd-nuxwdog@instance_name.service
MYATTR1: a_value MYATTR2: a.Value MYATTR3: aValue cn: John Doe o: Example Corporation
X500Name.directoryStringEncodingOrder=encoding_list_separated_by_commas
X500Name.directoryStringEncodingOrder=PrintableString,BMPString
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
X500Name.directoryStringEncodingOrder=PrintableString,UniversalString
systemctl start pki-tomcatd-nuxwdog@instance_name.service
policyset.userCertSet.6.default.class_id=keyUsageExtDefaultImpl policyset.userCertSet.6.default.params.keyUsageCrlSign=true
pki-server stop instance_name
cd /var/lib/pki/instance-name/ca/conf/
ca.crl_signing.cacertnickname=nickname cert-instance_ID ca.crl_signing.defaultSigningAlgorithm=signing_algorithm ca.crl_signing.tokenname=token_name
ca.crl_signing.cacertnickname=crlSigningCert cert-pki-ca ca.crl_signing.defaultSigningAlgorithm=SHA512withRSA ca.crl_signing.tokenname=Internal Key Storage Token
pki-server restart instance_name
systemctl stop pki-tomcatd-nuxwdog@instance_name.service*
cd /var/lib/instance_name/conf/
ca.crl.MasterCRL.enableCRLCache=true ca.crl.MasterCRL.enableCacheRecovery=true
systemctl start pki-tomcatd-nuxwdog@instance_name.service
ca.crl.MasterCRL.updateSchema=3 ca.crl.MasterCRL.enableDailyUpdates=true ca.crl.MasterCRL.enableUpdateInterval=true ca.crl.MasterCRL.autoUpdateInterval=240 ca.crl.MasterCRL.dailyUpdates=1:00 ca.crl.MasterCRL.nextUpdateGracePeriod=0
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
cd /var/lib/instance_name/conf/
ca.crl.MasterCRL.updateSchema=3
ca.crl.MasterCRL.enableDailyUpdates=true ca.crl.MasterCRL.enableUpdateInterval=false ca.crl.MasterCRL.dailyUpdates=0:50,04:55,06:55
ca.crl.MasterCRL.enableDailyUpdates=false ca.crl.MasterCRL.enableUpdateInterval=true ca.crl.MasterCRL.autoUpdateInterval=240
ca.crl.MasterCRL.nextUpdateGracePeriod=0
ca.crl.MasterCRL.nextUpdateGracePeriod=time_in_minutes
ocsp.store.defStore.refreshInSec=time_in_seconds
systemctl start pki-tomcatd-nuxwdog@instance_name.service
ca.crl.MasterCRL.enableDailyUpdates=true ca.crl.MasterCRL.enableUpdateInterval=true ca.crl.MasterCRL.autoUpdateInterval=240 ca.crl.MasterCRL.dailyUpdates=1:00
authz.evaluateOrder=deny,allow
authz.sourceType=web.xml
dbs.beginRequestNumber=1001001007001 dbs.endRequestNumber=11001001007000 dbs.requestIncrement=10000000000000 dbs.requestLowWaterMark=2000000000000 dbs.requestCloneTransferNumber=10000 dbs.requestDN=ou=ca, ou=requests dbs.requestRangeDN=ou=requests, ou=ranges dbs.beginSerialNumber=1001001007001 dbs.endSerialNumber=11001001007000 dbs.serialIncrement=10000000000000 dbs.serialLowWaterMark=2000000000000 dbs.serialCloneTransferNumber=10000 dbs.serialDN=ou=certificateRepository, ou=ca dbs.serialRangeDN=ou=certificateRepository, ou=ranges dbs.beginReplicaNumber=1 dbs.endReplicaNumber=100 dbs.replicaIncrement=100 dbs.replicaLowWaterMark=20 dbs.replicaCloneTransferNumber=5 dbs.replicaDN=ou=replica dbs.replicaRangeDN=ou=replica, ou=ranges dbs.ldap=internaldb dbs.newSchemaEntryAdded=true
authType=sslclientauth
pki-server stop rhcs10-RSA-SubCA
ca.publish.rule.instance.ocsprule-<host/port info>.enable=false
ca.publish.rule.instance.ocsprule-rhcs10-example-com-32443.enable=false
pki-server start rhcs10-RSA-SubCA
ocsp.store.ldapStore.validateConnCertWithCRL=true auths.revocationChecking.enabled=true
ca.publish.enable=true ca.publish.cert.enable=true ca.publish.crl.enable=true
ca.publish.enable=true ca.publish.cert.enable=false
ca.publish.enable=true ca.publish.crl.enable=false
cms.passwordlist=internaldb,replicationdb,CA LDAP Publishing cms.password.ignore.publishing.failure=true
passwordFile=/var/lib/pki/instance_name/conf/password.conf
name=password
internal=413691159497
hardware-name=password
hardware-NHSM-CONN-XC=MyHSMUSDS8cret
internal=376577078151 internaldb=secret12 replicationdb=1535106826 hardware-NHSM-CONN-XC=MyHSMUSDS8cret
cp -p /var/lib/pki/instance_name/conf/server.xml /root/
cp -p /var/lib/pki/instance_name/conf/password.conf /root/
systemctl stop pki-tomcatd@instance_name.service
systemctl disable pki-tomcatd@instance_name.service
egrep "^hardware-" /var/lib/pki/instance_name/conf/password.conf hardware-HSM_token_name=password
cms.tokenList=HMS_token_name
pki-server instance-nuxwdog-enable instance_name
pki-server nuxwdog-enable
cp -p /usr/lib/systemd/system/instance_name-nuxwdog@.service /etc/systemd/system/
User new_user_name
systemctl daemon-reload
systemctl enable pki-tomcatd-nuxwdog@instance_name.service
systemctl start pki-tomcatd-nuxwdog@instance_name.service
systemctl is-enabled pki-tomcatd-nuxwdog@instance_name.service enabled
systemctl is-disabled pki-tomcatd@instance_name.service disabled
passwordFile="/var/lib/pki/instance_name/ca/CS.cfg"
passwordClass="com.netscape.cms.tomcat.NuxwdogPasswordStore"
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
systemctl disable pki-tomcatd-nuxwdog@instance_name.service
pki-server instance-nuxwdog-disable instance_name
systemctl enable pki-tomcatd@instance_name.service
cp /root/password.conf.bak /var/lib/pki/instance_name/conf/password.conf
systemctl start pki-tomcatd@instance_name.service
<Connector name="Secure" port="21443" protocol="org.dogtagpki.tomcat.Http11NioProtocol" SSLEnabled="true" sslImplementationName="org.dogtagpki.tomcat.JSSImplementation" scheme="https" secure="true" connectionTimeout="3000000" keepAliveTimeout="300000" maxHttpHeaderSize="8192" acceptCount="100" maxThreads="150" minSpareThreads="25" enableLookups="false" disableUploadTimeout="true" enableOCSP="true" ocspCacheSize="1000" ocspMinCacheEntryDuration="7200" ocspMaxCacheEntryDuration="14400" ocspTimeout="10" serverCertNickFile="/var/lib/pki/rhcs10-ECC-SubCA/conf/serverCertNick.conf" passwordFile="/var/lib/pki/rhcs10-ECC-SubCA/conf/password.conf" passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile" certdbDir="/var/lib/pki/rhcs10-ECC-SubCA/alias"> <SSLHostConfig sslProtocol="TLS" protocols="TLSv1.2" certificateVerification="optional" ciphers="ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA- AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384"> <Certificate certificateKeystoreType="pkcs11" certificateKeystoreProvider="Mozilla-JSS" certificateKeyAlias="NHSM-CONN-XC:Server-Cert cert-rhcs10-ECC-SubCA"/> </SSLHostConfig> </Connector>
systemctl stop pki-tomcatd@ <instance_name> .service
<Connector name="Secure" enableOCSP="true" ocspCacheSize="1000" ocspMinCacheEntryDuration="60" ocspMaxCacheEntryDuration="120" ocspTimeout="10" />
systemctl start pki-tomcatd@ <instance_name> .service
systemctl stop pki-tomcatd@ <instance_name> .service
ca.defaultOcspUri=http:// hostname :32080/ocsp/ee/ocsp
systemctl start pki-tomcatd@ <instance_name> .service
Server Service Connector name="Secure" keepAliveTimeout="300000" / /Service /Server
web-app session-config session-timeout30/session-timeout /session-config /web-app
pki-server stop instance_name
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
cd /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF
cp web.xml web.xml.servlets
<servlet> <servlet-name> caadminEnroll </servlet-name> <servlet-class> com.netscape.cms.servlet.cert.EnrollServlet </servlet-class> <init-param><param-name> GetClientCert </param-name> <param-value> false </param-value> </init-param> <init-param><param-name> successTemplate </param-name> <param-value> /admin/ca/EnrollSuccess.template </param-value> </init-param> <init-param><param-name> AuthzMgr </param-name> <param-value> BasicAclAuthz </param-value> </init-param> <init-param><param-name> authority </param-name> <param-value> ca </param-value> </init-param> <init-param><param-name> interface </param-name> <param-value> admin </param-value> </init-param> <init-param><param-name> ID </param-name> <param-value> caadminEnroll </param-value> </init-param> <init-param><param-name> resourceID </param-name> <param-value> certServer.admin.request.enrollment </param-value> </init-param> <init-param><param-name> AuthMgr </param-name> <param-value> passwdUserDBAuthMgr </param-value> </init-param> </servlet>
<servlet-mapping> <servlet-name> caadminEnroll </servlet-name> <url-pattern> /admin/ca/adminEnroll </url-pattern> </servlet-mapping>
<filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /certbasedenrollment </url-pattern> </filter-mapping> <filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /enrollment </url-pattern> </filter-mapping> <filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /profileSubmit </url-pattern> </filter-mapping>
pki-server start instance_name
systemctl start pki-tomcatd-nuxwdog@instance_name.service
<Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true" allowLinking="true" </Context
cp -r /usr/share/pki/ca/webapps/ca /var/lib/pki/pki-tomcat/webapps
<Context docBase="ca" crossContext="true" allowLinking="true" </Context
rm -rf /var/lib/pki/pki-tomcat/webapps/ca
<Context docBase="/usr/share/pki/common-ui" crossContext="true" allowLinking="true" </Context
cp -r /usr/share/pki/common-ui /var/lib/pki/pki-tomcat/webapps/pki
<Context docBase="pki" crossContext="true" allowLinking="true" </Context
rm -rf /var/lib/pki/pki-tomcat/webapps/pki
cp /usr/share/pki/tps/conf/token-states.properties /var/lib/pki/pki-tomcat/tps/conf
rm /var/lib/pki/pki-tomcat/tps/conf/token-states.properties
pki ca-cert-show 0x1 WARNING! Access to this service is restricted to those individuals with specific permissions. If you are not an authorized user, disconnect now. Any attempts to gain unauthorized access will be prosecuted to the fullest extent of the law. Do you want to proceed (y/N)? y ----------------- Certificate "0x1" ----------------- Serial Number: 0x1 Issuer: CN=CA Signing Certificate,OU=instance_name,O=EXAMPLE Subject: CN=CA Signing Certificate,OU=instance_name,O=EXAMPLE Status: VALID Not Before: Mon Feb 20 18:21:03 CET 2017 Not After: Fri Feb 20 18:21:03 CET 2037
mv /etc/pki/instance_name/banner.txt /etc/pki/instance_name/banner.txt.UNUSED
pki-server banner-show -i instance_name
pki-server banner-validate -i instance_name --------------- Banner is valid ---------------
cmc.popLinkWitnessRequired=true
ldapmodify -D "cn=Directory Manager" -H ldaps://server.example.com:636 -W -x dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 2.16.840.1.117370.3.1.123 NAME 'shrTok' DESC 'User Defined ObjectClass for SharedToken' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE X-ORIGIN 'custom for sharedToken')
cmc.token=NHSM-CONN-XC
auths.impl.SharedToken.class=com.netscape.cms.authentication.SharedSecret auths.instance.SharedToken.dnpattern= auths.instance.SharedToken.ldap.basedn=ou=People,dc=example,dc=org auths.instance.SharedToken.ldap.ldapauth.authtype=BasicAuth auths.instance.SharedToken.ldap.ldapauth.bindDN=cn=Directory Manager auths.instance.SharedToken.ldap.ldapauth.bindPWPrompt=Rule SharedToken auths.instance.SharedToken.ldap.ldapauth.clientCertNickname= auths.instance.SharedToken.ldap.ldapconn.host=server.example.com auths.instance.SharedToken.ldap.ldapconn.port=636 auths.instance.SharedToken.ldap.ldapconn.secureConn=true auths.instance.SharedToken.ldap.ldapconn.version=3 auths.instance.SharedToken.ldap.maxConns= auths.instance.SharedToken.ldap.minConns= auths.instance.SharedToken.ldapByteAttributes= auths.instance.SharedToken.ldapStringAttributes= auths.instance.SharedToken.pluginName=SharedToken auths.instance.SharedToken.shrTokAttr=shrTok
ca.cert.issuance_protection.nickname=issuance_protection_certificate
systemctl restart pki-tomcatd@instance_name.service
cmc.bypassClientAuth=true