Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

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
Copiar o link

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
Copiar o link

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”

Expand
Table 9.1. Certificate server port assignments (default)
Port TypePort NumberNotes

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
Copiar o link

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.

Expand
Table 9.2. CA subsystem information for the default instance (pki-tomcat)
SettingValue

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
Copiar o link

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.

Expand
Table 9.3. KRA subsystem information for the default instance (pki-tomcat)
SettingValue

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
Copiar o link

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.

Expand
Table 9.4. OCSP subsystem information for the default instance (pki-tomcat)
SettingValue

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
Copiar o link

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.

Expand
Table 9.5. Every time a subsystem is created either through the initial installation or creating additional instances with (pki-tomcat)
SettingValue

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
Copiar o link

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.

Expand
Table 9.6. TPS subsystem information for the default instance (pki-tomcat)
SettingValue

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
Copiar o link

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”.

Expand
Table 9.7. Subsystem file locations
Directory LocationContents

/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
Copiar o link

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
Copiar o link

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. 

/var/lib/pki/instance_name/subsystem_type/conf
Copy to Clipboard Toggle word wrap

For example: 

/var/lib/pki/instance_name/ca/conf
Copy to Clipboard Toggle word wrap

9.2.2. Editing the configuration file
Copiar o link

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:

  1. Stop the subsystem instance. 

    # pki-server stop instance_name
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

    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.

  2. Open the /var/lib/pki/instance_name/subsystem_type/conf directory.
  3. Open the CS.cfg file in a text editor.
  4. Edit the parameters in the file, and save the changes.

  5. Start the subsystem instance. 

    # pki-server start instance_name
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

9.2.3. Overview of the CS.cfg configuration file
Copiar o link

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. 

#comment
parameter=value
Copy to Clipboard Toggle word wrap

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

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=## $ pki-server ca-audit-event-find
log.instance.SignedAudit._005=##
log.instance.SignedAudit._006=## To enable/disable audit event:
log.instance.SignedAudit._007=## $ 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
Copy to Clipboard Toggle word wrap

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

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
Copy to Clipboard Toggle word wrap
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
Copiar o link

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

[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

[Tomcat]
# Separated CA Tomcat ports
pki_ajp_port=18009
pki_tomcat_server_port=18005
Copy to Clipboard Toggle word wrap
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
Copiar o link

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: 

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=## $ pki-server ca-audit-event-find
log.instance.SignedAudit._005=##
log.instance.SignedAudit._006=## To enable/disable audit event:
log.instance.SignedAudit._007=## $ 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
Copy to Clipboard Toggle word wrap

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
Copiar o link

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. 

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
Copy to Clipboard Toggle word wrap

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. 

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
Copy to Clipboard Toggle word wrap

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: 

auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication
auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents
auths.instance.AgentCertAuth.pluginName=AgentCertAuth
Copy to Clipboard Toggle word wrap

9.2.3.4. Subsystem certificate settings
Copiar o link

Several of the subsystems have entries for each subsystem certificate in the configuration file. 

ca.sslserver.cert=MIIDmDCCAoCgAwIBAgIBAzANBgkqhkiG9w0BAQUFADBAMR4wHAYDVQQKExVSZWR...
ca.sslserver.certreq=MIICizCCAXMCAQAwRjEeMBwGA1UEChMVUmVkYnVkY29tcHV0ZXIgRG9tYWluMSQwIgYDV...
ca.sslserver.nickname=Server-Cert cert-pki-ca
ca.sslserver.tokenname=Internal Key Storage Token
Copy to Clipboard Toggle word wrap

9.2.3.5. Settings for required subsystems
Copiar o link

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: 

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
Copy to Clipboard Toggle word wrap

9.2.3.6. Database settings
Copiar o link

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: 

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
Copy to Clipboard Toggle word wrap

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
Copiar o link

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.

  1. Stop the CA server, so that you can edit the configuration files. 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

  2. Open the CA’s CS.cfg file. 

    # vim /var/lib/pki/instance_name/ca/conf/CS.cfg
    Copy to Clipboard Toggle word wrap

  3. Set the ca.publish.queue.enable to true. If the parameter is not present, then add a line as follows: 

    ca.publish.queue.enable=true
    Copy to Clipboard Toggle word wrap

  4. 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. 

      ca.publish.queue.maxNumberOfThreads=1
	ca.publish.queue.priorityLevel=0
	ca.publish.queue.pageSize=100
	ca.publish.queue.saveStatus=200
      Copy to Clipboard Toggle word wrap
      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.

  5. Restart the CA server. 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

9.2.3.8. Settings for PKI tasks
Copiar o link

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. 

kra.noOfRequiredRecoveryAgents=1
Copy to Clipboard Toggle word wrap

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
Copiar o link

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.

Expand
Table 9.8. Allowed characters for value types
AttributeValue TypeObject 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: 

X500Name.NEW_ATTRNAME.oid=n.n.n.n
X500Name.NEW_ATTRNAME.class=string_to_DER_value_converter_class
Copy to Clipboard Toggle word wrap

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: 

X500Name.MY_ATTR.oid=1.2.3.4.5.6
X500Name.MY_ATTR.class=netscape.security.x509.DirStrConverter
Copy to Clipboard Toggle word wrap
9.2.3.9.1. Adding new or custom attributes
Copiar o link

To add a new or proprietary attribute to the Certificate System schema, do the following:

  1. Stop the Certificate Manager. 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  2. Open the /var/lib/pki/cs_instance/conf/ directory.
  3. Open the configuration file, CS.cfg.

  4. 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: 

    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
    Copy to Clipboard Toggle word wrap
  5. Save the changes, and close the file.

  6. Restart the Certificate Manager. 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  7. Reload the enrollment page and verify the changes; the new attributes should show up in the form.

  8. 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: 

    MYATTR1: a_value
MYATTR2: a.Value
MYATTR3: aValue
cn: John Doe
o: Example Corporation
    Copy to Clipboard Toggle word wrap
  9. Open the agent services page, and approve the request.
  10. 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
Copiar o link

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: 

X500Name.directoryStringEncodingOrder=encoding_list_separated_by_commas
Copy to Clipboard Toggle word wrap

The possible encoding values are as follows:

  • PrintableString
  • IA5String
  • UniversalString
  • BMPString
  • UTF8String

For example, the DER-encoding ordered can be listed as follows: 

X500Name.directoryStringEncodingOrder=PrintableString,BMPString
Copy to Clipboard Toggle word wrap

To change the DirectoryString encoding, do the following:

  1. Stop the Certificate Manager. 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  2. Open the /var/lib/pki/cs_instance/conf/ directory.
  3. Open the CS.cfg configuration file.

  4. 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 next, add the following line at the end of the configuration file: 

    X500Name.directoryStringEncodingOrder=PrintableString,UniversalString
    Copy to Clipboard Toggle word wrap
  5. Save the changes, and close the file.

  6. Start the Certificate Manager. 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  7. To verify that the encoding orders are in effect, enroll for a certificate using the manual enrollment form. Use John_Doe for the cn.
  8. Open the agent services page, and approve the request.

  9. 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.

  10. 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
Copiar o link

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:

  1. 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: 

    policyset.userCertSet.6.default.class_id=keyUsageExtDefaultImpl
policyset.userCertSet.6.default.params.keyUsageCrlSign=true
    Copy to Clipboard Toggle word wrap

  2. After you have generated the CRL signing certificate, install the certificate in the Certificate Manager’s crypto module database.

  3. Stop the Certificate Manager. 

    # pki-server stop instance_name
    Copy to Clipboard Toggle word wrap

  4. Update the Certificate Manager’s configuration to recognize the new key pair and certificate.

    1. Change to the Certificate Manager instance configuration directory. 

      # cd /var/lib/pki/instance-name/ca/conf/
      Copy to Clipboard Toggle word wrap

    2. Open the CS.cfg file and add the following lines: 

      ca.crl_signing.cacertnickname=nickname cert-instance_ID
ca.crl_signing.defaultSigningAlgorithm=signing_algorithm
ca.crl_signing.tokenname=token_name
      Copy to Clipboard Toggle word wrap

      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: 

      ca.crl_signing.cacertnickname=crlSigningCert cert-pki-ca
ca.crl_signing.defaultSigningAlgorithm=SHA512withRSA
ca.crl_signing.tokenname=Internal Key Storage Token
      Copy to Clipboard Toggle word wrap
    3. Save the changes, and close the file.

  5. Restart the Certificate Manager. 

    # pki-server restart instance_name
    Copy to Clipboard Toggle word wrap

    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
Copiar o link

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.

  1. Stop the CA server. 

    systemctl stop pki-tomcatd-nuxwdog@instance_name.service*
    Copy to Clipboard Toggle word wrap

  2. Open the CA configuration directory. 

    # cd /var/lib/instance_name/conf/
    Copy to Clipboard Toggle word wrap

  3. Edit the CS.cfg file, setting the enableCRLCache and enableCacheRecovery parameters to true: 

    ca.crl.MasterCRL.enableCRLCache=true
ca.crl.MasterCRL.enableCacheRecovery=true
    Copy to Clipboard Toggle word wrap

  4. Start the CA server. 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

9.2.3.12. Configuring update intervals for CRLs in CS.cfg
Copiar o link

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: 

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
Copy to Clipboard Toggle word wrap

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.

Expand
Table 9.9. CRL extended interval parameters
ParameterDescriptionAccepted 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

  1. Stop the CA server. 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

  2. Change to the CA configuration directory. 

    # cd /var/lib/instance_name/conf/
    Copy to Clipboard Toggle word wrap

  3. Edit the CS.cfg file, and add the following line to set the update interval: 

    ca.crl.MasterCRL.updateSchema=3
    Copy to Clipboard Toggle word wrap

    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.

  4. 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: 

      ca.crl.MasterCRL.enableDailyUpdates=true
	ca.crl.MasterCRL.enableUpdateInterval=false
	ca.crl.MasterCRL.dailyUpdates=0:50,04:55,06:55
      Copy to Clipboard Toggle word wrap

      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: 

      ca.crl.MasterCRL.enableDailyUpdates=false
	ca.crl.MasterCRL.enableUpdateInterval=true
	ca.crl.MasterCRL.autoUpdateInterval=240
      Copy to Clipboard Toggle word wrap

  5. Set the following parameters depending on your environment:

    • If you run a CA without an OCSP subsystem, set: 

      ca.crl.MasterCRL.nextUpdateGracePeriod=0
      Copy to Clipboard Toggle word wrap

    • If you run a CA with an OCSP subsystem, set: 

      ca.crl.MasterCRL.nextUpdateGracePeriod=time_in_minutes
      Copy to Clipboard Toggle word wrap

      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: 

      ocsp.store.defStore.refreshInSec=time_in_seconds
      Copy to Clipboard Toggle word wrap

      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.

  6. Restart the CA server. 

    systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
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: 

ca.crl.MasterCRL.enableDailyUpdates=true
ca.crl.MasterCRL.enableUpdateInterval=true
ca.crl.MasterCRL.autoUpdateInterval=240
ca.crl.MasterCRL.dailyUpdates=1:00
Copy to Clipboard Toggle word wrap

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
Copiar o link

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. 

authz.evaluateOrder=deny,allow
Copy to Clipboard Toggle word wrap

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. 

authz.sourceType=web.xml
Copy to Clipboard Toggle word wrap
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
Copiar o link

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: 

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
Copy to Clipboard Toggle word wrap
Note

Certificate System supports BigInteger values for the ranges.

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: 

authType=sslclientauth
Copy to Clipboard Toggle word wrap

9.2.3.16. Changing the signing algorithms
Copiar o link

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

9.2.3.17. Disabling the direct CA-OCSP CRL publishing
Copiar o link

When configuring the OCSP manager to use an LDAP directory, you need to disable the direct CA→OCSP CRL publishing method :

  1. Stop the SubCA: 

    # pki-server stop rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

  2. 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: 

    ca.publish.rule.instance.ocsprule-<host/port info>.enable=false
    Copy to Clipboard Toggle word wrap

    For example: 

    ca.publish.rule.instance.ocsprule-rhcs10-example-com-32443.enable=false
    Copy to Clipboard Toggle word wrap

  3. Start the CA for the configuration change to take effect: 

    # pki-server start rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

9.2.3.18. Enabling client certificate verification using latest CRL within OCSP
Copiar o link

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: 

    ocsp.store.ldapStore.validateConnCertWithCRL=true

auths.revocationChecking.enabled=true
    Copy to Clipboard Toggle word wrap

    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
Copiar o link

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: 

    ca.publish.enable=true
ca.publish.cert.enable=true
ca.publish.crl.enable=true
    Copy to Clipboard Toggle word wrap

  • Example of CA’s CS.cfg file with Certificate publishing disabled: 

    ca.publish.enable=true
ca.publish.cert.enable=false
    Copy to Clipboard Toggle word wrap

  • Example of CA’s CS.cfg file with CRL publishing disabled: 

    ca.publish.enable=true
ca.publish.crl.enable=false
    Copy to Clipboard Toggle word wrap

9.3. Managing system passwords
Copiar o link

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: 

cms.passwordlist=internaldb,replicationdb,CA LDAP Publishing
cms.password.ignore.publishing.failure=true
Copy to Clipboard Toggle word wrap
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 next 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
Copiar o link

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: 

passwordFile=/var/lib/pki/instance_name/conf/password.conf
Copy to Clipboard Toggle word wrap

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: 

name=password
Copy to Clipboard Toggle word wrap

For example: 

internal=413691159497
Copy to Clipboard Toggle word wrap

In cases where an HSM token is required, use the following format: 

hardware-name=password
Copy to Clipboard Toggle word wrap

For example: 

hardware-NHSM-CONN-XC=MyHSM$S8cret
Copy to Clipboard Toggle word wrap

Example content of a password.conf file: 

internal=376577078151
internaldb=secret12
replicationdb=1535106826
hardware-NHSM-CONN-XC=MyHSM$S8cret
Copy to Clipboard Toggle word wrap

9.3.2. Using the Certificate System watchdog service
Copiar o link

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
Copiar o link

To enable the watchdog service:

  1. 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”.

  2. Backup the server.xml and password.conf files from the /var/lib/pki/instance_name/conf/ directory. For example: 

    # cp -p /var/lib/pki/instance_name/conf/server.xml /root/
    Copy to Clipboard Toggle word wrap 
    # cp -p /var/lib/pki/instance_name/conf/password.conf /root/
    Copy to Clipboard Toggle word wrap

  3. Stop and disable the Certificate System instance’s service: 

    # systemctl stop pki-tomcatd@instance_name.service
    Copy to Clipboard Toggle word wrap 
    # systemctl disable pki-tomcatd@instance_name.service
    Copy to Clipboard Toggle word wrap

  4. 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: 

      # egrep "^hardware-" /var/lib/pki/instance_name/conf/password.conf

hardware-HSM_token_name=password
      Copy to Clipboard Toggle word wrap

      The highlighted string in the previous 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: 

      cms.tokenList=HMS_token_name
      Copy to Clipboard Toggle word wrap

  5. Enable the watchdog configuration for the instance: 

    # pki-server instance-nuxwdog-enable instance_name
    Copy to Clipboard Toggle word wrap

    Alternatively, enable the watchdog for all instances: 

    # pki-server nuxwdog-enable
    Copy to Clipboard Toggle word wrap

    For further details, see the pki-server-nuxwdog(8) man page.

  6. 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: 

      # cp -p /usr/lib/systemd/system/instance_name-nuxwdog@.service /etc/systemd/system/
      Copy to Clipboard Toggle word wrap
      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: 

      User new_user_name
      Copy to Clipboard Toggle word wrap

    • Reload the systemd configuration: 

      # systemctl daemon-reload
      Copy to Clipboard Toggle word wrap

  7. Enable the Certificate System service that uses the watchdog: 

    # systemctl enable pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  8. Optionally: See Section 9.3.2.3, “Verifying that the Certificate System watchdog service is enabled”.

  9. To start the Certificate System instance, run the following command and enter the prompted passwords: 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

9.3.2.2. Starting and stopping Certificate System with the watchdog enabled
Copiar o link

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
Copiar o link

To verify that the watchdog service is enabled:

  1. Verify that the pki-tomcatd-nuxwdog service is enabled: 

    # systemctl is-enabled pki-tomcatd-nuxwdog@instance_name.service

enabled
    Copy to Clipboard Toggle word wrap

  2. Verify that the pki-tomcatd service is disabled: 

    # systemctl is-disabled pki-tomcatd@instance_name.service

disabled
    Copy to Clipboard Toggle word wrap

  3. In the /etc/pki/instance_name/server.xml file:

    • verify that the passwordFile parameter refers to the CS.cfg file. For example: 

      passwordFile="/var/lib/pki/instance_name/ca/CS.cfg"
      Copy to Clipboard Toggle word wrap

    • verify that the passwordClass parameter is set to com.netscape.cms.tomcat.NuxwdogPasswordStore: 

      passwordClass="com.netscape.cms.tomcat.NuxwdogPasswordStore"
      Copy to Clipboard Toggle word wrap

9.3.2.4. Disabling the watchdog service
Copiar o link

To disable the watchdog service:

  1. Stop and disable the Certificate System instance’s service that uses the watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap 
    # systemctl disable pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

  2. Enable the regular service without watch dog for the instance: 

    # pki-server instance-nuxwdog-disable instance_name
    Copy to Clipboard Toggle word wrap

  3. Disable the watchdog configuration for the instance: 

    # systemctl enable pki-tomcatd@instance_name.service
    Copy to Clipboard Toggle word wrap

    For further details, see the pki-server-nuxwdog(8) man page.

  4. Restore the password.conf file to its original location. For example: 

    # cp /root/password.conf.bak /var/lib/pki/instance_name/conf/password.conf
    Copy to Clipboard Toggle word wrap

  5. Start the Certificate System instance: 

    # systemctl start pki-tomcatd@instance_name.service
    Copy to Clipboard Toggle word wrap

9.4. Configuration files for the tomcat engine and web services
Copiar o link

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
Copiar o link

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. 

    <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>
Copy to Clipboard Toggle word wrap

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
Copiar o link

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.

9.4.1.2. Enabling automatic revocation checking on the CA
Copiar o link

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
Copiar o link

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
Copiar o link

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

  1. Stop the instance: 

    # systemctl stop pki-tomcatd@<instance_name>.service
    Copy to Clipboard Toggle word wrap

  2. Edit the /var/lib/pki/<instance_name>/conf/server.xml file to configure the Connector name="Secure" section:

    1. Set the enableOCSP parameter to true

    2. Make sure you remove these two parameters and their assigned values:

      • ocspResponderURL
      • ocspResponderCertNickname

      For example: 

    <Connector name="Secure"
     enableOCSP="true"
     ocspCacheSize="1000"
     ocspMinCacheEntryDuration="60"
     ocspMaxCacheEntryDuration="120"
     ocspTimeout="10"
     ...
/>
    Copy to Clipboard Toggle word wrap

  3. Start the instance: 

    # systemctl start pki-tomcatd@<instance_name>.service
    Copy to Clipboard Toggle word wrap
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
Copiar o link

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
Copiar o link

The following table provides information on each parameter relevant to certificate revocation checks (that is, OCSP and CRL) in the server.xml file.

Expand
Table 9.10. OCSP parameters for server.xml
ParameterDescription

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 next 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 next 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
Copiar o link

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

  1. Stop the CA: 

    # systemctl stop pki-tomcatd@<instance_name>.service
    Copy to Clipboard Toggle word wrap

  2. Edit the CA’s CS.cfg and set the ca.defaultOcspUri variable to point to the OCSP. For example: 

    ca.defaultOcspUri=http://hostname:32080/ocsp/ee/ocsp
    Copy to Clipboard Toggle word wrap

  3. Start the CA: 

    # systemctl start pki-tomcatd@<instance_name>.service
    Copy to Clipboard Toggle word wrap
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
Copiar o link

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
Copiar o link

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
Copiar o link

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: 

...
Server
	Service
		Connector name="Secure"
			...
			keepAliveTimeout="300000"
			...
			/
	/Service
/Server
...
Copy to Clipboard Toggle word wrap

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
Copiar o link

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: 

...
web-app
	session-config
		session-timeout30/session-timeout
	/session-config
/web-app
...
Copy to Clipboard Toggle word wrap

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
Copiar o link

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
Copiar o link

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
Copiar o link

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)
Copiar o link

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

  1. Stop the CA. 

    # pki-server stop instance_name
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

  2. Open the web files directory for the CA. For example: 

    # cd /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF
    Copy to Clipboard Toggle word wrap

  3. Back up the current web.xml file. 

    # cp web.xml web.xml.servlets
    Copy to Clipboard Toggle word wrap

  4. 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: 

      <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>
      Copy to Clipboard Toggle word wrap

  5. After removing the servlet entries, remove the corresponding <servlet-mapping> entries. 

    <servlet-mapping>
      <servlet-name>  caadminEnroll  </servlet-name>
      <url-pattern>   /admin/ca/adminEnroll  </url-pattern>
</servlet-mapping>
    Copy to Clipboard Toggle word wrap

  6. Remove three <filter-mapping> entries for an end-entity request interface. 

       <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>
    Copy to Clipboard Toggle word wrap

  7. Start the CA again. 

    # pki-server start instance_name
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

9.4.4. Customizing Web Services
Copiar o link

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
Copiar o link

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: 

<Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true" allowLinking="true"
    ...
</Context
Copy to Clipboard Toggle word wrap

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: 

$ cp -r /usr/share/pki/ca/webapps/ca /var/lib/pki/pki-tomcat/webapps
Copy to Clipboard Toggle word wrap

Then change the docBase to point to the custom web application directory relative from the webapps directory: 

<Context docBase="ca" crossContext="true" allowLinking="true"
    ...
</Context
Copy to Clipboard Toggle word wrap

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: 

$ rm -rf /var/lib/pki/pki-tomcat/webapps/ca
Copy to Clipboard Toggle word wrap

9.4.4.2. Customizing the Web UI theme
Copiar o link

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: 

<Context docBase="/usr/share/pki/common-ui" crossContext="true" allowLinking="true"
    ...
</Context
Copy to Clipboard Toggle word wrap

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: 

$ cp -r /usr/share/pki/common-ui /var/lib/pki/pki-tomcat/webapps/pki
Copy to Clipboard Toggle word wrap

Then change the docBase to point to the custom theme directory relative from the webapps directory: 

<Context docBase="pki" crossContext="true" allowLinking="true"
    ...
</Context
Copy to Clipboard Toggle word wrap

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: 

$ rm -rf /var/lib/pki/pki-tomcat/webapps/pki
Copy to Clipboard Toggle word wrap

9.4.4.3. Customizing TPS token state labels
Copiar o link

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: 

$ cp /usr/share/pki/tps/conf/token-states.properties /var/lib/pki/pki-tomcat/tps/conf
Copy to Clipboard Toggle word wrap

The change will be effective immediately without the need to restart the server.

To remove the customized labels, simply delete the customized file: 

$ rm /var/lib/pki/pki-tomcat/tps/conf/token-states.properties
Copy to Clipboard Toggle word wrap

9.5. Using an access banner
Copiar o link

In Certificate System, Administrators can configure a banner with customizable text. The banner will be displayed in the following situations:

Expand
ApplicationWhen 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: 

$ 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
Copy to Clipboard Toggle word wrap

9.5.1. Enabling an access banner
Copiar o link

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
Copiar o link

To disable the access banner, either delete or rename the /etc/pki/instance_name/banner.txt file. For example: 

# mv /etc/pki/instance_name/banner.txt /etc/pki/instance_name/banner.txt.UNUSED
Copy to Clipboard Toggle word wrap

9.5.3. Displaying the banner
Copiar o link

To display the currently configured banner: 

# pki-server banner-show -i instance_name
Copy to Clipboard Toggle word wrap

9.5.4. Validating the banner
Copiar o link

To validate that the banner does not contain invalid characters: 

# pki-server banner-validate -i instance_name
---------------
Banner is valid
---------------
Copy to Clipboard Toggle word wrap

9.6. Configuration for CMC
Copiar o link

This section describes how to configure Certificate System for Certificate Management over CMS (CMC).

9.6.1. Understanding how CMC works
Copiar o link

Before configuring CMC, read the following documentation to learn more about the subject:

9.6.2. Enabling the PopLinkWitnessV2 feature
Copiar o link

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: 

cmc.popLinkWitnessRequired=true
Copy to Clipboard Toggle word wrap

9.6.3. Enabling the CMC Shared Secret feature
Copiar o link

To enable the shared token feature in a Certificate Authority (CA):

  1. If the watchdog service is enabled on the host, temporarily disable it. See Section 9.3.2.4, “Disabling the watchdog service”.

  2. Add the shrTok attribute to Directory Server’s schema: 

    # 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')
    Copy to Clipboard Toggle word wrap

  3. 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: 

    cmc.token=NHSM-CONN-XC
    Copy to Clipboard Toggle word wrap

  4. Enable the shared token authentication plugin by adding the following settings into the /var/lib/pki/instance_name/ca/conf/CS.cfg file: 

    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
    Copy to Clipboard Toggle word wrap

  5. 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: 

    ca.cert.issuance_protection.nickname=issuance_protection_certificate
    Copy to Clipboard Toggle word wrap

    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.

  6. Restart Certificate System: 

    # systemctl restart pki-tomcatd@instance_name.service
    Copy to Clipboard Toggle word wrap

    When the CA starts, Certificate System prompts for the LDAP password used by the Shared Token plugin.

  7. 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
Copiar o link

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: 

cmc.bypassClientAuth=true
Copy to Clipboard Toggle word wrap
Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat