Administration Guide (Common Criteria Edition)
Updated for Red Hat Certificate System 9.4 Common Criteria Certification
Edition 9.4-1
Abstract
Chapter 1. Overview of Red Hat Certificate System Subsystems
Note
Note
1.1. Uses for Certificates
1.2. A Review of Certificate System Subsystems
1.3. A Look at Managing Certificates (Non-TMS)
- Managing Certificates
- Using a Single Certificate Manager
- Planning for Lost Keys: Key Archival and Recovery
- Balancing Certificate Request Processing
- Balancing Client OCSP Requests
1.4. A Look at the Token Management System (TMS)
Note
- Working with Smart Cards (TMS)
- Using Smart Cards
1.5. Red Hat Certificate System services
Part I. Red Hat Certificate System User Interfaces
Chapter 2. User Interfaces
2.1. User Interfaces Overview
- The PKI command-line interface and other command-line utilities
- The PKI Console graphical interface
- The Certificate System web interface.
~/.dogtag/nssdb/
directory. Section 2.5.1.1, “pki CLI Initialization” provides detailed steps for initializing the NSS database with the administrator's certificate and key. Some examples of using the PKI command-line utility are described in Section 2.5.1.2, “Using "pki" CLI”. Additional examples are shown through the rest of the guide.
PKCS10Client
”.
pkiconsole
Initialization” describes how to initialize it. Section 2.3.2, “Using pkiconsole
for CA, OCSP, KRA, and TKS Subsystems” gives an overview of using the console interface. Later sections, such as Section 3.2.2, “Managing Certificate Enrollment Profiles Using the Java-based Administration Console” go into greater detail for specific operations.
Note
2.2. Client NSS Database Initialization
- Prepare an NSS database for the client. This can be a new database or an existing one.
- Import the CA certificate chain and trust them.
- Have a certificate and corresponding key. They can be generated in the NSS database or imported from somewhere else, such as from a PKCS #12 file.
2.3. Graphical Interface
pkiconsole
is a graphical interface that is designed for users with the Administrator role privilege to manage the subsystem itself. This includes adding users, configuring logs, managing profiles and plug-ins, and the internal database, among many other functions. This utility communicates with the Certificate System server via TLS using client-authentication and can be used to manage the server remotely.
2.3.1. pkiconsole
Initialization
pkiconsole
interface for the first time, specify a new password and use the following command:
$ pki -c password -d ~/.redhat-idm-console client-init
~/.redhat-idm-console/
directory.
.p12
file:
$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt
$ PKICertImport -d ~/.redhat-idm-console -n "nickname" -t ",," -a -i file.crt -u C
Important
$ pki -c password -d ~/.redhat-idm-console pkcs12-import --pkcs12-file file --pkcs12-password pkcs12-password
$ certutil -V -u C -n "nickname" -d ~/.redhat-idm-console
2.3.2. Using pkiconsole
for CA, OCSP, KRA, and TKS Subsystems
pkiconsole
utility. It can access any subsystem because the command requires the host name, the subsystem's administrative TLS port, and the specific subsystem type.
pkiconsole https://server.example.com:admin_port/subsystem_type
https://192.0.2.1:8443/ca https://[2001:DB8::1111]:8443/ca
Figure 2.1. Certificate System Console
- Users and groups
- Access control lists
- Log configuration
- Subsystem certificates (meaning the certificates issued to the subsystem for use, for example, in the security domain or audit signing)
2.4. Web Interface
2.4.1. Browser Initialization
Importing a CA Certificate
- Click→ → → .
- Select the Authorities tab and click the button.
- Select the
ca.crt
file and click .
Importing a Client Certificate
- Click→ → → .
- Select the Your Certificates tab.
- Click onand select the client p12 file, such as
ca_admin_cert.p12
. - Enter the password for the client certificate on the prompt.
- Click.
- Verify that an entry is added under Your Certificates.
Accessing the Web Console
https://host_name:port
in your browser.
2.4.2. The Administrative Interfaces
Note
Figure 2.2. TPS Admin Page
2.4.3. Agent Interfaces
Figure 2.3. Certificate Manager's Agent Services Page
- The Certificate Manager agent services include approving certificate requests (which issues the certificates), revoking certificates, and publishing certificates and CRLs. All certificates issued by the CA can be managed through its agent services page.
- The TPS agent services, like the CA agent services, manages all of the tokens which have been formatted and have had certificates issued to them through the TPS. Tokens can be enrolled, suspended, and deleted by agents. Two other roles (operator and admin) can view tokens in web services pages, but cannot perform any actions on the tokens.
- KRA agent services pages process key recovery requests, which set whether to allow a certificate to be issued reusing an existing key pair if the certificate is lost.
- The OCSP agent services page allows agents to configure CAs which publish CRLs to the OCSP, to load CRLs to the OCSP manually, and to view the state of client OCSP requests.
2.4.4. End User Pages
Figure 2.4. Certificate Manager's End-Entities Page
2.5. Command Line Interfaces
2.5.1. "pki" CLI
pki
command-line interface (CLI) provides access to various services on the server using the REST interface (see the REST Interface section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition)). The CLI can be invoked as follows:
$
pki [CLI options]
<command> [command parameters]
2.5.1.1. pki CLI Initialization
$
pki -c <password> client-init
~/.dogtag/nssdb
directory. The password must be specified in all CLI operations that uses the client NSS database. Alternatively, if the password is stored in a file, you can specify the file using the -C
option. For example:
$
pki -C password_file client-init
.p12
file:
$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt
$ PKICertImport -d ~/.dogtag/nssdb -n "nickname" -t ",," -a -i file.crt -u C
Important
$
pki -c <password> pkcs12-import --pkcs12-file <file> --pkcs12-password <password>
certutil -V -u C -n "nickname" -d ~/.dogtag/nssdb
2.5.1.2. Using "pki" CLI
pki
command without any additional commands or parameters:
$
pki
pki
with the command name and no additional options. For example:
$
pki ca
$
pki ca-cert
--help
option:
$
pki --help
$
pki ca-cert-find --help
help
command:
$
pki help
$
pki help ca-cert-find
$
pki ca-cert-find
$
pki -U <server URL> -n <nickname> -c <password> <command> [command parameters]
$
pki -n jsmith -c password ca-user-find ...
http://local_host_name:8080
. To communicate with a server at a different location, specify the URL with the -U
option, for example:
$
pki -U https://server.example.com:8443 -n jsmith -c password ca-user-find
2.5.2. AtoB
$
AtoB input.ascii output.bin
2.5.3. AuditVerify
$ AuditVerify -d ~jsmith/auditVerifyDir -n Log Signing Certificate -a ~jsmith/auditVerifyDir/logListFile -P "" -v
Log Signing Certificate
(-n
) in the ~jsmith/auditVerifyDir
NSS database (-d
). The list of logs to verify (-a
) are in the ~jsmith/auditVerifyDir/logListFile
file, comma-separated and ordered chronologically. The prefix (-P
) to prepend to the certificate and key database file names is empty. The output is verbose (-v
).
2.5.4. BtoA
$
BtoA input.bin output.ascii
2.5.5. CMCRequest
$
CMCRequest example.cfg
Note
CMCRequest
utility are specified as part of the configuration filed passed to the utility. See the CMCRequest(1) man page for configuration file options and further information. Also see 4.3. Requesting and Receiving Certificates Using CMC and 6.2.1. Revoking a Certificate Using CMCRequest in Red Hat Certificate System Administration Guide.
2.5.6. CMCRevoke
2.5.8. CRMFPopClient
CRMFPopClient
utility is Certificate Request Message Format (CRMF) client using NSS databases and supplying Proof of Possession.
$ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -t false -v -o /user_or_entity_database_directory/example.csr
cn=subject_name
subject DN (-n)
, NSS database in the current directory (-d
), certificate to use for transport kra.transport
(-b
), the AES/CBC/PKCS5Padding
key wrap algorithm verbose output is specified (-v
) and the resulting CSR is written to the /user_or_entity_database_directory/example.csr
file (-o)
.
CRMFPopClient --help
command and also 4.2.4. Creating a CSR Using CRMFPopClient in Red Hat Certificate System Administration Guide.
2.5.9. HttpClient
HttpClient
utility is an NSS-aware HTTP client for submitting CMC requests.
$ HttpClient request.cfg
Note
HttpClient
utility are stored in the request.cfg
file. For further information, see the output of the HttpClient --help
command.
2.5.10. OCSPClient
$ OCSPClient -h server.example.com -p 8080 -d /etc/pki/pki-tomcat/alias -c "caSigningCert cert-pki-ca" --serial 2
server.example.com
OCSP server (-h
) on port 8080
(-p
) to check whether the certificate signed by caSigningcet cert-pki-ca
(-c
) with serial number 2
(--serial
) is valid. The NSS database in the /etc/pki/pki-tomcat/alias
directory is used.
OCSPClient --help
command.
2.5.11. PKCS10Client
PKCS10Client
utility creates a CSR in PKCS10 format for RSA and EC keys, optionally on an HSM.
$ PKCS10Client -d /etc/dirsrv/slapd-instance_name/ -p password -a rsa -l 2048 -o ~/ds.csr -n "CN=$HOSTNAME"
-a
) key with 2048 bits (-l
) in the /etc/dirsrv/slapd-instance_name/
directory (-d
with database password password
(-p
). The output CSR is stored in the ~/ds.cfg
file (-o
) and the certificate DN is CN=$HOSTNAME
(-n
).
2.5.12. PrettyPrintCert
$ PrettyPrintCert ascii_data.cert
ascii_data.cert
file and displays its contents in human readable format. The output includes information like signature algorithm, exponent, modulus, and certificate extensions.
2.5.13. PrettyPrintCrl
$ PrettyPrintCrl ascii_data.crl
ascii_data.crl
and displays its contents in human readable format. The output includes information, such as revocation signature algorithm, the issuer of the revocation, and a list of revoked certificates and their reason.
2.5.14. TokenInfo
$ TokenInfo ./nssdb/
TokenInfo
command
2.5.15. tkstool
tkstool
utility is interacting with the token Key Service (TKS) subsystem.
$ tkstool -M -n new_master -d /var/lib/pki/pki-tomcat/alias -h token_name
-M
) named new_master
(-n
) in the /var/lib/pki/pki-tomcat/alias
NSS database on the HSM token_name
tkstool -H
command.
Part II. Setting up Certificate Services
Note
CS.cfg
, server.xml
or any configuration file post-installation is expressly prohibited in a certified environment.
Chapter 3. Making Rules for Issuing Certificates (Certificate Profiles)
3.1. About Certificate Profiles
- Authentication. In every certification profile can be specified an authentication method.
- Authorization. In every certification profile can be specified an authorization method.
- Profile inputs. Profile inputs are parameters and values that are submitted to the CA when a certificate is requested. Profile inputs include public keys for the certificate request and the certificate subject name requested by the end entity for the certificate.
- Profile outputs. Profile outputs are parameters and values that specify the format in which to provide the certificate to the end entity. Profile outputs are CMC responses which contain a PKCS#7 certificate chain, when the request was successful.
- Certificate content. Each certificate defines content information, such as the name of the entity to which it is assigned (the subject name), its signing algorithm, and its validity period. What is included in a certificate is defined in the X.509 standard. With version 3 of the X509 standard, certificates can also contain extensions. For more information about certificate extensions, see Section B.3, “Standard X.509 v3 Certificate Extension Reference”.All of the information about a certificate profile is defined in the
set
entry of the profile policy in the profile's configuration file. When multiple certificates are expected to be requested at the same time, multiple set entries can be defined in the profile policy to satisfy needs of each certificate. Each policy set consists of a number of policy rules and each policy rule describes a field in the certificate content. A policy rule can include the following parts:- Profile defaults. These are predefined parameters and allowed values for information contained within the certificate. Profile defaults include the validity period of the certificate, and what certificate extensions appear for each type of certificate issued.
- Profile constraints. Constraints set rules or policies for issuing certificates. Amongst other, profile constraints include rules to require the certificate subject name to have at least one CN component, to set the validity of a certificate to a maximum of 360 days, to define the allowed grace period for renewal, or to require that the
subjectaltname
extension is always set totrue
.
3.1.1. The Enrollment Profile
caUserCert
profile in Example 3.1, “Example caCMCUserCert Profile”.
Example 3.1. Example caCMCUserCert Profile
desc=This certificate profile is for enrolling user certificates by using the CMC certificate request with CMC Signature authentication. visible=true enable=true enableBy=admin name=Signed CMC-Authenticated User Certificate Enrollment
Note
auth.instance_id=
entry in this profile means that with this profile, authentication is not needed to submit the enrollment request. However, manual approval by an authorized CA agent will be required to get an issuance.
input.list=i1 input.i1.class_id=cmcCertReqInputImp
caCMCUserCert
profile, this defines the certificate request type, which is CMC.
certOutputImpl
, which results in CMC response to be returned to the requestor in case of success.
output.list=o1 output.o1.class_id=certOutputImpl
policyset.list
parameter identifies the block name of the policies that apply to one certificate; the policyset.userCertSet.list
lists the individual policies to apply.
policyset.list=userCertSet policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9 ... policyset.userCertSet.6.constraint.class_id=keyUsageExtConstraintImpl policyset.userCertSet.6.constraint.name=Key Usage Extension Constraint policyset.userCertSet.6.constraint.params.keyUsageCritical=true policyset.userCertSet.6.constraint.params.keyUsageDigitalSignature=true policyset.userCertSet.6.constraint.params.keyUsageNonRepudiation=true policyset.userCertSet.6.constraint.params.keyUsageDataEncipherment=false policyset.userCertSet.6.constraint.params.keyUsageKeyEncipherment=true policyset.userCertSet.6.constraint.params.keyUsageKeyAgreement=false policyset.userCertSet.6.constraint.params.keyUsageKeyCertSign=false policyset.userCertSet.6.constraint.params.keyUsageCrlSign=false policyset.userCertSet.6.constraint.params.keyUsageEncipherOnly=false policyset.userCertSet.6.constraint.params.keyUsageDecipherOnly=false policyset.userCertSet.6.default.class_id=keyUsageExtDefaultImpl policyset.userCertSet.6.default.name=Key Usage Default policyset.userCertSet.6.default.params.keyUsageCritical=true policyset.userCertSet.6.default.params.keyUsageDigitalSignature=true policyset.userCertSet.6.default.params.keyUsageNonRepudiation=true policyset.userCertSet.6.default.params.keyUsageDataEncipherment=false policyset.userCertSet.6.default.params.keyUsageKeyEncipherment=true policyset.userCertSet.6.default.params.keyUsageKeyAgreement=false policyset.userCertSet.6.default.params.keyUsageKeyCertSign=false policyset.userCertSet.6.default.params.keyUsageCrlSign=false policyset.userCertSet.6.default.params.keyUsageEncipherOnly=false policyset.userCertSet.6.default.params.keyUsageDecipherOnly=false ...
3.1.2. Certificate Extensions: Defaults and Constraints
policyset.caCertSet.5.default.name=Basic Constraints Extension Default policyset.caCertSet.5.default.params.basicConstraintsCritical=true policyset.caCertSet.5.default.params.basicConstraintsIsCA=true policyset.caCertSet.5.default.params.basicConstraintsPathLen=-1
policyset.caCertSet.5.constraint.class_id=basicConstraintsExtConstraintImpl policyset.caCertSet.5.constraint.name=Basic Constraint Extension Constraint policyset.caCertSet.5.constraint.params.basicConstraintsCritical=true policyset.caCertSet.5.constraint.params.basicConstraintsIsCA=true policyset.caCertSet.5.constraint.params.basicConstraintsMinPathLen=-1 policyset.caCertSet.5.constraint.params.basicConstraintsMaxPathLen=-1
Note
3.1.3. Inputs and Outputs
input.i1.class_id
parameter in all enabled profiles to cmcCertReqInputImpl
:
input.i1.class_id=cmcCertReqInputImpl
output.o1.class_id
parameter in all enabled profiles to certOutputImpl
:
output.o1.class_id=CertOutputImpl
/ca/ee/ca/profileSubmitUserSignedCMCFull
servlet that is accessed through the end-entities interface.
3.2. Setting up Certificate Profiles
- Using the PKI command-line interface
- Using the Java-based administration console
3.2.1. Managing Certificate Enrollment Profiles Using the PKI Command-line Interface
pki
utility. For further details, see the pki-ca-profile(1) man page.
Note
3.2.1.1. Enabling and Disabling a Certificate Profile
Note
caCMCECserverCert
certificate profile:
# pki -c password -n caagent ca-profile-disable caCMCECserverCert
caCMCECserverCert
certificate profile:
# pki -c password -n caagent ca-profile-enable caCMCECserverCert
3.2.1.2. Creating a Certificate Profile in Raw Format
# pki -c password -n caadmin ca-profile-add profile_name.cfg --raw
Note
profileId=profile_name
3.2.1.3. Editing a Certificate Profile in Raw Format
caCMCECserverCert
profile:
# pki -c password -n caadmin ca-profile-edit caCMCECserverCert
VI
editor. When you close the editor, the profile configuration is updated on the server.
Important
Example 3.2. Editing a Certificate Profile in RAW Format
caCMCserverCert
profile to accept multiple user-supplied extensions:
- Disable the profile as a CA agent:
# pki -c password -n caagemt ca-profile-disable caCMCserverCert
- Edit the profile as a CA administrator:
- Download and open the profile in the
VI
editor:# pki -c password -n caadmin ca-profile-edit caCMCserverCert
- Update the configuration to accept the extensions. For details, see Example B.3, “Multiple User Supplied Extensions in CSR”.
- Enable the profile as a CA agent:
# pki -c password -n caagent ca-profile-enable caCMCserverCert
3.2.1.4. Deleting a Certificate Profile
# pki -c password -n caadmin ca-profile-del profile_name
Important
3.2.2. Managing Certificate Enrollment Profiles Using the Java-based Administration Console
3.2.2.1. Creating Certificate Profiles through the CA Console
- Log in to the Certificate System CA subsystem console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, select Certificate Manager, and then select Certificate Profiles.The Certificate Profile Instances Management tab, which lists configured certificate profiles, opens.
- To create a new certificate profile, click.In the Select Certificate Profile Plugin Implementation window, select the type of certificate for which the profile is being created.
- Fill in the profile information in the Certificate Profile Instance Editor.
- Certificate Profile Instance ID. This is the ID used by the system to identify the profile.
- Certificate Profile Name. This is the user-friendly name for the profile.
- Certificate Profile Description.
- End User Certificate Profile. This sets whether the request must be made through the input form for the profile. This is usually set to
true
. Setting this tofalse
allows a signed request to be processed through the Certificate Manager's certificate profile framework, rather than through the input page for the certificate profile. - Certificate Profile Authentication. This sets the authentication method. An automated authentication is set by providing the instance ID for the authentication instance. If this field is blank, the authentication method is agent-approved enrollment; the request is submitted to the request queue of the agent services interface.Unless it is for a TMS subsystem, administrators must select one of the following authentication plug-ins:
CMCAuth
: Use this plug-in when a CA agent must approve and submit the enrollment request.CMCUserSignedAuth
: Use this plug-in to enable non-agent users to enroll own certificates.
- Click. The plug-in editor closes, and the new profile is listed in the profiles tab.
- Configure the policies, inputs, and outputs for the new profile. Select the new profile from the list, and click.
- Set up policies in the Policies tab of the Certificate Profile Rule Editor window. The Policies tab lists policies that are already set by default for the profile type.
- To add a policy, click.
- Choose the default from the Default field, choose the constraints associated with that policy in the Constraints field, and click .
- Fill in the policy set ID. When issuing dual key pairs, separate policy sets define the policies associated with each certificate. Then fill in the certificate profile policy ID, a name or identifier for the certificate profile policy.
- Configure any parameters in the Defaults and Constraints tabs.Defaults defines attributes that populate the certificate request, which in turn determines the content of the certificate. These can be extensions, validity periods, or other fields contained in the certificates. Constraints defines valid values for the defaults.See Section B.1, “Defaults Reference” and Section B.2, “Constraints Reference” for complete details for each default or constraint.
To modify an existing policy, select a policy, and click. Then edit the default and constraints for that policy.To delete a policy, select the policy, and click. - Set inputs in the Inputs tab of the Certificate Profile Rule Editor window. There can be more than one input type for a profile.
Note
Unless you configure the profile for a TMS subsystem, select onlycmcCertReqInput
and delete other profiles by selecting them and clicking the button.- To add an input, click.
- Choose the input from the list, and click Section A.1, “Input Reference” for complete details of the default inputs.. See
- The New Certificate Profile Editor window opens. Set the input ID, and click .
Inputs can be added and deleted. It is possible to select edit for an input, but since inputs have no parameters or other settings, there is nothing to configure.To delete an input, select the input, and click. - Set up outputs in the Outputs tab of the Certificate Profile Rule Editor window.Outputs must be set for any certificate profile that uses an automated authentication method; no output needs to be set for any certificate profile that uses agent-approved authentication. The Certificate Output type is set by default for all profiles and is added automatically to custom profiles.Unless you configure the profile for a TMS subsystem, select only
certOutput
.Outputs can be added and deleted. It is possible to select edit for an output, but since outputs have no parameters or other settings, there is nothing to configure.- To add an output, click.
- Choose the output from the list, and click.
- Give a name or identifier for the output, and click.This output will be listed in the output tab. You can edit it to provide values to the parameters in this output.
To delete an output, select the output from list, and click. - Restart the CA to apply the new profile.
systemctl restart pki-tomcatd-nuxwdog@instance_name.service
- After creating the profile as an administrator, a CA agent has to approve the profile in the agent services pages to enable the profile.
- Open the CA's services page.
https://server.example.com:8443/ca/services
- Click the Manage Certificate Profiles link. This page lists all of the certificate profiles that have been set up by an administrator, both active and inactive.
- Click the name of the certificate profile to approve.
- At the bottom of the page, click thebutton.
Note
3.2.2.2. Editing Certificate Profiles in the Console
- Log into the agent services pages and disable the profile.Once a certificate profile is enabled by an agent, that certificate profile is marked enabled in the Certificate Profile Instance Management tab, and the certificate profile cannot be edited in any way through the console.
- Log in to the Certificate System CA subsystem console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, select Certificate Manager, and then select Certificate Profiles.
- Select the certificate profile, and click.
- The Certificate Profile Rule Editor window appears. Many any changes to the defaults, constraints, inputs, or outputs.
Note
The profile instance ID cannot be modified.If necessary, enlarge the window by pulling out one of the corners of the window. - Restart the CA to apply the changes.
- In the agent services page, re-enable the profile.
Note
3.2.3. Listing Certificate Enrollment Profiles
pki
utility. For example:
# pki -c password -n caadmin ca-profile-find ------------------ 59 entries matched ------------------ Profile ID: caCMCserverCert Name: Server Certificate Enrollment using CMC Description: This certificate profile is for enrolling server certificates using CMC. Profile ID: caCMCECserverCert Name: Server Certificate wth ECC keys Enrollment using CMC Description: This certificate profile is for enrolling server certificates with ECC keys using CMC. Profile ID: caCMCECsubsystemCert Name: Subsystem Certificate Enrollment with ECC keys using CMC Description: This certificate profile is for enrolling subsystem certificates with ECC keys using CMC. Profile ID: caCMCsubsystemCert Name: Subsystem Certificate Enrollment using CMC Description: This certificate profile is for enrolling subsystem certificates using CMC. ... ----------------------------- Number of entries returned 20
3.2.4. Displaying Details of a Certificate Enrollment Profile
caECFullCMCUserSignedCert
:
$ pki -c password -n caadmin ca-profile-show caECFullCMCUserSignedCert ----------------------------------- Profile "caECFullCMCUserSignedCert" ----------------------------------- Profile ID: caECFullCMCUserSignedCert Name: User-Signed CMC-Authenticated User Certificate Enrollment Description: This certificate profile is for enrolling user certificates with EC keys by using the CMC certificate request with non-agent user CMC authentication. Name: Certificate Request Input Class: cmcCertReqInputImpl Attribute Name: cert_request Attribute Description: Certificate Request Attribute Syntax: cert_request Name: Certificate Output Class: certOutputImpl Attribute Name: pretty_cert Attribute Description: Certificate Pretty Print Attribute Syntax: pretty_print Attribute Name: b64_cert Attribute Description: Certificate Base-64 Encoded Attribute Syntax: pretty_print
caECFullCMCUserSignedCert
, in raw format:
$ pki -c password -n caadmin ca-profile-show caECFullCMCUserSignedCert --raw #Wed Jul 25 14:41:35 PDT 2018 auth.instance_id=CMCUserSignedAuth policyset.cmcUserCertSet.1.default.params.name= policyset.cmcUserCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl policyset.cmcUserCertSet.6.default.params.keyUsageKeyCertSign=false policyset.cmcUserCertSet.10.default.class_id=noDefaultImpl policyset.cmcUserCertSet.10.constraint.name=Renewal Grace Period Constraint output.o1.class_id=certOutputImpl ...
3.3. Defining Key Defaults in Profiles
policyset.set1.p3.constraint.class_id=noConstraintImpl policyset.set1.p3.constraint.name=No Constraint policyset.set1.p3.default.class_id=subjectKeyIdentifierExtDefaultImpl policyset.set1.p3.default.name=Subject Key Identifier Default ... policyset.set1.p11.constraint.class_id=keyConstraintImpl policyset.set1.p11.constraint.name=Key Constraint policyset.set1.p11.constraint.params.keyType=RSA policyset.set1.p11.constraint.params.keyParameters=1024,2048,3072,4096 policyset.set1.p11.default.class_id=userKeyDefaultImpl policyset.set1.p11.default.name=Key Default
policyset
list, then, the Key Default (p11
) must be listed before the Subject Key Identifier Default (p3
).
policyset.set1.list=p1,p2,p11,p3
,p4,p5,p6,p7,p8,p9,p10
3.4. Configuring Profiles to Enable Renewal
3.4.1. About Renewal
3.4.1.1. The Renewal Process
renewGracePeriodConstraint
entry. For example:
policyset.cmcUserCertSet.10.constraint.class_id=renewGracePeriodConstraintImpl policyset.cmcUserCertSet.10.constraint.name=Renewal Grace Period Constraint policyset.cmcUserCertSet.10.constraint.params.renewal.graceBefore=30 policyset.cmcUserCertSet.10.constraint.params.renewal.graceAfter=30 policyset.cmcUserCertSet.10.default.class_id=noDefaultImpl policyset.cmcUserCertSet.10.default.name=No Default
3.4.1.1.1. Renewing Using the Same Key
allowSameKeyRenewal
parameter set to true
in the uniqueKeyConstraint
entry. For example:
policyset.cmcUserCertSet.9.constraint.class_id=uniqueKeyConstraintImpl policyset.cmcUserCertSet.9.constraint.name=Unique Key Constraint policyset.cmcUserCertSet.9.constraint.params.allowSameKeyRenewal=true policyset.cmcUserCertSet.9.default.class_id=noDefaultImpl policyset.cmcUserCertSet.9.default.name=No Default
3.4.1.1.2. Renewal Using a New Key
subjectDN
from the user signing certificate used to sign the request for the new certificate.
3.5. Setting the Signing Algorithms for Certificates
3.5.1. Setting the CA's Default Signing Algorithm
- Open the CA console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, expand the Certificate Manager tree.
- In the General Settings tab, set the algorithm to use in the Algorithm drop-down menu.
3.5.2. Setting the Signing Algorithm Default in a Profile
.cfg
file, the algorithm is set with two parameters:
policyset.cmcUserCertSet.8.constraint.class_id=signingAlgConstraintImpl policyset.cmcUserCertSet.8.constraint.name=No Constraint policyset.cmcUserCertSet.8.constraint.params.signingAlgsAllowed=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withRSA,SHA384withEC,SHA512withEC policyset.cmcUserCertSet.8.default.class_id=signingAlgDefaultImpl policyset.cmcUserCertSet.8.default.name=Signing Alg policyset.cmcUserCertSet.8.default.params.signingAlg=-
Note
- Open the CA console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, expand the Certificate Manager tree.
- Click the Certificate Profiles item.
- Click the Policies tab.
- Select the Signing Alg policy, and click the button.
- To set the default signing algorithm, set the value in the Defaults tab. If this is set to -, then the profile uses the CA's default.
- To set a list of allowed signing algorithms which can be accepted in a certificate request, open the Constraints tab, and set the list of algorithms in the Value field for
signingAlgsAllowed
.The possible values for the constraint are listed in Section B.2.10, “Signing Algorithm Constraint”.
3.7. Managing Subject Names and Subject Alternative Names
Important
3.7.1. Using the Requester CN or UID in the Subject Name
cn
or uid
value from a certificate request can be used to build the subject name of the issued certificate. This section demonstrates a profile that requires the naming attribute (CN or UID) being specified in the Subject Name Constraint to be present in the certificate request. If the naming attribute is missing, the request is rejected.
- The CN or UID format is set in the
pattern
configuration in the Subject Name Constraint. - The format of the subject DN, including the CN or UID token and the specific suffix for the certificate, is set in the Subject Name Default.
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.serverCertSet.1.constraint.name=Subject Name Constraint policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl policyset.serverCertSet.1.default.name=Subject Name Default policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,DC=example, DC=com
cn=John Smith
, then the certificate will be issued with a subject DN of cn=John Smith,DC=example, DC=com
. If the request comes in but it has a UID of uid=jsmith
and no CN, then the request is rejected.
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.serverCertSet.1.constraint.name=Subject Name Constraint policyset.serverCertSet.1.constraint.params.pattern=UID=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl policyset.serverCertSet.1.default.name=Subject Name Default policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.uid$,DC=example, DC=com
pattern
parameter is covered in Section B.2.11, “Subject Name Constraint” and Section B.1.28, “Subject Name Default”.
3.7.2. Inserting LDAP Directory Attribute Values and Other Information into the Subject Alt Name
policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl policyset.userCertSet.8.default.name=Subject Alt Name Constraint policyset.userCertSet.8.default.params.subjAltNameExtCritical=false policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$ policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true
Type_
, Pattern_
, and Enable_
values numerically, such as Type_1
.
- Inserting LDAP attribute values requires enabling the user directory authentication plug-in,
SharedSecret
.- Open the CA Console.
pkiconsole https://server.example.com:8443/ca
- Select Authentication in the left navigation tree.
- In the Authentication Instance tab, click , and add an instance of the
SharedSecret
authentication plug-in. - Enter the following information:
Authentication InstanceID=SharedToken shrTokAttr=shrTok ldap.ldapconn.host=server.example.com ldap.ldapconn.port=636 ldap.ldapconn.secureConn=true ldap.ldapauth.bindDN=cn=Directory Manager password=password ldap.ldapauth.authtype=BasicAuth ldap.basedn=ou=People,dc=example,dc=org
- Save the new plug-in instance.
For information on setting a CMC shared token, see Section 8.1.3.2, “Setting a CMC Shared Secret”. - The
ldapStringAttributes
parameter instructs the authentication plug-in to read the value of themail
attribute from the user's LDAP entry and put that value in the certificate request. When the value is in the request, the certificate profile policy can be set to insert that value for an extension value.The format for thednpattern
parameter is covered in Section B.2.11, “Subject Name Constraint” and Section B.1.28, “Subject Name Default”. - To enable the CA to insert the LDAP attribute value in the certificate extension, edit the profile's configuration file, and insert a policy set parameter for an extension. For example, to insert the
mail
attribute value in the Subject Alternative Name extension in thecaFullCMCSharedTokenCert
profile, change the following code:policyset.setID.8.default.params.
subjAltExtPattern_0=$request.auth_token.mail[0]$
For more details about editing a profile, see Section 3.2.1.3, “Editing a Certificate Profile in Raw Format”. - Restart the CA.
systemctl restart pki-tomcatd-nuxwdog@instance_name.service
caFullCMCSharedTokenCert
profile enrollment form will have the Subject Alternative Name extension added with the value of the requester's mail
LDAP attribute. For example:
Identifier: Subject Alternative Name - 2.5.29.17 Critical: no Value: RFC822Name: jsmith@example.com
Pattern_
parameters in the policy set. The common tokens are listed in Table 3.1, “Variables Used to Populate Certificates”, and the default profiles contain examples for how these tokens are used.
Policy Set Token | Description |
---|---|
$request.auth_token.cn[0]$ | The LDAP common name (cn ) attribute of the user who requested the certificate. |
$request.auth_token.mail[0]$ | The value of the LDAP email (mail ) attribute of the user who requested the certificate. |
$request.auth_token.tokencertsubject$ | The certificate subject name. |
$request.auth_token.uid$ | The LDAP user ID (uid ) attribute of the user who requested the certificate. |
$request.auth_token.userdn$ | The user DN of the user who requested the certificate. |
$request.auth_token.userid$ | The value of the user ID attribute for the user who requested the certificate. |
$request.uid$ | The value of the user ID attribute for the user who requested the certificate. |
$request.requestor_email$ | The email address of the person who submitted the request. |
$request.request_name$ | The person who submitted the request. |
$request.upn$ | The Microsoft UPN. This has the format (UTF8String)1.3.6.1.4.1.311.20.2.3,$request.upn$. |
$server.source$ | Instructs the server to generate a version 4 UUID (random number) component in the subject name. This always has the format (IA5String)1.2.3.4,$server.source$. |
$request.auth_token.user$ | Used when the request was submitted by TPS. The TPS subsystem trusted manager who requested the certificate. |
$request.subject$ | Used when the request was submitted by TPS. The subject name DN of the entity to which TPS has resolved and requested for. For example, cn=John.Smith.123456789,o=TMS Org |
3.7.3. Using the CN Attribute in the SAN Extension
dNSName
Subject Alternative Name (SAN) value in the certificate request.
dNSName
value based on the CN is appended to existing SANs.
- Disable the profile:
# pki -c password -p 8080 \ -n "PKI Administrator for example.com" ca-profile-disable profile_name
- Edit the profile:
# pki -c password -p 8080 \ -n "PKI Administrator for example.com" ca-profile-edit profile_name
- Add the following configuration with a unique set number for the profile. For example:
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl policyset.serverCertSet.12.constraint.name=No Constraint policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl policyset.serverCertSet.12.default.name=Copy Common Name to Subject
The previous example uses12
as the set number. - Append the new policy set number to the
policyset.userCertSet.list
parameter. For example:policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9,12
- Save the profile.
- Enable the profile:
# pki -c password -p 8080 \ -n "PKI Administrator for example.com" ca-profile-enable profile_name
Note
commonNameToSANDefaultImpl
default.
3.7.4. Accepting SAN Extensions from a CSR
3.7.4.1. Configuring a Profile to Retrieve SANs from a CSR
Note
caCMCECserverCert
:
prefix.constraint.class_id=noConstraintImpl prefix.constraint.name=No Constraint prefix.default.class_id=userExtensionDefaultImpl prefix.default.name=User supplied extension in CSR prefix.default.params.userExtOID=2.5.29.17
3.7.4.2. Generating a CSR with SANs
certutil
utility:
# certutil -R -k ec -q nistp256 -d . -s "cn=Example Multiple SANs" --extSAN dns:www.example.com,dns:www.example.org -a -o /root/request.csr.p10
Chapter 4. Setting up Key Archival and Recovery
Note
Note
Note
4.1. About Key Archival and Recovery
pki
utility, which can generate a key and a certificate profile which is configured to support key archival. For details about the pki
utility, see the Command-Line Interface (CLI) section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition).
4.1.1. Key Archival
Figure 4.1. How the Key Archival Process Works
- The client generates and encrypts its private key and submits the request to the CA.
- After approving the certificate request and issuing the certificate, the Certificate Manager sends it to the KRA for storage, along with the public key. The Certificate Manager waits for verification from the KRA that the private key has been received and stored and that it corresponds to the public encryption key.
- The KRA decrypts it with the transport private key. After confirming that the private encryption key corresponds to the public encryption key, the KRA encrypts it again with its public key pair of the storage key before storing it in its internal database.
- The Certificate Manager issues the certificate, which is embedded in the CMC response.
Figure 4.2. Async and Sync Recovery, Side by Side
Important
4.1.2. Key Recovery
- Generate a CRMF request and submit it through the CA’s enrollment portal.For more information, see Section 5.3.2.3.1, “Example on Obtaining an Encryption-only certificate with Key Archival”.
- Import the certificates into an email client capable of doing SMIME.
- Confirm that the key has been archived. In the KRA's agent services page, select Show completed requests. If the key has been archived successfully, there will be information about that key. If the key is not shown, check the logs, and correct the problem. If the key has been successfully archived, close the browser window.
- Verify the key. Send a signed and encrypted email. When the email is received, open it, and check the message to see if it is signed and encrypted. There should be a security icon at the top-right corner of the message window that indicates that the message is signed and encrypted.
- Delete the certificate. Check the encrypted email again; the mail client should not be able to decrypt the message.
- Test whether an archived key can be recovered successfully:
- Open the KRA's agent services page, and click the Recover Keys link. Search for the key by the key owner, serial number, or public key. If the key has been archived successfully, the key information will be shown.
- Click.
- In the form that appears, enter the base-64 encoded certificate that corresponds to the private key to recover; use the CA to get this information. If the archived key was searched for by providing the base-64 encoded certificate, then the certificate does not have to be supplied here.
- Make sure that the Async Recovery checkbox is selected to allow the browser session to be closed while recovery is ongoing.
- Depending on the agent scheme, a specified number of agents must authorize this key recovery. Have the agents search for the key to recover and then to approve the initiated recovery.
- Once all the agents have authorized the recovery, the next screen requests a password to encrypt the PKCS #12 file with the certificate.
- The next screen returns a link to download a PKCS #12 blob containing the recovered key pair. Follow the link, and save the blob to file.
Important
Opening the PKCS #12 file directly from the browser in thegcr-viewer
utility can fail in certain situations. To work around the problem, download the file and manually open it ingcr-viewer
.
- Restore the key to the browser's database. Import the
.p12
file into the browser and mail client. - Open the test email. The message should be shown again.
Chapter 5. Requesting, Enrolling, and Managing Certificates
5.1. About Enrolling and Renewing Certificates
- A user generates a certificate request.
- The certificate request is submitted to the CA.
- The request is verified by authenticating the entity which requested it and by confirming that the request meets the certificate profile rules which were used to submit it.
- The request is approved.
- The user retrieves the new certificate.
5.2. Creating Certificate Signing Requests
CMCRequest
utility accepts Certificate Signing Requests (CSR) in PKCS #10 and CRMF format.
certutil
: Supports creating PKCS #10 requests.PKCS10Client
: Supports creating PKCS #10 requests.CRMFPopClient
: Supports creating CRMF requests.
5.2.1. Creating a CSR Using certutil
certutil
utility to create a CSR.
certutil
, see:
- The certutil(1) man page
- The output of the
certutil --help
command
5.2.1.1. Using certutil
to Create a CSR with EC Keys
certutil
utility to create an Elliptic Curve (EC) key pair and CSR:
- Change to the certificate database directory of the user or entity for which the certificate is being requested, for example:
$ cd /user_or_entity_database_directory/
- Create the binary CSR and store it in the
/user_or_entity_database_directory/request.csr
file:$ certutil -d . -R -k ec -q nistp256 -s "CN=subject_name" -o /user_or_entity_database_directory/request-bin.csr
Enter the required NSS database password when prompted.For further details about the parameters, see the certutil(1) man page. - Convert the created binary format CSR to PEM format:
$ BtoA /user_or_entity_database_directory/request-bin.csr /user_or_entity_database_directory/request.csr
- Optionally, verify that the CSR file is correct:
$ cat /user_or_entity_database_directory/request.csr MIICbTCCAVUCAQAwKDEQMA4GA1UEChMHRXhhbXBsZTEUMBIGA1UEAxMLZXhhbXBs ...
This is a PKCS#10 PEM certificate request. - For the next steps, see Section 5.3.1, “The CMC Enrollment Process”, but skip the step about creating the certificate request.
5.2.1.2. Using certutil
to Create a CSR With User-defined Extensions
certutil
utility.
- Change to the certificate database directory of the user or entity for which the certificate is being requested, for example:
$ cd /user_or_entity_database_directory/
- Create the CSR with user-defined Key Usage extension as well as user-defined Extended Key Usage extension and store it in the
/user_or_entity_database_directory/request.csr
file:$ certutil -d . -R -k rsa -g 1024 -s "CN=subject_name" --keyUsage keyEncipherment,dataEncipherment,critical --extKeyUsage timeStamp,msTrustListSign,critical -a -o /user_or_entity_database_directory/request.csr
Enter the required NSS database password when prompted.For further details about the parameters, see the certutil(1) man page. - Optionally, verify that the CSR file is correct:
$ cat /user_or_entity_database_directory/request.csr Certificate request generated by Netscape certutil Phone: (not specified) Common Name: user 4-2-1-2 Email: (not specified) Organization: (not specified) State: (not specified) Country: (not specified)
This is a PKCS#10 PEM certificate request. - For the next steps, see Section 5.3.1, “The CMC Enrollment Process”, but skip the step about creating the certificate request.
Note
Remove the header information from the CSR.
5.2.2. Creating a CSR Using PKCS10Client
PKCS10Client
utility to create a CSR.
PKCS10Client
, see:
- The PKCS10Client(1) man page
- The output of the
PKCS10Client --help
command
5.2.2.1. Using PKCS10Client
to Create a CSR
PKCS10Client
utility to create an Elliptic Curve (EC) key pair and CSR:
- Change to the certificate database directory of the user or entity for which the certificate is being requested, for example:
$ cd /user_or_entity_database_directory/
- Create the CSR and store it in the
/user_or_entity_database_directory/example.csr
file:$ PKCS10Client -d . -p NSS_password -a ec -c nistp256 -o /user_or_entity_database_directory/example.csr -n "CN=subject_name"
For further details about the parameters, see the PKCS10Client(1) man page. - Optionally, verify that the CSR is correct:
$ cat /user_or_entity_database_directory/example.csr -----BEGIN CERTIFICATE REQUEST----- MIICzzCCAbcCAQAwgYkx ... -----END CERTIFICATE REQUEST-----
5.2.2.2. Using PKCS10Client
to Create a CSR for SharedSecret-based CMC
PKCS10Client
utility to create an RSA key pair and CSR for SharedSecret-based CMC. Use it only with the CMC Shared Secret authentication method which is, by default, handled by the caFullCMCSharedTokenCert
and caECFullCMCSharedTokenCert
profiles.
- Change to the certificate database directory of the user or entity for which the certificate is being requested, for example:
$ cd /user_or_entity_database_directory/
- Create the CSR and store it in the
/user_or_entity_database_directory/example.csr
file:$ PKCS10Client -d . -p NSS_password -o /user_or_entity_database_directory/example.csr -y true -n "CN=subject_name"
For further details about the parameters, see the PKCS10Client(1) man page. - Optionally, verify that the CSR is correct:
$ cat /user_or_entity_database_directory/example.csr -----BEGIN CERTIFICATE REQUEST----- MIICzzCCAbcCAQAwgYkx ... -----END CERTIFICATE REQUEST-----
5.2.3. Creating a CSR Using CRMFPopClient
CRMFPopClient
utility to create a CSR.
CRMFPopClient
, see the CRMFPopClient(1) man page.
5.2.3.1. Using CRMFPopClient
to Create a CSR with Key Archival
CRMFPopClient
utility to create an RSA key pair and a CSR with the key archival option:
- Change to the certificate database directory of the user or entity for which the certificate is being requested, for example:
$ cd /user_or_entity_database_directory/
- Retrieve the KRA transport certificate:
$ pki ca-cert-find --name "DRM Transport Certificate" --------------- 1 entries found --------------- Serial Number: 0x7 Subject DN: CN=DRM Transport Certificate,O=EXAMPLE Status: VALID Type: X.509 version 3 Key A lgorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Thu Oct 22 18:26:11 CEST 2015 Not Valid After: Wed Oct 11 18:26:11 CEST 2017 Issued On: Thu Oct 22 18:26:11 CEST 2015 Issued By: caadmin ---------------------------- Number of entries returned 1
- Export the KRA transport certificate:
$ pki ca-cert-show 0x7 --output kra.transport
- Create the CSR and store it in the
/user_or_entity_database_directory/example.csr
file:$ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -v -o /user_or_entity_database_directory/example.csr
To create an Elliptic Curve (EC) key pair and CSR, pass the-a ec -t false
options to the command.For further details about the parameters, see the CRMFPopClient(1) man page. - Optionally, verify that the CSR is correct:
$ cat /user_or_entity_database_directory/example.csr -----BEGIN CERTIFICATE REQUEST----- MIICzzCCAbcCAQAwgYkx ... -----END CERTIFICATE REQUEST-----
5.2.3.2. Using CRMFPopClient
to Create a CSR for SharedSecret-based CMC
CRMFPopClient
utility to create an RSA key pair and CSR for SharedSecret-based CMC. Use it only with the CMC Shared Secret authentication method which is, by default, handled by the caFullCMCSharedTokenCert
and caECFullCMCSharedTokenCert
profiles.
- Change to the certificate database directory of the user or entity for which the certificate is being requested, for example:
$ cd /user_or_entity_database_directory/
- Retrieve the KRA transport certificate:
$ pki ca-cert-find --name "DRM Transport Certificate" --------------- 1 entries found --------------- Serial Number: 0x7 Subject DN: CN=DRM Transport Certificate,O=EXAMPLE Status: VALID Type: X.509 version 3 Key A lgorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Thu Oct 22 18:26:11 CEST 2015 Not Valid After: Wed Oct 11 18:26:11 CEST 2017 Issued On: Thu Oct 22 18:26:11 CEST 2015 Issued By: caadmin ---------------------------- Number of entries returned 1
- Export the KRA transport certificate:
$ pki ca-cert-show 0x7 --output kra.transport
- Create the CSR and store it in the
/user_or_entity_database_directory/example.csr
file:$ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -y -v -o /user_or_entity_database_directory/example.csr
To create an EC key pair and CSR, pass the-a ec -t false
options to the command.For further details about the parameters, see the output of theCRMFPopClient --help
command. - Optionally, verify that the CSR is correct:
$ cat /user_or_entity_database_directory/example.csr -----BEGIN CERTIFICATE REQUEST----- MIICzzCCAbcCAQAwgYkx ... -----END CERTIFICATE REQUEST-----
5.3. Requesting and Receiving Certificates Using CMC
- The Configuration for CMC section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition).
- The Enrolling with CMC section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition).
- CMCRequest(1) man page
- CMCResponse(1) man page
5.3.1. The CMC Enrollment Process
- Create a Certificate Signing Request (CSR) in one of the following formats:
- PKCS #10 format
- Certificate Request Message Format (CRMF) format:
For details about creating CSRs in these formats, see Section 5.2, “Creating Certificate Signing Requests”. - Import the admin certificate into the client NSS database. For example:
- Execute the command below to extract the admin client certificate from the
.p12
file:$
openssl pkcs12 -in /root/.dogtag/instance/ca_admin_cert.p12 -clcerts -nodes -nokeys -out /root/.dogtag/instance/ca_admin_cert.crt - Validate and import the admin client certificate according to guidance in Chapter 11, Managing Certificate/Key Crypto Token:
$
PKICertImport -d . -n "CA Admin - Client Certificate" -t ",," -a -i /root/.dogtag/instance/ca_admin_cert.crt -u CImportant
Make sure all intermediate certificates and the root CA certificate have been imported before importing the CA Admin client certificate. - Import the private keys associated with the certificates.
$ pki -c password pkcs12-import --pkcs12-file /root/.dogtag/instance/ca_admin_cert.p12 --pkcs12-password-file /root/.dogtag/instance/ca/pkcs12_password.conf
- Create a configuration file for a CMC request, such as
/home/user_name/cmc-request.cfg
, with the following content:# NSS database directory where CA agent certificate is stored dbdir=/home/user_name/.dogtag/nssdb/ # NSS database password password=password # Token name (default is internal) tokenname=internal # Nickname for signing certificate nickname=subsystem_admin # Request format: pkcs10 or crmf format=pkcs10 # Total number of PKCS10/CRMF requests numRequests=1 # Path to the PKCS10/CRMF request # The content must be in Base-64 encoded format. # Multiple files are supported. They must be separated by space. input=/home/user_name/file.csr # Path for the CMC request output=/home/user_name/cmc-request.bin
For further details, see the CMCRequest(1) man page. - Create the CMC request:
$ CMCRequest /home/user_name/cmc-request.cfg
If the command succeeds, theCMCRequest
utility stored the CMC request in the file specified in theoutput
parameter in the request configuration file. - Create a configuration file for
HttpClient
, such as/home/user_name/cmc-submit.cfg
, which you use in a later step to submit the CMC request to the CA. Add the following content to the created file:# PKI server host name host=server.example.com # PKI server port number port=8443 # Use secure connection secure=true # Use client authentication clientmode=true # NSS database directory where the CA agent certificate is stored. dbdir=/home/user_name/.dogtag/nssdb/ # NSS database password password=password # Token name (default: internal) tokenname=internal # Nickname of signing certificate nickname=subsystem_admin # Path for the CMC request input=/home/user_name/cmc-request.bin # Path for the CMC response output=/home/user_name/cmc-response.bin
Important
The nickname of the certificate specified in thenickname
parameter must match the one previously used for the CMC request. - Depending on what type of certificate you request, add the following parameter to the configuration file created in the previous step:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=profile_name
For example, for a CA signing certificate:servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
Important
When an agent submits the CMC request in the next step, the profile specified in this parameter must use theCMCAuth
authentication plug-in. Whereas in user-initiated enrollments, the profile must use theCMCUserSignedAuth
plug-in. For further details, see Section 8.1.2, “CMC Authentication Plug-ins”. - Submit the CMC request to the CA:
$ HttpClient /home/user_name/cmc-submit.cfg
- To convert the CMC response to a PKCS #7 certificate chain, pass the CMC response file to the
-i
parameter of theCMCResponse
utility. For example:$ CMCResponse -i /home/user_name/cmc-response.bin -o /home/user_name/cert_chain.crt
5.3.2. Practical CMC Enrollment Scenarios
5.3.2.1. Obtaining System and Server Certificates
- Enrollment Profiles
- The agent must either use one of the existing CMC profiles listed in Section 8.1.2, “CMC Authentication Plug-ins” or, alternatively, create a custom profile that uses the
CMCAuth
authentication mechanism. - CMC Signing Certificate
- For system certificates, the CA agent must generate and sign the CMC request. For this, set the
nickname
parameter in theCMCRequest
configuration file to the nickname of the CA agent.Note
The CA agent must have access to its own private key. HttpClient
TLS Client Nickname- Use the same certificate for signing in the
CMCRequest
utility's configuration file as for TLS client authentication in the configuration file forHttpClient
. HttpClient
servlet
Parameter- The
servlet
in the configuration file passed to theHttpClient
utility refers to the CMC servlet and the enrollment profile which handles the request.Depending on what type of certificate you request, add one of the following entries to the configuration file created in the previous step:- For a CA signing certificate:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
- For a KRA transport certificate:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCkraTransportCert
- For a OCSP signing certificate:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCocspCert
- For a audit signing certificate:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCauditSigningCert
- For a subsystem certificate:
- For RSA certificates:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCsubsystemCert
- For ECC certificates:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCsubsystemCert
- For a TLS server certificate:
- For RSA certificates:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
- For ECC certificates:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCserverCert
- For an admin certificate:
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
- When an agent pre-signs a CSR, the Proof of Identification is considered established because the agent examines the CSR for identification. No additional CMC-specific identification proof is required.
- PKCS #10 files already provide Proof of Possession information and no additional Proof of Possession (POP) is required.
- In agent pre-approved requests, the
PopLinkWittnessV2
feature must be disabled because the identification is checked by the agent.
5.3.2.2. Obtaining the First Signing Certificate for a User
- An agent signs the CMC request. See Section 5.3.2.2.1, “Signing a CMC Request with an Agent Certificate”.
- Certificate enrollment is authenticated by using a Shared Secret. See Section 5.3.2.2.2, “Authenticating for Certificate Enrollment Using a Shared Secret”.
5.3.2.2.1. Signing a CMC Request with an Agent Certificate
5.3.2.3. Obtaining an Encryption-only Certificate for a User
Note
- Use the cryptographic token stored in a Network Security Services (NSS) database or on a smart card that contains the user's signing certificate and keys.
- Generate the CSR in PKCS #10 or the CRMF format.
Note
Use the CRMF format, if key archival is required. - Generate the CMC request.Since this is an encryption-only certificate, the private key is not able to sign. Therefore, Proof Of Possession (POP) is not included. For this reason, the enrollment requires two steps: If the initial request is successful, results in a CMC status with the
EncryptedPOP
control. The user then uses the response and generates a CMC request that contains theDecryptedPOP
control and submits it in the second step.- For the first step, in addition to the default parameters, the user must set the following parameters in the configuration file passed to the
CMCRequest
utility:identification.enable
witness.sharedSecret
identityProofV2.enable
identityProofV2.hashAlg
identityProofV2.macAlg
popLinkWitnessV2.enable
if required by the CApopLinkWitnessV2.keyGenAlg
if required by the CApopLinkWitnessV2.macAlg
if required by the CArequest.privKeyId
For details, see the CMCRequest(1) man page.The response contains:- A CMC encrypted POP control
- The
CMCStatusInfoV2
control with thePOP required
error - The request ID
- For the second step, in addition to the default parameters, the user must set the following parameters in the configuration file passed to the
CMCRequest
utility:decryptedPop.enable
encryptedPopResponseFile
decryptedPopRequestFile
request.privKeyId
For details, see the CMCRequest(1) man page.
5.3.2.3.1. Example on Obtaining an Encryption-only certificate with Key Archival
Note
-q POP_SUCCESS
option instead of -q POP_NONE
to the CRMFPopClient
utility for a single-trip issuance.
CRMFPoPClient
with POP_SUCCESS
, see Section 5.2.3.1, “Using CRMFPopClient
to Create a CSR with Key Archival” and Section 5.2.3.2, “Using CRMFPopClient
to Create a CSR for SharedSecret-based CMC”.
- Search for the KRA transport certificate. For example:
$ pki cert-find --name KRA_transport_certificate_subject_CN
- Use the serial number of the KRA transport certificate, which you retrieved in the previous step, to store the certificate in a file. For example, to store the certificate with the 12345 serial number in the
/home/user_name/kra.cert
file:$ pki cert-show 12345 --output /home/user_name/kra.cert
- Use the
CRMFPopClient
utility to:- Create a CSR with key archival:
- Change to the certificate database directory of the user or entity for which the certificate is being requested, for example:
$ cd /home/user_name/
- Use the
CRMFPopClient
utility to create a CRMF request, where the RSA private key is wrapped by the KRA transport certificate. For example, to store the request in the/home/user_name/crmf.req
file:$ CRMFPopClient -d . -p token_password -n subject_DN -q POP_NONE \ -b /home/user_name/kra.cert -w "AES/CBC/PKCS5Padding" \ -v -o /home/user_name/crmf.req
Note the ID of the private key displayed by the command. The ID is required in a later step as value in therequest.privKeyId
parameter in the configuration file for the second trip.
- Create a configuration file for the
CRMRequest
utility, such as/home/user_name/cmc.cfg
with the following content:#numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 #input: full path for the PKCS10 request or CRMF request, #the content must be in Base-64 encoded format input=/home/user_name/crmf.req #output: full path for the CMC request in binary format output=/home/user_name/cmc.req #tokenname: name of token where agent signing cert can be found #(default is internal) tokenname=internal #nickname: nickname for user certificate which will be used #to sign the CMC full request. nickname=signing_certificate #dbdir: directory for cert8.db, key3.db and secmod.db dbdir=/home/user_name/.dogtag/nssdb/ #password: password for cert8.db which stores the agent certificate password=password #format: request format, either pkcs10 or crmf format=crmf
- Create the CMC request:
$ CMCRequest /home/user_name/cmc.cfg
If the command succeeds, theCMCRequest
utility stored the CMC request in the file specified in theoutput
parameter in the request configuration file. - Create a configuration file for
HttpClient
, such as/home/user_name/cmc-submit.cfg
, which you use in a later step to submit the CMC request to the CA. Add the following content to the created file:#host: host name for the http server host=server.example.com #port: port number port=8443 #secure: true for secure connection, false for nonsecure connection secure=true #input: full path for the enrollment request, the content must be in #binary format input=/home/user_name/cmc.req #output: full path for the response in binary format output=/home/user_name/cmc-response_round_1.bin #tokenname: name of token where TLS client authentication cert can be found #(default is internal) #This parameter will be ignored if secure=false tokenname=internal #dbdir: directory for cert8.db, key3.db and secmod.db #This parameter will be ignored if secure=false dbdir=/home/user_name/.dogtag/nssdb/ #clientmode: true for client authentication, false for no client authentication #This parameter will be ignored if secure=false clientmode=true #password: password for cert8.db #This parameter will be ignored if secure=false and clientauth=false password=password #nickname: nickname for client certificate #This parameter will be ignored if clientmode=false nickname=signing_certificate #servlet: servlet name servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull?profileId=caFullCMCUserSignedCert
- Submit the CMC request to the CA:
$ HttpClient /home/user_name/cmc-submit.cfg
If the command succeeds, theHTTPClient
utility stored the CMC response in the file specified in theoutput
parameter in the configuration file. - Verify the response by passing the response file to the
CMCResponse
utility. For example:$ CMCResponse -d /home/user_name/.dogtag/nssdb/ -i /home/user_name/cmc-response_round_1.bin
If the first trip was successful,CMCResponse
displays output similar to the following:Certificates: Certificate: Data: Version: v3 Serial Number: 0x1 Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11 Issuer: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain Validity: Not Before: Wednesday, May 17, 2017 6:06:50 PM PDT America/Los_Angeles Not After: Sunday, May 17, 2037 6:06:50 PM PDT America/Los_Angeles Subject: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain ... Number of controls is 3 Control #0: CMC encrypted POP OID: {1 3 6 1 5 5 7 7 9} encryptedPOP decoded Control #1: CMCStatusInfoV2 OID: {1 3 6 1 5 5 7 7 25} BodyList: 1 OtherInfo type: FAIL failInfo=POP required Control #2: CMC ResponseInfo requestID: 15
- For the second trip, create a configuration file for
DecryptedPOP
, such as/home/user_name/cmc_DecryptedPOP.cfg
, which you use in a later step. Add the following content to the created file:#numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 #input: full path for the PKCS10 request or CRMF request, #the content must be in Base-64 encoded format #this field is actually unused in 2nd trip input=/home/user_name/crmf.req #output: full path for the CMC request in binary format #this field is actually unused in 2nd trip output=/home/user_name/cmc2.req #tokenname: name of token where agent signing cert can be found #(default is internal) tokenname=internal #nickname: nickname for agent certificate which will be used #to sign the CMC full request. nickname=signing_certificate #dbdir: directory for cert8.db, key3.db and secmod.db dbdir=/home/user_name/.dogtag/nssdb/ #password: password for cert8.db which stores the agent #certificate password=password #format: request format, either pkcs10 or crmf format=crmf decryptedPop.enable=true encryptedPopResponseFile=/home/user_name/cmc-response_round_1.bin request.privKeyId=-25aa0a8aad395ebac7e6a19c364f0dcb5350cfef decryptedPopRequestFile=/home/user_name/cmc.DecryptedPOP.req
- Create the
DecryptPOP
CMC request:$ CMCRequest /home/user_name/cmc.DecryptedPOP.cfg
If the command succeeds, theCMCRequest
utility stored the CMC request in the file specified in thedecryptedPopRequestFile
parameter in the request configuration file. - Create a configuration file for
HttpClient
, such as/home/user_name/decrypted_POP_cmc-submit.cfg
, which you use in a later step to submit theDecryptedPOP
CMC request to the CA. Add the following content to the created file:#host: host name for the http server host=server.example.com #port: port number port=8443 #secure: true for secure connection, false for nonsecure connection secure=true #input: full path for the enrollment request, the content must be in binary format input=/home/user_name/cmc.DecryptedPOP.req #output: full path for the response in binary format output=/home/user_name/cmc-response_round_2.bin #tokenname: name of token where TLS client authentication cert can be found (default is internal) #This parameter will be ignored if secure=false tokenname=internal #dbdir: directory for cert8.db, key3.db and secmod.db #This parameter will be ignored if secure=false dbdir=/home/user_name/.dogtag/nssdb/ #clientmode: true for client authentication, false for no client authentication #This parameter will be ignored if secure=false clientmode=true #password: password for cert8.db #This parameter will be ignored if secure=false and clientauth=false password=password #nickname: nickname for client certificate #This parameter will be ignored if clientmode=false nickname=singing_certificate #servlet: servlet name servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull?profileId=caFullCMCUserCert
- Submit the
DecryptedPOP
CMC request to the CA:$ HttpClient /home/user_name/decrypted_POP_cmc-submit.cfg
If the command succeeds, theHTTPClient
utility stored the CMC response in the file specified in theoutput
parameter in the configuration file. - To convert the CMC response to a PKCS #7 certificate chain, pass the CMC response file to the
-i
parameter of theCMCResponse
utility. For example:$ CMCResponse -i /home/user_name/cmc-response_round_2.bin -o /home/user_name/certs.p7
Alternatively, to display the individual certificates in PEM format, pass the-v
to the utility.If the second trip was successful,CMCResponse
displays output similar to the following:Certificates: Certificate: Data: Version: v3 Serial Number: 0x2D Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11 Issuer: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain Validity: Not Before: Thursday, June 15, 2017 3:43:45 PM PDT America/Los_Angeles Not After: Tuesday, December 12, 2017 3:43:45 PM PST America/Los_Angeles Subject: CN=user_name,UID=example,OU=keyArchivalExample ... Number of controls is 1 Control #0: CMCStatusInfo OID: {1 3 6 1 5 5 7 7 1} BodyList: 1 Status: SUCCESS
5.4. Renewing Certificates
CMCUserSignedAuth
authentication plug-in, and to renew with agent approval, use profiles that require the CMCAuth
authentication plug-in. For further details about these plug-ins and in which profiles they are enabled by default, see Section 8.1.2, “CMC Authentication Plug-ins”.
5.4.1. Renewal Using the Same Key
Note
uniqueKeyConstraint
entry with the params.allowSameKeyRenewal
parameter set to True
as described in Section 3.4.1, “About Renewal” and Section 3.4.1.1.1, “Renewing Using the Same Key”.
5.4.2. Renewal Using a New Key
subjectDN
attribute as the signing certificate.
5.5. Tracing Issued Certificate to CSR, and CSR to Issued Certificate
- Access the
https://host_name:port/ca/agent/ca
. - Click Search for Requests
- Select and fill in Request ID Range (for example
12
for Lowest Request ID and12
for Highest Request ID. - Select Request Type and choose enrollment type.
- Select Request Status and choose completed status
- Make sure everything else is unselected.
- Click.
- Click on the request number. You see the certificate in clear text at this point.
- To display the CSR and certificate linking, right-click and select This Frame and View Frame Source.
- Search for
inputList.inputName="Certificate Request";
. The request is theinputList.inputVal
below that. - Search for
outputList.outputSyntax="pretty_print";
. The certificate is theoutputList.outputVal
below that.
- Access the
https://host_name:port/ca/agent/ca
. - Click Find.
- Click Details.
- You see the certificate in clear text, along with a Request ID link. Click on the link to open the Request page.
- To display the certificate and CSR linking:
- Search for
inputList.inputName="Certificate Request";
. The request is theinputList.inputVal
below that. - Search for
outputList.outputSyntax="pretty_print";
. The certificate is theoutputList.outputVal
below that.
Chapter 6. Revoking Certificates and Issuing CRLs
6.1. About Revoking Certificates
- Revoke the certificate if a revocation request is received by the CA and approved.
- Make the revoked certificate status available to parties or applications that need to verify its validity status.
Note
6.1.1. CRL Issuing Points
6.1.2. Delta CRLs
DeltaCRLIndicator
extension.
6.1.3. Publishing CRLs
6.2. Revoking Certificates
6.2.1. Performing a CMC Revocation
subjectDN
attribute. Then the user can send the signed request to the Certificate Manager.
CMCRequest
. For details, see Section 6.2.1.1, “Revoking a Certificate UsingCMCRequest
”.CMCRevoke
. For details, see Section 6.2.1.2, “Revoking a Certificate UsingCMCRevoke
”.
Important
CMCRequest
utility to generate CMC revocation requests, because it provides more options than CMCRevoke
.
6.2.1.1. Revoking a Certificate Using CMCRequest
CMCRequest
:
- Create a configuration file for the CMC revocation request, such as
/home/user_name/cmc-request.cfg
, with the following content:#numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 #output: full path for the CMC request in binary format output=/home/user_name/cmc.revoke.userSigned.req #tokenname: name of token where user signing cert can be found #(default is internal) tokenname=internal #nickname: nickname for user signing certificate which will be used #to sign the CMC full request. nickname=signer_user_certificate #dbdir: directory for cert8.db, key3.db and secmod.db dbdir=/home/user_name/.dogtag/nssdb/ #password: password for cert8.db which stores the user signing #certificate and keys password=myPass #format: request format, either pkcs10 or crmf. format=pkcs10 ## revocation parameters revRequest.enable=true revRequest.serial=45 revRequest.reason=unspecified revRequest.comment=user test revocation revRequest.issuer=issuer revRequest.sharedSecret=shared_secret
- Create the CMC request:
# CMCRequest /home/user_name/cmc-request.cfg
If the command succeeds, theCMCRequest
utility stores the CMC request in the file specified in theoutput
parameter in the request configuration file. - Create a configuration file, such as
/home/user_name/cmc-submit.cfg
, which you use in a later step to submit the CMC revocation request to the CA. Add the following content to the created file:#host: host name for the http server host=>server.example.com #port: port number port=8443 #secure: true for secure connection, false for nonsecure connection secure=true #input: full path for the enrollment request, the content must be #in binary format input=/home/user_name/cmc.revoke.userSigned.req #output: full path for the response in binary format output=/home/user_name/cmc.revoke.userSigned.resp #tokenname: name of token where TLS client authentication certificate #can be found (default is internal) #This parameter will be ignored if secure=false tokenname=internal #dbdir: directory for cert8.db, key3.db and secmod.db #This parameter will be ignored if secure=false dbdir=/home/user_name/.dogtag/nssdb/ #clientmode: true for client authentication, false for no client #authentication. This parameter will be ignored if secure=false clientmode=true #password: password for cert8.db #This parameter will be ignored if secure=false and clientauth=false password=password #nickname: nickname for client certificate #This parameter will be ignored if clientmode=false nickname=signer_user_certificate
Important
If the CMC revocation request is signed, set thesecure
andclientmode
parameters totrue
and, additionally, fill thenickname
parameter. - Depending on who signed the request, the
servlet
parameter in the configuration file forHttpClient
must be set accordingly:- If an agent signed the request, set:
servlet=/ca/ee/ca/profileSubmitCMCFull
- If a user signed the request, set:
servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull
- Submit the CMC request:
# HttpClient /home/user_name/cmc-submit.cfg
CMCRequest
, see the CMCRequest(1) man page.
6.2.1.2. Revoking a Certificate Using CMCRevoke
CMCRevoke
, is used to sign a revocation request with an agent's certificate. This utility simply passes the required information — certificate serial number, issuer name, and revocation reason — to identify the certificate to revoke, and then the require information to identify the CA agent performing the revocation (certificate nickname and the database with the certificate).
Important
CMCRevoke
requires that the CA administrator followed the instructions specified in the Enabling CMCRevoke for the Web User Interface section in the Red Hat Certificate System 9 Planning, Installation and Deployment Guide (Common Criteria Edition) during the installation.
CMCRevoke
utility):
0
— unspecified1
— the key was compromised2
— the CA key was compromised3
— the employee's affiliation changed4
— the certificate has been superseded5
— cessation of operation6
— the certificate is on hold
6.2.1.2.1. Testing CMCRevoke
- Create a CMC revocation request for an existing certificate.
CMCRevoke -d/path/to/agent-cert-db -nnickname -iissuerName -sserialName -mreason -ccomment
For example, if the directory containing the agent certificate is~jsmith/.mozilla/firefox/
, the nickname of the certificate isAgentCert
, and the serial number of the certificate is22
, the command is as shown:CMCRevoke -d"~jsmith/.mozilla/firefox/" -n"ManagerAgentCert" -i"cn=agentAuthMgr" -s22 -m0 -c"test comment"
Note
Surround values that include spaces in quotation marks.Important
Do not have a space between the argument and its value. For example, giving a serial number of 26 is-s26
, not-s 26
. - Open the end-entities page.
http
s
://server.example.com:8443/ca/ee/ca
- Select the Revocation tab.
- Select the CMC Revoke link on the menu.
- Paste the output from the
CMCRevoke
into the text area. - Remove
-----BEGIN NEW CERTIFICATE REQUEST-----
and----END NEW CERTIFICATE REQUEST-----
from the pasted content. - Click.
- The returned page should confirm that correct certificate has been revoked.
6.2.2. Performing Revocation as an Agent from the Web UI
6.2.2.1. Listing Certificates
- Open the Certificate Manager agent services page.
- Click List Certificates.
Figure 6.1. List Certificates
- To find a certificate with a specific serial number, enter the serial number in both the upper limit and lower limit fields of the List Certificates form, in either decimal or hexadecimal form. Use
0x
to indicate the beginning of a hexadecimal number; for example,0x00000006
. Serial numbers are displayed in hexadecimal form in the Search Results and Details pages. - To find all certificates within a range of serial numbers, enter the upper and lower limits of the serial number range in decimal or hexadecimal form.
Leaving either the lower limit or upper limit field blank displays the certificate with the specified number, plus all certificates before or after it in sequence. - To limit the returned list to valid certificates, select the check boxes labeled with filtering methods. It is possible to include revoked certificates, to include expired certificates or certificates that are not yet valid, or to display only valid certificates.
- Enter the maximum number of certificates matching the criteria that should be returned in the results page.When any number is entered, the first certificates up to that number matching the criteria are displayed.
- Click.The Certificate System displays a list of the certificates that match the search criteria. Select a certificate in the list to examine it in more detail or perform various operations on it. For more information, refer to Section 6.2.2.3, “Examining Certificate Details”.
6.2.2.2. Searching for Certificates (Advanced)
- Open the Certificate Manager agent services page. The agent must submit the proper client certificate to access this page.
- Click Search for Certificates to display the Search for Certificates form to specify search criteria.
- To search by particular criteria, use one or more of the sections of the Search for Certificates form. To use a section, select the check box, then fill in any necessary information.
- Serial Number Range. Finds a certificate with a specific serial number or lists all certificates within a range of serial numbers.
- To find a certificate with a specific serial number, enter the serial number in both the upper limit and lower limit fields in either decimal or hexadecimal. Use
0x
to indicate the beginning of a hexadecimal number, such as0x2A
. Serial numbers are displayed in hexadecimal form in the Search Results and Details pages. - To find all certificates within a range of serial numbers, enter the upper and lower limits of the serial number range in decimal or hexadecimal. Leaving either the lower limit or upper limit field blank returns all certificates before or after the number specified.
- Status. Selects certificates by their status. A certificate has one of the following status codes:
- Valid. A valid certificate has been issued, its validity period has begun but not ended, and it has not been revoked.
- Invalid. An invalid certificate has been issued, but its validity period has not yet begun.
- Revoked. The certificate has been revoked.
- Expired. An expired certificate has passed the end of its validity period.
- Revoked and Expired. The certificate has passed its validity period and been revoked.
- Subject Name. Lists certificates belonging to a particular owner; it is possible to use wildcards in this field.
Note
Certificate System certificate request forms support all UTF-8 characters for the common name, organizational unit, and requester name fields. The common name and organization unit fields are included in the subject name of the certificate. This means that the searches for subject names support UTF-8 characters.This support does not include supporting internationalized domain names. - Revocation Information. Lists certificates that have been revoked during a particular period, by a particular agent, or for a particular reason. For example, an agent can list all certificates revoked between July 2005 and April 2006 or all certificates revoked by the agent with the username
admin
.- To list certificates revoked within a time period, select the day, month, and year from the drop-down lists to identify the beginning and end of the period.
- To list certificates revoked by a particular agent, enter the name of the agent; it is possible to use wildcards in this field.
- To list certificates revoked for a specific reason, select the revocation reasons from the list.
- Issuing Information. Lists certificates that have been issued during a particular period or by a particular agent. For example, an agent can list all certificates issued between July 2005 and April 2006 or all certificates issued by the agent with the username
jsmith
.- To list certificates issued within a time period, select the day, month, and year from the drop-down lists to identify the beginning and end of the period.
- To list certificates issued by a particular agent, enter the name of the agent; it is possible to use wildcards in this field.
- To list certificates enrolled through a specific profile, enter the name of the profile.
- Dates of Validity. List certificates that become effective or expire during a particular period. For example, an agent can list all certificates that became valid on June 1, 2003, or that expired between January 1, 2006, and June 1, 2006.It is also possible to list certificates that have a validity period of a certain length of time, such as all certificates that are valid for less than one month.
- To list certificates that become effective or expire within a time period, select the day, month, and year from the drop-down lists to identify the beginning and end of the period.
- To list certificates that have a validity period of a certain length in time, selector from the drop-down list, enter a number, and select a time unit from the drop-down list: days, weeks, months, or years.
- Basic Constraints. Shows CA certificates that are based on the Basic Constraints extension.
- Type. Lists certain types of certificates, such as all certificates for subordinate CAs. This search works only for certificates containing the Netscape Certificate Type extension, which stores type information. For each type, choose from the drop-down list to find certificates where that type is , , or .
- To find a certificate with a specific subject name, use the Subject Name section. Select the check box, then enter the subject name criteria. Enter values for the included search criteria and leave the others blank.The standard tags or components are as follows:
- Email address. Narrows the search by email address.
- Common name. Finds certificates associated with a specific person or server.
- UserID. Searches certificates by the user ID for the person to whom the certificate belongs.
- Organization unit. Narrows the search to a specific division, department, or unit within an organization.
- Organization. Narrows the search by organization.
- Locality. Narrows the search by locality, such as the city.
- State. Narrows the search by state or province.
- Country. Narrows the search by country; use the two-letter country code, such as
US
.
Note
Certificate System certificate request forms support all UTF-8 characters for the common name and organizational unit fields. The common name and organization unit fields are included in the subject name of the certificate. This means that the searches for subject names or those elements in the subject name support UTF-8 characters.This support does not include supporting internationalized domain names, such as in email addresses. - After entering the field values for the server to match, specify the type of search to perform:
- Exact searches for certificate subject names match the exact components specified and contain none of the components left blank. Wildcards cannot be used in this type of search.
- Partial searches for certificate subject names match the specified components, but the returned certificates may also contain values in components that were left blank. Wildcard patterns can be used in this type of search by using a question mark (
?
) to match an arbitrary single character and an asterisk (*
) to match an arbitrary string of characters.Note
Placing a single asterisk in a search field means that the component must be in the certificate's subject name but may have any value. Leave the field blank if it does not matter if the field is present.
- After entering the search criteria, scroll to the bottom of the form, and enter the number of certificates matching the specified criteria that should be returned.Setting the number of certificates to be returned returns the first certificates found that match the search criteria up to that number. It is also possible to put a time limit on the search in seconds.
- Click.
- The Search Results form appears, showing a list of the certificates that match the search criteria. Select a certificate in the list to examine it in more detail. For more information, refer to Section 6.2.2.3, “Examining Certificate Details”.
6.2.2.3. Examining Certificate Details
- On the agent services page, click List Certificates or Search for Certificates, specify search criteria, and click to display a list of certificates.
- On the Search Results form, select a certificate to examine.If the desired certificate is not shown, scroll to the bottom of the list, specify an additional number of certificates to be returned, and click. The system displays the next certificates up to that number that match the original search criteria.
- After selecting a certificate, click thebutton at the left side of its entry.
- The Certificate page shows the detailed contents of the selected certificate and instructions for installing the certificate in a server or in a web browser.
Figure 6.2. Certificate Details
- The certificate is shown in base-64 encoded form at the bottom of the Certificate page, under the heading Installing this certificate in a server.
6.2.2.4. Revoking Certificates
- The owner of the certificate has changed status and no longer has the right to use the certificate.
- The private key of a certificate owner has been compromised.
6.2.2.4.1. Revoking Certificates
- Open the Certificate Manager agent services page.
- Click.
Note
The search form that appears has the same search criteria sections as the Search for Certificates form. - Specify the search criteria by selecting the check boxes for the sections and filling in the required information.
- Scroll to the bottom of the form, and set the number of matching certificates to display.
- Click.
- The search returns a list of matching certificates. It is possible to revoke one or all certificates in the list.
Note
If the search criteria are very specific and all of the certificates returned are to be revoked, then click thebutton at the bottom of the page. The number shown on the button is the total number of certificates returned by the search. This is usually a larger number than the number of certificates displayed on the current page.Verify that all of the certificates returned by the search should be revoked, not only those displayed on the current page. - Click thebutton next to the certificate to be revoked.
Warning
Whether revoking a single certificate or a list of certificates, be extremely careful that the correct certificate has been selected or that the list contains only certificates which should be revoked. Once a revocation operation has been confirmed, there is no way to undo it. - Select an invalidity date. The invalidity date is the date which it is known or suspected that the user's private key was compromised or that the certificate became invalid. A set of drop down lists allows the agent to select the correct invalidity date.
- Select a reason for the revocation.
- Key compromised
- CA key compromised
- Affiliation changed
- Certificate superseded
- Cessation of operation
- Certificate is on hold
- Enter any additional comment. The comment is included in the revocation request.
Completed
.
6.2.2.4.2. Taking Ceritificates Off Hold
- Search for the on hold certificate, as in Section 6.2.2.2, “Searching for Certificates (Advanced)”. Scroll to the Revocation Information section, and set the Certificate is on hold revocation reason as the search criterion.
- In the results list, click thebutton by the certificate to take off hold.
6.2.2.5. Managing the Certificate Revocation List
6.2.2.5.1. Viewing or Examining CRLs
- Go to the Certificate Manager agent services page.
- Click Display Certificate Revocation List to display the form for viewing the CRL.
- Select the CRL to view. If the administrator has created multiple issuing points, these are listed in thedrop-down list. Otherwise, only the master CRL is shown.
- Choose how to display the CRL by selecting one of the options from themenu. The choices on this menu are as follows:
- Cached CRL. Views the CRL from the cache rather than from the CRL itself. This option displays results faster than viewing the entire CRL.
- Entire CRL. Retrieves and displays the entire CRL.
- CRL header. Retrieves and displays the CRL header only.
- Base 64 Encoded. Retrieves and displays the CRL in base-64 encoded format.
- Delta CRL. Retrieves and displays a delta CRL, which is a subset of the CRL showing only new revocations since the last CRL was published. This option is available only if delta CRL generation is enabled.
- To examine the selected CRL, click.The CRL appears in the browser window. This allows the agent to check whether a particular certificate (by its serial number) appears in the list and to note recent changes such as the total number of certificates revoked since the last update, the total number of certificates taken off hold since the last update, and the total number of certificates that expired since the last update.
6.2.2.5.2. Updating the CRL
- Open the Certificate Manager agent services page.
- Click Update Revocation List to display the form for updating the CRL.
Figure 6.3. Update Certificate Revocation List
- Select the CRL issuing point which will update the CRL. There can be multiple issuing points configured for a single CA.
- Select the algorithm to use to sign the new CRL. Before choosing an algorithm, make sure that any system or network applications that need to read or view this CRL support the algorithm.
- SHA-256 with RSA.
- SHA-384 with RSA.
- SHA-512 with RSA.
Before selecting an algorithm, make sure that the Certificate System has that algorithm enabled. The Certificate System administrator will have that information. - Clickto update the CRL with the latest certificate revocation information.
6.2.3. Performing Revocation on Own Certificate as a User Using the Web UI
6.2.3.1. Revoking Your User Certificate
- Click the Revocation tab.
- Click the User Certificate link.
- Select the reason why the certificate is being revoked, and click.
- Select the certificates to revoke from the list.
6.2.3.2. Checking Whether a Certificate Is Revoked
- Click the Retrieval tab.
- Click the Import Certificate Revocation List link.
- Select the radio button by Check whether the following certificate is included in CRL cache or Check whether the following certificate is listed by CRL, and enter the serial number of the certificate.
- Click the Submit button.A message is returned either saying that the certificate is not listed in any CRL or giving the information for the CRL which contains the certificate.
6.2.3.3. Downloading and Importing CRLs
- Click the Retrieval tab.
- Click the Import Certificate Revocation List link.
- Select the radio button to view, download, or import the CRL.
- To import the CRL into the browser or download and save it, select the appropriate radio button. There are two options: to download/import the full CRL or the delta CRL. The delta CRL only imports/downloads the list of certificates which have been revoked since the last time the CRL was generated.
- To view the CRL, select Display the CRL information and select which CRL subset (called an issuing point) to view. This shows the CRL information, including the number of certificates included in it.
- Click thebutton.
- Save the file or approve the import operation.
6.3. Issuing CRLs
- The Certificate Manager uses its OCSP signing key to sign CRLs. To use a separate signing key pair for CRLs, set up a CRL signing key and change the Certificate Manager configuration to use this key to sign CRLs. See 9.2.3.11. Setting a CA to Use a Different Certificate to Sign CRLs in Red Hat Certificate System's Planning, Installation, and Deployment Guide for more information.
- Set up CRL issuing points. An issuing point is already set up and enabled for a master CRL.
Figure 6.4. Default CRL Issuing Point
Additional issuing points for the CRLs can be created. See Section 6.3.1, “Configuring Issuing Points” for details.There are five types of CRLs the issuing points can create, depending on the options set when configuring the issuing point to define what the CRL will list:- Master CRL contains the list of revoked certificates from the entire CA.
- ARL is an Authority Revocation List containing only revoked CA certificates.
- CRL with expired certificates includes revoked certificates that have expired in the CRL.
- CRL from certificate profiles determines the revoked certificates to include based on the profiles used to create the certificates originally.
- CRLs by reason code determines the revoked certificates to include based on the revocation reason code.
- Configure the CRLs for each issuing point. See Section 6.3.2, “Configuring CRLs for Each Issuing Point” for details.
- Set up the CRL extensions which are configured for the issuing point. See Section 6.3.3, “Setting CRL Extensions” for details.
- Set up the delta CRL for an issuing point by enabling extensions for that issuing point,
DeltaCRLIndicator
orCRLNumber
. - Set up the
CRLDistributionPoint
extension to include information about the issuing point. - Set up publishing CRLs to files, an LDAP directory, or an OCSP responder. See Chapter 7, Publishing Certificates and CRLs for details about setting up publishing.
6.3.1. Configuring Issuing Points
- Open the Certificate System Console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, expand Certificate Manager from the left navigation menu. Then select CRL Issuing Points.
- To edit an issuing point, select the issuing point, and click. The only parameters which can be edited are the name of the issuing point and whether the issuing point is enabled or disabled.To add an issuing point, click. The CRL Issuing Point Editor window opens.
Figure 6.5. CRL Issuing Point Editor
Note
If some fields do not appear large enough to read the content, expand the window by dragging one of the corners.Fill in the following fields:- Enable. Enables the issuing point if selected; deselect to disable.
- CRL Issuing Point name. Gives the name for the issuing point; spaces are not allowed.
- Description. Describes the issuing point.
- Click.
6.3.2. Configuring CRLs for Each Issuing Point
- Open the CA console.
pkiconsole https://server.example.com:8443/ca
- In the navigation tree, select Certificate Manager, and then select CRL Issuing Points.
- Select the issuing point name below the Issuing Points entry.
- Configure how and how often the CRLs are updated by supplying information in the Update tab for the issuing point. This tab has two sections, Update Schema and Update Frequency.
- The Update Schema section has the following options:
- Enable CRL generation. This checkbox sets whether CRLs are generated for that issuing point.
- Generate full CRL every # delta(s). This field sets how frequently CRLs are created in relation to the number of changes.
- Extend next update time in full CRLs. This provides an option to set the
nextUpdate
field in the generated CRLs. ThenextUpdate
parameter shows the date when the next CRL is issued, regardless of whether it is a full or delta CRL. When using a combination of full and delta CRLs, enablingExtend next update time in full CRLs
will make thenextUpdate
parameter in a full CRL show when the next full CRL will be issued. Otherwise, thenextUpdate
parameter in the full CRL will show when the next delta CRL will be issued, since the delta will be the next CRL to be issued.
- The Update Frequency section sets the different intervals when the CRLs are generated and issued to the directory.
- Every time a certificate is revoked or released from hold. This sets the Certificate Manager to generate the CRL every time it revokes a certificate. The Certificate Manager attempts to issue the CRL to the configured directory whenever it is generated. Generating a CRL can be time consuming if the CRL is large. Configuring the Certificate Manager to generate CRLs every time a certificate is revoked may engage the server for a considerable amount of time; during this time, the server will not be able to update the directory with any changes it receives.This setting is not recommended for a standard installation. This option should be selected to test revocation immediately, such as testing whether the server issues the CRL to a flat file.
- Update the CRL at. This field sets a daily time when the CRL should be updated. To specify multiple times, enter a comma-separate 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, this sets revocation on Day 1 of the cycle at 1:50am, 4:55am, and 6:55am and then Day 2 at 2am, 5am, and 5pm:01:50,04:55,06:55;02:00,05:00,17:00
- Next update grace period. If the Certificate Manager updates the CRL at a specific frequency, the server can be configured to have a grace period to the next update time to allow time to create the CRL and issue it. For example, if the server is configured to update the CRL every 20 minutes with a grace period of 2 minutes, and if the CRL is updated at 16:00, the CRL is updated again at 16:18.
Important
Due to a known issue, when currently setting full and delta Certificate Revocation List schedules, theUpdate CRL every time a certificate is revoked or released from hold
option also requires you to fill out the twograce period
settings. Thus, in order to select this option you need to first select theUpdate CRL every
option and enter a number for theNext update grace period # minutes
box. - The Cache tab sets whether caching is enabled and the cache frequency.
Figure 6.6. CRL Cache Tab
- Enable CRL cache. This checkbox enables the cache, which is used to create delta CRLs. If the cache is disabled, delta CRLs will not be created. For more information about the cache, see Section 6.1, “About Revoking Certificates”.
- Update cache every. This field sets how frequently the cache is written to the internal database. Set to
0
to have the cache written to the database every time a certificate is revoked. - Enable cache recovery. This checkbox allows the cache to be restored.
- Enable CRL cache testing. This checkbox enables CRL performance testing for specific CRL issuing points. CRLs generated with this option should not be used in deployed CAs, as CRLs issued for testing purposed contain data generated solely for the purpose of performance testing.
- The Format tab sets the formatting and contents of the CRLs that are created. There are two sections, CRL Format and CRL Contents.
Figure 6.7. CRL Format Tab
- The CRL Format section has two options:
- Revocation list signing algorithm is a drop down list of allowed ciphers to encrypt the CRL.
- Allow extensions for CRL v2 is a checkbox which enabled CRL v2 extensions for the issuing point. If this is enabled, set the required CRL extensions described in Section 6.3.3, “Setting CRL Extensions”.
Note
Extensions must be turned on to create delta CRLs. - The CRL Contents section has three checkboxes which set what types of certificates to include in the CRL:
- Include expired certificates. This includes revoked certificates that have expired. If this is enabled, information about revoked certificates remains in the CRL after the certificate expires. If this is not enabled, information about revoked certificates is removed when the certificate expires.
- CA certificates only. This includes only CA certificates in the CRL. Selecting this option creates an Authority Revocation List (ARL), which lists only revoked CA certificates.
- Certificates issued according to profiles. This only includes certificates that were issued according to the listed profiles; to specify multiple profiles, enter a comma-separated list.
- Click.
- Extensions are allowed for this issuing point and can be configured. See Section 6.3.3, “Setting CRL Extensions” for details.
6.3.3. Setting CRL Extensions
Note
CRLReason
, InvalidityDate
, and CRLNumber
. Other extensions are available but are disabled by default. These can be enabled and modified. For more information about the available CRL extensions, see Section B.4.2, “Standard X.509 v3 CRL Extensions Reference”.
- Open the CA console.
pkiconsole https://server.example.com:8443/ca
- In the navigation tree, select Certificate Manager, and then select CRL Issuing Points.
- Select the issuing point name below the Issuing Points entry, and select the CRL Extension entry below the issuing point.The right pane shows the CRL Extensions Management tab, which lists configured extensions.
Figure 6.8. CRL Extensions
- To modify a rule, select it, and click.
- Most extensions have two options, enabling them and setting whether they are critical. Some require more information. Supply all required values. See Section B.4.2, “Standard X.509 v3 CRL Extensions Reference” for complete information about each extension and the parameters for those extensions.
- Click.
- Clickto see the updated status of all the rules.
6.3.4. Generating CRLs from Cache
Note
enableCRLCache
parameter in most environments. However, the Enable CRL cache testing
parameter should not be enabled in a production environment.
6.3.4.1. Configuring CRL Generation from Cache in the Console
- Open the console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, expand the Certificate Manager folder and the CRL Issuing Points subfolder.
- Select the MasterCRL node.
- Select Enable CRL cache.
- Save the changes.
6.4. Setting Full and Delta CRL Schedules
Interval 1, 2, 3, 4, 5, 6, 7 ... Full CRL 1 4 7 ... Delta CRL 1, 2, 3, 4, 5, 6, 7 ...
Note
6.4.1. Configuring CRL Update Intervals in the Console
- Open the console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, expand the Certificate Manager folder and the CRL Issuing Points subfolder.
- Select the MasterCRL node.
- Enter the required interval in the Generate full CRL every # delta(s) field.
- Set the update frequency, either by specifying the occasion of a certificate revocation, a cyclical interval or set times for the updates to occur:
- Select the Update CRL every time a certificate is revoked or released from hold checkbox. The Update CRL every time a certificate is revoked or released from hold option also requires you to fill out the two Grace period settings. This is a known issue, and the bug is being tracked in Red Hat Bugzilla.
- Select the Update CRL every time a certificate is revoked or released from hold checkbox.
- Select the Update CRL at checkbox and enter specific times separated by commas, such as
01:50,04:55,06:55
. - Select Update CRL every checkbox and enter the required interval, such as
240
.
- Save the changes.
Important
Note
6.4.2. Configuring CRL Generation Schedules over Multiple Days
ca.crl.MasterCRL.dailyUpdates=01:00,03:00,18:00;02:00,05:00,17:00
Note
ca.crl.MasterCRL.dailyUpdates=01:00,03:00,18:00,*23:00;02:00,05:00,21:00,*23:30
Note
6.5. Using the Online Certificate Status Protocol (OCSP) Responder
6.5.1. Setting up the OCSP Responder
Note
- Configure the CRLs for every CA that will publish to an OCSP responder.
- Enable publishing, set up a publisher, and set publishing rules in every CA that the OCSP service will handle (Chapter 7, Publishing Certificates and CRLs). This is not necessary if the Certificate Managers publish to an LDAP directory and the Online Certificated Status Manager is set up to read from that directory.
- The certificate profiles must be configured to include the Authority Information Access extension, pointing to the location at which the Certificate Manager listens for OCSP service requests (Section 6.5.4, “Enabling the Certificate Manager's Internal OCSP Service”).
- Configure the OCSP Responder.
- Configure the Revocation Info store (Section 6.5.2.2, “Configure the Revocation Info Stores: Internal Database” and Section 6.5.2.3, “Configure the Revocation Info Stores: LDAP Directory”).
- Identify every publishing Certificate Manager to the OCSP responder (Section 6.5.2, “Identifying the CA to the OCSP Responder”).
- If necessary, configure the trust settings for the CA which signed the OCSP signing certificate (Section 14.5, “Changing the Trust Settings of a CA Certificate”).
- Restart both subsystems after configuring them.
- Verify that the CA is properly connected to the OCSP responder (Section 6.5.2.1, “Verify Certificate Manager and Online Certificate Status Manager Connection”).
6.5.2. Identifying the CA to the OCSP Responder
Note
- Get the Certificate Manager's base-64 CA signing certificate from the end-entities page of the CA.
- Open the Online Certificate Status Manager agent page. The URL has the format
https://
hostname:SSLport/ocsp/agent/ocsp
. - In the left frame, click.
- In the form, paste the encoded CA signing certificate inside the text area labeled Base 64 encoded certificate (including the header and footer).
- To verify that the certificate is added successfully, in the left frame, click List Certificate Authorities.
6.5.2.1. Verify Certificate Manager and Online Certificate Status Manager Connection
6.5.2.2. Configure the Revocation Info Stores: Internal Database
- Open the Online Certificate Status Manager Console.
pkiconsole https://server.example.com:8443/ocsp
- In the Configuration tab, select Online Certificate Status Manager, and then select Revocation Info Stores.The right pane shows the two repositories the Online Certificate Status Manager can use; by default, it uses the CRL in its internal database.
- Select the
defStore
, and click . - Edit the
defStore
values.- notFoundAsGood. Sets the OCSP service to return an OCSP response of GOOD if the certificate in question cannot be found in any of the CRLs. If this is not selected, the response is UNKNOWN, which, when encountered by a client, results in an error message.
- byName. The OCSP Responder only supports the basic response type, which includes the ID of the OCSP Responder making the response. The ResponderID field within the basic response type is determined by the value of the
ocsp.store.defStore.byName
parameter. IfbyName
parameter is true or is missing, the OCSP authority signing certificate subject name is used as the ResponderID field of the OCSP response. IfbyName
parameter is false, the OCSP authority signing certificate key hash will be the ResponderID field of the OCSP response. - includeNextUpdate. Includes the timestamp of the next CRL update time.
6.5.2.3. Configure the Revocation Info Stores: LDAP Directory
Important
ldapStore
method is enabled, the OCSP user interface does not check the certificate status.
- Open the Online Certificate Status Manager Console.
pkiconsole https://server.example.com:8443/ocsp
- In the Configuration tab, select Online Certificate Status Manager, and then select Revocation Info Stores.The right pane shows the two repositories the Online Certificate Status Manager can use; by default, it uses the CRL in its internal database.
- To use the CRLs in LDAP directories, clickto enable the
ldapStore
option. - Select
ldapStore
, and click . - Set the
ldapStore
parameters.- numConns. The total number of LDAP directories the OCSP service should check. By default, this is set to 0. Setting this value shows the corresponding number of host, port, baseDN, and refreshInSec fields.
- host. The fully-qualified DNS hostname of the LDAP directory.
- port. The non-TLS port of the LDAP directory.
- baseDN. The DN to start searching for the CRL. For example,
O=example.com
. - refreshInSec. How often the connection is refreshed. The default is 86400 seconds (daily).
- caCertAttr. Leave the default value,
cACertificate;binary
, as it is. It is the attribute to which the Certificate Manager publishes its CA signing certificate. - crlAttr. Leave the default value,
certificateRevocationList;binary
, as it is. It is the attribute to which the Certificate Manager publishes CRLs. - notFoundAsGood. Sets the OCSP service to return an OCSP response of GOOD if the certificate in question cannot be found in any of the CRLs. If this is not selected, the response is UNKNOWN, which, when encountered by a client, results in an error message.
- byName. The OCSP Responder only supports the basic response type, which includes the ID of the OCSP Responder making the response. The ResponderID field within the basic response type is determined by the value of the
ocsp.store.defStore.byName
parameter. IfbyName
parameter is true or is missing, the OCSP authority signing certificate subject name is used as the ResponderID field of the OCSP response. IfbyName
parameter is false, the OCSP authority signing certificate key hash will be the ResponderID field of the OCSP response. - includeNextUpdate. The Online Certificate Status Manager can include the timestamp of the next CRL update time.
6.5.2.4. Testing the OCSP Service Setup
- Turn on revocation checking in the browser or client.
- Request a certificate from the CA that has been enabled for OCSP services.
- Approve the request.
- Download the certificate to the browser or client.
- Make sure the CA is trusted by the browser or client.
- Check the status of Certificate Manager's internal OCSP service.Open the CA agent services page, and select the OCSP Services link.
- Test the independent Online Certificate Status Manager subsystem.Open the Online Certificate Status Manager agent services page, and click the List Certificate Authorities link.The page should show information about the Certificate Manager configured to publish CRLs to the Online Certificate Status Manager. The page also summarizes the Online Certificate Status Manager's activity since it was last started.
- Revoke the certificate.
- Verify the certificate in the browser or client. The server should return that the certificate has been revoked.
- Check the Certificate Manager's OCSP-service status again to verify that these things happened:
- The browser sent an OCSP query to the Certificate Manager.
- The Certificate Manager sent an OCSP response to the browser.
- The browser used that response to validate the certificate and returned its status, that the certificate could not be verified.
- Check the independent OCSP service subsystem again to verify that these things happened:
- The Certificate Manager published the CRL to the Online Certificate Status Manager.
- The browser sent an OCSP response to the Online Certificate Status Manager.
- The Online Certificate Status Manager sent an OCSP response to the browser.
- The browser used that response to validate the certificate and returned its status, that the certificate could not be verified.
6.5.3. Setting the Response for Bad Serial Numbers
notFoundAsGood
parameter sets how the OCSP handles a certificate with an invalid serial number. This parameter is enabled by default, which means that if a certificate is present with a bad serial number but the certificate is otherwise valid, the OCSP returns a status of GOOD
for the certificate.
notFoundAsGood
setting. In that case, the OCSP returns a status of UNKNOWN
with a certificate with a bad serial number. The client interprets that as an error and can respond accordingly.
- Open the Online Certificate Status Manager Console.
pkiconsole https://server.example.com:8443/ocsp
- In the Configuration tab, select Online Certificate Status Manager, and then select Revocation Info Stores.
- Select the
defStore
, and click . - Edit the
notFoundAsGood
value. Selecting the checkbox means that the OCSP returns a value ofGOOD
even if the serial number on the certificate is bad. Unselecting the checkbox means that the OCSP sends a value ofUNKNOWN
, which the client can intrepret as an error. - Restart the OCSP Manager.
systemctl restart pki-tomcatd-nuxwdog@instance_name.service
6.5.4. Enabling the Certificate Manager's Internal OCSP Service
- Go to the CA's end-entities page. For example:
http
s
://server.example.com:8443/ca/ee/ca
- Find the CA signing certificate.
- Look for the Authority Info Access extension in the certificate, and note the
Location URIName
value, such ashttp
.s
://server.example.com:8443
/ca/ocsp - Update the enrollment profiles to enable the Authority Information Access extension, and set the
Location
parameter to the Certificate Manager's URI. For information on editing the certificate profiles, see Section 3.2, “Setting up Certificate Profiles”. - Restart the CA instance.
systemctl restart pki-tomcatd-nuxwdog@instance_name.service
6.5.5. Submitting OCSP Requests Using the OCSPClient program
]# OCSPClient -h server.example.com -p 8080 -d /etc/pki/pki-tomcat/alias -c "caSigningCert cert-pki-ca" --serial 2 CertID.serialNumber=2 CertStatus=Good
OCSPClient
command can be used with the following command-line options:
Option | Description |
---|---|
-d database | Security database location (default: current directory) |
-h hostname | OCSP server hostname (default: example.com) |
-p port | OCSP server port number (default: 8080) |
-t path | OCSP service path (default: /ocsp/ee/ocsp) |
-c nickname | CA certificate nickname (defaut: CA Signing Certificate) |
-n times | Number of submissions (default: 1) |
--serial serial_number | Serial number of certificate to be checked |
--input input_file | Input file containing DER-encoded OCSP request |
--output output_file | Output file to store DER-encoded OCSP response |
-v, --verbose | Run in verbose mode |
--help | Show help message |
6.5.6. Submitting OCSP Requests Using the GET Method
- Generate an OCSP request for the certificate the status of which is being queried. For example:
]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64 MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
- Paste the URL in the address bar of a web browser to return the status information. The browser must be able to handle OCSP requests.
https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
- The OCSP Manager responds with the certificate status which the browser can interpret. The possible statuses are GOOD, REVOKED, and UNKNOWN.
curl
to send the request and openssl
to parse the response. For example:
- Generate an OCSP request for the certificate the status of which is being queried. For example:
]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64 MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
- Connect to the OCSP Manager using
curl
to send the OCSP request.curl https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE= > ocspresp.der
- Parse the response using
openssl
:openssl ocsp -respin ocspresp.der -resp_text
Part III. Additional Configuration to Manage CA Services
Chapter 7. Publishing Certificates and CRLs
Note
- Configure publishing to a file, LDAP directory, or OCSP responder.There can be a single publisher or multiple publishers, depending on how many locations will be used. The locations can be split by certificates and CRLs or narrower definitions, such as certificate type. Rules determine which type to publish and to what location by being associated with the publisher.
- Set rules to determine what certificates are published to the locations. Any rule which a certificate or CRL matches is activated, so the same certificate can be published to a file and to an LDAP directory by matching a file-based rule and matching a directory-based rule.Rules can be set for each object type: CA certificates, CRLs, user certificates, and cross-pair certificates. Disable all rules that will not be used.
- Configure CRLs. CRLs must be configured before they can be published. See Chapter 6, Revoking Certificates and Issuing CRLs.
- Enable publishing after setting up publishers, mappers, and rules. Once publishing is enabled, the server starts publishing immediately. If the publishers, mappers, and rules are not completely configured, publishing may not work correctly or at all.
7.1. About Publishing
Note
CRL
is set as the type.
/etc/CS/certificates
, the certificate is published as a file to that location. If another rule matches all certificates issued to users, and the rule has a publisher that publishes to the LDAP attribute userCertificate;binary
attribute, the certificate is published to the directory specified when LDAP publishing was enabled in this attribute in the user's entry.
7.1.1. Publishers
7.1.2. Mappers
7.1.3. Rules
7.1.4. Publishing to Files
- For each certificate the server issues, it creates a file that contains the certificate in either DER-encoded or base-64 encoded format. Each file is named either
cert-
serial_number.der
orcert-
serial_number.b64
. The serial_number is the serial number of the certificate contained in the file. For example, the filename for a DER-encoded certificate with the serial number1234
iscert-1234.der
. - Every time the server generates a CRL, it creates a file that contains the new CRL in either DER-encoded or base-64 encoded format. Each file is named either issuing_point_name-this_update
.der
or issuing_point_name-this_update.b64
, depending on the format. The issuing_point_name identifies the CRL issuing point which published the CRL, and this_update specifies the value derived from the time-dependent update value for the CRL contained in the file. For example, the filename for a DER-encoded CRL with the valueThis Update: Friday January 28 15:36:00 PST 2021
, isMasterCRL-20210128-153600.der
.
7.1.5. OCSP Publishing
7.1.6. LDAP Publishing
- For each certificate the server issues, it creates a blob that contains the certificate in its DER-encoded format in the specified attribute of the user's entry. The certificate is published as a DER encoded binary blob.
- Every time the server generates a CRL, it creates a blob that contains the new CRL in its DER-encoded format in the specified attribute of the entry for the CA.
7.2. Configuring Publishing to a File
- Log into the Certificate Manager Console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing, and then Publishers.The Publishers Management tab, which lists configured publisher instances, opens on the right.
- Click Select Publisher Plug-in Implementation window, which lists registered publisher modules.to open the
- Select the
FileBasedPublisher
module, then open the editor window.This is the module that enables the Certificate Manager to publish certificates and CRLs to files. - Configure the information for publishing the certificate:
- The publisher ID, an alphanumeric string with no spaces like
PublishCertsToFile
- The path to the directory in which the Certificate Manager should publish the files. The path can be an absolute path or can be relative to the Certificate System instance directory. For example,
/export/CS/certificates
. - The file type to publish, by selecting the checkboxes for DER-encoded files, base-64 encoded files, or both.
- For CRLs, the format of the timestamp. Published certificates include serial numbers in their file names, while CRLs use timestamps.
- For CRLs, whether to generate a link in the file to go to the latest CRL. If enabled, the link assumes that the name of the CRL issuing point to use with the extension will be supplied in the crlLinkExt field.
- For CRLs, whether to compress (zip) CRLs and the compression level to use.
7.3. Configuring Publishing to an OCSP
7.3.1. Enabling Publishing to an OCSP with Client Authentication
- Log into the Certificate Manager Console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing, and then Publishers.
- Click Select Publisher Plug-in Implementation window, which lists registered publisher modules.to open the
- Select the
OCSPPublisher
module, then open the editor window. This is the publisher module that enables the Certificate Manager to publish CRLs to the Online Certificate Status Manager.- The publisher ID must be an alphanumeric string with no spaces, like
PublishCertsToOCSP
. - The host can be the fully-qualified domain name, such as
ocspResponder.example.com
, or an IPv4 or IPv6 address. - The default path is the directory to send the CRL to, like
/ocsp/agent/ocsp/addCRL
. - If client authentication is used (enableClientAuth is checked), then the nickname field gives the nickname of the certificate to use for authentication. This certificate must already exist in the OCSP security database; this will usually be the CA subsystem certificate.
- Create a user entry for the CA on the OCSP Manager. The user is used to authenticate to the OCSP when sending a new CRL. There are two things required:
- Name the OCSP user entry after the CA server, like
CA-
hostname-EEport. - Use whatever certificate was specified in the publisher configuration as the user certificate in the OCSP user account. This is usually the CA's subsystem certificate.
Setting up subsystem users is covered in Section 12.3.2.1, “Creating Users”.
7.4. Configuring Publishing to an LDAP Directory
- Configure the Directory Server to which certificates will be published. Certain attributes have to be added to entries and bind identities and authentication methods have to be configured.
- Configure a publisher for each type of object published: CA certificates, cross-pair certificates, CRLs, and user certificates. The publisher declares in which attribute to store the object. The attributes set by default are the X.500 standard attributes for storing each object type. This attribute can be changed in the publisher, but generally, it is not necessary to change the LDAP publishers.
- Set up mappers to enable an entry's DN to be derived from the certificate's subject name. This generally does not need set for CA certificates, CRLs, and user certificates. There can be more than one mapper set for a type of certificate. This can be useful, for example, to publish certificates for two sets of users from different divisions of a company who are located in different parts of the directory tree. A mapper is created for each of the groups to specify a different branch of the tree.For details about setting up mappers, see Section 7.4.3, “Creating Mappers”.
- Create rules to connect publishers to mappers, as described in Section 7.5, “Creating Rules”.
- Enable publishing, as described in Section 7.6, “Enabling Publishing”.
7.4.1. Configuring the LDAP Directory
- Set up the entry for the CA. For the Certificate Manager to publish its CA certificate and CRL, the directory must include an entry for the CA.
Note
When LDAP publishing is configured, the Certificate Manager automatically creates or converts an entry for the CA in the directory. This option is set in both the CA and CRL mapper instances and enabled by default. If the directory restricts the Certificate Manager from creating entries in the directory, turn off this option in those mapper instances, and add an entry for the CA manually in the directory.When adding the CA's entry to the directory, select the entry type based on the DN of the CA:- If the CA's DN begins with the
cn
component, create a newperson
entry for the CA. Selecting a different type of entry may not allow thecn
component to be specified. - If the CA's DN begins with the
ou
component, create a neworganizationalunit
entry for the CA.
The entry does not have to be in thepkiCA
orcertificationAuthority
object class. The Certificate Manager will convert this entry to thepkiCA
orcertificationAuthority
object class automatically by publishing its CA's signing certificate.Note
ThepkiCA
object class is defined in RFC 4523, while thecertificationAuthority
object class is defined in the (obsolete) RFC 2256. Either object class is acceptable, depending on the schema definitions used by the Directory Server. In some situations, both object classes can be used for the same CA entry.For more information on creating directory entries, see the Red Hat Directory Server documentation. - Add the correct schema elements to the CA and user directory entries.For a Certificate Manager to publish certificates and CRLs to a directory, it must be configured with specific attributes and object classes.
Object Type Schema Reason End-entity certificate userCertificate;binary (attribute) This is the attribute to which the Certificate Manager publishes the certificate.This is a multi-valued attribute, and each value is a DER-encoded binary X.509 certificate. The LDAP object class namedinetOrgPerson
allows this attribute. ThestrongAuthenticationUser
object class allows this attribute and can be combined with any other object class to allow certificates to be published to directory entries with other object classes. The Certificate Manager does not automatically add this object class to the schema table of the corresponding Directory Server.If the directory object that it finds does not allow theuserCertificate;binary
attribute, adding or removing the certificate fails.CA certificate caCertificate;binary (attribute) This is the attribute to which the Certificate Manager publishes the certificate.The Certificate Manager publishes its own CA certificate to its own LDAP directory entry when the server starts. The entry corresponds to the Certificate Manager's issuer name.This is a required attribute of thepkiCA
orcertificationAuthority
object class. The Certificate Manager adds this object class to the directory entry for the CA if it can find the CA's directory entry.CRL certificateRevocationList;binary (attribute) This is the attribute to which the Certificate Manager publishes the CRL.The Certificate Manager publishes the CRL to its own LDAP directory entry. The entry corresponds to the Certificate Manager's issuer name.This is an attribute of thepkiCA
orcertificationAuthority
object class. The value of the attribute is the DER-encoded binary X.509 CRL. The CA's entry must already contain thepkiCA
orcertificationAuthority
object class for the CRL to be published to the entry.Delta CRL deltaRevocationList;binary (attribute) This is the attribute to which the Certificate Manager publishes the delta CRL. The Certificate Manager publishes the delta CRL to its own LDAP directory entry, separate from the full CRL. The delta CRL entry corresponds to the Certificate Manager's issuer name.This attribute belongs to thedeltaCRL
orcertificationAuthority-V2
object class. The value of the attribute is the DER-encoded binary X.509 delta CRL. - Set up a bind DN for the Certificate Manager to use to access the Directory Server.The Certificate Manager user must have read-write permissions to the directory to publish certificates and CRLs to the directory so that the Certificate Manager can modify the user entries with certificate-related information and the CA entry with CA's certificate and CRL related information.The bind DN entry can be either of the following:
- An existing DN that has write access, such as the Directory Manager.
- A new user which is granted write access. The entry can be identified by the Certificate Manager's DN, such as
cn=testCA, ou=Research Dept, o=Example Corporation, st=California, c=US
.Note
Carefully consider what privileges are given to this user. This user can be restricted in what it can write to the directory by creating ACLs for the account. For instructions on giving write access to the Certificate Manager's entry, see the Directory Server documentation.
- Set the directory authentication method for how the Certificate Manager authenticates to Directory Server. There are three options: basic authentication (simple username and password); TLS without client authentication (simple username and password); and TLS with client authentication (certificate-based).See the Red Hat Directory Server documentation for instructions on setting up these methods of communication with the server.
7.4.2. Configuring LDAP Publishers
Publisher | Description |
---|---|
LdapCaCertPublisher | Publishes CA certificates to the LDAP directory. |
LdapCrlPublisher | Publishes CRLs to the LDAP directory. |
LdapDeltaCrlPublisher | Publishes delta CRLs to the LDAP directory. |
LdapUserCertPublisher | Publishes all types of end-entity certificates to the LDAP directory. |
LdapCrossCertPairPublisher | Publishes cross-signed certificates to the LDAP directory. |
7.4.3. Creating Mappers
Mapper | Description |
---|---|
LdapUserCertMap | Locates the correct attribute of user entries in the directory in order to publish user certificates. |
LdapCrlMap | Locates the correct attribute of the CA's entry in the directory in order to publish the CRL. |
LdapCaCertMap | Locates the correct attribute of the CA's entry in the directory in order to publish the CA certificate. |
- Log into the Certificate Manager Console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing, and then Mappers.The Mappers Management tab, which lists configured mappers, opens on the right.
- To create a new mapper instance, click Select Mapper Plugin Implementation window opens, which lists registered mapper modules. Select a module, and edit it. For complete information about these modules, see Section C.2, “Mapper Plug-in Modules ”.. The
- Edit the mapper instance, and click.See Section C.2, “Mapper Plug-in Modules ” for detailed information about each mapper.
7.4.4. Completing Configuration: Rules and Enabling
7.5. Creating Rules
- Log into the Certificate Manager Console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing, and then Rules.The Rules Management tab, which lists configured rules, opens on the right.
- To edit an existing rule, select that rule from the list, and click Rule Editor window.. This opens the
- To create a rule, click Select Rule Plug-in Implementation window.. This opens theSelect the
Rule
module. This is the only default module. If any custom modules have been been registered, they are also available. - Edit the rule.
- type. This is the type of certificate for which the rule applies. For a CA signing certificate, the value is
cacert
. For a cross-signed certificate, the value isxcert
. For all other types of certificates, the value iscerts
. For CRLs, specifycrl
. - predicate. This sets the predicate value for the type of certificate or CRL issuing point to which this rule applies. The predicate values for CRL issuing points, delta CRLs, and certificates are listed in Table 7.3, “Predicate Expressions”.
- enable.
- mapper. Mappers are not necessary when publishing to a file; they are only needed for LDAP publishing. If this rule is associated with a publisher that publishes to an LDAP directory, select an appropriate mapper here. Leave blank for all other forms of publishing.
- publisher. Sets the publisher to associate with the rule.
Predicate Type | Predicate |
---|---|
CRL Issuing Point | issuingPointId== Issuing_Point_Instance_ID && isDeltaCRl==[true|false]
To publish only the master CRL, set
isDeltaCRl==false . To publish only the delta CRL, set isDeltaCRl==true . To publish both, set a rule for the master CRL and another rule for the delta CRL.
|
Certificate Profile | profileId== profile_name
To publish certificates based on the profile used to issue them, set
profileId== to a profile name, such as caServerCert .
|
7.6. Enabling Publishing
Note
- Log into the Certificate Manager Console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing.The right pane shows the details for publishing to an LDAP-compliant directory.
- To enable publishing to a file only, select Enable Publishing.
- To enable LDAP publishing, select both Enable Publishing and Enable Default LDAP Connection.In the Destination section, set the information for the Directory Server instance.
- Host name. If the Directory Server is configured for TLS client authenticated communication, the name must match the
cn
component in the subject DN of the Directory Server's TLS server certificate.The hostname can be the fully-qualified domain name or an IPv4 or IPv6 address. - Port number.
- Directory Manager DN. This is the distinguished name (DN) of the directory entry that has Directory Manager privileges. The Certificate Manager uses this DN to access the directory tree and to publish to the directory. The access control set up for this DN determines whether the Certificate Manager can perform publishing. It is possible to create another DN that has limited read-write permissions for only those attributes that the publishing system actually needs to write.
- Password. This is the password which the CA uses to bind to the LDAP directory to which the certificate or CRL is published. The Certificate Manager saves this password in its
password.conf
file. For example:CA LDAP Publishing:password
- Client certificate. This sets the certificate the Certificate Manager uses for TLS client authentication to the publishing directory. By default, the Certificate Manager uses its TLS server certificate.
- LDAP version. Select LDAP version 3.
- Authentication. The way the Certificate Manager authenticates to the Directory Server. The choices are
Basic authentication
andTLS client authentication
.If the Directory Server is configured for basic authentication or for TLS communication without client authentication, selectBasic authentication
and specify values for the Directory manager DN and password.If the Directory Server is configured for TLS communication with client authentication, selectTLS client authentication
and theUse TLS communication
option, and identify the certificate that the Certificate Manager must use for TLS client authentication to the directory.
7.7. Setting up Resumable CRL Downloads
7.7.1. Retrieving CRLs Using wget
wget
. The wget
command can be used to retrieve any published CRL. For example, to retrieve a full CRL which is newer than the previous full CRL:
[root@server ~]# wget --no-check-certificate -d https://server.example.com:8443/ca/ee/ca/crl/MasterCRL.bin
wget
are summarized in Table 7.4, “wget Options to Use for Retrieving CRLs”.
Argument | Description |
---|---|
no argument | Retrieves the full CRL. |
-N | Retrieves the CRL that is newer than the local copy (delta CRL). |
-c | Retrieves a partially-downloaded file. |
--no-check-certificate | Skips TLS for the connection, so it is not necessary to configure TLS between the host and client. |
-d | Prints debug information. |
7.8. Publishing Cross-Pair Certificates
crossCertificatePair
entry to an LDAP directory or to a file; this is enabled by default. If this has been disabled, it can be re-enabled through the Certificate Manager Console by doing the following:
- Open the CA console.
pkiconsole https://server.example.com:8443/ca
- In the Configuration tab, select the Certificate Manager link in the left pane, then the Publishing link.
- Click the Rules link under Publishing. This opens the Rules Management pane on the right.
- If the rule exists and has been disabled, select the enable checkbox. If the rule has been deleted, then click and create a new rule.
- Select xcerts from the type drop-down menu.
- Make sure the enable checkbox is selected.
- Select LdapCaCertMap from the mapper drop-down menu.
- Select LdapCrossCertPairPublisher from the publisher drop-down menu.
LdapCaCertMap
, by default designates that the crossCertificatePair
be stored to the LdapCaSimpleMap
LDAP entry. The publisher, LDAPCrossPairPublisher
, by default sets the attribute to store the cross-pair certificate in the CA entry to crossCertificatePair;binary
.
7.9. Testing Publishing to Files
- Open the CA's end-entities page, and request a certificate.
- Approve the request through the agent services page, if required.
- Retrieve the certificate from the end-entities page, and download the certificate into the browser.
- Check whether the server generated the DER-encoded file containing the certificate.Open the directory to which the binary blob of the certificate is supposed to be published. The certificate file should be named
cert-
serial_number.der
. - Convert the DER-encoded certificate to its base 64-encoded format using the Binary to ASCII tool. For more information on this tool, refer to the
BtoA(1)
man page.BtoA input_file output_file
input_file sets the path to the file that contains the DER-encoded certificate, and output_file sets the path to the file to write the base-64 encoded certificate. - Open the ASCII file; the base-64 encoded certificate is similar to the one shown:
-----BEGIN CERTIFICATE----- MMIIBtgYJYIZIAYb4QgIFoIIBpzCCAZ8wggGbMIIBRaADAgEAAgEBMA0GCSqGSIb3DQEBBAUAMFcxC AJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aWhfyyuougjgjjgmkgjkgmjg fjfgjjjgfyjfyj9ucyBDb3Jwb3JhdGlvbjpMEaMBgGA1UECxMRSXNzdWluZyhgdfhbfdpffjphotoo gdhkBBdXRob3JpdHkwHhcNOTYxMTA4MDkwNzM0WhcNOTgxMTA4MDkwNzMM0WjBXMQswCQYDVQQGEwJ VUzEsMCoGA1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yY2F0aW9ucyBDb3Jwb3Jhd GlvbjpMEaMBgGA1UECxMRSXNzdWluZyBBdXRob3JpdHkwHh -----END CERTIFICATE-----
- Convert the base 64-encoded certificate to a readable form using the Pretty Print Certificate tool. For more information on this tool, refer to the
PrettyPrintCert(1)
man page.PrettyPrintCert input_file [output_file]
input_file sets the path to the ASCII file that contains the base-64 encoded certificate, and output_file, optionally, sets the path to the file to write the certificate. If an output file is not set, the certificate information is written to the standard output. - Compare the output with the certificate issued; check the serial number in the certificate with the one used in the filename.If everything matches, the Certificate Manager is configured correctly to publish certificates to file.
- Revoke the certificate.
- Check whether the server generated the DER-encoded file containing the CRL.Open the directory to which the server is to publish the CRL as a binary blob. The CRL file should have a name in the form
crl-
this_update.der
. this_update specifies the value derived from the time-dependentThis Update
variable of the CRL. - Convert the DER-encoded CRL to its base 64-encoded format using the Binary to ASCII tool.
BtoA input_file output_file
- Convert the base 64-encoded CRL to readable form using the Pretty Print CRL tool.
PrettyPrintCrl input_file [output_file]
- Compare the output.
7.10. Viewing Certificates and CRLs Published to File
dumpasn1
tool or the PrettyPrintCert
or PrettyPrintCrl
tool.
- Convert the base-64 file to binary. For example:
AtoB /tmp/example.b64 /tmp/example.bin
- Use the
PrettyPrintCert
orPrettyPrintCrl
tool to convert the binary file to pretty-print format. For example:PrettyPrintCert example.bin example.cert
dumpasn1
, PrettyPrintCert
, or PrettyPrintCrl
tool with the DER-encoded file. For example:
PrettyPrintCrl example.der example.crl
7.11. Updating Certificates and CRLs in a Directory
- Search the internal database for certificates that are out of sync and publish or unpublish.
- Publish certificates that were issued while the Directory Server was down. Similarly, unpublish certificates that were revoked or that expired while Directory Server was down.
- Publish or unpublish a range of certificates based on serial numbers, from serial number xx to serial number yy.
7.11.1. Manually Updating Certificates in the Directory
- Update the directory with certificates.
- Remove expired certificates from the directory.Removing expired certificates from the publishing directory can be automated by scheduling an automated job.
- Remove revoked certificates from the directory.
- Open the Certificate Manager agent services page.
- Select the Update Directory Server link.
- Select the appropriate options, and click.The Certificate Manager starts updating the directory with the certificate information in its internal database. If the changes are substantial, updating the directory can take considerable time. During this period, any changes made through the Certificate Manager, including any certificates issued or any certificates revoked, may not be included in the update. If any certificates are issued or revoked while the directory is updated, update the directory again to reflect those changes.
- Modify the default publishing rule for user certificates by changing the value of the
predicate
parameter toprofileId!=caCACert
. - Use the
LdapCaCertPublisher
publisher plug-in module to add another rule, with the predicate parameter set toprofileId=caCACert
, for publishing subordinate CA certificates.
7.11.2. Manually Updating the CRL in the Directory
- Open the Certificate Manager agent services page.
- Select Update Revocation List.
- Click.
Chapter 8. Authentication for Enrolling Certificates
8.1. Automatic Approval by an Authentication Plug-in
auth.instance_id
parameter in a profile specifies the authentication mechanism. A certificate request can either be automatically approved through an authentication plug-in, or be manually approved by a CA agent.
Note
8.1.1. Setting up Auto-approval of Enrollment Requests
- For agent-pre-approved CMC requests, set in the CA profile:
auth.instance_id=CMCAuth authz.acl=group="Certificate Manager Agents"
Theauthz.acl
parameter defines the group that is allowed to approve requests. - For user-initiated requests:
- When using CMC Shared Token, set in the CA profile:
auth.instance_id=CMCUserSignedAuth
Required default and constraint:policyset.cmcUserCertSet.1.constraint.class_id=cmcSharedTokenSubjectNameConstraintImpl policyset.cmcUserCertSet.1.constraint.name=CMC Shared Token Subject Name Constraint policyset.cmcUserCertSet.1.default.class_id=authTokenSubjectNameDefaultImpl policyset.cmcUserCertSet.1.default.name=Subject Name Default
- When using User-signed requests, set in the CA profile:
auth.instance_id=CMCUserSignedAuth
Required default and constraint:policyset.cmcUserCertSet.1.default.params.name= policyset.cmcUserCertSet.9.constraint.class_id=uniqueKeyConstraintImpl policyset.cmcUserCertSet.9.constraint.name=Unique Key Constraint policyset.cmcUserCertSet.9.constraint.params.allowSameKeyRenewal=true policyset.cmcUserCertSet.9.default.class_id=noDefaultImpl policyset.cmcUserCertSet.9.default.name=No Default
8.1.2. CMC Authentication Plug-ins
CMCAuth
- Use this plug-in when a CA agent signs CMC requests.To use the
CMCAuth
plug-in, set the following in the enrollment profile:auth.instance_id=CMCAuth
By default, the following enrollment profiles use theCMCAuth
plug-in:- For system certificates:
caCMCauditSigningCert
caCMCcaCert
caCMCECserverCert
caCMCECsubsystemCert
caCMCECUserCert
caCMCkraStorageCert
caCMCkraTransportCert
caCMCocspCert
caCMCserverCert
caCMCsubsystemCert
- For user certificates:
caCMCUserCert
caECFullCMCUserCert
caFullCMCUserCert
CMCUserSignedAuth
- Use this plug-in when users submit signed or SharedSecret-based CMC requests.To use the
CMCUserSignedAuth
plug-in, set the following in the enrollment profile:auth.instance_id=CMCUserSignedAuth
A user-signed CMC request must be signed by the user's certificate which contains the samesubjectDN
attribute as the requested certificate. You can only use a user-signed CMC request if the user already obtained a signing certificate which can be used to prove the user's identity for other certificates.A SharedSecret-based CMC request means that the request was signed by the private key of the request itself. In this case, the CMC request must use the Shared Secret mechanism for authentication. A SharedSecret-based CMC request is typically used to obtain the user's first signing certificate, which is later used to obtain other certificates. For further details, see Section 8.1.3, “CMC SharedSecret Authentication”.By default, the following enrollment profiles use theCMCUserSignedAuth
plug-in:caFullCMCUserSignedCert
caECFullCMCUserSignedCert
caFullCMCSharedTokenCert
caECFullCMCSharedTokenCert
8.2. Manual Approval by a CA Agent
- Set the
auth.instance_id
to an empty value:auth.instance_id=
- Do not set the
authz.acl
parameter.
8.3. Manually Reviewing the Certificate Status Using the Command Line
pki
command-line interface, see Section 2.5.1.1, “pki CLI Initialization”.
- Display the list of pending certificate requests:
$ pki agent_authentication_parameters ca-cert-request-find --status pending
This command lists all pending certificate requests. - Download a particular certificate request:
$ pki agent_authentication_parameters ca-cert-request-review id --file request.xml
- Open the
request.xml
file in an editor or a separate terminal, and review the contents of the request to ensure it is legitimate. Then answer the prompt: if the request is valid, answer "approve
and press Enter. If the request is invalid, answerreject
and press Enter. Organizations can subscribe semantic differences toreject
andcancel
; both result in no certificate being issued.
8.4. Manually Reviewing the Certificate Status Using the Web Interface
- Open the following URL in a web browser:
https://server_host_name:8443/ca/agent/ca
- Authenticate as an agent. For information about authenticating as a user and configuring your browser, see Section 2.4.1, “Browser Initialization”.
- On the sidebar on the left, click the List requests link.
- Filter the requests be selecting
Show all requests
for Request type andShow pending requests
for Request status. - Clickin the lower right corner.
- The results page lists all pending requests waiting for review. Click on the request number to review a request.
- Review the request information and ensure that it is a legitimate request. If necessary, modify the policy information to correct any mistakes or make any desired changes to the certificate, such as changing the not valid after field. Optionally, leave an additional note.The drop down menu includes several review status updates. Select Approve request to approve the request or Reject request to deny it, and click . Organizations can subscribe semantic differences to Reject request and Cancel Request; both result in no certificate being issued.
Chapter 9. Authorization for Enrolling Certificates (Access Evaluators)
Note
9.1. Authorization Mechanism
type
, op
, value
), evaluates an expression such as group='Certificate Manager Agents'
and returns a boolean depending on the result of evaluation.
9.2. Default Evaluators
accessEvaluator.impl.group.class=com.netscape.cms.evaluators.GroupAccessEvaluator accessEvaluator.impl.ipaddress.class=com.netscape.cms.evaluators.IPAddressAccessEvaluator accessEvaluator.impl.user.class=com.netscape.cms.evaluators.UserAccessEvaluator accessEvaluator.impl.user_origreq.class=com.netscape.cms.evaluators.UserOrigReqAccessEvaluator
group
access evaluator evaluates the group membership properties of a user. For example, in the following enrollment profile entry, only the CA agents are allowed to go through enrollment with that profile:
authz.acl=group="Certificate Manager Agents"
ipaddress
access evaluator evaluates the IP address of the requesting subject. For example, in the following enrollment profile entry, only the host bearing the specified IP address can go through enrollment with that profile:
authz.acl=ipaddress="a.b.c.d.e.f"
user
access evaluator evaluates the user ID for exact match. For example, in the following enrollment profile entry, only the user matching the listed user is allowed to go through enrollment with that profile:
authz.acl=user="bob"
user_origreq
access evaluator evaluates the authenticated user against a previous matching request for equality. This special evaluator is designed specifically for renewal purpose to make sure the user requesting the renewal is the same user that owns the original request. For example, in the following renewal enrollment profile entry, the UID of the authenticated user must match the UID of the user requesting the renewal:
authz.acl=user_origreq="auth_token.uid"
Part IV. Managing the Subsystem Instances
Chapter 10. Self Tests
10.1. Running Self-Tests
10.1.1. Running Self-Tests
10.1.1.1. Running Self-Tests from the Console
- Log into the Console.
pkiconsole https://server.example.com:admin_port/subsystem_type
- Select the subsystem name at the top of the left pane.
- Select the Self Tests tab.
- Click.The self-tests that are configured for the subsystem will run. If any critical self-tests fail, the server will stop.
- The On-Demand Self Tests Results window appears, showing the logged events for this run of the self-tests.
10.1.1.2. Running TPS Self-Tests
pki tps-selftest-find
pki tps-selftest-run
pki tps-selftest-show
10.2. Debugging Self-Tests Failures
# systemctl restart pki-tomcatd-nuxwdog@instance_name.service
10.2.1. Self-Test Logging
selftests.log
, is added to the log directory that contains reports for both the start up self-tests and the on-demand self-tests.
Chapter 11. Managing Certificate/Key Crypto Token
About Crypto Tokens
11.1. About certutil
and PKICertImport
certutil
command is provided by Network Security Services (NSS). certutil
is used for validating and importing certificates. A basic overview of how we use certutil
is presented below, however, PKICertImport
is our wrapper script of choice for safely validating and importing certificates. Using certutil
to do so requires multiple command invocations and correct usage is outside the scope of this documentation.
11.1.1. certutil
Basic Usage
certutil [command] [options]
certutil
invocation takes a command flag, usually denoted by a capital letter, and a series of options which control what the command does. If an option takes a value, that value is named between "<" and ">" symbols.
11.1.2. PKICertImport Basic Usage
PKICertImport [options]
PKICertImport
invocation accepts a series of options to validate and import a specified certificate. Unlike the broad use cases of certutil
, PKICertImport
is only focused on safely importing and validating certificates. See Section 11.1.4, “Common certutil
and PKICertImport
Options” for more information about available options.
Note
PKICertImport
prompts for the NSS DB and/or HSM passwords multiple times throughout the course of its execution. This is expected as PKICertImport
has to interact with the NSS DB multiple times. To avoid having to input the NSS DB password repetitively, specify a password file via -f <filename>
. When done, be sure to delete the password file.
11.1.3. certutil
Common Commands
certutil
and provide a brief overview of several common commands. PKICertImport
is not compatible with nor require these command flags.
certutil -A
-A
command denotes "adding" a certificate. It requires a certificate to import (-i
), a nickname (-n
) for that certificate, and a series of trust flags (-t
) for the certificate.
certutil -V
-V
command denotes "verifying" a certificate. It requires a certificate nickname to validate (-n
) and a type of verification (-u
) to perform.
certutil -D
-D
command denotes "deleting" a certificate. It requires a certificate nickname (-n
) to remove.
certutil -M
-M
command denotes "modifying" a certificate. It requires a certificate nickname (-n
) to modify, and a series of trust flags (-t
) to give the certificate.
certutil -L
-L
command denotes "listing" a certificate or all certificates. If given the nickname option (-n
), it will list detailed information about that certificate, else if omitted, it will list general information about all certificates present.
certutil -L
would show each certificate by its nickname along with its trust info. For example:
Certificate Nickname
|
Trust Attributes |
---|---|
caSigningCert pki-ca1
|
CT, C, C
|
Note
certutil -L
correspond to what is specified with the -t
option.
certutil -L
does not modify the database, and can thus be executed safely as many times as desired.
11.1.4. Common certutil
and PKICertImport
Options
PKICertImport
as well.
-n <nickname>
-n <nickname>
option specifies the nickname for a certificate. This can be any text and is only used as a reference to the certificate. It MUST be unique.
-d <directory>
-d <directory>
option specifies the path to the NSS DB directory in use. We usually assume you are already in this directory and use "." to refer to the current directory.
-t <trust>
-t <trust>
option specifies the trust level for the certificate.
- trust for TLS
- trust for email
- trust for object signing
c
, C
, and T
.
c
states that this certificate should be a Certificate Authority (CA).C
states that this is a trusted certificate authority for signing server certificates (C
implies lowercasec
, hence you do not need to specify both).T
states that this certificate is a trusted authority for signing client certificates (T
implies lowercasec
, hence you do not need to specify bothT
andc
).
-t CT,C,c
means that the certificate is trusted for signing client and server TLS certificates, signing server email certificates (S/MIME), and is a valid CA for object signing (though untrusted).
- This ensures that, if this certificate signs another certificate, which in turn is used for object signing, it will be deemed invalid.
-t ,,
.
certutil -L -d
- Each certificate's nickname will be listed and the trust flags will be specified at the end of the line.
-h
option.
man certutil
command on a system with certutil properly installed.
-h <HSM>
-h <HSM>
option specifies the name of the HSM to perform operations on.
-h
option is incompatible with the -t
option, as HSMs cannot store trust. Only an NSS DB can store trust, so using the certutil -A
command or the certutil -M
command in conjunction with -h <HSM>
will fail. Instead, specify the desired trust level on a separate certutil -M
command without the -h
option.
-e
-e
option specifies that the validity of the signature is checked as well, when used in conjunction with the certutil -V
command. PKICertImport
always performs the certificate signature validation and does not understand the -e
option.
-a
-a
option specifies that the key in question is in PEM (ASCII) format.
-i <certificate>
-i <certificate>
option specifies the path to the certificate. This is only used in the certutil -A
command to specify the path to the certificate to import.
-u <usage>
-u <usage>
option specifies that usage of the certificate to verify when used in conjunction with the certutil -V
command.
-u C
stands for verify a client TLS certificate. Note that this mostly accepts any certificate, but will check expiration date and signature.-u V
stands for verify a server TLS certificate. Note that this will reject CA certificates and will check expiration date and signature.-u L
stands for verify a CA TLS certificate. Note that this will validate trust flags (to see ifc
is present) and will check key usage to ensure that the key is a CA key. This also checks expiration and signatures.-u O
stands for verify a OCSP status responder certificate. Note that this checks expiry and signatures.-u J
stands for verify an object signing certificate. Note that this checks expiry and signatures.
c
flag for an CA TLS certificate), certutil -V
will give incorrect results.
Note
man certutil
command on a system with certutil properly installed.
11.2. Importing a Root Certificate
cd
/path/to/nssdb
ca_root.crt
. Please substitute the correct name and path to this file as appropriate for your scenario.
certutil
and PKICertImport
options used below, see Section 11.1, “About certutil
and PKICertImport
”.
To import the root certificate:
- Execute
PKICertImport -d . -n "CA Root" -t "CT,C,C" -a -i ca_root.crt -u L
command.This command validates and imports the root certificate into your NSS DB. The validation succeeds when no error message is printed and the return code is 0. To check the return code, executeecho $?
immediately after executing the previous command above. In most cases, a visual error message is printed. The certificate usually fails to validate because it is expired or because it is not a CA certificate. Therefore, make sure your certificate file is correct and up-to-date. Contact the issuer and ensure that all intermediate and root certificates are present on your system.
11.3. Importing an Intermediate Certificate Chain
cd
/path/to/nssdb
ca_sub_<num>.crt
(for example ca_sub_1.crt
, ca_sub_2.crt
, and so on). Substitute names and paths for your certificates as appropriate to your deployment.
Note
fullchain.crt
, fullchain.pem
, or similar and it contains multiple certificates, split it into the above format by copying each block (between and including the ----BEGIN CERTIFICATE----- and an -----END CERTIFICATE----- markers) to its own file. The first ones should be named ca_sub_<num>.crt
and the last will be your server cert named service.crt
. Server certificates are discussed in later sections.
certutil
and PKICertImport
options used below, see Section 11.1, “About certutil
and PKICertImport
”.
For every intermediate certificate in the chain:
- Execute
PKICertImport -d . -n "CA Sub $num" -t "CT,C,C" -a -i ca_sub_$num.crt -u L
This command validates and imports the Intermediate CA certificate into your NSS DB. The validation succeeds when no error message is printed and the return code is 0. To check the return code, executeecho $?
immediately after executing the previous command above. In most cases, a visual error message is printed. If the validation does not succeed, contact the issuer and ensure that all intermediate and root certificates are present on your system.
11.4. Importing a certificate into an NSS Database
- For any subsystem's
auditSigningCert
, please follow the steps below for validating an object Signing certificate. - For the CA subsystem's
caSigningCert
, please follow the steps above for importing and validating an intermediate certificate chain, but do so only with the caSigningCert. - For the CA subsystem's
ocspSigningCert
, please follow the steps below for validating an OCSP certificate. - For user's client or S/MIME certificate, follow the Client Certificate steps.
certutil
and PKICertImport
options used below, see Section 11.1, “About certutil
and PKICertImport
”.
Importing a Client Certificate Into the NSS Database
- Change into the NSS database directory. For example:
# cd /path/to/nssdb/
- Import and trust the root certificate, if it is not already imported and trusted. For details, see Section 11.2, “Importing a Root Certificate”.
- Import and validate the intermediate certificates, if not already imported and validated. For details, see Section 11.3, “Importing an Intermediate Certificate Chain”.
- Validate and import the client certificate:
#
PKICertImport -d . -n "client name" -t ",," -a -i client.crt -u C
The validation succeeds when no error message is printed and the return code is 0. To check the return code, executeecho $?
immediately after executing the previous command above. In most cases, a visual error message is printed. If the validation does not succeed, contact the issuer and ensure that all intermediate and root certificates are present on your system.
Importing an Object Signing Certificate
- Change into the NSS database directory. For example:
# cd /path/to/nssdb/
- Import and trust the root certificate, if it is not already imported and trusted. For details, see Section 11.2, “Importing a Root Certificate”.
- Import and validate the intermediate certificates, if not already imported and validated. For details, see Section 11.3, “Importing an Intermediate Certificate Chain”.
- Validate and import the object signing certificate:
#
PKICertImport -d . -n "certificate name" -t ",,P" -a -i objectsigning.crt -u J
The validation succeeds when no error message is printed and the return code is 0. To check the return code, executeecho $?
immediately after executing the previous command above. In most cases, a visual error message is printed. If the validation does not succeed, contact the issuer and ensure that all intermediate and root certificates are present on your system.
Importing an OCSP Responder
- Change into the NSS database directory. For example:
# cd /path/to/nssdb/
- Import and trust the root certificate, if it is not already imported and trusted. For details, see Section 11.2, “Importing a Root Certificate”.
- Import and validate the intermediate certificates, if not already imported and validated. For details, see Section 11.3, “Importing an Intermediate Certificate Chain”.
- Validate and import the OCSP responder certificate:
#
PKICertImport -d . -n "certificate name" -t ",," -a -i ocsp.crt -u O
The validation succeeds when no error message is printed and the return code is 0. To check the return code, executeecho $?
immediately after executing the previous command above. In most cases, a visual error message is printed. If the validation does not succeed, contact the issuer and ensure that all intermediate and root certificates are present on your system.
Chapter 12. Managing Certificate System Users and Groups
12.1. About Authorization
Note
- The users authenticate to the interface using a certificate.
- The server authenticates the user by checking the certificate against one stored in the database. The server also checks that the certificate is valid and finds the group membership of the user by associating the DN of the certificate with a user and checking the user entry.
- When the user tries to perform an operation, the authorization mechanism compares the user ID of the user, the group in which the user belongs, or the IP address of the user to the ACLs set for that user, group, or IP address. If an ACL exists that allows that operation, then the operation proceeds.
12.2. Default Groups
- Administrators. This group is given full access to all of the tasks available in the administrative interface.
- Agents. This group is given full access to all of the tasks available in the agent services interface.
- Auditors. This group is given access to view the signed audit logs. This group does not have any other privileges.
- Enterprise administrators. Each subsystem instance is automatically assigned a subsystem-specific role as an enterprise administrator when it is joined to a security domain during configuration. These roles automatically provide trusted relationships among subsystems in the security domain, so that each subsystem can efficiently carry out interactions with other subsystems.
12.2.1. Administrators
Administrators
group for the group. Every member of that group has administrative privileges for that instance of Certificate System.
Role | Description |
---|---|
Security Domain Administrators |
By default, the CA administrator of the CA hosting the domain is assigned as the security domain administrator.
|
Enterprise CA Administrators |
|
Enterprise KRA Administrators |
|
Enterprise OCSP Administrators |
|
Enterprise TKS Administrators |
|
Enterprise TPS Administrators |
|
12.2.2. Auditors
Auditors
group and storing the auditor's certificate in the user entry. The auditor's certificate is used to encrypt the private key of the key pair used to sign the audit log.
Auditors
group is set when the subsystem is configured. No auditors are assigned to this group during configuration.
12.2.3. Agents
- The Certificate Manager Agents group.
- The Key Recovery Authority Agents group.
- The Online Certificate Status Manager Agents group.
- The Token Key Service Agents group.
- The Token Processing System Agents group.
12.2.4. Enterprise Groups
Note
- Enterprise CA Administrators
- Enterprise KRA Administrators
- Enterprise OCSP Administrators
- Enterprise TKS Administrators
- Enterprise TPS Administrators
12.3. Managing Users and Groups for a CA, OCSP, KRA, or TKS
12.3.1. Managing Groups
12.3.1.1. Creating a New Group
- Log into the administrative console.
pkiconsole https://server.example.com:8443/subsystem_type
- Select Users and Groups from the navigation menu on the left.
- Select the Groups tab.
- Click, and fill in the group information.It is only possible to add users who already exist in the internal database.
- Edit the ACLs to grant the group privileges. See Section 12.4.3, “Editing ACLs” for more information. If no ACIs are added to the ACLs for the group, the group will have no access permissions to any part of Certificate System.
12.3.1.2. Changing Members in a Group
- Log into the administrative console.
- Select Users and Groups from the navigation tree on the left.
- Click the Groups tab.
- Select the group from the list of names, and click.
- Make the appropriate changes.
- To change the group description, type a new description in the Group description field.
- To remove a user from the group, select the user, and click.
- To add users, click. Select the users to add from the dialog box, and click .
12.3.2. Managing Users (Administrators, Agents, and Auditors)
12.3.2.1. Creating Users
Note
12.3.2.1.1. Creating Users Using the Command Line
- Add a user account. For example, to add the
example
user to the CA:# pki -c password -n caadmin \ ca-user-add example --fullName "Example User" --------------------- Added user "example" --------------------- User ID: example Full name: Example User
This command uses thecaadmin
user to add a new account. - Optionally, add a user to a group. For example, to add the
example
user to theCertificate Manager Agents
group:# pki -p password -n "caadmin" \ user-add-membership example Certificate Manager Agents
- Create a certificate request:
- If a Key Recovery Authority (KRA) exists in your Certificate System environment:
# CRMFPopClient -d ~/.dogtag/pki-instance_name/ -p password \ -n "user_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" \ -v -o ~/user_name.req
This command stores the Certificate Signing Request (CSR) in theCRMF
format in the~/user_name.req
file. - If no Key Recovery Authority (KRA) exists in your Certificate System environment:
# PKCS10Client -d ~/.dogtag/pki-instance_name/ -p password \ -n "user_name" -o ~/user_name.req
This command stores the CSR inpkcs10
format in the~/user_name.req
file.
- Create an enrollment request:
- Create the
~/cmc.role_crmf.cfg
file with the following content:#numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 #input: full path for the PKCS10 request or CRMF request, #the content must be in Base-64 encoded format #Multiple files are supported. They must be separated by space. input=~/user_name.req #output: full path for the CMC request in binary format output=~/cmc.role_crmf.req #tokenname: name of token where agent signing cert can be found (default is internal) tokenname=internal #nickname: nickname for agent certificate which will be used #to sign the CMC full request. nickname=PKI Administrator for Example.com #dbdir: directory for cert8.db, key3.db and secmod.db dbdir=~/.dogtag/pki-instance_name/ #password: password for cert8.db which stores the agent #certificate password=password #format: request format, either pkcs10 or crmf format=crmf
Set the parameters based on your environment and the CSR format used in the previous step. - Pass the previously created configuration file to the
CMCRequest
utility to create the CMC request:# CMCRequest ~/cmc.role_crmf.cfg
- Submit a Certificate Management over CMS (CMC) request:
- Create the
~/HttpClient_role_crmf.cfg
file with the following content:# #host: host name for the http server host=server.example.com #port: port number port=8443 #secure: true for secure connection, false for nonsecure connection secure=true #input: full path for the enrollment request, the content must be in binary format input=~/cmc.role_crmf.req #output: full path for the response in binary format output=~/cmc.role_crmf.resp #tokenname: name of token where TLS client authentication cert can be found (default is internal) #This parameter will be ignored if secure=false tokenname=internal #dbdir: directory for cert8.db, key3.db and secmod.db #This parameter will be ignored if secure=false dbdir=~/.dogtag/pki-instance_name/ #clientmode: true for client authentication, false for no client authentication #This parameter will be ignored if secure=false clientmode=true #password: password for cert8.db #This parameter will be ignored if secure=false and clientauth=false password=password #nickname: nickname for client certificate #This parameter will be ignored if clientmode=false nickname=PKI Administrator for Example.com #servlet: servlet name servlet=/ca/ee/ca/profileSubmitCMCFull
Set the parameters based on your environment. - Submit the request to the CA:
# HttpClient ~/HttpClient_role_crmf.cfg Total number of bytes read = 3776 after SSLSocket created, thread token is Internal Key Storage Token client cert is not null handshake happened writing to socket Total number of bytes read = 2523 MIIJ1wYJKoZIhvcNAQcCoIIJyDCCCcQCAQMxDzANBglghkgBZQMEAgEFADAxBggr ... The response in data format is stored in ~/cmc.role_crmf.resp
- Verify the result:
# CMCResponse ~/cmc.role_crmf.resp Certificates: Certificate: Data: Version: v3 Serial Number: 0xE Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11 Issuer: CN=CA Signing Certificate,OU=pki-instance_name Security Domain Validity: Not Before: Friday, July 21, 2017 12:06:50 PM PDT America/Los_Angeles Not After: Wednesday, January 17, 2018 12:06:50 PM PST America/Los_Angeles Subject: CN=user_name ... Number of controls is 1 Control #0: CMCStatusInfoV2 OID: {1 3 6 1 5 5 7 7 25} BodyList: 1 Status: SUCCESS
- Optionally, to import the certificate as the user to its own
~/.dogtag/pki-instance_name/
database:# certutil -d ~/.dogtag/pki-instance_name/ -A -t "u,u,u" -n "user_name certificate" -i ~/cmc.role_crmf.resp
- Add the certificate to the user record:
- List certificates issued for the user to discover the certificate's serial number. For example, to list certificates that contain the
example
user name in the certificate's subject:pki -c password -n caadmin ca-user-cert-find example ----------------- 1 entries matched ----------------- Cert ID: 2;6;CN=CA Signing Certificate,O=EXAMPLE;CN=PKI Administrator,E=example@example.com,O=EXAMPLE Version: 2 Serial Number: 0x6 Issuer: CN=CA Signing Certificate,O=EXAMPLE Subject: CN=PKI Administrator,E=example@example.com,O=EXAMPLE ---------------------------- Number of entries returned 1
The serial number of the certificate is required in the next step. - Add the certificate using its serial number from the certificate repository to the user account in the Certificate System database. For example, for a CA user:
pki -c password -n caadmin ca-user-cert-add example --serial 0x6
12.3.2.1.2. Creating Users Using the Console
- Log into the administrative console.
pkiconsole https://server.example.com:8443/subsystem_type
- In the Configuration tab, select Users and Groups. Click .
- Fill in the information in the Edit User Information dialog.Most of the information is standard user information, such as the user's name, email address, and password. This window also contains a field called User State, which can contain any string, which is used to add additional information about the user; most basically, this field can show whether this is an active user.
- Select the group to which the user will belong. The user's group membership determines what privileges the user has. Assign agents, administrators, and auditors to the appropriate subsystem group.
- Store the user's certificate.
- Request a user certificate through the CA end-entities service page.
- If auto-enrollment is not configured for the user profile, then approve the certificate request.
- Retrieve the certificate using the URL provided in the notification email, and copy the base-64 encoded certificate to a local file or to the clipboard.
- Select the new user entry, and click.
- Click, and paste in the base-64 encoded certificate.
12.3.2.2. Changing a Certificate System User's Certificate
- Log into the administrative console.
- Select Users and Groups.
- Select the user to edit from the list of user IDs, and click.
- Clickto add the new certificate.
- In the Import Certificate window, paste the new certificate in the text area. Include the
-----BEGIN CERTIFICATE-----
and-----END CERTIFICATE-----
marker lines.
12.3.2.3. Renewing Administrator, Agent, and Auditor User Certificates
- Renew the admin user certificate. For details, seeSection 5.4, “Renewing Certificates”.
- Add the renewed user certificate to the user entry in the internal LDAP database.
- Open the console for the subsystem.
pkiconsole https://server.example.com:admin_port/subsystem_type
- Configuration | Users and Groups | Users | admin | Certificates | Import
- In the Configuration tab, select Users and Groups.
- In the Users tab, double-click the user entry with the renewed certificate, and click .
- Click, and paste in the base-64 encoded certificate.
This can also be done by usingldapmodify
to add the renewed certification directly to the user entry in the internal LDAP database, by replacing theuserCertificate
attribute in the user entry, such asuid=admin,ou=people,dc=
subsystem-base-DN.
12.3.2.4. Deleting a Certificate System User
- Log into the administrative console.
- Select Users and Groups from the navigation menu on the left.
- Select the user from the list of user IDs, and click.
- Confirm the delete when prompted.
12.4. Configuring Access Control for Users
12.4.1. About Access Control
LogAdmins
, can be added to the ACLs relevant to logs to allow read or modify access to this group. If this group is not added to any other ACLs, members of this group only have access to the logs.
allow|deny (operation) user|group|IP="name"
Note
allow (read) group="Administrators"
allow (read,modify) group="Administrators"
||
) with a space on either side. For example:
allow (read) group="Administrators" || group="Auditors"
Note
Administrators
group. If an ACL has only the following ACL, JohnB is denied any access since he does not match any of the allow ACIs:
Allow (read,modify) group="Auditors" || user="BrianC"
JohnB
, a member of the Administrators
group, has just been fired. It may be necessary to deny access specifically to JohnB
if the user cannot be deleted immediately. Another situation is that a user, BrianC
, is an administrator, but he should not have the ability to change some resource. Since the Administrators
group must access this resource, BrianC
can be specifically denied access by creating an ACI that denies this user access.
=
) or does not equal (!=
).
group="groupname"
. The syntax to exclude a group is group!="groupname"
, which allows any group except for the group named. For example:
group="Administrators" || group!="Auditors"
*
). For example:
group="* Managers"
user="userID"
. The syntax to exclude the user is user!="userID"
, which allows any user ID except for the user ID named. For example:
user="BobC" || user!="JaneK"
anybody
. For example:
user="anybody"
*
). For example:
user="*johnson"
ipaddress="ipaddress"
. The syntax to exclude an ID address from the ACL is ipaddress!="ipaddress"
. An IP address is specified using its numeric value; DNS values are not permitted. For example:
ipaddress="12.33.45.99" ipaddress!="23.99.09.88"
ipaddress="0:0:0:0:0:0:13.1.68.3"
*
). For example:
ipaddress="12.33.45.*"
user="BobC" || group="Auditors" || group="Administrators"
12.4.2. Adding ACLs
- Log into the administrative console.
- Select Access Control List.
- Click Access Control Editor.to open the
- Fill the
Resource name
andAvailable rights
fields. - To add an access control instruction (ACI), click, and supply the ACI information.
- Select the allow or deny radio button from the Access field to allow or deny the operation to the groups, users, or IP addresses specified. For more information about allowing or denying access, see Section 12.4.1, “About Access Control”.
- Set the rights. The available options are
read
andmodify
. To select both, hold the or button while selecting the entries. - Specify the user, group, or IP address that will be granted or denied access in the Syntax field. See Section 12.4.1, “About Access Control” for details on syntax.
- Click Access Control Editor window.to return to the
- Clickto store the ACI.
12.4.3. Editing ACLs
- Log into the administrative console.
- Select Access Control List in the left navigation menu.
- Select the ACL to edit from the list, and click.The ACL opens in the Access Control Editor window.
- To add an ACI, click, and supply the ACI information.To edit an ACI, select the ACI from the list in the ACI entries text area of the ACL Editor window. Click .
- Select the allow or deny radio button from the Access field to allow or deny the operation to the groups, users, or IP addresses specified. For more information about allowing or denying access, see Section 12.4.1, “About Access Control”.
- Set the rights for the access control. The options are
read
andmodify
. To set both, use the or buttons. - Specify the user, group, or IP address that will be granted or denied access in the Syntax field. See Section 12.4.1, “About Access Control” for details on syntax.
Chapter 13. Configuring Subsystem Logs
13.1. Managing Logs
13.1.1. Configuring Logs in the Console
- In the navigation tree of the Configuration tab, select Log.
- The Log Event Listener Management tab lists the currently configured listeners.To create a new log instance, click Select Log Event Listener Plug-in Implementation window., and select a module plug-in from the list in the
- Set or modify the fields in the Log Event Listener Editor window. The different parameters are listed in Table 13.1, “Log Event Listener Fields”.
Field | Description |
---|---|
Log Event Listener ID | Gives the unique name that identifies the listener. The names can have any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-), but it cannot contain other characters or spaces. |
type | Gives the type of log file. system creates error and system logs; transaction records audit logs. |
enabled | Sets whether the log is active. Only enabled logs actually record events. The value is either true or false . |
level | Sets the log level in the text field. The level must be manually entered in the field; there is no selection menu. The choices are Debug, Information, Warning, Failure, Misconfiguration, Catastrophe, and Security. |
fileName | Gives the full path, including the file name, to the log file. The subsystem user should have read/write permission to the file. |
bufferSize | Sets the buffer size in kilobytes (KB) for the log. Once the buffer reaches this size, the contents of the buffer are flushed out and copied to the log file. The default size is 512 KB. |
flushInterval | Sets the amount of time before the contents of the buffer are flushed out and added to the log file. The default interval is 5 seconds. |
maxFileSize | Sets the size, in kilobytes (KB), a log file can become before it is rotated. Once it reaches this size, the file is copied to a rotated file, and the log file is started new. The default size is 2000 KB. |
rolloverInterval | Sets the frequency for the server to rotate the active log file. The available options are hourly, daily, weekly, monthly, and yearly. The default is monthly. |
13.1.2. Managing Audit Logs
Note
/var/log/pki/instance_name/subsystem_name/
directory with other types of logs, while signed audit logs are written to /var/log/pki/instance_name/subsystem_name/signedAudit/
. The default location for logs can be changed by modifying the configuration.
13.1.2.1. Configuring a Signed Audit Log in the Console
Note
logSigning
parameter to enable
and providing the nickname of the certificate used to sign the log. A special log signing certificate is created when the subsystems are first configured.
AuditVerify
tool to verify that signed audit logs have not been tampered with.
- Open the Console.
- In the navigation tree of the Configuration tab, select Log.
- In the Log Event Listener Management tab, select the SignedAudit entry.
- Click.
- There are two fields which must be reset in the Log Event Listener Editor window.
- Set the logSigning field to
true
to enable signed logging.Note
For more fine-grained audit event select, set audit event filters during the installation configuration. For details, see the Filtering Audit Events section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition). - Set any events which are logged to the audit log. Appendix E, Audit Events lists the loggable events. Log events are separated by commas with no spaces.
- Save the log configuration.
AuditVerify(1)
man page for details about using this tool. For further details, see Section 13.2.2, “Using Signed Audit Logs”.
13.1.2.2. Handling Audit Logging Failures
- Servlets are disabled and will not process new requests.
- All pending and new requests are killed.
- The subsystem is shut down.
13.2. Using Logs
13.2.1. Viewing Logs in the Console
- Log into the Console.
- Select the Status tab.
- Under Logs, select the log to view.
- Set the viewing preferences in the Display Options section.
- Entries — The maximum number of entries to be displayed. When this limit is reached, the Certificate System returns any entries that match the search request. Zero (0) means no messages are returned. If the field is blank, the server returns every matching entry, regardless of the number found.
- Source — Select the Certificate System component or service for which log messages are to be displayed. Choosing All means messages logged by all components that log to this file are displayed.
- Level — Select a message category that represents the log level for filtering messages.
- Filename — Select the log file to view. Choose Current to view the currently active system log file.
- Click.The table displays the system log entries. The entries are in reverse chronological order, with the most current entry placed at the top. Use the scroll arrows on the right edge of the panel to scroll through the log entries.Each entry has the following information shown:
- Source — The component or resource that logged the message.
- Level — The severity of the corresponding entry.
- Date — The date on which the entry was logged.
- Time — The time at which the entry was logged.
- Details — A brief description of the log.
- To view a full entry, double-click it, or select the entry, and click.
13.2.2. Using Signed Audit Logs
13.2.2.1. Listing Audit Logs
pki subsystem-audit-file-find
command to list existing audit log files on the server.
server.example.com
:
# pki -h server.example.com -p 8443 -n auditor ca-audit-file-find ----------------- 3 entries matched ----------------- File name: ca_audit.20170331225716 Size: 2883 File name: ca_audit.20170401001030 Size: 189 File name: ca_audit Size: 6705 ---------------------------- Number of entries returned 3 ----------------------------
~/.dogtag/nssdb/
directory for authenticating to the CA. For further details about the parameters used in the command and alternative authentication methods, see the pki(1) man page.
13.2.2.2. Downloading Audit Logs
pki subsystem-audit-file-retrieve
command to download a specific audit log from the server.
server.example.com
:
- Optionally, list the available log files on the CA. See Section 13.2.2.1, “Listing Audit Logs”.
- Download the log file. For example, to download the
ca_audit
file:# pki -U https://server.example.com:8443 -n auditor ca-audit-file-retrieve ca_audit
The command uses the client certificate with the auditor nickname stored in the~/.dogtag/nssdb/
directory for authenticating to the CA. For further details about the parameters used in the command and alternative authentication methods, see the pki(1) man page.
grep
utility:
# grep "\[AuditEvent=ACCESS_SESSION_ESTABLISH\]" log_file
13.2.2.3. Verifying Signed Audit Logs
- Initialize the NSS database and import the CA certificate. For details, see the Command-line Initialization section in the Red Hat Certificate System 9 Planning, Installation and Deployment Guide (Common Criteria Edition).
- If the audit signing certificate does not exist in the PKI client database, import it:
- Search the audit signing certificate for the subsystem logs you want to verify. For example:
# pki ca-cert-find --name "CA Audit Signing Certificate" --------------- 1 entries found --------------- Serial Number: 0x5 Subject DN: CN=CA Audit Signing Certificate,O=EXAMPLE Status: VALID Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Jul 08 03:56:08 CEST 2016 Not Valid After: Thu Jun 28 03:56:08 CEST 2018 Issued On: Fri Jul 08 03:56:08 CEST 2016 Issued By: system ---------------------------- Number of entries returned 1 ----------------------------
- Import the audit signing certificate into the PKI client:
# pki client-cert-import "CA Audit Signing Certificate" --serial 0x5 --trust ",,P" --------------------------------------------------- Imported certificate "CA Audit Signing Certificate" ---------------------------------------------------
- Download the audit logs. See Section 13.2.2.2, “Downloading Audit Logs”.
- Verify the audit logs.
- Create a text file that contains a list of the audit log files you want to verify in chronological order. For example:
# cat > ~/audit.txt << EOF ca_audit.20170331225716 ca_audit.20170401001030 ca_audit EOF
- Use the
AuditVerify
utility to verify the signatures. For example:# AuditVerify -d ~/.dogtag/nssdb/ -n "CA Audit Signing Certificate" \ -a ~/audit.txt Verification process complete. Valid signatures: 10 Invalid signatures: 0
For further details about usingAuditVerify
, see the AuditVerify(1) man page.
13.2.3. Displaying Operating System-level Audit Logs
Note
auditd
logging framework must be configured per the Enabling OS-level Audit Logs section in the Red Hat Certificate System 9 Planning, Installation and Deployment Guide (Common Criteria Edition).
ausearch
utility as root or as a privileged user with the sudo
utility.
13.2.3.1. Displaying Audit Log Deletion Events
rhcs_audit_deletion
), use the -k
parameter to find events matching that key:
# ausearch -k rhcs_audit_deletion
13.2.3.2. Displaying Access to the NSS Database for Secret and Private Keys
rhcs_audit_nssdb
), use the -k
parameter to find events matching that key:
# ausearch -k rhcs_audit_nssdb
13.2.3.3. Displaying Time Change Events
rhcs_audit_time_change
), use the -k
parameter to find events matching that key:
# ausearch -k rhcs_audit_time_change
13.2.3.4. Displaying Package Update Events
SOFTWARE_UPDATE
), use the -m
parameter to find events matching that type:
# ausearch -m SOFTWARE_UPDATE
13.2.3.5. Displaying Changes to the PKI Configuration
rhcs_audit_config
), use the -k
parameter to find events matching that key:
# ausearch -k rhcs_audit_config
Chapter 14. Managing Subsystem Certificates
14.1. Required Subsystem Certificates
14.1.1. Certificate Manager Certificates
14.1.1.1. CA Signing Key Pair and Certificate
caSigningCert cert-
instance_ID CA, where instance_ID identifies the Certificate Manager instance. The default validity period for the certificate is five years.
- If the Certificate Manager is a root CA, its CA signing certificate is self-signed, meaning the subject name and issuer name of the certificate are the same.
- If the Certificate Manager is a subordinate CA, its CA signing certificate is signed by another CA, usually the one that is a level above in the CA hierarchy (which may or may not be a root CA). The root CA's signing certificate must be imported into individual clients and servers before the Certificate Manager can be used to issue certificates to them.
Note
14.1.1.2. OCSP Signing Key Pair and Certificate
cn=OCSP cert-
instance_ID CA, and it contains extensions, such as OCSPSigning
and OCSPNoCheck
, required for signing OCSP responses.
ocspSigningCert cert-
instance_ID, where instance_ID CA identifies the Certificate Manager instance.
14.1.1.3. Subsystem Certificate
subsystemCert cert-
instance_ID.
14.1.1.4. TLS Server Key Pair and Certificate
Server-Cert cert-
instance_ID, where instance_ID identifies the Certificate Manager instance.
14.1.1.5. Audit Log Signing Key Pair and Certificate
Note
14.1.2. Online Certificate Status Manager Certificates
14.1.2.1. OCSP Signing Key Pair and Certificate
ocspSigningCert cert-
instance_ID, where instance_ID OSCP is the Online Certificate Status Manager instance name.
14.1.2.2. TLS Server Key Pair and Certificate
Server-Cert cert-
instance_ID, where instance_ID identifies the Online Certificate Status Manager instance name.
14.1.2.3. Subsystem Certificate
subsystemCert cert-
instance_ID.
14.1.2.4. Audit Log Signing Key Pair and Certificate
Note
14.1.2.5. Recognizing Online Certificate Status Manager Certificates
- If the Online Certificate Status Manager's server certificate is signed by the CA that is publishing CRLs, then nothing needs to be done.
- If the Online Certificate Status Manager's server certificate is signed by the same root CA that signed the subordinate Certificate Manager's certificates, then the root CA must be marked as a trusted CA in the subordinate Certificate Manager's certificate database.
- If the Online Certificate Status Manager's TLS server certificate is signed by a different root CA, then the root CA certificate must be imported into the subordinate Certificate Manager's certificate database and marked as a trusted CA.
Note
14.1.3. Key Recovery Authority Certificates
14.1.3.1. Transport Key Pair and Certificate
14.1.3.2. Storage Key Pair
14.1.3.3. TLS Server Certificate
Server-Cert cert-
instance_ID, where instance_id identifies the KRA instance is installed.
14.1.3.4. Subsystem Certificate
subsystemCert cert-
instance_ID.
14.1.3.5. Audit Log Signing Key Pair and Certificate
Note
14.1.4. TKS Certificates
14.1.4.1. TLS Server Certificate
Server-Cert cert-
instance_ID.
14.1.4.2. Subsystem Certificate
subsystemCert cert-
instance_ID.
14.1.4.3. Audit Log Signing Key Pair and Certificate
Note
14.1.5. TPS Certificates
14.1.5.1. TLS Server Certificate
Server-Cert cert-
instance_ID.
14.1.5.2. Subsystem Certificate
subsystemCert cert-
instance_ID.
14.1.5.3. Audit Log Signing Key Pair and Certificate
14.1.6. About Subsystem Certificate Key Types
pkispawn
utility.
Example 14.1. Key Type-related Configuration Parameters for a CA
pkispawn
when creating a new CA.
pki_ocsp_signing_key_algorithm=SHA256withRSA pki_ocsp_signing_key_size=2048 pki_ocsp_signing_key_type=rsa pki_ca_signing_key_algorithm=SHA256withRSA pki_ca_signing_key_size=2048 pki_ca_signing_key_type=rsa pki_sslserver_key_algorithm=SHA256withRSA pki_sslserver_key_size=2048 pki_sslserver_key_type=rsa pki_subsystem_key_algorithm=SHA256withRSA pki_subsystem_key_size=2048 pki_subsystem_key_type=rsa pki_admin_keysize=2048 pki_admin_key_size=2048 pki_admin_key_type=rsa pki_audit_signing_key_algorithm=SHA256withRSA pki_audit_signing_key_size=2048 pki_audit_signing_key_type=rsa
Note
- The Understanding the
pkispawn
Utility section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition). - The pki_default.cfg(5) man page for descriptions of the parameters and examples.
14.1.7. Using an HSM to Store Subsystem Certificates
key3.db
and cert8.db
, respectively, in the /var/lib/pki/instance_name/alias/
directory. However, Red Hat Certificate System also supports hardware security modules (HSM), external devices which can store keys and certificates in a centralized place on the network. Using an HSM can make some functions, like cloning, easier because the keys and certificates for the instance are readily accessible.
serverCert="nethsm:Server-Cert cert-instance_ID
Note
14.2. Renewing Subsystem Certificates
HttpClient
utility. For details about the different system certificate profiles, see Section 5.3.2.1, “Obtaining System and Server Certificates”.
14.2.1. Renewing Certificates Using certutil
certutil
can be used to generate a certificate request using an existing key pair in the certificate database. The new certificate request can then be converted to a CMC request to be submitted to the CA. For details, see Section 5.2.1, “Creating a CSR Using certutil
”.
Note
- Get the password for the token database.
cat /var/lib/pki/instance_name/conf/password.conf internal=263163888660
- Open the certificate database directory of the instance whose certificate is being renewed.
cd /var/lib/pki/instance_name/alias
- List the key and nickname for the certificate being renewed. In order to renew a certificate, the key pairs used to generate and the subject name given to the new certificate must be the same as the one in the old certificate.
# certutil -K -d . certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" Enter Password or Pin for "NSS Certificate DB": < 0> rsa 69481646e38a6154dc105960aa24ccf61309d37d caSigningCert cert-pki-tomcat CA
- Copy the
alias
directory as a backup, then delete the original certificate from the certificate database. For example:certutil -D -n "ServerCert cert-example" -d .
- Run the
certutil
command with the options set to the values in the existing certificate.certutil -d . -R -k "NSS Certificate DB:cert-pki-tomcat CA" -s "cn=CA Authority,o=Example Domain" -a -o example.req2.txt
The difference between generating a new certificate and key pair and renewing the certificate is the value of the-k
option. To generate an entirely new request and key pair, then-k
sets the key type and is used with-g
, which sets the bit length. For a renewal request, the-k
option uses the certificate nickname to access the existing key pair stored in the security database.For further details about the parameters, see the certutil(1) man page. - Submit the certificate request and then retrieve it and install it.
14.2.2. Renewing Expired Certificate System Server Certificates
- If the system certificate is expired:
- Create a temporary certificate:
# pki-server cert-create sslserver --temp
- Import the temporary certificate into Certificate System's Network Security Services (NSS) database:
# pki-server cert-import sslserver
- Start Certificate System:
# systemctl start pki-tomcatd-nuxwdog@instance_name.service
- Display the certificates and note the ID of the expired system certificate:
# pki-server cert-find
- Create the new permanent certificate:
# pki-server cert-create certificate_ID
- Stop Certificate System:
# systemctl stop pki-tomcatd-nuxwdog@instance_name.service
- Import the new certificate to replace the expired certificate:
# pki-server cert-import certificate_ID
- Start Certificate System:
# systemctl start pki-tomcatd-nuxwdog@instance_name.service
14.3. Changing the Names of Subsystem Certificates
CA Signing Certificate |
|
OCSP Signing Certificate |
|
Subsystem Certificate |
|
Server Certificate |
|
Audit Signing Certificate |
|
Transport Certificate |
|
Storage Certificate |
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
OCSP Signing Certificate |
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
KRA Transport Certificate[a] |
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
[a]
This needs changed in the TKS configuration if the KRA transport certificate nickname changes, even if the TKS certificates all stay the same.
|
Server Certificate |
|
Subsystem Certificate |
|
Audit Log Signing Certificate |
|
14.4. Managing the Certificate Database
Note
certutil
can be used to manage the certificate database by editing trust settings and adding and deleting certificates. For details about this tool, see http://www.mozilla.org/projects/security/pki/nss/tools/.
14.4.1. Installing Certificates in the Certificate System Database
certutil
utility.
14.4.1.1. Installing Certificates through the Console
- Any of the certificates used by a Certificate System subsystem
- Any trusted CA certificates from external CAs or other Certificate System CAs
- Certificate chains
- Open the console.
pkiconsole https://server.example.com:secure_port/subsystem_type
- In the Configuration tab, select System Keys and Certificates from the left navigation tree.
- There are two tabs where certificates can be installed, depending on the subsystem type and the type of certificate.
- The CA Certificates tab is for installing CA certificates and certificate chains. For Certificate Managers, this tab is used for third-party CA certificates or other Certificate System CA certificates; all of the local CA certificates are installed in the Local Certificates tab. For all other subsystems, all CA certificates and chains are installed through this tab.
- The Local Certificates tab is where all server certificates, subsystem certificates, and local certificates such as OCSP signing or KRA transport are installed.
Select the appropriate tab. - To install a certificate in the Local Certificates tab, click . To install a certificate in the CA Certificates tab, click . Both will open the Certificate Setup Wizard.
- When the wizard opens, select the Install a certificate radio button, and click .
- Select the type of certificate to install. The options for the drop-down menu are the same options available for creating a certificate, depending on the type of subsystem, with the additional option to install a cross-pair certificate.
- Paste in the certificate body, including the
-----BEGIN CERTIFICATE-----
and-----END CERTIFICATE-----
, into the text area, or specify the absolute file location; this must be a local file.The certificate will look like the following:-----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANgkqkiG9w0BAQQFADA3MQswCQYDVQQGEw JVUzERMA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncy BDQTAeFw05NzEwMTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBg NVBAYTAlVTMREwDwYDVQQKEwhOZXRzY2FwZTENMAsGA1UECxMEUHawcz EXMBUGA1UEAxMOU3Vwcml5YSBTaGV0dHkwgZ8wDQYJKoZIhdfNAQEBBQ ADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG7SdATYzBcABu1AVyd7 chRFOGD3wNktbf6hRo6EAmM5R1Askzf8AW7LiQZBcrXpc0k4du+2j6xJ u2MPm8WKuMOTuvzpo+SGXelmHVChEqooCwfdiZywyZNmgaMa2MS6pUkf QVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgD -----END CERTIFICATE-----
- The wizard displays the certificate details. Review the fingerprint to make sure this is the correct certificate, or use thebutton to go back and submit a different one. Give a nickname for the certificate.The wizard installs the certificate.
- Any CA that signed the certificate must be trusted by the subsystem. Make sure that this CA's certificate exists in the subsystem's certificate database (internal or external) and that it is trusted.If the CA certificate is not listed, add the certificate to the certificate database as a trusted CA. If the CA's certificate is listed but untrusted, change the trust setting to trusted, as shown in Section 14.5, “Changing the Trust Settings of a CA Certificate”.When installing a certificate issued by a CA that is not stored in the Certificate System certificate database, add that CA's certificate chain to the database. To add the CA chain to the database, copy the CA chain to a text file, start the wizard again, and install the CA chain.
14.4.1.2. Installing Certificates Using certutil
certutil
, do the following:
- Open the subsystem's security database directory.
cd /var/lib/pki/instance_name/alias
- Run the
certutil
command with the-A
to add the certificate and-i
pointing to the file containing the certificate issued by the CA.certutil -A -n cert-name -t trustargs -d . -a -i certificate_file
Note
If the Certificate System instance's certificates and keys are stored on an HSM, then specify the token name using the-h
option.For example:certutil -A -n "ServerCert cert-instance_name" -t u,u,u -d . -a -i /tmp/example.cert
certutil
command, see http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html.
14.4.1.3. About CA Certificate Chains
14.4.2. Viewing Database Content
cert8.db
, can be viewed through the subsystem administrative console. Alternatively, the certificates can be listed using the certutil
utility. certutil
must be used to view the TPS certificates because the TPS subsystem does not use an administrative console.
Note
cert8.db
database are the subsystem certificates used for subsystem operations. User certificates are stored with the user entries in the LDAP internal database.
14.4.2.1. Viewing Database Content through the Console
- Open the subsystem console.
pkiconsole https://server.example.com:secure_port/subsystem_type
- In the Configuration tab, select System Keys and Certificates from the left navigation tree.
- There are two tabs, CA Certificates and Local Certificates, which list different kinds of certificates.
- CA Certificates lists CA certificates for which the corresponding private key material is not available, such as certificates issued by third-party CAs such as Entrust or Verisign or external Certificate System Certificate Managers.
- Local Certificates lists certificates kept by the Certificate System subsystem instance, such as the KRA transport certificate or OCSP signing certificate.
Figure 14.1. Certificate Database Tab
- The Certificate Database Management table lists the all of the certificates installed on the subsystem. The following information is supplied for each certificate:
- Certificate Name
- Serial Number
- Issuer Names, the common name (
cn
) of the issuer of this certificate. - Token Name, the name of the cryptographic token holding the certificate; for certificate stored in the database, this is
internal
.
14.4.2.2. Viewing Database Content Using certutil
certutil
, open the instance's certificate database directory, and run the certutil
with the -L
option. For example:
cd /var/lib/pki/instance_name/alias certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-instance name u,u,u Server-Cert cert-instance_name u,u,u
certutil
, run the certutil
with the -K
option. For example:
cd /var/lib/pki/instance_name/alias certutil -K -d . Enter Password or Pin for "NSS Certificate DB": <0> subsystemCert cert-instance_name <1> <2> Server-Cert cert-instance_name
certutil
command, see http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html.
14.4.3. Deleting Certificates from the Database
Note
14.4.3.1. Deleting Certificates through the Console
- Open the subsystem console.
pkiconsole https://server.example.com:secure_port/subsystem_type
- In the Configuration tab, select System Keys and Certificates from the left navigation tree.
- Select the certificate to delete, and click.
- When prompted, confirm the delete.
14.4.3.2. Deleting Certificates Using certutil
certutil
:
- Open the instance's certificate databases directory.
/var/lib/pki/instance_name/alias
- List the certificates in the database by running the
certutil
with the-L
option. For example:certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-instance_name u,u,u Server-Cert cert-instance_name u,u,u
- Delete the certificate by running the
certutil
with the-D
option.certutil -D -d . -n certificate_nickname
For example:certutil -D -d . -n "ServerCert cert-instance_name"
- List the certificates again to confirm that the certificate was removed.
certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-instance_name u,u,u
certutil
command, see http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html.
14.5. Changing the Trust Settings of a CA Certificate
14.5.1. Changing Trust Settings through the Console
- Open the subsystem console.
pkiconsole https://server.example.com:secure_port/subsystem_type
- In the Configuration tab, System Keys and Certificates from the left navigation tree.
- Select the CA certificates tab.
- Select the CA certificate to modify, and click.
- A prompt opens which reads The Certificate chain is (un)trusted, are you sure you want to (un)trust it?Clicking yes changes the trust setting of the certificate chain; pressing no preserves the original trust relationship.
14.5.2. Changing Trust Settings Using certutil
certutil
, do the following:
- Open the instance's certificate databases directory.
cd /var/lib/pki/instance_name/alias
- List the certificates in the database by running the
certutil
with the-L
option. For example:certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-instance_name u,u,u Server-Cert cert-instance_name u,u,u
- Change the trust settings for the certificate by running the
certutil
with the-M
option.certutil -M -n cert_nickname -t trust -d .
For example:certutil -M -n "Certificate Authority - Example Domain" -t TCu,TCu,TCu -d .
- List the certificates again to confirm that the certificate trust was changed.
certutil -L -d . Certificate Authority - Example Domain CTu,CTu,CTu subsystemCert cert-instance_name u,u,u Server-Cert cert-instance_name u,u,u
certutil
command, see http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html.
14.6. Managing Tokens Used by the Subsystems
Note
14.6.1. Detecting Tokens
TokenInfo
utility.
TokenInfo /var/lib/pki/instance_name/alias Database Path: /var/lib/pki/instance_name/alias Found external module 'NSS Internal PKCS #11 Module'
14.6.2. Viewing Tokens
modutil
utility.
- Open the instance
alias
directory. For example:cd /var/lib/pki/instance_name/alias
- Show the information about the installed PKCS #11 modules installed as well as information on the corresponding tokens using the
modutil
tool.modutil -dbdir . -nocertdb -list
14.6.3. Changing a Token's Password
certutil
command-line utility.
certutil
, see http://www.mozilla.org/projects/security/pki/nss/tools/.
password.conf
file. This file must be manually updated every time the token password is changed.
Chapter 15. Setting Time and Date in Red Hat Enterprise Linux 7.6
timedatectl
utility is distributed as part of the systemd
system and service manager and allows you to review and change the configuration of the system clock.
Changing the Current Time
timedatectl set-time HH:MM:SS
Changing the Current Date
timedatectl set-time YYYY-MM-DD
Chapter 16. Determining Certificate System Product Version
/usr/share/pki/CS_SERVER_VERSION
file. To display the version:
# cat /usr/share/pki/CS_SERVER_VERSION Red Hat Certificate System 9.4 (Batch Update 3)
http://host_name:port_number/ca/admin/ca/getStatus
http://host_name:port_number/kra/admin/kra/getStatus
http://host_name:port_number/ocsp/admin/ocsp/getStatus
http://host_name:port_number/tks/admin/tks/getStatus
http://host_name:port_number/tps/admin/tps/getStatus
Note
Chapter 17. Updating Red Hat Certificate System
yum update
command. This downloads, verifies, and installs updates to Certificate System and operating system packages. For further information on updating Certificate System and validating that the update was successful, see Updating Certificate System Packages section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition).
Chapter 18. Troubleshooting
- Q: The init script returned an OK status, but my CA instance does not respond. Why?
- Q: I can't open the pkiconsole and I'm seeing Java exceptions in stdout.
- Q: I tried to run pkiconsole, and I got Socket exceptions in stdout. Why?
- Q: I tried to enroll for a certificate, and I got the error "request is not submitted...Subject Name Not Found"?
- Q: Why are my enrolled certificates not being published?
- Q: How do I open the pkiconsole utility from a remote host?
- Q: What do I do when the LDAP server is not responding?
catalina.out
, system
, and debug
log files for the instance to see what errors have occurred. This lists a couple of common errors.
catalina.out
file:
Oct 29, 2010 4:15:44 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-9080 java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:243) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:408) Caused by: java.lang.UnsatisfiedLinkError: jss4
libnss3.so
in the path. Check this with this command:
ldd /usr/lib64/libjss4.so
libnss3.so
is not found, try unsetting the LD_LIBRARY_PATH
variable and restart the CA.
unset LD_LIBRARY_PATH systemctl restart pki-tomcatd-nuxwdog@instance_name.service
pkiconsole
and I'm seeing Java exceptions in stdout.
alternatives --config java
to see what JRE is selected. Red Hat Certificate System requires OpenJDK 1.8.
pkiconsole
, and I got Socket exceptions in stdout. Why?
NSS Cipher Supported '0xff04' java.io.IOException: SocketException cannot read on socket at org.mozilla.jss.ssl.SSLSocket.read(SSLSocket.java:1006) at org.mozilla.jss.ssl.SSLInputStream.read(SSLInputStream.java:70) at com.netscape.admin.certsrv.misc.HttpInputStream.fill(HttpInputStream.java:303) at com.netscape.admin.certsrv.misc.HttpInputStream.readLine(HttpInputStream.java:224) at com.netscape.admin.certsrv.connection.JSSConnection.readHeader(JSSConnection.java:439) at com.netscape.admin.certsrv.connection.JSSConnection.initReadResponse(JSSConnection.java:430) at com.netscape.admin.certsrv.connection.JSSConnection.sendRequest(JSSConnection.java:344) at com.netscape.admin.certsrv.connection.AdminConnection.processRequest(AdminConnection.java:714) at com.netscape.admin.certsrv.connection.AdminConnection.sendRequest(AdminConnection.java:623) at com.netscape.admin.certsrv.connection.AdminConnection.sendRequest(AdminConnection.java:590) at com.netscape.admin.certsrv.connection.AdminConnection.authType(AdminConnection.java:323) at com.netscape.admin.certsrv.CMSServerInfo.getAuthType(CMSServerInfo.java:113) at com.netscape.admin.certsrv.CMSAdmin.run(CMSAdmin.java:499) at com.netscape.admin.certsrv.CMSAdmin.run(CMSAdmin.java:548) at com.netscape.admin.certsrv.Console.main(Console.java:1655)
debug
log. For example, this profile used a custom attribute (MYATTRIBUTE
) that the directory didn't recognize:
[14/Feb/2011:15:52:25][http-1244-Processor24]: BasicProfile: populate() policy setid =userCertSet [14/Feb/2011:15:52:25][http-1244-Processor24]: AuthTokenSubjectNameDefault: populate start [14/Feb/2011:15:52:25][http-1244-Processor24]: AuthTokenSubjectNameDefault: java.io.IOException: Unknown AVA keyword 'MYATTRIBUTE'. [14/Feb/2011:15:52:25][http-1244-Processor24]: ProfileSubmitServlet: populate Subject Name Not Found [14/Feb/2011:15:52:25][http-1244-Processor24]: CMSServlet: curDate=Mon Feb 14 15:52:25 PST 2011 id=caProfileSubmit time=13
debug
log, which can indicate where the misconfiguration is. For example, this has a problem with the mappers:
[31/Jul/2010:11:18:29][Thread-29]: LdapSimpleMap: cert subject dn:UID=me,E=me@example.com,CN=yes [31/Jul/2010:11:18:29][Thread-29]: Error mapping: mapper=com.netscape.cms.publish.mappers.LdapSimpleMap@258fdcd0 error=Cannot find a match in the LDAP server for certificate. netscape.ldap.LDAPException: error result (32); matchedDN = ou=people,c=test; No such object
ca.publish.mapper.instance.LdapUserCertMap.dnPattern=UID=$subj.UID,dc=publish
pkiconsole
utility from a remote host?
pkiconsole
on the Certificate System server from a remote host. For that, administrators can use a Virtual Network Computing (VNC) connection:
- Setup a VNC server, for example, on the Red Hat Certificate System server.
Important
Thepkiconsole
utility cannot run on a server with Federal Information Processing Standard (FIPS) mode enabled. Use a different host with Red Hat Enterprise Linux to run the VNC server, if FIPS mode is enabled on your Certificate System server.For details about installing a VNC server, see the VNC Server section in the Red Hat System Administrator's Guide. - Use a VNC viewer to connect to the host running the VNC server. For details, see the VNC Viewer section in the Red Hat System Administrator's Guide.
- Open the
pkiconsole
utility in the VNC window. For example:# pkiconsole https://server.example.com:8443/ca
Note
[02/Apr/2019:15:55:41][authorityMonitor]: authorityMonitor: failed to get LDAPConnection. Retrying in 1 second. [02/Apr/2019:15:55:42][authorityMonitor]: In LdapBoundConnFactory::getConn() [02/Apr/2019:15:55:42][authorityMonitor]: masterConn is null. [02/Apr/2019:15:55:42][authorityMonitor]: makeConnection: errorIfDown true [02/Apr/2019:15:55:42][authorityMonitor]: TCP Keep-Alive: true java.net.ConnectException: Connection refused (Connection refused) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) [02/Apr/2019:15:55:42][authorityMonitor]: Can't create master connection in LdapBoundConnFactory::getConn! Could not connect to LDAP server host example911.redhat.com port 389 Error netscape.ldap.LDAPException: Unable to create socket: java.net.ConnectException: Connection refused (Connection refused) (-1)
# systemctl stop pki-tomcatd-nuxwdog@instance_name.service
# systemctl start pki-tomcatd-nuxwdog@instance_name.service
Chapter 19. Subsystem Control And maintenance
19.1. Starting, Stopping, Restarting, and Obtaining Status
systemctl
utility on Red Hat Enterprise Linux 7.
# systemctl start unit_file@instance_name.service
# systemctl stop unit_file@instance_name.service
# systemctl restart unit_file@instance_name.service
# systemctl status unit_file@instance_name.service
pki-tomcat
: With watchdog disabledpki-tomcat-nuxwdog
: With watchdog enabled
19.2. Subsystem Health Check
- Audit failure caused by a full disk
- Signing failure caused by HSM connection issue
- LDAP server connection issues
- And so on
Part V. References
Appendix A. Certificate Profile Input and Output Reference
A.1. Input Reference
A.1.1. CMC Certificate Request Input
Example A.1.
caCMCUserCert.cfg:input.i1.class_id=cmcCertReqInputImpl
A.1.2. nsHKeyCertRequest (Token Key) Input
- Token Key CUID. This field gives the CUID (contextually unique user ID) for the token device.
- Token Key User Public Key. This field must contain the token user's public key.
Example A.2.
caTempTokenDeviceKeyEnrollment.cfg:input.i1.class_id=nsHKeyCertReqInputImpl
A.1.3. nsNKeyCertRequest (Token User Key) Input
- Token Key User UID. This field gives the UID for the LDAP entry of the user of the token device.
- Token Key User Public Key. This field must contain the token user's public key.
Example A.3.
caTempTokenUserEncryptionKeyEnrollment.cfg:input.i1.class_id=nsNKeyCertReqInputImpl
A.1.4. Subject DN Input
Example A.4.
caAdminCert.cfg:input.i3.class_id=subjectDNInputImpl
A.1.5. Subject Alternative Name Extension Input
req_san_pattern_#
into the input and therefore the SubjectAltNameExt
extension. For example, URI containing:
...&req_san_pattern_0=host0.Example.com&req_san_pattern_1=host1.Example.com
host0.Example.com
and host1.Example.com
into the SubjectAltNameExt
extension from the profile below.
Example A.5.
input.i3.class_id= input.i3.name=subjectAltNameExtInputImplsubjectAltNameExtInputImpl … policyset.serverCertSet.9.constraint.class_id=noConstraintImpl policyset.serverCertSet.9.constraint.name=No Constraint policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl policyset.serverCertSet.9.default.name=Subject Alternative Name Extension Default policyset.serverCertSet.9.default.params.subjAltExtGNEnable_0=true policyset.serverCertSet.9.default.params.subjAltExtPattern_0=$request.req_san_pattern_0$ policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName policyset.serverCertSet.9.default.params.subjAltExtGNEnable_1=true policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.req_san_pattern_1$ policyset.serverCertSet.9.default.params.subjAltExtType_1=DNSName policyset.serverCertSet.9.default.params.subjAltExtGNEnable_2=false policyset.serverCertSet.9.default.params.subjAltExtPattern_2=$request.req_san_pattern_2$ policyset.serverCertSet.9.default.params.subjAltExtType_2=DNSName policyset.serverCertSet.9.default.params.subjAltNameExtCritical=false policyset.serverCertSet.9.default.params.subjAltNameNumGNs=2
A.2. Output Reference
A.2.1. CMC Certificate Output
A.2.2. nsNSKeyOutput
Example A.6. caTokenUserDelegateAuthKeyEnrollment.cfg
output.list=o1 output.o1.class=nsNKeyOutputImpl
Appendix B. Defaults, Constraints, and Extensions for Certificates and CRLs
Important
B.1. Defaults Reference
B.1.1. Authority Info Access Extension Default
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
Method_n |
Specifies the access method for retrieving additional information about the CA that has issued the certificate in which the extension appears. This is one of the following values:
|
LocationType_n | Specifies the general name type for the location that contains additional information about the CA that has issued the certificate. This is one of the following types:
|
Location_n |
Specifies the address or location to get additional information about the CA that has issued the certificate.
|
Enable_n | Specifies whether this location is enabled. Select true to mark this as set; select false to disable it. |
B.1.2. Authority Key Identifier Extension Default
- No Constraints; see Section B.2.8, “No Constraint”.
B.1.3. Authentication Token Subject Name Default
- No Constraints; see Section B.2.8, “No Constraint”.
B.1.4. CMC User-signed Subject Name Default
subjectDN
. The following constraint must be used with this default:
CMCUserSignedSubjectNameConstraint
: See Section B.2.14, “CMC User-signed Subject Name Constraint”.
B.1.5. Basic Constraints Extension Default
- Basic Constraints Extension Constraint; see Section B.2.1, “Basic Constraints Extension Constraint”.
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
IsCA | Specifies whether the certificate subject is a CA. With true , the server checks the PathLen parameter and sets the specified path length in the certificate. With false , the server treats the certificate subject as a non-CA and ignores the value specified for the PathLen parameter. |
PathLen |
Specifies the path length, the maximum number of CA certificates that may be chained below (subordinate to) the subordinate CA certificate being issued. The path length affects the number of CA certificates to be used during certificate validation. The chain starts with the end-entity certificate being validated and moves up.
The
maxPathLen parameter has no effect if the extension is set in end-entity certificates.
The permissible values are
0 or n. The value should be less than the path length specified in the Basic Constraints extension of the CA signing certificate. 0 specifies that no subordinate CA certificates are allowed below the subordinate CA certificate; only an end-entity certificate may follow in the path. n must be an integer greater than zero. It specifies the maximum number of subordinate CA certificates allowed below the subordinate CA certificate.
If the field is blank, the path length defaults to a value that is determined by the path length set in the Basic Constraints extension in the issuer's certificate. If the issuer's path length is unlimited, the path length in the subordinate CA certificate will also be unlimited. If the issuer's path length is an integer greater than zero, the path length in the subordinate CA certificate will be set to a value that is one less than the issuer's path length; for example, if the issuer's path length is 4, the path length in the subordinate CA certificate will be set to 3.
|
B.1.6. CA Validity Default
- Validity Constraint; see Section B.2.15, “Validity Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
bypassCAnotafterrange | Sets the default value for whether a requesting CA can request a certificate whose validity period extends past the issuing CA's validity period. |
range | Specifies the absolute validity period for this certificate, in the number of days. |
startTime | Sets when the validity period begins, based on the current time. |
B.1.7. Certificate Policies Extension Default
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
numCertPolicies | Specifies the number of policies that can be defined. The default is 5 . |
enable | Select true to enable the policy; select false to disable the policy. |
policyId | Specifies the OID identifier for the policy. |
cpsURI.enable | The extension can include a URI to the issuer's Certificate Practice Statement. Select true to enable URI; select false to disable URI. |
CPSURI.value | This value is a pointer to a Certification Practice Statement (CPS) published by the CA. The pointer is in the form of a URI. |
usernotice.enable | The extension can include a URI to the issuer's Certificate Practice Statement or can embed issuer information, such as a user notice in text form. Select true to enable user notices; select false to disable the user notices. |
usernotice.noticeReference.noticeNumbers | This optional user notice parameter is a sequence of numbers that points to messages stored elsewhere. |
usernotice.noticeReference.organization | This optional user notice parameter specifies the name of the company. |
usernotice.explicitText.value | This optional user notice parameter contains the message within the certificate. |
B.1.8. CRL Distribution Points Extension Default
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
Type_n | Specifies the type of CRL distribution point. The permissible values are DirectoryName , URIName , or RelativeToIssuer . The type must correspond to the value in the Name field. |
Name_n |
Specifies the name of the CRL distribution point, the name can be in any of the following formats:
|
Reasons_n |
Specifies revocation reasons covered by the CRL maintained at the distribution point. Provide a comma-separated list of the following constants:
|
IssuerType_n |
Specifies the naming type of the issuer that has signed the CRL maintained at the distribution point. The issuer name can be in any of the following formats:
|
IssuerName_n |
Specifies the name format of the CRL issuer that signed the CRL. The permissible values are as follows:
The value for this parameter must correspond to the value in the
issuerName field.
|
B.1.9. Extended Key Usage Extension Default
Usage | OID |
---|---|
Server authentication | 1.3.6.1.5.5.7.3.1 |
Client authentication | 1.3.6.1.5.5.7.3.2 |
Code signing | 1.3.6.1.5.5.7.3.3 |
1.3.6.1.5.5.7.3.4 | |
IPsec end system | 1.3.6.1.5.5.7.3.5 |
IPsec tunnel | 1.3.6.1.5.5.7.3.6 |
IPsec user | 1.3.6.1.5.5.7.3.7 |
Timestamping | 1.3.6.1.5.5.7.3.8 |
- Extended Key Usage Constraint; see Section B.2.3, “Extended Key Usage Extension Constraint”.
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
OIDs | Specifies the OID that identifies a key-usage purpose. The permissible values are a unique, valid OID specified in the dot-separated numeric component notation. For example, 2.16.840.1.113730.1.99. Depending on the key-usage purposes, the OIDs can be designated by PKIX (listed in Table B.6, “PKIX Usage Definitions for the Extended Key Usage Extension”) or custom OIDs. Custom OIDs must be in the registered subtree of IDs reserved for the company's use. Although it is possible to use custom OIDs for evaluating and testing the Certificate System, in a production environment, comply with the ISO rules for defining OIDs and for registering subtrees of IDs. |
B.1.10. Freshest CRL Extension Default
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
PointEnable_n | Select true to enable this point; select false to disable this point. |
PointType_n | Specifies the type of issuing point, either DirectoryName or URIName . |
PointName_n |
|
PointIssuerName_n |
Specifies the name of the issuer that has signed the CRL. The name can be in any of the following formats:
The name value must comply with the format specified in
PointType_ .
|
PointType_n | Specifies the general name type of the CRL issuer that signed the CRL. The permissible values are as follows:
PointIssuerName field. |
B.1.11. Generic Extension Default
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
genericExtOID | Specifies the extensions OID identifier. |
genericExtData | The binary data contained within the extension. |
B.1.12. Inhibit Any-Policy Extension Default
Parameter | Description |
---|---|
Critical | This policy must be marked as critical. Select true to mark this extension critical; select false to mark the extension noncritical. |
SkipCerts | This parameter indicate the number of additional certificates that may appear in the path before any-policy is no longer allowed. A value of 1 indicates that any-policy may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path. |
B.1.13. Issuer Alternative Name Extension Default
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
issuerAltExtType | This sets the type of name extension to be used, which can be one of the following:
|
issuerAltExtPattern |
Specifies the request attribute value to include in the extension. The attribute value must conform to any of the supported general name types. The permissible value is a request attribute included in the certificate request.
If the server finds the attribute in the request, it sets the attribute value in the extension and adds the extension to certificates. If multiple attributes are specified and none of the attributes are present in the request, the server does not add the Issuer Alternative Name extension to certificates. If no suitable attributes can be used from the request to form the issuerAlternativeName, then literal string can be used without any token expression. For example, Certificate Authority.
|
B.1.14. Key Usage Extension Default
- Key Usage Constraint; see Section B.2.6, “Key Usage Extension Constraint”.
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
digitalSignature | Specifies whether to allow signing TLS client certificates and S/MIME signing certificates. Select true to set. |
nonRepudiation | Specifies whether to use for S/MIME signing certificates. Select true to set.
Warning
Using this bit is controversial. Carefully consider the legal consequences of its use before setting it for any certificate.
|
keyEncipherment | Specifies whether the public key in the subject is used to encipher private or secret keys. This is set for TLS server certificates and S/MIME encryption certificates. Select true to set. |
dataEncipherment | Specifies whether to set the extension when the subject's public key is used to encipher user data as opposed to key material. Select true to set. |
keyAgreement | Specifies whether to set the extension whenever the subject's public key is used for key agreement. Select true to set. |
keyCertsign | Specifies whether the public key is used to verify the signature of other certificates. This setting is used for CA certificates. Select true to set the option. |
cRLSign | Specifies whether to set the extension for CA signing certificates that sign CRLs. Select true to set. |
encipherOnly | Specifies whether to set the extension if the public key is only for encrypting data while performing key agreement. If this bit is set, keyAgreement should also be set. Select true to set. |
decipherOnly | Specifies whether to set the extension if the public key is only for decrypting data while performing key agreement. If this bit is set, keyAgreement should also be set. Select true to set. |
B.1.15. Name Constraints Extension Default
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
PermittedSubtreesn.min |
Specifies the minimum number of permitted subtrees.
|
PermittedSubtreesmax_n |
Specifies the maximum number of permitted subtrees.
|
PermittedSubtreeNameChoice_n | Specifies the general name type for the permitted subtree to include in the extension. The permissible values are as follows:
|
PermittedSubtreeNameValue_n |
Specifies the general name value for the permitted subtree to include in the extension.
|
PermittedSubtreeEnable_n | Select true to enable this permitted subtree entry. |
ExcludedSubtreesn.min |
Specifies the minimum number of excluded subtrees.
|
ExcludedSubtreeMax_n |
Specifies the maximum number of excluded subtrees.
|
ExcludedSubtreeNameChoice_n | Specifies the general name type for the excluded subtree to include in the extension. The permissible values are as follows:
|
ExcludedSubtreeNameValue_n |
Specifies the general name value for the permitted subtree to include in the extension.
|
ExcludedSubtreeEnable_n | Select true to enable this excluded subtree entry. |
B.1.16. Netscape Certificate Type Extension Default
Warning
B.1.17. Netscape Comment Extension Default
Warning
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
CommentContent | Specifies the content of the comment to appear in the certificate. |
B.1.18. No Default Extension
B.1.19. OCSP No Check Extension Default
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
B.1.20. Policy Constraints Extension Default
ReqExplicitPolicy
and InhibitPolicyMapping
. PKIX standard requires that, if present in the certificate, the extension must never consist of a null sequence. At least one of the two specified fields must be present.
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
reqExplicitPolicy |
Specifies the total number of certificates permitted in the path before an explicit policy is required. This is the number of CA certificates that can be chained below the subordinate CA certificate before an acceptable policy is required.
This number affects the number of CA certificates to be used during certificate validation. The chain starts with the end-entity certificate being validated and moving up the chain. The parameter has no effect if the extension is set in end-entity certificates.
|
inhibitPolicyMapping |
Specifies the total number of certificates permitted in the path before policy mapping is no longer permitted.
|
B.1.21. Policy Mappers Extension Default
issuerDomainPolicy
and subjectDomainPolicy
. The pairing indicates that the issuing CA considers the issuerDomainPolicy
equivalent to the subjectDomainPolicy
of the subject CA. The issuing CA's users may accept an issuerDomainPolicy
for certain applications. The policy mapping tells these users which policies associated with the subject CA are equivalent to the policy they accept.
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
IssuerDomainPolicy_n | Specifies the OID assigned to the policy statement of the issuing CA to map with the policy statement of another CA. For example, 1.2.3.4.5. |
SubjectDomainPolicy_n | Specifies the OID assigned to the policy statement of the subject CA that corresponds to the policy statement of the issuing CA. For example, 6.7.8.9.10. |
B.1.22. Private Key Usage Period Extension Default
Parameter | Description |
---|---|
Critical | This extension should always be non-critical. |
puStartTime | This parameters sets the start time. The default value is 0 , which starts the validity period from the time the extension is activated. |
puDurationDays | This parameters sets the duration of the usage period. The default value is 365 , which sets the validity period to 365 days from the time the extension is activated. |
B.1.23. Signing Algorithm Default
- Signing Algorithm Constraint; see Section B.2.10, “Signing Algorithm Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
signingAlg | Specify the default signing algorithm to be used to create this certificate. An agent can override this value by specifying one of the values contained in the signingAlgsAllowed parameter. |
signingAlgsAllowed | Specify the signing algorithms that can be used for signing this certificate. The algorithms can be any or all of the following:
|
B.1.24. Subject Alternative Name Extension Default
ldapStringAttributes
and ldapByteAttributes
fields defined in the automated enrollment modules.
$request.
X$
token.
subjAltExtSource
parameter.
Example B.1. Default Subject Alternative Name Extension Configuration
policyset.serverCertSet.9.constraint.name=No Constraint policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl policyset.serverCertSet.9.default.name=Subject Alternative Name Extension Default policyset.serverCertSet.9.default.params.subjAltExtGNEnable_0=true policyset.serverCertSet.9.default.params.subjAltExtPattern_0=$request.requester_email$ policyset.serverCertSet.9.default.params.subjAltExtType_0=RFC822Name policyset.serverCertSet.9.default.params.subjAltExtGNEnable_1=true policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.SAN1$ policyset.serverCertSet.9.default.params.subjAltExtType_1=DNSName policyset.serverCertSet.9.default.params.subjAltExtGNEnable_2=true policyset.serverCertSet.9.default.params.subjAltExtPattern_2=http://www.server.example.com policyset.serverCertSet.9.default.params.subjAltExtType_2=URIName policyset.serverCertSet.9.default.params.subjAltExtType_3=OtherName policyset.serverCertSet.9.default.params.subjAltExtPattern_3=(IA5String)1.2.3.4,$server.source$ policyset.serverCertSet.9.default.params.subjAltExtSource_3=UUID4 policyset.serverCertSet.9.default.params.subjAltExtGNEnable_3=true policyset.serverCertSet.9.default.params.subjAltExtType_4=RFC822Name policyset.serverCertSet.9.default.params.subjAltExtGNEnable_4=false policyset.serverCertSet.9.default.params.subjAltExtPattern_4= policyset.serverCertSet.9.default.params.subjAltNameExtCritical=false policyset.serverCertSet.9.default.params.subjAltNameNumGNs=4
Policy Set Token | Description |
---|---|
$request.auth_token.cn$ | The LDAP common name (cn ) attribute of the user who requested the certificate. |
$request.auth_token.mail$ | The value of the LDAP email (mail ) attribute of the user who requested the certificate. |
$request.auth_token.tokenCertSubject$ | The certificate subject name. |
$request.auth_token.uid$ | The LDAP user ID (uid ) attribute of the user who requested the certificate. |
$request.auth_token.user$ | |
$request.auth_token.userDN$ | The user DN of the user who requested the certificate. |
$request.auth_token.userid$ | The value of the user ID attribute for the user who requested the certificate. |
$request.uid$ | The value of the user ID attribute for the user who requested the certificate. |
$request.profileRemoteAddr$ | The IP address of the user making the request. This can be an IPv4 or an IPv6 address, depending on the client. An IPv4 address must be in the format n.n.n.n or n.n.n.n,m.m.m.m. For example, 128.21.39.40 or 128.21.39.40,255.255.255.00. An IPv6 address uses a 128-bit namespace, with the IPv6 address separated by colons and the netmask separated by periods. For example, 0:0:0:0:0:0:13.1.68.3, FF01::43, 0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0, and FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000. |
$request.profileRemoteHost$ | The hostname or IP address of the user's machine. The hostname can be the fully-qualified domain name and the protocol, such as http://server.example.com . An IPv4 address must be in the format n.n.n.n or n.n.n.n,m.m.m.m. For example, 128.21.39.40 or 128.21.39.40,255.255.255.00. An IPv6 address uses a 128-bit namespace, with the IPv6 address separated by colons and the netmask separated by periods. For example, 0:0:0:0:0:0:13.1.68.3, FF01::43, 0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0, and FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000. |
$request.requestor_email$ | The email address of the person who submitted the request. |
$request.requestowner$ | The person who submitted the request. |
$request.subject$ | The subject name DN of the entity to which the certificate is issued. For example, uid=jsmith, e=jsmith@example.com. |
$request.tokencuid$ | The card unique ID (CUID) of the smart card token used for requesting the enrollment. |
$request.upn$ | The Microsoft UPN. This has the format (UTF8String)1.3.6.1.4.1.311.20.2.3,$request.upn$. |
$server.source$ | Instructs the server to generate a version 4 UUID (random number) component in the subject name. This always has the format (IA5String)1.2.3.4,$server.source$. |
subjAltNameNumGNs
parameter controls how many of the listed attributes are required to be added to the certificate. This parameter must be added to custom profiles and may need modified in default profiles to include as many attributes as required. In Example B.1, “Default Subject Alternative Name Extension Configuration”, the subjAltNameNumGNs
is set to 3
to insert the RFC822Name
, DNSName
, and URIName
names (generic names _0
, _1
, and _2
).
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
Pattern | Specifies the request attribute value to include in the extension. The attribute value must conform to any of the supported general name types. If the server finds the attribute in the request, it sets the attribute value in the extension and adds the extension to certificates. If multiple attributes are specified and none of the attributes are present in the request, the server does not add the Subject Alternative Name extension to certificates. The permissible value is a request attribute included in the certificate request. For example, $request.requester_email$. |
Type |
Specifies the general name type for the request attribute.
|
Source | Specifies an identification source or protocol to use to generate an ID. The only supported source is UUID4, which generates a random number to create the UUID. |
Number of Components (NumGNs) | Specifies the number of name components that must be included in the subject alternative name. |
B.1.25. Subject Directory Attributes Extension Default
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Critical | Select true to mark this extension critical; select false to mark the extension noncritical. |
Name | The attribute name; this can be any LDAP directory attribute, such as cn or mail . |
Pattern | Specifies the request attribute value to include in the extension. The attribute value must conform to the allowed values of the attribute. If the server finds the attribute, it sets the attribute value in the extension and adds the extension to certificates. If multiple attributes are specified and none of the attributes are present in the request, the server does not add the Subject Directory Attributes extension to certificates. For example, $request.requester_email$. |
Enable | Sets whether that attribute is able to be added to the certificate. Select true to enable the attribute. |
B.1.26. Subject Info Access Extension Default
Parameter | Description |
---|---|
Critical | This extension is supposed to be non-critical. |
subjInfoAccessNumADs | The number of information access sections included with the certificate. |
subjInfoAccessADMethod_n | OID of the access method. |
subjInfoAccessADMethod_n | Type of access method.
|
subjInfoAccessADLocation_n |
Location based on the type subjInfoAccessADMethod_n
i.e., a URL for URI Name.
|
subjInfoAccessADEnable_n | Select true to enable this extension; select false to disable this extension. |
B.1.27. Subject Key Identifier Extension Default
- Extension Constraint; see Section B.2.4, “Extension Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
B.1.28. Subject Name Default
- Subject Name Constraint; see Section B.2.11, “Subject Name Constraint”.
- Unique Subject Name Constraint; see Section B.2.13, “Unique Subject Name Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
Name | Specify the subject name for this certificate. |
Name
parameter with the "Subject Name" from the AuthToken as shown below.
policyset.userCertSet.1.default.class_id=subjectNameDefaultImpl policyset.userCertSet.1.default.name=Subject Name Default policyset.userCertSet.1.default.params.name=$request.auth_token.tokenCertSubject$
B.1.29. User Key Default
- Key Constraint; see Section B.2.5, “Key Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
B.1.30. User Signing Algorithm Default
- Signing Algorithm Constraint; see Section B.2.10, “Signing Algorithm Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
B.1.31. User Subject Name Default
- Subject Name Constraint; see Section B.2.11, “Subject Name Constraint”.
- Unique Subject Name Constraint; see Section B.2.13, “Unique Subject Name Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
B.1.32. User Validity Default
- Validity Constraint; see Section B.2.15, “Validity Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
B.1.33. User Supplied Extension Default
Warning
- If the OID of the extension is specified in both the certificate request and the default, then the extension is validated by the constraints and applied to the certificate.
- If an OID of an extension is given in the request but is not specified in the User Supplied Extension Default in the profile, then the user-specified extension is ignored, and the certificate is successfully enrolled without that extension.
- If this extension is set on a profile with a corresponding OID (Extension Constraint), then any certificate request processed through that profile must carry the specified extension or the request is rejected.
userExtOID
parameter is for the Extended Key Usage Extension.
Example B.2. User Supplied Extension Default for the Extended Key Usage Extension
policyset.set1.2.constraint.class_id=extendedKeyUsageExtConstraintImpl policyset.set1.2.constraint.name=Extended Key Usage Extension policyset.set1.2.constraint.params.exKeyUsageCritical=false policyset.set1.2.constraint.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.4 policyset.set1.2.default.class_id=userExtensionDefaultImpl policyset.set1.2.default.name=User Supplied Extension Default policyset.set1.2.default.params.userExtOID=2.5.29.37
Example B.3. Multiple User Supplied Extensions in CSR
- For Extended Key Usage Extension:
policyset.serverCertSet.2.constraint.class_id=extendedKeyUsageExtConstraintImpl policyset.serverCertSet.2.constraint.name=Extended Key Usage Extension policyset.serverCertSet.2.constraint.params.exKeyUsageCritical=false policyset.serverCertSet.2.constraint.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.4 policyset.serverCertSet.2.default.class_id=userExtensionDefaultImpl policyset.serverCertSet.2.default.name=User Supplied Extension Default policyset.serverCertSet.2.default.params.userExtOID=2.5.29.37
- For Key Usage Extension:By using the following format, you can apply a policy which parameter of the extension:
- Must exist in the CSR:
value = "true"
- Must not exist in the CSR:
value = "false"
- Is optional:
value = "-"
For example:policyset.serverCertSet.13.constraint.class_id=keyUsageExtConstraintImpl policyset.serverCertSet.13.constraint.name=Key Usage Extension Constraint policyset.serverCertSet.13.constraint.params.keyUsageCritical=- policyset.serverCertSet.13.constraint.params.keyUsageCrlSign=false policyset.serverCertSet.13.constraint.params.keyUsageDataEncipherment=- policyset.serverCertSet.13.constraint.params.keyUsageDecipherOnly=- policyset.serverCertSet.13.constraint.params.keyUsageDigitalSignature=- policyset.serverCertSet.13.constraint.params.keyUsageEncipherOnly=- policyset.serverCertSet.13.constraint.params.keyUsageKeyAgreement=true policyset.serverCertSet.13.constraint.params.keyUsageKeyCertSign=- policyset.serverCertSet.13.constraint.params.keyUsageKeyEncipherment=- policyset.serverCertSet.13.constraint.params.keyUsageNonRepudiation=- policyset.serverCertSet.13.default.class_id=userExtensionDefaultImpl policyset.serverCertSet.13.default.name=User Supplied Key Usage Extension policyset.serverCertSet.13.default.params.userExtOID=2.5.29.15
Note
certutil
to Create a CSR With User-defined Extensions”.
B.1.34. Validity Default
- Validity Constraint; see Section B.2.15, “Validity Constraint”.
- No Constraints; see Section B.2.8, “No Constraint”.
Parameter | Description |
---|---|
range | Specifies the validity period for this certificate. |
startTime | Sets when the validity period begins, based on the current time. |
B.2. Constraints Reference
B.2.1. Basic Constraints Extension Constraint
Parameter | Description |
---|---|
basicConstraintsCritical | Specifies whether the extension can be marked critical or noncritical. Select true to mark this extension critical; select false to prevent this extension from being marked critical. Selecting a hyphen - , implies no criticality preference. |
basicConstraintsIsCA | Specifies whether the certificate subject is a CA. Select true to require a value of true for this parameter (is a CA); select false to disallow a value of true for this parameter; select a hyphen, - , to indicate no constraints are placed for this parameter. |
basicConstraintsMinPathLen |
Specifies the minimum allowable path length, the maximum number of CA certificates that may be chained below (subordinate to) the subordinate CA certificate being issued. The path length affects the number of CA certificates used during certificate validation. The chain starts with the end-entity certificate being validated and moves up.
This parameter has no effect if the extension is set in end-entity certificates.
The permissible values are
0 or n . The value must be less than the path length specified in the Basic Constraints extension of the CA signing certificate.
0 specifies that no subordinate CA certificates are allowed below the subordinate CA certificate being issued; only an end-entity certificate may follow in the path.
n must be an integer greater than zero. This is the minimun number of subordinate CA certificates allowed below the subordinate CA certificate being used.
|
basicConstraintsMaxPathLen |
Specifies the maximum allowable path length, the maximum number of CA certificates that may be chained below (subordinate to) the subordinate CA certificate being issued. The path length affects the number of CA certificates used during certificate validation. The chain starts with the end-entity certificate being validated and moves up.
This parameter has no effect if the extension is set in end-entity certificates.
The permissible values are
0 or n. The value must be greater than the path length specified in the Basic Constraints extension of the CA signing certificate.
0 specifies that no subordinate CA certificates are allowed below the subordinate CA certificate being issued; only an end-entity certificate may follow in the path.
n must be an integer greater than zero. This is the maximum number of subordinate CA certificates allowed below the subordinate CA certificate being used.
If the field is blank, the path length defaults to a value determined by the path length set on the Basic Constraints extension in the issuer's certificate. If the issuer's path length is unlimited, the path length in the subordinate CA certificate is also unlimited. If the issuer's path length is an integer greater than zero, the path length in the subordinate CA certificate is set to a value one less than the issuer's path length; for example, if the issuer's path length is 4, the path length in the subordinate CA certificate is set to 3.
|
B.2.2. CA Validity Constraint
B.2.3. Extended Key Usage Extension Constraint
Important
Parameter | Description |
---|---|
exKeyUsageCritical | When set to true , the extension can be marked as critical. When set to false , the extension can be marked noncritical. |
exKeyUsageOIDs | Specifies the allowable OIDs that identifies a key-usage purpose. Multiple OIDs can be added in a comma-separated list. |
B.2.4. Extension Constraint
Parameter | Description |
---|---|
extCritical | Specifies whether the extension can be marked critical or noncritical. Select true to mark the extension critical; select false to mark it noncritical. Select - to enforce no preference. |
extOID | The OID of an extension that must be present in the cert to pass the constraint. |
B.2.5. Key Constraint
KeyParameters
parameter contains a comma-separated list of legal key sizes, and with EC Keys the KeyParameters
parameter contains a comma-separated list of available ECC curves.
Parameter | Description |
---|---|
keyType | Gives a key type; this is set to - by default and uses an RSA key system. The choices are rsa and ec. If the key type is specified and not identified by the system, the constraint will be rejected. |
KeyParameters | Defines the specific key parameters. The parameters which are set for the key differe, depending on the value of the keyType parameter (meaning, depending on the key type).
|
B.2.6. Key Usage Extension Constraint
Important
Parameter | Description |
---|---|
keyUsageCritical | Select true to mark this extension critical; select false to mark it noncritical. Select - for no preference. |
keyUsageDigitalSignature | Specifies whether to sign TLS client certificates and S/MIME signing certificates. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter. |
kleyUsageNonRepudiation | Specifies whether to set S/MIME signing certificates. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter.
Warning
Using this bit is controversial. Carefully consider the legal consequences of its use before setting it for any certificate.
|
keyEncipherment | Specifies whether to set the extension for TLS server certificates and S/MIME encryption certificates. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter. |
keyUsageDataEncipherment | Specifies whether to set the extension when the subject's public key is used to encrypt user data, instead of key material. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter. |
keyUsageKeyAgreement | Specifies whether to set the extension whenever the subject's public key is used for key agreement. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter. |
keyUsageCertsign | Specifies whether the extension applies for all CA signing certificates. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter. |
keyUsageCRLSign | Specifies whether to set the extension for CA signing certificates that are used to sign CRLs. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter. |
keyUsageEncipherOnly | Specifies whether to set the extension if the public key is to be used only for encrypting data. If this bit is set, keyUsageKeyAgreement should also be set. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter. |
keyUsageDecipherOnly | Specifies whether to set the extension if the public key is to be used only for deciphering data. If this bit is set, keyUsageKeyAgreement should also be set. Select true to mark this as set; select false to keep this from being set; select a hyphen, - , to indicate no constraints are placed for this parameter. |
B.2.7. Netscape Certificate Type Extension Constraint
Warning
B.2.8. No Constraint
B.2.9. Renewal Grace Period Constraint
Parameter | Description |
---|---|
renewal.graceAfter | Sets the period, in days, after the certificate expires that it can be submitted for renewal. If the certificate has been expired longer that that time, then the renewal request is rejected. If no value is given, there is no limit. |
renewal.graceBefore | Sets the period, in days, before the certificate expires that it can be submitted for renewal. If the certificate is not that close to its expiration date, then the renewal request is rejected. If no value is given, there is no limit. |
B.2.10. Signing Algorithm Constraint
Parameter | Description |
---|---|
signingAlgsAllowed | Sets the signing algorithms that can be specified to sign the certificate. The algorithms can be any or all of the following:
|
B.2.11. Subject Name Constraint
Parameter | Description |
---|---|
Pattern | Specifies a regular expression or other string to build the subject DN. |
The regular expression for the Subject Name Constraint is matched by the Java facility for matching regular expressions. The format for these regular expressions are listed in https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html. This allows wildcards such as asterisks (*
) to search for any number of the characters and periods (.
) to search for any type character.
uid=.*
, the certificate profile framework checks if the subject name in the certificate request matches the pattern. A subject name like uid=user, o=Example, c=US
satisfies the pattern uid=.*
. The subject name cn=user, o=example,c=US
does not satisfy the pattern. uid=.*
means the subject name must begin with the uid
attribute; the period-asterisk (.*
) wildcards allow any type and number of characters to follow uid
.
.*ou=Engineering.*
, which requires the ou=Engineering
attribute with any kind of string before and after it. This matches cn=jdoe,ou=internal,ou=west coast,ou=engineering,o="Example Corp",st=NC
as well as uid=bjensen,ou=engineering,dc=example,dc=com
.
|
) between the options. For example, to permit subject names that contain either ou=engineering,ou=people
or ou=engineering,o="Example Corp"
, the pattern is .*ou=engineering,ou=people.* | .*ou=engineering,o="Example Corp".*
.
Note
.
), escape the character with a back slash (\
). For example, to search for the string o="Example Inc."
, set the pattern to o="Example Inc\."
.
The pattern that is used to build the subject DN can also be based on the CN or UID of the person requesting the certificate. The Subject Name Constraint sets the patter of the CN (or UID) to recognize in the DN of the certificate request, and then the Subject Name Default builds on that CN to create the subject DN of the certificate, using a predefined directory tree.
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.serverCertSet.1.constraint.name=Subject Name Constraint policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl policyset.serverCertSet.1.default.name=Subject Name Default policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,DC=example, DC=com
B.2.12. Unique Key Constraint
Parameter | Description |
---|---|
allowSameKeyRenewal |
A request is considered a renewal and is accepted if this parameter is set to
true , if a public key is not unique, and if the subject DN matches an existing certificate. However, if the public key is a duplicate and does not match an existing Subject DN, the request is rejected.
When the parameter is set to
false , a duplicate public key request will be rejected.
|
B.2.13. Unique Subject Name Constraint
Parameter | Description |
---|---|
enableKeyUsageExtensionChecking | Optional setting which allows certificates to have the same subject name as long as their key usage settings are different. This is either true or false . The default is true , which allows duplicate subject names. |
B.2.14. CMC User-signed Subject Name Constraint
CMCUserSignedSubjectNameDefault
.
B.2.15. Validity Constraint
notBefore
parameter that provides a time which has already passed will not be accepted, and a notAfter
parameter that provides a time earlier than the notBefore
time will not be accepted.
Parameter | Description |
---|---|
range | The range of the validity period. This is an integer which sets the number of days. The difference (in days) between the notBefore time and the notAfter time must be less than the range value, or this constraint will be rejected. |
notBeforeCheck | Verifies that the range is not within the grace period. When the NotBeforeCheck Boolean parameter is set to true, the system will check the notBefore time is not greater than the current time plus the notBeforeGracePeriod value. If the notBeforeTime is not between the current time and the notBeforeGracePeriod value, this constraint will be rejected. |
notBeforeGracePeriod | The grace period (in seconds) after the notBefore time. If the notBeforeTime is not between the current time and the notBeforeGracePeriod value, this constraint will be rejected. This constraint is only checked if the notBeforeCheck parameter has been set to true. |
notAfterCheck | Verfies whether the given time is not after the expiration period. When the notAfterCheck Boolean parameter is set to true, the system will check the notAfter time is not greater than the current time. If the current time exceeds the notAfter time, this constraint will be rejected. |
B.3. Standard X.509 v3 Certificate Extension Reference
0x2
(which corresponds to version 3).
Example B.4. Sample Pretty-Print Certificate Extensions
Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE" Validity: Not Before: Fri Feb 22 19:06:56 2019 Not After : Tue Feb 22 19:06:56 2039 Subject: "CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: dd:6d:ad:02:10:43:12:ad:ec:6c:10:82:b3:bc:ec:6d: 4b:e9:46:bc:a3:19:63:15:86:cf:6d:62:43:92:6b:a6: 3d:72:54:4b:4f:d5:ad:a9:1d:76:8d:1c:e9:15:24:10: a1:03:1e:1b:14:5e:08:0a:0f:5b:02:aa:e9:3f:85:e1: d4:a6:01:1e:58:ab:7b:f2:67:32:f4:95:3d:35:9c:76: 3a:cb:3b:ef:e3:7d:32:04:bb:35:46:68:bd:21:0c:16: b6:63:aa:e7:bb:cd:0f:55:66:21:09:e6:a6:f7:4c:fd: af:c8:a6:d1:98:03:aa:89:b8:76:e7:dd:df:2b:23:c5: b3:06:16:1d:4a:13:8b:0b:56:0c:d5:a2:9a:22:5e:7d: 08:af:e4:bf:a0:f6:28:ee:ae:0f:2c:b2:4d:2a:09:5b: 6f:32:2e:05:3a:3b:92:5d:d6:1d:69:95:09:0d:f4:b8: 52:ac:48:0f:a8:4f:0a:22:1b:01:4c:d2:79:89:e0:bc: cd:1c:84:f8:88:e6:92:16:ed:08:ad:6d:9c:17:8d:70: 92:bd:18:74:1a:31:5f:9b:f7:eb:f7:6e:f8:9a:e6:37: fe:7a:c6:07:9b:8a:6c:e8:5b:77:7c:37:e0:66:39:72: 62:5d:5d:d0:65:a2:d9:b0:7f:d3:ba:ed:4b:42:89:47 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 88:fb:c7:45:a8:b8:e9:74:ab:71:a2:ab:ce:4e:26:b9: a5:97:dc:05 Name: Certificate Basic Constraints Critical: True Data: Is a CA with no maximum path length. Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Certificate Signing CRL Signing Name: Certificate Subject Key ID Data: 88:fb:c7:45:a8:b8:e9:74:ab:71:a2:ab:ce:4e:26:b9: a5:97:dc:05 Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://localhost.localdomain:8080/ca/ocsp" Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 6b:ed:d8:2b:de:40:a4:14:dd:e8:ce:52:2d:40:0a:f1: 88:57:36:3b:7f:c4:e8:77:2b:95:e9:60:fd:57:9b:c2: 2d:17:a2:67:4e:c0:23:00:7a:2c:ef:5f:12:13:05:cc: 9e:d7:4f:70:55:68:88:eb:29:34:94:cd:59:a6:92:31: c6:36:74:dd:e5:a2:1f:b1:9e:6d:f0:41:95:c2:7f:4c: 38:46:62:d9:f3:27:f4:a3:a7:f3:a2:ba:1c:e5:77:4a: d3:2d:50:10:47:03:2e:4f:f2:ef:75:92:36:d8:99:6d: f6:ef:f5:ee:17:70:c2:e0:c1:a1:26:fa:00:e2:ec:35: d5:11:4d:df:66:8d:3c:84:fa:72:ff:47:a5:95:08:c2: 80:e6:19:60:ab:51:d6:f1:aa:ac:72:77:d0:01:97:1f: 13:f0:c9:55:09:4d:d9:62:5b:bc:4a:21:5a:af:77:cb: 4e:cf:48:aa:3d:fc:f6:5e:c8:e2:e0:e3:58:58:40:39: 2b:9c:15:d3:65:62:d0:96:1b:35:3f:6e:35:96:ae:36: c2:6c:2b:46:e8:a3:d3:52:21:f0:47:5a:73:5e:1a:b0: 99:2f:5d:1b:bc:a1:81:65:68:16:08:e8:3e:2f:5e:32: 79:ca:8e:25:e5:78:a1:fc:cd:c0:b3:aa:83:02:18:43 Fingerprint (SHA-256): 2B:2F:05:59:12:F7:A4:6D:DE:22:43:82:59:EC:9F:45:AD:6C:1E:0A:63:6B:79:57:B1:34:3E:1B:BA:D2:13:AC Fingerprint (SHA1): E1:87:42:85:AF:07:6C:B2:5F:07:CB:50:4D:49:17:AB:43:99:31:F7 Mozilla-CA-Policy: false (attribute missing) Certificate Trust Flags: SSL Flags: Valid CA Trusted CA Trusted Client CA Email Flags: Valid CA Trusted CA Object Signing Flags:
Netscape Certificate Comment
is 2.16.840.1.113730.1.13. The OID assigned to this extension is hierarchical and includes the former Netscape company arc, 2.16.840.1
. The OID definition entry is http://www.alvestrand.no/objectid/2.16.840.1.113730.1.13.html.
B.3.1. authorityInfoAccess
accessMethod
and an accessLocation
field. accessMethod
specifies by OID the type and format of information about the issuer named in accessLocation
.
accessMethod
(id-ad-caIssuers
) to get a list of CAs that have issued certificates higher in the CA chain than the issuer of the certificate using the extension. The accessLocation
field then typically contains a URL indicating the location and protocol (LDAP, HTTP, or FTP) used to retrieve the list.
id-ad-ocsp
) for using OCSP to verify certificates. The accessLocation
field then contains a URL indicating the location and protocol used to access an OCSP responder that can validate the certificate.
1.3.6.1.5.5.7.1.1
This extension must be noncritical.
B.3.2. authorityKeyIdentifier
- An explicit key identifier, set in the
keyIdentifier
field - An issuer, set in the
authorityCertIssuer
field, and serial number, set in theauthorityCertSerialNumber
field, identifying a certificate
keyIdentifier
field exists, it is used to select the certificate with a matching subjectKeyIdentifier
extension. If the authorityCertIssuer
and authorityCertSerialNumber
fields are present, then they are used to identify the correct certificate by issuer
and serialNumber
.
authorityCertIssuer
and authorityCertSerialNumber
fields be specified. These fields permit construction of a complete certificate chain by matching the SubjectName
and CertificateSerialNumber
fields in the issuer's certificate against the authortiyCertIssuer
and authorityCertSerialNumber
in the Authority Key Identifier extension of the subject certificate.
2.5.29.35
This extension is always noncritical and is always evaluated.
B.3.3. basicConstraints
cA
component should be set to true
for all CA certificates. PKIX recommends that this extension should not appear in end-entity certificates.
pathLenConstraint
component is present, its value must be greater than the number of CA certificates that have been processed so far, starting with the end-entity certificate and moving up the chain. If pathLenConstraint
is omitted, then all of the higher level CA certificates in the chain must not include this component when the extension is present.
2.5.29.19
PKIX Part 1 requires that this extension be marked critical. This extension is evaluated regardless of its criticality.
B.3.4. certificatePoliciesExt
2.5.29.32
This extension may be critical or noncritical.
B.3.5. CRLDistributionPoints
DistributionPointName
with a type set to URI, the URI is assumed to be a pointer to the current CRL for the specified revocation reasons and will be issued by the named cRLIssuer
. The expected values for the URI are those defined for the Subject Alternative Name extension. If the distributionPoint
omits reasons, the CRL must include revocations for all reasons. If the distributionPoint
omits cRLIssuer
, the CRL must be issued by the CA that issued the certificate.
2.5.29.31
PKIX recommends that this extension be marked noncritical and that it be supported for all certificates.
B.3.6. extKeyUsage
Important
OCSP Signing
in an OCSP responder's certificate unless the CA signing key that signed the certificates validated by the responder is also the OCSP signing key. The OCSP responder's certificate must be issued directly by the CA that signs certificates the responder will validate.
2.5.29.37
If this extension is marked critical, the certificate must be used for one of the indicated purposes only. If it is not marked critical, it is treated as an advisory field that may be used to identify keys but does not restrict the use of the certificate to the indicated purposes.
Use | OID |
---|---|
Server authentication | 1.3.6.1.5.5.7.3.1 |
Client authentication | 1.3.6.1.5.5.7.3.2 |
Code signing | 1.3.6.1.5.5.7.3.3 |
1.3.6.1.5.5.7.3.4 | |
Timestamping | 1.3.6.1.5.5.7.3.8 |
OCSP Signing |
1.3.6.1.5.5.7.3.9[a]
|
[a]
OCSP Signing is not defined in PKIX Part 1, but in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.
|
Use | OID |
---|---|
Certificate trust list signing | 1.3.6.1.4.1.311.10.3.1 |
Microsoft Server Gated Crypto (SGC) | 1.3.6.1.4.1.311.10.3.3 |
Microsoft Encrypted File System | 1.3.6.1.4.1.311.10.3.4 |
Netscape SGC | 2.16.840.1.113730.4.1 |
B.3.7. issuerAltName Extension
2.5.29.18
PKIX Part 1 recommends that this extension be marked noncritical.
B.3.8. keyUsage
Important
digitalSignature
(0
) for TLS client certificates, S/MIME signing certificates, and object-signing certificates.nonRepudiation
(1
) for some S/MIME signing certificates and object-signing certificates.Warning
Use of this bit is controversial. Carefully consider the legal consequences of its use before setting it for any certificate.keyEncipherment
(2
) for TLS server certificates and S/MIME encryption certificates.dataEncipherment
(3
) when the subject's public key is used to encrypt user data instead of key material.keyAgreement
(4
) when the subject's public key is used for key agreement.keyCertSign
(5
) for all CA signing certificates.cRLSign
(6
) for CA signing certificates that are used to sign CRLs.encipherOnly
(7
) if the public key is used only for enciphering data. If this bit is set,keyAgreement
should also be set.decipherOnly
(8
) if the public key is used only for deciphering data. If this bit is set,keyAgreement
should also be set.
keyUsage
extension is present and marked critical, then it is used to enforce the usage of the certificate and key. The extension is used to limit the usage of a key; if the extension is not present or not critical, all types of usage are allowed.
keyUsage
extension is present, critical or not, it is used to select from multiple certificates for a given operation. For example, it is used to distinguish separate signing and encryption certificates for users who have separate certificates and key pairs for operations.
2.5.29.15
This extension may be critical or noncritical. PKIX Part 1 recommends that it should be marked critical if it is used.
Purpose of Certificate | Required Key Usage Bit |
---|---|
CA Signing |
|
TLS Client | digitalSignature |
TLS Server | keyEncipherment |
S/MIME Signing | digitalSignature |
S/MIME Encryption | keyEncipherment |
Certificate Signing | keyCertSign |
Object Signing | digitalSignature |
B.3.9. nameConstraints
2.5.29.30
PKIX Part 1 requires that this extension be marked critical.
B.3.10. OCSPNocheck
OCSPNocheck
should be issued with short lifetimes and be renewed frequently.
1.3.6.1.5.5.7.48.4
This extension should be noncritical.
B.3.11. policyConstraints
2.5.29.36
This extension may be critical or noncritical.
B.3.12. policyMappings
2.5.29.33
This extension must be noncritical.
B.3.13. privateKeyUsagePeriod
Note
2.5.29.16
B.3.14. subjectAltName
EmailAddress
attribute defined by PKCS #9. Software that supports S/MIME must be able to read an email address from either the Subject Alternative Name extension or from the subject name field.
2.5.29.17
If the certificate's subject field is empty, this extension must be marked critical.
B.3.15. subjectDirectoryAttributes
2.5.29.9
PKIX Part 1 requires that this extension be marked noncritical.
B.3.16. subjectKeyIdentifier
subjectPublicKey
, as recommended by PKIX. The Subject Key Identifier extension is used in conjunction with the Authority Key Identifier extension for CA certificates. If the CA certificate has a Subject Key Identifier extension, the key identifier in the Authority Key Identifier extension of the certificate being verified should match the key identifier of the CA's Subject Key Identifier extension. It is not necessary for the verifier to recompute the key identifier in this case.
2.5.29.14
This extension is always noncritical.
B.4. CRL Extensions
B.4.1. About CRL Extensions
Note
B.4.1.1. Structure of CRL Extensions
- The object identifier (OID) for the extension. This identifier uniquely identifies the extension. It also determines the ASN.1 type of value in the value field and how the value is interpreted. When an extension appears in a CRL, the OID appears as the extension ID field (
extnID
) and the corresponding ASN.1 encoded structure appears as the value of the octet string (extnValue
); examples are shown in Example B.4, “Sample Pretty-Print Certificate Extensions”. - A flag or Boolean field called
critical
.Thetrue
orfalse
value assigned to this field indicates whether the extension is critical or noncritical to the CRL.- If the extension is critical and the CRL is sent to an application that does not understand the extension based on the extension's ID, the application must reject the CRL.
- If the extension is not critical and the CRL is sent to an application that does not understand the extension based on the extension's ID, the application can ignore the extension and accept the CRL.
- An octet string containing the DER encoding of the value of the extension.
B.4.1.2. Sample CRL and CRL Entry Extensions
Certificate Revocation List: Data: Version: v2 Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Issuer: CN=Certificate Authority,O=Example Domain This Update: Wednesday, July 29, 2009 8:59:48 AM GMT-08:00 Next Update: Friday, July 31, 2009 8:59:48 AM GMT-08:00 Revoked Certificates: 1-3 of 3 Serial Number: 0x11 Revocation Date: Thursday, July 23, 2009 10:07:15 AM GMT-08:00 Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Privilege_Withdrawn Serial Number: 0x1A Revocation Date: Wednesday, July 29, 2009 8:50:11 AM GMT-08:00 Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Certificate_Hold Identifier: Invalidity Date - 2.5.29.24 Critical: no Invalidity Date: Sun Jul 26 23:00:00 GMT-08:00 2009 Serial Number: 0x19 Revocation Date: Wednesday, July 29, 2009 8:50:49 AM GMT-08:00 Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Key_Compromise Identifier: Invalidity Date - 2.5.29.24 Critical: no Invalidity Date: Fri Jul 24 23:00:00 GMT-08:00 2009 Extensions: Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1 Critical: no Access Description: Method #0: ocsp Location #0: URIName: http://example.com:9180/ca/ocsp Identifier: Issuer Alternative Name - 2.5.29.18 Critical: no Issuer Names: DNSName: example.com Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: 50:52:0C:AA:22:AC:8A:71:E3:91:0C:C5:77:21:46:9C: 0F:F8:30:60 Identifier: Freshest CRL - 2.5.29.46 Critical: no Number of Points: 1 Point 0 Distribution Point: [URIName: http://server.example.com:8443/ca/ee/ca/getCRL?op=getDeltaCRL&crlIssuingPoint=MasterCRL] Identifier: CRL Number - 2.5.29.20 Critical: no Number: 39 Identifier: Issuing Distribution Point - 2.5.29.28 Critical: yes Distribution Point: Full Name: URIName: http://example.com:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL Only Contains User Certificates: no Only Contains CA Certificates: no Indirect CRL: no Signature: Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Signature: 47:D2:CD:C9:E5:F5:9D:56:0A:97:31:F5:D5:F2:51:EB: 1F:CF:FA:9E:63:D4:80:13:85:E5:D8:27:F0:69:67:B5: 89:4F:59:5E:69:E4:39:93:61:F2:E3:83:51:0B:68:26: CD:99:C4:A2:6C:2B:06:43:35:36:38:07:34:E4:93:80: 99:2F:79:FB:76:E8:3D:4C:15:5A:79:4E:E5:3F:7E:FC: D8:78:0D:1D:59:A0:4C:14:42:B7:22:92:89:38:3A:4C: 4A:3A:06:DE:13:74:0E:E9:63:74:D0:2F:46:A1:03:37: 92:F0:93:D9:AA:F8:13:C5:06:25:02:B0:FD:3B:41:E7: 62:6F:67:A3:9F:F5:FA:03:41:DA:8D:FD:EA:2F:E3:2B: 3E:F8:E9:CC:3B:9F:E4:ED:73:F2:9E:B9:54:14:C1:34: 68:A7:33:8F:AF:38:85:82:40:A2:06:97:3C:B4:88:43: 7B:AF:5D:87:C4:47:63:4A:11:65:E3:75:55:4D:98:97: C2:2E:62:08:A4:04:35:5A:FE:0A:5A:6E:F1:DE:8E:15: 27:1E:0F:87:33:14:16:2E:57:F7:DC:77:BE:D2:75:AB: A9:7C:42:1F:84:6D:40:EC:E7:ED:84:F8:14:16:28:33: FD:11:CD:C5:FC:49:B7:7B:39:57:B3:E6:36:E5:CD:B6
ertificate Revocation List:
Data:
Version: v2
Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
Issuer: CN=Certificate Authority,O=SjcRedhat Domain
This Update: Wednesday, July 29, 2009 9:02:28 AM GMT-08:00
Next Update: Thursday, July 30, 2009 9:02:28 AM GMT-08:00
Revoked Certificates:
Serial Number: 0x1A
Revocation Date: Wednesday, July 29, 2009 9:00:48 AM GMT-08:00
Extensions:
Identifier: Revocation Reason - 2.5.29.21
Critical: no
Reason: Remove_from_CRL
Serial Number: 0x17
Revocation Date: Wednesday, July 29, 2009 9:02:16 AM GMT-08:00
Extensions:
Identifier: Revocation Reason - 2.5.29.21
Critical: no
Reason: Certificate_Hold
Identifier: Invalidity Date - 2.5.29.24
Critical: no
Invalidity Date: Mon Jul 27 23:00:00 GMT-08:00 2009
Extensions:
Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1
Critical: no
Access Description:
Method #0: ocsp
Location #0: URIName: http://server.example.com:8443/ca/ocsp
Identifier: Delta CRL Indicator - 2.5.29.27
Critical: yes
Base CRL Number: 39
Identifier: Issuer Alternative Name - 2.5.29.18
Critical: no
Issuer Names:
DNSName: a-f8.sjc.redhat.com
Identifier: Authority Key Identifier - 2.5.29.35
Critical: no
Key Identifier:
50:52:0C:AA:22:AC:8A:71:E3:91:0C:C5:77:21:46:9C:
0F:F8:30:60
Identifier: CRL Number - 2.5.29.20
Critical: no
Number: 41
Identifier: Issuing Distribution Point - 2.5.29.28
Critical: yes
Distribution Point:
Full Name:
URIName: http://server.example.com:8443/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL
Only Contains User Certificates: no
Only Contains CA Certificates: no
Indirect CRL: no
Signature:
Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
Signature:
68:28:DA:90:D5:39:CB:6D:BE:42:04:77:C9:E4:09:60:
C1:97:A6:99:AB:A0:5B:A2:F3:8B:5E:4E:D6:05:70:B0:
87:1F:D7:0E:4B:C6:B2:DE:8B:92:D8:7C:3B:36:1C:79:
96:2A:64:E6:7A:25:1D:E7:40:62:48:7A:24:C9:9D:11:
A6:7F:BB:6B:03:A0:9C:1D:BC:1C:EE:9A:4B:A6:48:2C:
3B:5E:2B:B1:70:3C:C3:42:96:28:26:AB:82:18:F2:E9:
F2:55:48:A8:7E:7F:FE:D4:3D:0B:EA:A2:2F:4E:E6:C3:
C3:C1:6A:E5:C6:85:5B:42:B1:70:2A:C6:E1:D9:0C:AF:
DA:01:22:FF:80:6E:2E:A7:E5:34:DC:AF:E6:C2:B5:B3:
1B:FC:28:36:8A:91:4A:22:E7:03:A5:ED:4E:62:0C:D9:
7F:81:BB:80:99:B8:61:2A:02:C6:9C:41:2E:01:82:21:
80:82:69:52:BD:B2:AA:DB:0F:80:0A:7E:2A:F3:15:32:
69:D2:40:0D:39:59:93:75:A2:ED:24:70:FB:EE:19:C0:
BE:A2:14:36:D0:AC:E8:E2:EE:23:83:DD:BC:DF:38:1A:
9E:37:AF:E3:50:D9:47:9D:22:7C:36:35:BF:13:2C:16:
A2:79:CF:05:41:88:8E:B6:A2:4E:B3:48:6D:69:C6:38
B.4.2. Standard X.509 v3 CRL Extensions Reference
B.4.2.1. Extensions for CRLs
B.4.2.1.1. authorityInfoAccess
1.3.6.1.5.5.7.1.1
PKIX requires that this extension must not be critical.
Parameter | Description |
---|---|
enable | Specifies whether the rule is enabled or disabled. The default is to have this extension disabled. |
critical | Sets whether the extension is marked as critical; the default is noncritical. |
numberOfAccessDescriptions |
Indicates the number of access descriptions, from 0 to any positive integer; the default is 0.
When setting this parameter to an integer other than 0, set the number, and then click OK to close the window. Re-open the edit window for the rule, and the fields to set the points will be present.
|
accessMethodn | The only accepted value for this parameter is caIssuers. The caIssuers method is used when the information available lists certificates that can be used to verify the signature on the CRL. No other method should be used when the AIA extension is included in a CRL. |
accessLocationTypen | Specifies the type of access location for the n access description. The options are either DirectoryName or URI . |
accessLocationn |
If
accessLocationType is set to DirectoryName , the value must be a string in the form of an X.500 name, similar to the subject name in a certificate. For example, CN=CACentral,OU=Research Dept,O=Example Corporation,C=US.
If
accessLocationType is set to URI , the name must be a URI; the URI must be an absolute pathname and must specify the host. For example, http://testCA.example.com/get/crls/here/.
|
B.4.2.1.2. authorityKeyIdentifier
2.5.29.35
Parameter | Description |
---|---|
enable | Specifies whether the rule is enabled or disabled. The default is to have this extension disabled. |
critical | Sets whether the extension is marked as critical; the default is noncritical. |
B.4.2.1.3. CRLNumber
2.5.29.20
This extension must not be critical.
Parameter | Description |
---|---|
enable | Specifies whether the rule is enabled, which is the default. |
critical | Sets whether the extension is marked as critical; the default is noncritical. |
B.4.2.1.4. deltaCRLIndicator
2.5.29.27
PKIX requires that this extension be critical if it exists.
Parameter | Description |
---|---|
enable | Sets whether the rule is enabled. By default, it is disabled. |
critical | Sets whether the extension is critical or noncritical. By default, this is critical. |
B.4.2.1.5. FreshestCRL
2.5.29.46
PKIX requires that this extension must be noncritical.
Parameter | Description |
---|---|
enable | Sets whether the extension rule is enabled. By default, this is disabled. |
critical | Marks the extension as critical or noncritical. The default is noncritical. |
numPoints | Indicates the number of issuing points for the delta CRL, from 0 to any positive integer; the default is 0 . When setting this to an integer other than 0, set the number, and then click to close the window. Re-open the edit window for the rule, and the fields to set these points will be present. |
pointTypen | Specifies the type of issuing point for the n issuing point. For each number specified in numPoints , there is an equal number of pointType parameters. The options are either DirectoryName or URIName . |
pointNamen |
If
pointType is set to directoryName , the value must be a string in the form of an X.500 name, similar to the subject name in a certificate. For example, CN=CACentral,OU=Research Dept,O=Example Corporation,C=US.
If
pointType is set to URIName , the name must be a URI; the URI must be an absolute pathname and must specify the host. For example, http://testCA.example.com/get/crls/here/.
|
B.4.2.1.6. issuerAltName
2.5.29.18
Parameter | Description |
---|---|
enable | Sets whether the extension rule is enabled; by default, this is disabled. |
critical | Sets whether the extension is critical; by default, this is noncritical. |
numNames | Sets the total number of alternative names or identities permitted in the extension. Each name has a set of configuration parameters, nameType and name , which must have appropriate values or the rule returns an error. Change the total number of identities by changing the value specified in this field; there is no limit on the total number of identities that can be included in the extension. Each set of configuration parameters is distinguished by an integer derived from the value of this field. For example, if the numNames parameter is set to 2 , the derived integers are 0 and 1 . |
nameTypen |
Specifies the general-name type; this can be any of the following:
|
namen |
Specifies the general-name value; the allowed values depend on the name type specified in the
nameType field.
|
B.4.2.1.7. issuingDistributionPoint
2.5.29.28
PKIX requires that this extension be critical if it exists.
Parameter | Description |
---|---|
enable | Sets whether the extension is enabled; the default is disabled. |
critical | Marks the extension as critical, the default, or noncritical. |
pointType |
Specifies the type of the issuing distribution point from the following:
|
pointName |
Gives the name of the issuing distribution point. The name of the distribution point depends on the value specified for the
pointType parameter.
Note
The CRL may be stored in the directory entry corresponding to the CRL issuing point, which may be different than the directory entry of the CA.
|
onlySomeReasons |
Specifies the reason codes associated with the distribution point.
Permissible values are a combination of reason codes (
unspecified , keyCompromise , cACompromise , affiliationChanged , superseded , cessationOfOperation , certificateHold , and removeFromCRL ) separated by commas. Leave the field blank if the distribution point contains revoked certificates with all reason codes (default).
|
onlyContainsCACerts | Specifies that the distribution point contains user certificates only if set. By default, this is not set, which means the distribution point contains all types of certificates. |
indirectCRL | Specifies that the distribution point contains an indirect CRL; by default, this is not selected. |
B.4.2.2. CRL Entry Extensions
B.4.2.2.1. certificateIssuer
2.5.29.29
B.4.2.2.2. invalidityDate
2.5.29.24
Parameter | Description |
---|---|
enable | Sets whether the extension rule is enabled or disabled. By default, this is enabled. |
critical | Marks the extension as critical or noncritical; by default, this is noncritical. |
B.4.2.2.3. CRLReason
2.5.29.21
Parameter | Description |
---|---|
enable | Sets whether the extension rule is enabled or disabled. By default, this is enabled. |
critical | Marks the extension as critical or noncritical. By default, this is noncritical. |
B.4.3. Netscape-Defined Certificate Extensions Reference
B.4.3.1. netscape-cert-type
- bit 0: TLS Client certificate
- bit 1: TLS Server certificate
- bit 2: S/MIME certificate
- bit 3: Object Signing certificate
- bit 4: reserved
- bit 5: TLS CA certificate
- bit 6: S/MIME CA certificate
- bit 7: Object Signing CA certificate
2.16.840.1.113730.1.1
B.4.3.2. netscape-comment
2.16.840.1.113730.13
Appendix C. Publishing Module Reference
C.1. Publisher Plug-in Modules
C.1.1. FileBasedPublisher
FileBasedPublisher
plug-in module configures a Certificate Manager to publish certificates and CRLs to file. This plug-in can publish base-64 encoded files, DER-encoded files, or both, depending on the checkboxes selected when the publisher is configured. The certificate and CRL content can be viewed by converting the files using the PrettyPrintCert
and PrettyPrintCRL
tools. For details on viewing the content in base-64 and DER-encoded certificates and CRLs, see Section 7.10, “Viewing Certificates and CRLs Published to File”.
FileBasedPublisher
module.
Parameter | Description |
---|---|
Publisher ID | Specifies a name for the publisher, an alphanumeric string with no spaces. For example, PublishCertsToFile . |
directory | Specifies the complete path to the directory to which the Certificate Manager creates the files; the path can be an absolute path or can be relative to the Certificate System instance directory. For example, /export/CS/certificates . |
C.1.2. LdapCaCertPublisher
LdapCaCertPublisher
plug-in module configures a Certificate Manager to publish or unpublish a CA certificate to the caCertificate;binary
attribute of the CA's directory entry.
pkiCA
or certificationAuthority
, if it is not used already. Similarly, it also removes the pkiCA
or certificationAuthority
object class when unpublishing if the CA has no other certificates.
LdapCaCertPublisher
module for publishing the CA certificate to the directory.
Parameter | Description |
---|---|
caCertAttr | Specifies the LDAP directory attribute to publish the CA certificate. This must be caCertificate;binary . |
caObjectClass | Specifies the object class for the CA's entry in the directory. This must be pkiCA or certificationAuthority . |
C.1.3. LdapUserCertPublisher
LdapUserCertPublisher
plug-in module configures a Certificate Manager to publish or unpublish a user certificate to the userCertificate;binary
attribute of the user's directory entry.
LdapUserCertPublisher
module for publishing end-entity certificates to the directory.
Parameter | Description |
---|---|
certAttr | Specifies the directory attribute of the mapped entry to which the Certificate Manager should publish the certificate. This must be userCertificate;binary . |
C.1.4. LdapCrlPublisher
LdapCrlPublisher
plug-in module configures a Certificate Manager to publish or unpublish the CRL to the certificateRevocationList;binary
attribute of a directory entry.
LdapCrlPublisher
module for publishing CRLs to the directory.
Parameter | Description |
---|---|
crlAttr | Specifies the directory attribute of the mapped entry to which the Certificate Manager should publish the CRL. This must be certificateRevocationList;binary . |
C.1.5. LdapDeltaCrlPublisher
LdapDeltaCrlPublisher
plug-in module configures a Certificate Manager to publish or unpublish a delta CRL to the deltaRevocationList
attribute of a directory entry.
LdapDeltaCrlPublisher
module for publishing CRLs to the directory.
Parameter | Description |
---|---|
crlAttr | Specifies the directory attribute of the mapped entry to which the Certificate Manager should publish the delta CRL. This must be deltaRevocationList;binary . |
C.1.6. LdapCertificatePairPublisher
LdapCertificatePairPublisher
plug-in module configures a Certificate Manager to publish or unpublish a cross-signed certificate to the crossCertPair;binary
attribute of the CA's directory entry.
pkiCA
or certificationAuthority
, if it is not used already. Similarly, it also removes the pkiCA
or certificationAuthority
object class when unpublishing if the CA has no other certificates.
LdapCertificatePairPublisher
module named LdapCrossCertPairPublisher
for publishing the cross-signed certificates to the directory.
Parameter | Description |
---|---|
crossCertPairAttr | Specifies the LDAP directory attribute to publish the CA certificate. This must be crossCertificatePair;binary . |
caObjectClass | Specifies the object class for the CA's entry in the directory. This must be pkiCA or certificationAuthority . |
C.1.7. OCSPPublisher
OCSPPublisher
plug-in module configures a Certificate Manager to publish its CRLs to an Online Certificate Status Manager.
OCSPPublisher
module at installation.
Parameter | Description |
---|---|
host | Specifies the fully qualified hostname of the Online Certificate Status Manager. |
port | Specifies the port number on which the Online Certificate Status Manager is listening to the Certificate Manager. This is the Online Certificate Status Manager's TLS port number. |
path | Specifies the path for publishing the CRL. This must be the default path, /ocsp/agent/ocsp/addCRL . |
enableClientAuth | Sets whether to use client (certificate-based) authentication to access the OCSP service. |
nickname | Gives the nickname of the certificate in the OCSP service's database to use for client authentication. This is only used if the enableClientAuth option is set to true. |
C.2. Mapper Plug-in Modules
C.2.1. LdapCaSimpleMap
LdapCaSimpleMap
plug-in module configures a Certificate Manager to create an entry for the CA in an LDAP directory automatically and then map the CA's certificate to the directory entry by formulating the entry's DN from components specified in the certificate request, certificate subject name, certificate extension, and attribute variable assertion (AVA) constants. For more information on AVAs, check the directory documentation.
dnPattern
parameter of this mapper is changed, but the uid
and o
attributes are the same, the mapper fails to create the second CA entry. For example, if the directory already has a CA entry for uid=CA,ou=Marketing,o=example.com
and a mapper is configured to create another CA entry with uid=CA,ou=Engineering,o=example.com
, the operation fails.
o=example.com
with the same UID, CA
.
LdapCrlMap
for CRLs (see Section C.2.1.2, “LdapCrlMap”)LdapCaCertMap
for CA certificates (see Section C.2.1.1, “LdapCaCertMap”).
Parameter | Description |
---|---|
createCAEntry |
Creates a CA's entry, if selected (default).
If selected, the Certificate Manager first attempts to create an entry for the CA in the directory. If the Certificate Manager succeeds in creating the entry, it then attempts to publish the CA's certificate to the entry. If this is not selected, the entry must already be present in order to publish to it.
|
dnPattern |
Specifies the DN pattern the Certificate Manager should use to construct to search for the CA's entry in the publishing directory. The value of
dnPattern can be a list of AVAs separated by commas. An AVA can be a variable, such as cn=$subj.cn , that the Certificate Manager can derive from the certificate subject name or a constant, such as o=Example Corporation .
If the CA certificate does not have the
cn component in its subject name, adjust the CA certificate mapping DN pattern to reflect the DN of the entry in the directory where the CA certificate is to be published. For example, if the CA certificate subject DN is o=Example Corporation and the CA's entry in the directory is cn=Certificate Authority, o=Example Corporation , the pattern is cn=Certificate Authority, o=$subj.o .
In the above examples,
$req takes the attribute from the certificate request, $subj takes the attribute from the certificate subject name, and $ext takes the attribute from the certificate extension.
|
C.2.1.1. LdapCaCertMap
LdapCaCertMap
mapper is an instance of the LdapCaSimpleMap
module. The Certificate Manager automatically creates this mapper during installation.
uid=$subj.cn,ou=people,o=$subj.o
C.2.1.2. LdapCrlMap
LdapCrlMap
mapper is an instance of the LdapCaSimpleMap
module. The Certificate Manager automatically creates this mapper during installation.
uid=$subj.cn,ou=people,o=$subj.o
C.2.2. LdapDNExactMap
LdapDNExactMap
plug-in module configures a Certificate Manager to map a certificate to an LDAP directory entry by searching for the LDAP entry DN that matches the certificate subject name. To use this mapper, each certificate subject name must exactly match a DN in a directory entry. For example, if the certificate subject name is uid=jdoe, o=Example Corporation, c=US
, when searching the directory for the entry, the Certificate Manager only searches for an entry with the DN uid=jdoe, o=Example Corporation, c=US
.
C.2.3. LdapSimpleMap
LdapSimpleMap
plug-in module configures a Certificate Manager to map a certificate to an LDAP directory entry by deriving the entry's DN from components specified in the certificate request, certificate's subject name, certificate extension, and attribute variable assertion (AVA) constants. For more information on AVAs, see the directory documentation.
LdapUserCertMap
. The default mapper maps various types of end-entity certificates to their corresponding directory entries.
dnPattern
. The value of dnPattern
can be a list of AVAs separated by commas. An AVA can be a variable, such as uid=$subj.UID
, or a constant, such as o=Example Corporation
.
- Example 1:
uid=CertMgr, o=Example Corporation
- Example 2:
cn=$subj.cn,ou=$subj.ou,o=$subj.o,c=US
- Example 3: uid=
$req.HTTP_PARAMS.uid, e=$ext.SubjectAlternativeName.RFC822Name,ou=$subj.ou
$req
takes the attribute from the certificate request, $subj
takes the attribute from the certificate subject name, and $ext
takes the attribute from the certificate extension.
C.2.4. LdapSubjAttrMap
LdapSubjAttrMap
plug-in module configures a Certificate Manager to map a certificate to an LDAP directory entry using a configurable LDAP attribute. To use this mapper, the directory entries must include the specified LDAP attribute.
certSubjectDN
and the certificate subject name is uid=jdoe, o=Example Corporation, c=US
, the Certificate Manager searches the directory for entries that have the attribute certSubjectDN=uid=jdoe, o=Example Corporation, c=US
.
Parameter | Description |
---|---|
certSubjNameAttr | Specifies the name of the LDAP attribute that contains a certificate subject name as its value. The default is certSubjectName , but this can be configured to any LDAP attribute. |
searchBase | Specifies the base DN for starting the attribute search. The permissible value is a valid DN of an LDAP entry, such as o=example.com, c=US . |
C.2.5. LdapDNCompsMap
LdapDNCompsMap
plug-in module implements the DN components mapper. This mapper maps a certificate to an LDAP directory entry by constructing the entry's DN from components, such as cn
, ou
, o
, and c
, specified in the certificate subject name, and then uses it as the search DN to locate the entry in the directory. The mapper locates the following entries:
- The CA's entry in the directory for publishing the CA certificate and the CRL.
- End-entity entries in the directory for publishing end-entity certificates.
DNComps
and filterComps
parameters accept valid DN components or attributes separated by commas. The parameters do not accept multiple entries of an attribute; for example, filterComps
can be set to cn,ou
but not to cn,ou2,ou1
. To create a filter with multiple instances of the same attribute, such as if directory entries contain multiple ou
s, modify the source code for the LdapDNCompsMap
module.
uid
represents the user ID of a user in the directory.cn
represents the common name of a user in the directory.ou
represents an organizational unit in the directory.o
represents an organization in the directory.l
represents a locality (city).st
represents a state.c
represents a country.
cn=Jane Doe, ou=Sales, o=Example Corporation, l=Mountain View, st=California, c=US
cn
, ou
, o
, l
, st
, and c
) to build a DN for searching the directory. When creating a mapper rule, these components can be specified for the server to use to build a DN; that is, components to match attributes in the directory. This is set through the dnComps
parameter.
cn
, ou
, o
, and c
are set as values for the dnComps
parameter. To locate Jane Doe's entry in the directory, the Certificate Manager constructs the following DN by reading the DN attribute values from the certificate, and uses the DN as the base for searching the directory:
cn=Jane Doe, ou=Sales, o=Example Corporation, c=US
- A subject name does not need to have all of the components specified in the
dnComps
parameter. The server ignores any components that are not part of the subject name, such asl
andst
in this example. - Unspecified components are not used to build the DN. In the example, if the
ou
component is not included, the server uses this DN as the base for searching the directory:cn=Jane Doe, o=Example Corporation, c=US
dnComps
parameter, enter those DN components that the Certificate Manager can use to form the LDAP DN exactly. In certain situations, however, the subject name in a certificate may match more than one entry in the directory. Then, the Certificate Manager might not get a single, distinct matching entry from the DN. For example, the subject name cn=Jane Doe, ou=Sales, o=Example Corporation, c=US
might match two users with the name Jane Doe in the directory. If that occurs, the Certificate Manager needs additional criteria to determine which entry corresponds to the subject of the certificate.
filterComps
parameter; for details, see Table C.10, “LdapDNCompsMap Configuration Parameters”. For example, if cn
, ou
, o
, and c
are values for the dnComps
parameter, enter l
for the filterComps
parameter only if the l
attribute can be used to distinguish between entries with identical cn
, ou
, o
, and c
values.
uid
attribute ‐ one entry's uid
is janedoe1
, and the other entry's uid
is janedoe2
‐ the subject names of certificates can be set to include the uid
component.
Note
e
, l
, and st
components are not included in the standard set of certificate request forms provided for end entities. These components can be added to the forms, or the issuing agents can be required to insert these components when editing the subject name in the certificate issuance forms.
C.2.5.1. Configuration Parameters of LdapDNCompsMap
dnComps
values to form a DN and the filterComps
values to form a search filter for the subtree.
- If the formed DN is null, the server uses the
baseDN
value for the subtree. If both the formed DN and base DN are null, the server logs an error. - If the filter is null, the server uses the
baseDN
value for the search. If both the filter and base DN are null, the server logs an error.
Parameter | Description |
---|---|
baseDN | Specifies the DN to start searching for an entry in the publishing directory. If the dnComps field is blank, the server uses the base DN value to start its search in the directory. |
dnComps |
Specifies where in the publishing directory the Certificate Manager should start searching for an LDAP entry that matches the CA's or the end entity's information.
For example, if
dnComps uses the o and c attributes of the DN, the server starts the search from the o= org, c= country entry in the directory, where org and country are replaced with values from the DN in the certificate.
If the
dnComps field is empty, the server checks the baseDN field and searches the directory tree specified by that DN for entries matching the filter specified by filterComps parameter values.
The permissible values are valid DN components or attributes separated by commas.
|
filterComps |
Specifies components the Certificate Manager should use to filter entries from the search result. The server uses the
filterComps values to form an LDAP search filter for the subtree. The server constructs the filter by gathering values for these attributes from the certificate subject name; it uses the filter to search for and match entries in the LDAP directory.
If the server finds more than one entry in the directory that matches the information gathered from the certificate, the search is successful, and the server optionally performs a verification. For example, if
filterComps is set to use the email and user ID attributes (filterComps=e,uid ), the server searches the directory for an entry whose values for email and user ID match the information gathered from the certificate.
The permissible values are valid directory attributes in the certificate DN separated by commas. The attribute names for the filters need to be attribute names from the certificate, not from ones in the LDAP directory. For example, most certificates have an
e attribute for the user's email address; LDAP calls that attribute mail .
|
C.3. Rule Instances
C.3.1. LdapCaCertRule
LdapCaCertRule
can be used to publish CA certificates to an LDAP directory.
Parameter | Value | Description |
---|---|---|
type | cacert | Specifies the type of certificate that will be published. |
predicate | Specifies a predicate for the publisher. | |
enable | yes | Enables the rule. |
mapper | LdapCaCertMap | Specifies the mapper used with the rule. See Section C.2.1.1, “LdapCaCertMap” for details on the mapper. |
publisher | LdapCaCertPublisher | Specifies the publisher used with the rule. See Section C.1.2, “LdapCaCertPublisher” for details on the publisher. |
C.3.2. LdapXCertRule
LdapXCertRule
is used to publish cross-pair certificates to an LDAP directory.
Parameter | Value | Description |
---|---|---|
type | xcert | Specifies the type of certificate that will be published. |
predicate | Specifies a predicate for the publisher. | |
enable | yes | Enables the rule. |
mapper | LdapCaCertMap | Specifies the mapper used with the rule. See Section C.2.1.1, “LdapCaCertMap” for details on the mapper. |
publisher | LdapCrossCertPairPublisher | Specifies the publisher used with the rule. See Section C.1.6, “LdapCertificatePairPublisher” for details on this publisher. |
C.3.3. LdapUserCertRule
LdapUserCertRule
is used to publish user certificates to an LDAP directory.
Parameter | Value | Description |
---|---|---|
type | certs | Specifies the type of certificate that will be published. |
predicate | Specifies a predicate for the publisher. | |
enable | yes | Enables the rule. |
mapper | LdapUserCertMap | Specifies the mapper used with the rule. See Section C.2.3, “LdapSimpleMap” for details on the mapper. |
publisher | LdapUserCertPublisher | Specifies the publisher used with the rule. See Section C.1.3, “LdapUserCertPublisher” for details on the publisher. |
C.3.4. LdapCRLRule
LdapCRLRule
is used to publish CRLs to an LDAP directory.
Parameter | Value | Description |
---|---|---|
type | crl | Specifies the type of certificate that will be published. |
predicate | Specifies a predicate for the publisher. | |
enable | yes | Enables the rule. |
mapper | LdapCrlMap | Specifies the mapper used with the rule. See Section C.2.1.2, “LdapCrlMap” for details on the mapper. |
publisher | LdapCrlPublisher | Specifies the publisher used with the rule. See Section C.1.4, “LdapCrlPublisher” for details on the publisher. |
Appendix D. ACL Reference
D.1. About ACL Configuration Files
acl.ldif
files in the instance's /var/lib/pki/instance_name/conf
directory.
Note
resourceACLS
attributes which identify the area of the subsystem being protected and then a list of all of the specific access controls being set.
resourceACLS: class_name:all rights: allow|deny (rights) type=target description
Example D.1. Default ACL to List Certificate Profiles
resourceACLS: certServer.ca.profiles:list:allow (list) group="Certificate Manager Agents":Certificate Manager agents may list profiles
acl.ldif
file and its own defined ACLs.
allow|deny (rights) user|group
user=
or group=
, though there are other options, like ipaddress=
which defines client-based access rather than entry-based access. If there is more than one condition, the conditions can be composed using the double pipe (||) operator, signifying logical disjunction ("or"), and the double ampersand (&&) operator, signifying logical conjunction ("and"). For example, group="group1" || "group2"
.
resourceACLS
attribute value is defined in Table D.1, “Sections of the ACL Attribute Value”.
Value | Description |
---|---|
class_name | The plug-in class to which the ACI is applied. |
all operations | The list of every operation covered in the ACI definition. There can be multiple operations in a single ACI and multiple ACIs in a single resourceACLS attribute. |
allow|deny | Whether the action is being allowed for the target user or group or denied to the target user or group. |
(operations) | The operations being allowed or denied. |
type=target | The target to identify who this applies to. This is commonly a user (such as user= "name") or a group (group= "group"). If there is more than one condition, the conditions can be composed using the double pipe (||) operator (logical "or") and the double ampersand (&&) operator (logical "and"). For example, group="group1" || "group2" . |
description | A description of what the ACL is doing. |
D.2. Common ACLs
Important
acl.ldif
file. These are not shared ACLs in the sense that the configuration files or settings are held in common by all subsystem instances. As with all other instance configuration, these ACLs are maintained independently of other subsystem instances, in the instance-specific acl.ldif
file.
D.2.1. certServer.acl.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View ACL resources and list ACL resources, ACL listing evaluators, and ACL evaluator types. | Allow |
| |||
modify | Add, delete, and update ACL evaluators. | Allow | Administrators |
D.2.2. certServer.admin.certificate
allow (import) user="anybody"
Note
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
import | Import a CA administrator certificate, and retrieve certificates by serial number. | Allow | Anyone |
D.2.3. certServer.auth.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View authentication plug-ins, authentication type, configured authentication manager plug-ins, and authentication instances. List authentication manager plug-ins and authentication manager instances. | Allow |
| |||
modify | Add or delete authentication plug-ins and authentication instances. Modify authentication instances. | Allow | Administrators |
D.2.4. certServer.clone.configuration
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | View original instance configuration. | Allow | Enterprise Administrators |
modify | Modify original instance configuration. | Allow | Enterprise Administrators |
D.2.5. certServer.general.configuration
allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View the operating environment, LDAP configuration, SMTP configuration, server statistics, encryption, token names, subject name of certificates, certificate nicknames, all subsystems loaded by the server, CA certificates, and all certificates for management. | Allow |
| |||
modify | Modify the settings for the LDAP database, SMTP, and encryption. Issue import certificates, install certificates, trust and untrust CA certificates, import cross-pair certificates, and delete certificates. Perform server restart and stop operations. Log in all tokens and check token status. Run self-tests on demand. Get certificate information. Process the certificate subject name. Validate the certificate subject name, certificate key length, and certificate extension. | Allow | Administrators |
D.2.6. certServer.log.configuration
allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View log plug-in information, log plug-in configuration, and log instance configuration. List log plug-ins and log instances (excluding NTEventLog). | Allow |
| |||
modify | Add and delete log plug-ins and log instances. Modify log instances, including log rollover parameters and log level. | Allow | Administrators |
D.2.7. certServer.log.configuration.fileName
allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents";deny (modify) user=anybody
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View the value of the fileName parameter for a log instance. | Allow |
| |||
modify | Change the value of the fileName parameter for a log instance. | Deny | Anyone |
D.2.8. certServer.log.content.system
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View log content. List all logs. | Allow |
|
D.2.9. certServer.log.content.transactions
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View log content. List all logs. | Allow |
|
D.2.10. certServer.log.content.signedAudit
allow (read) group="Auditors"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |
---|---|---|---|---|
read | View log content. List logs. | Allow |
|
D.2.11. certServer.registry.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View the administration registry, supported policy constraints, profile plug-in configuration, and the list of profile plug-ins. | Allow |
| |||
modify | Register individual profile implementation plug-ins. | Allow | Administrators |
D.3. Certificate Manager-Specific ACLs
D.3.1. certServer.admin.ocsp
allow (modify,read) group="Enterprise OCSP Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
modify | Modify the OCSP configuration, OCSP stores configuration, and default OCSP store. | Allow | Enterprise OCSP Administrators |
read | Read the OCSP configuration. | Allow | Enterprise OCSP Administrators |
D.3.2. certServer.ca.certificate
allow (import,unrevoke,revoke,read) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
import | Retrieve a certificate by serial number. | Allow | Certificate Manager Agents |
unrevoke | Change the status of a certificate from revoked. | Allow | Certificate Manager Agents |
revoke | Change the status of a certificate to revoked. | Allow | Certificate Manager Agents |
read | Retrieve certificates based on the request ID, and display certificate details based on the request ID or serial number. | Allow | Certificate Manager Agents |
D.3.3. certServer.ca.certificates
allow (revoke,list) group="Certificate Manager Agents"|| group="Registration Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | ||
---|---|---|---|---|---|
revoke | Revoke a certificates, or approve certificate revocation requests. Revoke a certificate from the TPS. Prompt users for additional data about a revocation request. | Allow |
| ||
list | List certificates based on a search. Retrieve details about a range of certificates based on a range of serial numbers. | Allow |
|
D.3.4. certServer.ca.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View CRL plug-in information, general CA configuration, CA connector configuration, CRL issuing points configuration, CRL profile configuration, request notification configuration, revocation notification configuration, request in queue notification configuration, and CRL extensions configuration. List CRL extensions configuration and CRL issuing points configuration. | Allow |
| |||
modify | Add and delete CRL issuing points. Modify general CA settings, CA connector configuration, CRL issuing points configuration, CRL configuration, request notification configuration, revocation notification configuration, request in queue notification configuration, and CRL extensions configuration. | Allow | Administrators |
D.3.5. certServer.ca.connector
allow (submit) group="Trusted Managers"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
submit | Submit requests from remote trusted managers. | Allow | Trusted Managers |
D.3.6. certServer.ca.connectorInfo
allow (read) group="Enterprise KRA Administrators";allow (modify) group="Enterprise KRA Administrators" || group="Subsystem Group"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | ||
---|---|---|---|---|---|
read | Read connector plug-in settings. | Allow | Enterprise KRA Administrators | ||
modify | Modify connector plug-in settings. | Allow |
|
D.3.7. certServer.ca.crl
allow (read,update) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Display CRLs and get detailed information about CA CRL processing. | Allow | Certificate Manager Agents |
update | Update CRLs. | Allow | Certificate Manager Agents |
D.3.8. certServer.ca.directory
allow (update) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
update | Publish CA certificates, CRLs, and user certificates to the LDAP directory. | Allow | Certificate Manager Agents |
D.3.9. certServer.ca.group
allow (modify,read) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
modify | Create, edit, or delete user and group entries for the instance. Add or modify a user certificate within attributes | Allow | Administrators |
read | View user and group entries for the instance. | Allow | Administrators |
D.3.10. certServer.ca.ocsp
allow (read) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Retrieve OCSP usage statistics. | Allow | Certificate Manager Agents |
D.3.11. certServer.ca.profile
allow (read,approve) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | View the details of the certificate profiles. | Allow | Certificate Manager Agents |
approve | Approve and enable certificate profiles. | Allow | Certificate Manager Agents |
D.3.12. certServer.ca.profiles
allow (list) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
list | List certificate profiles. | Allow | Certificate Manager Agents |
D.3.13. certServer.ca.registerUser
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
modify | Register a new agent. | Allow | Enterprise Administrators |
read | Read existing agent information. | Allow | Enterprise Administrators |
D.3.14. certServer.ca.request.enrollment
allow (submit) user="anybody";allow (read,execute,assign,unassign) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | View an enrollment request. | Allow | Certificate Manager Agents |
execute | Modify the approval state of a request. | Allow | Certificate Manager Agents |
submit | Sumbit a request. | Allow | Anybody |
assign | Assign a request to a Certificate Manager agent. | Allow | Certificate Manager Agents |
unassign | Change the assignment of a request. | Allow | Certificate Manager Agents |
D.3.15. certServer.ca.request.profile
allow (approve,read) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
approve | Modify the approval state of a certificate profile-based certificate request. | Allow | Certificate Manager Agents |
read | View a certificate profile-based certificate request. | Allow | Certificate Manager Agents |
D.3.16. certServer.ca.requests
allow (list) group="Certificate Manager Agents"|| group="Registration Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | ||
---|---|---|---|---|---|
list | Retrieve details on a range of requests, and search for certificates using a complex filter. | Allow |
|
D.3.17. certServer.ca.systemstatus
allow (read) group="Certificate Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | View statistics. | Allow | Certificate Manager Agents |
D.3.18. certServer.ee.certchain
allow (download,read) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
download | Download the CA's certificate chain. | Allow | Anyone |
read | View the CA's certificate chain. | Allow | Anyone |
D.3.19. certServer.ee.certificate
allow (renew,revoke,read,import) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
renew | Submit a request to renew an existing certificate. | Allow | Anyone |
revoke | Submit a revocation request for a user certificate. | Allow | Anyone |
read | Retrieve and view certificates based on the certificate serial number or request ID. | Allow | Anyone |
import | Import a certificate based on serial number. | Allow | Anyone |
D.3.20. certServer.ee.certificates
allow (revoke,list) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
revoke | Submit a list of certificates to revoke. | Allow |
Subject of Certificate to be Revoked must match Certificate presented to authenticate to the CA.
|
list | Search for certificates matching specified criteria. | Allow | Anyone |
D.3.21. certServer.ee.crl
allow (read,add) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Retrieve and view the certificate revocation list. | Allow | Anyone |
add | Add CRLs to the OCSP server. | Allow | Anyone |
D.3.22. certServer.ee.profile
allow (submit,read) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
submit | Submit a certificate request through a certificate profile. | Allow | Anyone |
read | Displaying details of a certificate profile. | Allow | Anyone |
D.3.23. certServer.ee.profiles
allow (list) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
list | List certificate profiles. | Allow | Anyone |
D.3.24. certServer.ee.request.ocsp
allow (submit) ipaddress=".*"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
submit | Submit OCSP requests. | Allow | All IP addresses |
D.3.25. certServer.ee.request.revocation
allow (submit) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
submit | Submit a request to revoke a certificate. | Allow | Anyone |
D.3.26. certServer.ee.requestStatus
allow (read) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Retrieve the status of a request and serial numbers of any certificates that have been issued against that request. | Allow | Anyone |
D.3.27. certServer.job.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View basic job settings, job instance settings, and job plug-in settings. List job plug-ins and job instances. | Allow |
| |||
modify | Add and delete job plug-ins and job instances. Modify job plug-ins and job instances. | Allow | Administrators |
D.3.28. certServer.profile.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View certificate profile defaults and constraints, input, output, input configuration, output configuration, default configuration, policy constraints configuration, and certificate profile instance configuration. List certificate profile plug-ins and certificate profile instances. | Allow |
| |||
modify | Add, modify, and delete certificate profile defaults and constraints, input, output, and certificate profile instances. Add and modify default policy constraints configuration. | Allow | Administrators |
D.3.29. certServer.publisher.configuration
allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View LDAP server destination information, publisher plug-in configuration, publisher instance configuration, mapper plug-in configuration, mapper instance configuration, rules plug-in configuration, and rules instance configuration. List publisher plug-ins and instances, rules plug-ins and instances, and mapper plug-ins and instances. | Allow |
| |||
modify | Add and delete publisher plug-ins, publisher instances, mapper plug-ins, mapper instances, rules plug-ins, and rules instances. Modify publisher instances, mapper instances, rules instances, and LDAP server destination information. | Allow | Administrators |
D.3.30. certServer.securitydomain.domainxml
allow (read) user="anybody";allow (modify) group="Subsystem Group"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | ||
---|---|---|---|---|---|
read | View the security domain configuration. | Allow | Anybody | ||
modify | Modify the security domain configuration by changing instance information and adding and removing instances. | Allow |
|
D.4. Key Recovery Authority-Specific ACLs
D.4.1. certServer.job.configuration
allow (read) group="Administrators" || group="Key Recovery Authority Agents" || group="Auditors";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View basic job settings, job instance settings, and job plug-in settings. List job plug-ins and job instances. | Allow |
| |||
modify | Add and delete job plug-ins and job instances. Modify job plug-ins and job instances. | Allow | Administrators |
D.4.2. certServer.kra.certificate.transport
allow (read) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | View the transport certificate for the KRA instance. | Allow | Anyone |
D.4.3. certServer.kra.configuration
allow (read) group="Administrators" || group="Auditors" || group="Key Recovery Authority Agents" || allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | Read the number of required recovery agent approvals. | Allow |
| |||
modify | Change the number of required recovery agent approvals. | Allow | Administrators |
D.4.4. certServer.kra.connector
allow (submit) group="Trusted Managers"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
submit | Submit a new key archival request (for non-TMS only). | Allow | Trusted Managers |
D.4.5. certServer.kra.GenerateKeyPair
allow (execute) group="Key Recovery Authority Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
Execute | Execute server-side key generation (TMS only). | Allow | KRA Agents |
D.4.6. certServer.kra.getTransportCert
allow (download) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
download | Retrieve KRA transport certificate. | Allow | Enterprise Administrators |
D.4.7. certServer.kra.group
allow (modify,read) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |
---|---|---|---|---|
modify | Create, edit, or delete user and group entries for the instance. | Allow | Administrators | |
read | View user and group entries for the instance. | Allow |
|
D.4.8. certServer.kra.key
allow (read,recover,download) group="Key Recovery Authority Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Display public information about key archival record. | Allow | KRA Agents |
recover | Retrieve key information from the database to perform a recovery operation. | Allow | KRA Agents |
download | Download key information through the agent services pages. | Allow | KRA Agents |
D.4.9. certServer.kra.keys
allow (list) group="Key Recovery Authority Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
list | Search for and list a range of archived keys. | Allow | KRA Agents |
D.4.10. certServer.kra.registerUser
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
modify | Register a new user. | Allow | Enterprise Administrators |
read | Read existing user info. | Allow | Enterprise Administrators |
D.4.11. certServer.kra.request
allow (read) group="Key Recovery Authority Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | View a key archival or recovery request. | Allow | KRA Agents |
D.4.12. certServer.kra.request.status
allow (read) group="Key Recovery Authority Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Retrieve the status of a key recovery request in the agents services pages. | Allow | KRA Agents |
D.4.13. certServer.kra.requests
allow (list) group="Key Recovery Authority Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
list | Retrieve details on a range of key archival and recovery requests. | Allow | KRA Agents |
D.4.14. certServer.kra.systemstatus
allow (read) group="Key Recovery Authority Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | View statistics. | Allow | KRA Agents |
D.4.15. certServer.kra.TokenKeyRecovery
allow (submit) group="Key Recovery Authority Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
submit | Submit or initiate key recovery requests for a token recovery. | Allow | KRA Agents |
D.5. Online Certificate Status Manager-Specific ACLs
D.5.1. certServer.ee.crl
allow (read) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Retrieve and view the certificate revocation list. | Allow | Anyone |
D.5.2. certServer.ee.request.ocsp
allow (submit) ipaddress=".*"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
submit | Submit OCSP requests. | Allow | All IP addresses |
D.5.3. certServer.ocsp.ca
allow (add) group="Online Certificate Status Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
Add | Instruct the OCSP responder to respond to OCSP requests for a new CA. | Allow | OCSP Manager Agents |
D.5.4. certServer.ocsp.cas
allow (list) group="Online Certificate Status Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
list | Lists all of the Certificate Managers which publish CRLs to the OCSP responder. | Allow | Agents |
D.5.5. certServer.ocsp.certificate
allow (validate) group="Online Certificate Status Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
validate | Verifies the status of a specified certificate. | Allow | OCSP Agents |
D.5.6. certServer.ocsp.configuration
allow (read) group="Administrators" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | |||
---|---|---|---|---|---|---|
read | View OCSP plug-in information, OCSP configuration, and OCSP stores configuration. List OCSP stores configuration. | Allow |
| |||
modify | Modify the OCSP configuration, OCSP stores configuration, and default OCSP store. | Allow | Administrators |
D.5.7. certServer.ocsp.crl
allow (add) group="Online Certificate Status Manager Agents" || group="Trusted Managers"
Operations | Description | Allow/Deny Access | Targeted Users/Groups | ||
---|---|---|---|---|---|
add | Add new CRLs to those managed by the OCSP responder. | Allow |
|
D.5.8. certServer.ocsp.group
allow (modify,read) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
modify | Create, edit or delete user and group entries for the instance. | Allow | Administrators |
read | View user and group entries for the instance. | Allow | Administrators |
D.5.9. certServer.ocsp.info
allow (read) group="Online Certificate Status Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | View OCSP responder information. | Allow | OCSP Agents |
D.6. Token Key Service-Specific ACLs
D.6.1. certServer.tks.encrypteddata
allow(execute) group="Token Key Service Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
Execute | Encrypted data stored in the TKS. | Allow | TKS Agents |
D.6.2. certServer.tks.group
allow (modify,read) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
modify | Create, edit, or delete user and group entries for the instance. | Allow | Administrators |
read | View user and group entries for the instance. | Allow | Administrators |
D.6.3. certServer.tks.importTransportCert
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
modify | Update the transport certificate. | Allow | Enterprise Administrators |
read | Import the transport certificate. | Allow | Enterprise Administrators |
D.6.4. certServer.tks.keysetdata
allow (execute) group="Token Key Service Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
Execute | Create diversified key set data. | Allow | TKS Agents |
D.6.5. certServer.tks.registerUser
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
modify | Register a new agent. | Allow | Enterprise Administrators |
read | Read existing agent information. | Allow | Enterprise Administrators |
D.6.6. certServer.tks.sessionkey
allow (execute) group="Token Key Service Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
Execute | Create session keys generated by the TKS. | Allow | TKS Agents |
D.6.7. certServer.tks.randomdata
allow (execute) group="Token Key Service Manager Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
Execute | Generate random data. | Allow | TKS Agents |
D.7. TPS-specific ACLs
D.7.1. certServer.tps.account
allow (login,logout) user="anybody"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
login | Log into the TPS | Allow | All users |
logout | Log out from the TPS | Allow | All users |
D.7.2. certServer.tps.authenticators
allow (read,change-status,add,modify,remove) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Read authenticators | Allow | Administrators |
change-status | Change status of authenticators | Allow | Administrators |
add | Add authenticators | Allow | Administrators |
modify | Update authenticators | Allow | Administrators |
remove | Remove authenticators | Allow | Administrators |
D.7.3. certServer.tps.audit
allow (read,modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Read configuration audit settings | Allow | Administrators |
modify | Update configuration audit settings | Allow | Administrators |
D.7.4. certServer.tps.config
allow (read,modify) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Read configuration settings | Allow | Administrators |
modify | Update configuration settings | Allow | Administrators |
D.7.5. certServer.tps.connectors
allow (read,change-status,add,modify,remove) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Read connectors | Allow | Administrators |
change-status | Change the status of connectors | Allow | Administrators |
add | Add connectors | Allow | Administrators |
modify | Update connectors | Allow | Administrators |
remove | Remove connectors | Allow | Administrators |
D.7.6. certServer.tps.groups
allow (execute) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
execute | Execute group operations | Allow | Administrators |
D.7.7. certServer.tps.users
allow (execute) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
execute | Execute user operations | Allow | Administrators |
D.7.8. certServer.tps.profiles
allow (read,change-status) group="Administrators" || group="TPS Agents" ; allow (add,modify,remove) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Read profiles | Allow | Administrators, TPS agents |
change-status | Change status of profiles | Allow | Administrators, TPS agents |
add | Add profiles | Allow | Administrators |
modify | Update profiles | Allow | Administrators |
remove | Remove profiles | Allow | Administrators |
D.7.9. certServer.tps.profile-mappings
allow (read,change-status,add,modify,remove) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Read profile mappings | Allow | Administrators |
change-status | Change status of profile mappings | Allow | Administrators |
add | Add profile mappings | Allow | Administrators |
modify | Update profile settings | Allow | Administrators |
remove | Remove profile settings | Allow | Administrators |
D.7.10. certServer.tps.selftests
allow (read,execute) group="Administrators"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Read self tests | Allow | Administrators |
execute | Execute self tests | Allow | Administrators |
D.7.11. certServer.tps.tokens
allow (read) group="Administrators" || group="TPS Agents" || group="TPS Operators"; allow (add,remove) group="Administrators" ; allow (modify) group="TPS Agents"
Operations | Description | Allow/Deny Access | Targeted Users/Groups |
---|---|---|---|
read | Read tokens | Allow | Administrators, TPS agents, TPS operators |
add | Add tokens | Allow | Administrators |
remove | Remove tokens | Allow | Administrators |
modify | Update tokens | Allow | TPS agents |
Appendix E. Audit Events
- The Java identifier of the thread. For example:
0.localhost-startStop-1
- The time stamp the event occurred at. For example:
[21/Jan/2019:17:53:00 IST]
- The log source (14 is SIGNED_AUDIT):
[14]
- The current log level (6 is Security-related events. See the Log Levels (Message Categories) section in the Red Hat Certificate System Planning, Installation, and Deployment Guide (Common Criteria Edition)). For example:
[6]
- The information about the log event (which is log event specific; see Section E.2, “Audit Event Descriptions” for information about each field in a particular log event). For example:
[AuditEvent=AUDIT_LOG_STARTUP][SubjectID=$System$][Outcome=Success] audit function startup
E.1. Required Audit Events and Their Examples
FAU_GEN.1
- Start-up of the TSF audit functions
AUDIT_LOG_STARTUP
0.localhost-startStop-1 - [21/Jan/2019:17:53:00 IST] [14] [6] [AuditEvent=AUDIT_LOG_STARTUP][SubjectID=$System$][Outcome=Success] audit function startup
- All administrative actions invoked through the TFS interface
CONFIG_CERT_PROFILE
0.http-bio-20443-exec-35 - [02/Jan/2019:05:05:09 EST] [14] [6] [AuditEvent=CONFIG_CERT_PROFILE][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=Scope;;rules+Operation;;OP_ADD+Resource;;caAgentExample+class_id;;caEnrollImpl+name;;caAgentExample Enrollment Profile+description;;This certificate profile is for enrolling user certificates+visible;;true] certificate profile configuration parameter(s) change
CERT_PROFILE_APPROVAL
0.http-bio-8443-exec-8 - [15/Nov/2018:15:37:19 PST] [14] [6] [AuditEvent=CERT_PROFILE_APPROVAL][SubjectID=cfuEC-0830-agent-2][Outcome=Success][ProfileID=caTPSCert][Op=disapprove] certificate profile approval
CONFIG_OCSP_PROFILE
0.http-bio-22443-exec-11 - [30/Jan/2019:06:18:02 EST] [14] [6] [AuditEvent=CONFIG_OCSP_PROFILE][SubjectID=ocspadmin][Outcome=Success][ParamNameValPairs=Scope;;ocspStoresRules+Operation;;OP_MODIFY+Resource;;ldapStore+includeNextUpdate;;false+byName;;true+implName;;com.netscape.cms.ocsp.LDAPStore+numConns;;0+caCertAttr;;cACertificate;binary+notFoundAsGood;;true+crlAttr;;certificateRevocationList;binary] OCSP profile configuration parameter(s) change
CONFIG_CRL_PROFILE
0.http-bio-20443-exec-48 - [29/Jan/2019:04:29:29 EST] [14] [6] [AuditEvent=CONFIG_CRL_PROFILE][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=Scope;;crl+Operation;;OP_MODIFY+Resource;;MasterCRL+enableCRLUpdates;;true+updateSchema;;1+extendedNextUpdate;;true+alwaysUpdate;;false+enableDailyUpdates;;true+dailyUpdates;;4:30+enableUpdateInterval;;true+autoUpdateInterval;;240+nextUpdateGracePeriod;;0+nextAsThisUpdateExtension;;0] CRL profile configuration parameter(s) change
CONFIG_AUTH
0.http-bio-20443-exec-11 - [15/Jan/2019:08:36:39 EST] [14] [6] [AuditEvent=CONFIG_AUTH][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=Scope;;instance+Operation;;OP_ADD+Resource;;plug502+implName;;UidPwdDirAuth+ldap.ldapconn.host;;server.example.com+dnpattern;;uid=test,ou=people,o=topology-02-CA+ldapStringAttributes;;mail+ldap.ldapconn.version;;3+ldap.ldapconn.port;;3389+ldap.maxConns;;10+ldap.basedn;;dc=example,dc=com+ldap.minConns;;3+ldap.ldapconn.secureConn;;false+ldapByteAttributes;;uid+ldap.password;;(sensitive)+ldap.ldapauth.authtype;;BasicAuth+ldap.ldapauth.bindDN;;cn=direcory manager] authentication configuration parameter(s) change
0.http-bio-20080-exec-25 - [29/Jan/2019:04:54:14 EST] [14] [6] [AuditEvent=CONFIG_AUTH][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=Scope;;instance+Operation;;OP_ADD+Resource;;plug7487+implName;;AgentCertAuth] authentication configuration parameter(s) change
CONFIG_ROLE(success)
0.http-bio-20443-exec-50 - [18/Jan/2019:04:08:45 EST] [14] [6] [AuditEvent=CONFIG_ROLE][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=Scope;;certs+Operation;;OP_ADD+Resource;;CA_AdminV+cert;;-----BEGIN CERTIFICATE-----MIIDYTCCAkmgAwIBAgIBfz...-----END CERTIFICATE-----] role configuration parameter(s) change
CONFIG_ROLE(Failure)
0.http-bio-20443-exec-39 - [18/Jan/2019:04:08:57 EST] [14] [6] [AuditEvent=CONFIG_ROLE][SubjectID=caadmin][Outcome=Failure][ParamNameValPairs=Scope;;users+Operation;;OP_ADD+Resource;;CA_AdminUnTrusted+password;;********+phone;;<null>+fullname;;CA_AdminUnTrusted+state;;<null>+userType;;<null>+email;;<null>] role configuration parameter(s) change
CONFIG_ACL
- CA
CA = 0.http-bio-20443-exec-18 - [29/Jan/2019:05:15:16 EST] [14] [6] [AuditEvent=CONFIG_ACL][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=Scope;;acls+Operation;;OP_MODIFY+Resource;;testACL+aci;;allow (read,allow) group="testGroup"+desc;;ALLOW READ to testGroup+rights;;read,allow] ACL configuration parameter(s) change
CONFIG_SIGNED_AUDIT
- CA
0.http-bio-20443-exec-20 - [29/Jan/2019:02:44:04 EST] [14] [6] [AuditEvent=CONFIG_SIGNED_AUDIT][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=Action;;disable] signed audit configuration parameter(s) change
- KRA
0.http-bio-21443-exec-9 - [30/Jan/2019:08:15:11 EST] [14] [6] [AuditEvent=CONFIG_SIGNED_AUDIT][SubjectID=kraadmin][Outcome=Success][ParamNameValPairs=Action;;enable] signed audit configuration parameter(s) change
- OCSP
0.http-bio-22443-exec-17 - [30/Jan/2019:08:17:06 EST] [14] [6] [AuditEvent=CONFIG_SIGNED_AUDIT][SubjectID=ocspadmin][Outcome=Success][ParamNameValPairs=Action;;enable] signed audit configuration parameter(s) change
- TKS
0.http-bio-23443-exec-15 - [30/Jan/2019:08:18:52 EST] [14] [6] [AuditEvent=CONFIG_SIGNED_AUDIT][SubjectID=tksadmin][Outcome=Success][ParamNameValPairs=Action;;enable] signed audit configuration parameter(s) change
- TPS
0.http-bio-25443-exec-5 - [30/Jan/2019:08:20:03 EST] [14] [6] [AuditEvent=CONFIG_SIGNED_AUDIT][SubjectID=tpsadmin][Outcome=Success][ParamNameValPairs=Action;;enable] signed audit configuration parameter(s) change
CONFIG_TRUSTED_PUBLIC_KEY
- CA
0.http-bio-20443-exec-9 - [29/Jan/2019:03:25:02 EST] [14] [6] [AuditEvent=CONFIG_TRUSTED_PUBLIC_KEY][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=Scope;;installCert+Operation;;OP_MODIFY+Resource;;trustedCACert+pkcs10;;-----BEGIN CERTIFICATE-----MIIEBDCCAuygAwI...-----END CERTIFICATE-----+nickname;;<null>+pathname;;<null>+serverRoot;;<null>+serverID;;instanceID] certificate database configuration
- KRA
0.http-bio-21443-exec-17 - [30/Jan/2019:08:29:07 EST] [14] [6] [AuditEvent=CONFIG_TRUSTED_PUBLIC_KEY][SubjectID=kraadmin][Outcome=Success][ParamNameValPairs=Scope;;installCert+Operation;;OP_MODIFY+Resource;;trustedCACert+pkcs10;;-----BEGIN CERTIFICATE-----MIIEBDCCAuygAw...-----END CERTIFICATE-----+nickname;;<null>+pathname;;<null>+serverRoot;;<null>+serverID;;instanceID] certificate database configuration
- OCSP
0.http-bio-22443-exec-25 - [30/Jan/2019:08:41:08 EST] [14] [6] [AuditEvent=CONFIG_TRUSTED_PUBLIC_KEY][SubjectID=ocspadmin][Outcome=Success][ParamNameValPairs=Scope;;installCert+Operation;;OP_MODIFY+Resource;;trustedCACert+pkcs10;;-----BEGIN CERTIFICATE-----MIIEBDCCAuygAwIB...-----END CERTIFICATE-----+nickname;;<null>+pathname;;<null>+serverRoot;;<null>+serverID;;instanceID] certificate database configuration
- TKS
0.http-bio-23443-exec-23 - [30/Jan/2019:08:45:40 EST] [14] [6] [AuditEvent=CONFIG_TRUSTED_PUBLIC_KEY][SubjectID=tksadmin][Outcome=Success][ParamNameValPairs=Scope;;installCert+Operation;;OP_MODIFY+Resource;;trustedCACert+pkcs10;;-----BEGIN CERTIFICATE-----MIIEBDCCAuygAwIBA...-----END CERTIFICATE-----+nickname;;<null>+pathname;;<null>+serverRoot;;<null>+serverID;;instanceID] certificate database configuration
- TPS
0.http-bio-22443-exec-23 - [30/Jan/2019:08:46:13 EST] [14] [6] [AuditEvent=CONFIG_TRUSTED_PUBLIC_KEY][SubjectID=tpsadmin][Outcome=Success][ParamNameValPairs=Scope;;installCert+Operation;;OP_MODIFY+Resource;;trustedCACert+pkcs10;;-----BEGIN CERTIFICATE-----MIIEBDCCAuygAwIBA...-----END CERTIFICATE-----+nickname;;<null>+pathname;;<null>+serverRoot;;<null>+serverID;;instanceID] certificate database configuration
CONFIG_DRM
0.http-bio-21443-exec-1 - [24/Jan/2019:09:36:52 EST] [14] [6] [AuditEvent=CONFIG_DRM][SubjectID=kraadmin][Outcome=Success][ParamNameValPairs=Scope;;general+Operation;;OP_MODIFY+Resource;;RS_ID_CONFIG+noOfRequiredRecoveryAgents;;2] DRM configuration parameter(s) change
OCSP_ADD_CA_REQUEST_PROCESSED
- Success
0.http-bio-22443-exec-24 - [29/Jan/2019:03:15:59 EST] [14] [6] [AuditEvent=OCSP_ADD_CA_REQUEST_PROCESSED][SubjectID=ocspadmin][Outcome=Success][CASubjectDN=CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_example.com] Add CA for OCSP Responde
- Failure
0.http-bio-22443-exec-12 - [30/Jan/2019:06:44:32 EST] [14] [6] [AuditEvent=OCSP_ADD_CA_REQUEST_PROCESSED][SubjectID=ocspadmin][Outcome=Failure][CASubjectDN=<null>] Add CA for OCSP Responder
OCSP_REMOVE_CA_REQUEST_PROCESSED
0.http-bio-22443-exec-24 - [29/Jan/2019:03:13:43 EST] [14] [6] [AuditEvent=OCSP_REMOVE_CA_REQUEST_PROCESSED][SubjectID=ocspadmin][Outcome=Success][CASubjectDN=CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_example.com] Remove CA for OCSP Responder is successful
SECURITY_DOMAIN_UPDATE
- Operation: Issue_token
0.http-bio-20443-exec-10 - [16/Jan/2019:03:19:57 EST] [14] [6] [AuditEvent=SECURITY_DOMAIN_UPDATE][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=operation;;issue_token+token;;2433856184928074456+ip;;192.0.2.1+uid;;caadmin+groupname;;Enterprise TKS Administrators] security domain update
- Operation: Add
0.http-bio-20443-exec-18 - [02/Jan/2019:04:39:21 EST] [14] [6] [AuditEvent=SECURITY_DOMAIN_UPDATE][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=host;;server.example.com+name;;OCSP server.example.com 22443+sport;;22443+clone;;false+type;;OCSP+operation;;add] security domain update
CONFIG_SERIAL_NUMBER
- CA
0.http-bio-20443-exec-2 - [29/Jan/2019:07:53:21 EST] [14] [6] [AuditEvent=CONFIG_SERIAL_NUMBER][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=source;;updateNumberRange+type;;request+beginNumber;;9990001+endNumber;;10000000] serial number range update
- KRA
0.http-bio-21443-exec-7 - [18/Jan/2019:19:11:47 EST] [14] [6] [AuditEvent=CONFIG_SERIAL_NUMBER][SubjectID=caadmin][Outcome=Success][ParamNameValPairs=source;;updateNumberRange+type;;serialNo+beginNumber;;fff0001+endNumber;;10000000] serial number range update
FDP_CER_EXT.1 (extended)
- Certificate generation
CERT_REQUEST_PROCESSED (SUCCESS)
0.http-bio-8443-exec-24 - [07/Sep/2018:10:21:57 PDT] [14] [6] [AuditEvent=CERT_REQUEST_PROCESSED][SubjectID=caadmin][Outcome=Success][ReqID=7][CertSerialNum=7] certificate request processed
FDP_CER_EXT.2 (extended)
- Linking of certificates to certificate requests
PROFILE_CERT_REQUEST
0.http-bio-8443-exec-24 - [07/Sep/2018:10:21:57 PDT] [14] [6] [AuditEvent=PROFILE_CERT_REQUEST][SubjectID=caadmin][Outcome=Success][ReqID=7][ProfileID=caECFullCMCUserCert][CertSubject=CN=cfuEC-0830] certificate request made with certificate profiles
Note
TheReqID
field effectively links to theReqID
field of a successfulCERT_REQUEST_PROCESSED
event.
FDP_CER_EXT.3
- Failed certificate approvals
CERT_REQUEST_PROCESSED (FAILURE)
0.http-bio-20443-exec-4 - [21/Jan/2019:00:24:16 EST] [14] [6] [AuditEvent=CERT_REQUEST_PROCESSED][SubjectID=$NonRoleUser$][Outcome=Failure][ReqID=1483][InfoName=rejectReason][InfoValue=Request 1483 Rejected - Subject Name Not Matched UID=testuser00,E=example@example.com,CN=MyTestUser] certificate request processed
FIA_X509_EXT.1, FIA_X509_EXT.2
- Failed certificate validations; failed authentications
ACCESS_SESSION_ESTABLISH (FAILURE)
- User with revoked cert trying to perform an operation.
0.http-bio-21443-exec-9 - [12/Feb/2019:14:52:26 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.2][SubjectID=UID=KRA_AgentR,E=KRA_AgentR@example.org,CN=KRA_AgentR,OU=IDMQE,C=US][Outcome=Failure][Info=CERTIFICATE_REVOKED] access session establish failure
- User with expired cert trying to perform an operation.
0.http-bio-21443-exec-9 - [12/Feb/2019:14:52:26 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.2][SubjectID=UID=KRA_AgentR,E=KRA_AgentR@example.org,CN=KRA_AgentR,OU=IDMQE,C=US][Outcome=Failure][Info=CERTIFICATE_EXPIRED] access session establish failure
- CMC enrollment request submitted using a TLS client cert issued by an unknown CA.
0.http-bio-20443-exec-28 - [12/Feb/2019:16:31:08 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.2][SubjectID=CN=CA Signing Certificate,OU=pki-tomcat,O=EXAMPLE][Outcome=Failure][Info=UNKNOWN_CA] access session establish failure
- When client protocol does not match. For example: client use
ssl3
but server does not support.0.http-bio-20443-exec-11 - [12/Feb/2019:16:35:26 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.2][SubjectID=][Outcome=Failure][Info=HANDSHAKE_FAILURE] access session establish failure
- For incorrect protocol version. Example server supports
tls1.1
andtls1.2
but client sendstls1
.0.http-bio-20443-exec-46 - [12/Feb/2019:16:39:10 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.2][SubjectID=][Outcome=Failure][Info=PROTOCOL_VERSION] access session establish failure
- When client sends list of cipher but Server have no list of ciphers.Server:
0.http-bio-21443-exec-3 - [13/Feb/2019:07:40:44 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.2][SubjectID=][Outcome=Failure][Info=INTERNAL_ERROR] access session establish failure
FIA_UIA_EXT.1
- Privileged user identification and authentication
ACCESS_SESSION_ESTABLISH
- CA Example
0.http-bio-8443-exec-1 - [10/Oct/2018:15:42:13 PDT] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.1][SubjectID=][Outcome=Success] access session establish success
- TPS Example
0.http-bio-25443-exec-1 - [02/Jan/2019:04:44:12 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.1][SubjectID=][Outcome=Success] access session establish success
AUTH
- CA Example
0.http-bio-8443-exec-1 - [28/Nov/2018:16:23:15 PST] [14] [6] [AuditEvent=AUTH][SubjectID=caagentJoe][Outcome=Success][AuthMgr=CMCAuth] authentication success
- TPS Example
0.http-bio-25443-exec-1 - [25/Jan/2019:13:00:59 IST] [14] [6] [AuditEvent=AUTH][SubjectID=tpsadmin][Outcome=Success][AuthMgr=passwdUserDBAuthMgr] authentication success
AUTHZ
- CA Example
0.http-bio-8443-exec-1 - [28/Nov/2018:16:23:15 PST] [14] [6] [AuditEvent=AUTHZ][SubjectID=caagentJoe][Outcome=Success][aclResource=certServer.ee.profile][Op=submit] authorization success
- TPS Example
0.http-bio-25443-exec-1 - [25/Jan/2019:13:00:59 IST] [14] [6] [AuditEvent=AUTHZ][SubjectID=tpsadmin][Outcome=Success][aclResource=certServer.tps.account][Op=login][Info=AccountResource.login] authorization success
ROLE_ASSUME
- CA Example
0.http-bio-8443-exec-1 - [28/Nov/2018:16:23:15 PST] [14] [6] [AuditEvent=ROLE_ASSUME][SubjectID=caagentJoe][Outcome=Success][Role=Certificate Manager Agents] assume privileged role
- TPS Example
0.http-bio-25443-exec-9 - [25/Jan/2019:13:00:07 IST] [14] [6] [AuditEvent=ROLE_ASSUME][SubjectID=cfu][Outcome=Success][Role=Certificate Manager Agents] assume privileged role
FMT_SMR.2
- Modifications to the group of users that are part of a role
CONFIG_ROLE
SeeCONFIG_ROLE
event above.
FPT_FLS.1
- Failure with preservation of secure state
SELFTESTS_EXECUTION
- CA Example
0.localhost-startStop-1 - [10/Jan/2019:00:47:57 EST] [14] [6] [AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] self tests execution (see selftests.log for details)
- TPS Example
0.localhost-startStop-1 - [22/Jan/2019:11:55:32 IST] [14] [6] [AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] self tests execution (see selftests.log for details)
FPT_KST_EXT.2
- Private/secret keys are stored by the HSM and the only operations to "access" those keys are through the TSF as signing operations.
CERT_REQUEST_PROCESSED (failure) 0.http-bio-20443-exec-8 - [28/Jan/2019:13:48:14 EST] [14] [6] [AuditEvent=CERT_REQUEST_PROCESSED][SubjectID=$Unidentified$][Outcome=Failure][ReqID=28][InfoName=rejectReason][InfoValue=Request Key Type RSA Not Matched Rejected - {1}] certificate request processed
FPT_RCV.1
- The fact that a failure or service discontinuity occurred. Resumption of the regular operation.
- Failure:
SELFTESTS_EXECUTION (Failure)
- CA Example
0.localhost-startStop-1 - [29/Jan/2019:13:29:03 UTC] [14] [6] [AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] self tests execution (see selftests.log for details)
- TPS Example
0.localhost-startStop-1 - [22/Jan/2019:11:55:32 IST] [14] [6] [AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] self tests execution (see selftests.log for details)
- Self-test log, see 13.3.2. Configuring Self-Tests in Red Hat Certificat Systemitem's Planning, Installation, and Deployment Guide.
- Resumption:
AUDIT_LOG_STARTUP; SELFTESTS_EXECUTION (Success)
- TPS Example
0.localhost-startStop-1 - [21/Jan/2019:16:47:44 IST] [14] [6] [AuditEvent=AUDIT_LOG_STARTUP][SubjectID=$System$][Outcome=Success] audit function startup
- CA Example
0.localhost-startStop-1 - [04/Feb/2019:18:29:38 EST] [14] [6] [AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Success] self tests execution (see selftests.log for details)
FPT_STM.1
- Changes to the time.
FPT_TUD_EXT.1
- Initiation of update.
FTA_SSL.4
- The termination of an interactive session.
ACCESS_SESSION_TERMINATED
0.http-bio-20443-exec-7 - [21/Jan/2019:03:42:17 EST] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=192.0.2.1][ServerIP=192.0.2.1][SubjectID=CN=PKI Administrator,E=caadmin@example.com,OU=topology-02-CA,O=topology-02_example.com][Outcome=Success][Info=CLOSE_NOTIFY] access session terminated
- TPS
0.http-bio-25443-exec-1 - [02/Jan/2019:04:44:12 EST] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=192.0.2.1][ServerIP=192.0.2.1][SubjectID=][Outcome=Success][Info=CLOSE_NOTIFY] access session
FTP_TRP.1
- Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions.
ACCESS_SESSION_ESTABLISH
2529:0.http-bio-20443-exec-8 - [29/Jan/2019:02:41:10 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.1][SubjectID=CN=PKI Administrator,E=tpsadmin@server.example.com,OU=topology-02-TPS,O=topology-02_example.com][Outcome=Failure][Info=UNKNOWN_CA] access session establish failure
- TPS
0.http-bio-25443-exec-4 - [25/Jan/2019:12:58:31 IST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=0:0:0:0:0:0:0:1][ServerIP=0:0:0:0:0:0:0:1][SubjectID=][Outcome=Failure][Info=RECORD_OVERFLOW] access session establish failure
ACCESS_SESSION_TERMINATED
0.http-bio-20443-exec-48 - [29/Jan/2019:04:30:49 EST] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=192.0.2.1][ServerIP=192.0.2.1][SubjectID=][Outcome=Success][Info=CLOSE_NOTIFY] access session terminated
- TPS
TPS=0.http-bio-25443-exec-19 - [25/Jan/2019:12:47:07 IST] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=192.0.2.1][ServerIP=192.0.2.1][SubjectID=][Outcome=Success][Info=CLOSE_NOTIFY] access session terminated
FCS_CKM.1 and FCS_CKM.2
- Not available. There are no TOE-related functions where a TOE subsystem generates (or requests the OE to generate) a non-ephemeral key. All system certificates are generated in the same manner as user keys during the installation, before the TOE is running and, thus, before the it can audit.
FCS_CKM_EXT.4
- Not available
FCS_COP.1(2)
- All occurrences of signature generation using a CA signing key.
CERT_SIGNING_INFO
records CA signing certificate key info at system startup0.authorityMonitor - [03/Jan/2019:02:33:35 EST] [14] [6] [AuditEvent=CERT_SIGNING_INFO][SubjectID=$System$][Outcome=Success][SKI=E3:D2:5B:2A:F5:76:FF:7B:48:CA:94:18:5F:7B:BD:6B:95:FB:8F:30][AuthorityID=dbec10a4-1264-4759-96d5-6d2aadbf9d34] certificate signing info
CERT_REQUEST_PROCESSED (success)
0.http-bio-20443-exec-378 - [19/Jan/2019:05:57:39 EST] [14] [6] [AuditEvent=CERT_REQUEST_PROCESSED][SubjectID=caadmin][Outcome=Success][ReqID=1352][CertSerialNum=984] certificate request processed
OCSP_SIGNING_INFO
records OCSP signing certificate key info at system startup0.http-bio-29443-exec-3 - [10/Oct/2018:14:15:24 PDT] [14] [6] [AuditEvent=OCSP_SIGNING_INFO][SubjectID=$System$][Outcome=Success][SKI=71:B1:D0:AE:44:DF:ED:D0:20:15:2B:E3:37:E8:EE:04:EB:D6:F1:44] OCSP signing info
OCSP_GENERATION (success)
0.http-nio-22080-exec-3 - [31/Jan/2019:15:34:47 EST] [14] [6] [AuditEvent=OCSP_GENERATION][SubjectID=$NonRoleUser$][Outcome=Success] OCSP response generation
CRL_SIGNING_INFO
records CRL signing certificate key info at system startup0.localhost-startStop-1 - [10/Jan/2019:09:10:27 EST] [14] [6] [AuditEvent=CRL_SIGNING_INFO][SubjectID=$System$][Outcome=Success][SKI=23:98:ED:52:5B:2C:27:C6:FF:7C:34:D1:D5:48:57:E9:B8:D1:4E:95] CRL signing info
FULL_CRL_GENERATION (success)
0.CRLIssuingPoint-testing123 - [30/Jan/2019:08:35:02 EST] [14] [6] [AuditEvent=FULL_CRL_GENERATION][SubjectID=$System$][Outcome=Success][CRLnum=6] Full CRL generation
DELTA_CRL_GENERATION (success)
0.CRLIssuingPoint-testing123 - [30/Jan/2019:08:35:01 EST] [14] [6] [AuditEvent=DELTA_CRL_GENERATION][SubjectID=$Unidentified$][Outcome=Success][CRLnum=5] Delta CRL generation
- Failure in signature generation.
CERT_REQUEST_PROCESSED (failure)
0.http-bio-20443-exec-8 - [28/Jan/2019:13:48:14 EST] [14] [6] [AuditEvent=CERT_REQUEST_PROCESSED][SubjectID=$Unidentified$][Outcome=Failure][ReqID=28][InfoName=rejectReason][InfoValue=Request Key Type RSA Not Matched Rejected - {1}] certificate request processed
OCSP_GENERATION (failure)
0.http-nio-22080-exec-6 - [31/Jan/2019:15:35:38 EST] [14] [6] [AuditEvent=OCSP_GENERATION][SubjectID=$NonRoleUser$][Outcome=Failure][FailureReason=Missing issuer certificate] OCSP response generation
FULL_CRL_GENERATION (failure)
FCS_HTTPS_EXT.1 and FCS_TLSS_EXT.2
- Failure to establish a HTTPS/TLS session.
ACCESS_SESSION_ESTABLISH (Failure)
See FTP_TRP.1
- Establishment/termination of a HTTPS/TLS session
ACCESS_SESSION_TERMINATED
See FIA_UIA_EXT.1
FCS_TLSC_EXT.2
- Failure to establish a TLS session.
CLIENT_ACCESS_SESSION_ESTABLISH (Failure)
0.http-bio-20443-exec-21 - [13/Feb/2019:07:48:08 EST] [14] [6] [AuditEvent=CLIENT_ACCESS_SESSION_ESTABLISH][ClientHost=192.0.2.1][ServerHost=pki1.example.com][ServerPort=21443][SubjectID=SYSTEM][Outcome=Failure][Info=send:java.io.IOException: SocketException cannot write on socket] access session failed to establish when Certificate System acts as client
When Server is not reachable by Client and Session ran into failures. In this scenario, CA acts as a client for KRA during Key Archival and KRA is not reachable by CA.0.http-bio-20443-exec-11 - [12/Feb/2019:18:20:03 EST] [14] [6] [AuditEvent=CLIENT_ACCESS_SESSION_ESTABLISH][ClientHost=192.0.2.1][ServerHost=pki1.example.com][ServerPort=21443][SubjectID=SYSTEM][Outcome=Failure][Info=send:java.io.IOException: Socket has been closed, and cannot be reused.] access session failed to establish when Certificate System acts as client
When CA's subsystem cert is revoked and it tried to access KRA.- KRA
0.http-bio-21443-exec-3 - [13/Feb/2019:08:15:53 EST] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=192.0.2.1][ServerIP=192.0.2.2][SubjectID=CN=Subsystem Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org][Outcome=Failure][Info=CERTIFICATE_REVOKED] access session establish failure
- CA
0.http-bio-20443-exec-10 - [13/Feb/2019:08:16:08 EST] [14] [6] [AuditEvent=CLIENT_ACCESS_SESSION_ESTABLISH][ClientHost=192.0.2.1][ServerHost=pki1.example.com][ServerPort=21443][SubjectID=SYSTEM][Outcome=Failure][Info=send:java.io.IOException: SocketException cannot write on socket] access session failed to establish when Certificate System acts as client
- Establishment/termination of a TLS session.
CLIENT_ACCESS_SESSION_TERMINATED
0.http-bio-8443-exec-6 - [10/Oct/2018:15:10:54 PDT] [14] [6] [AuditEvent=CLIENT_ACCESS_SESSION_TERMINATED][ClientHost=192.0.2.1][ServerHost=192.0.2.1][ServerPort=29443][SubjectID=SYSTEM][Outcome=Success][Info=CLOSE_NOTIFY] access session terminated when Certificate System acts as client
FDP_CRL_EXT.1
- Failure to generate a CRL.
FULL_CRL_GENERATION (failure)
0.http-bio-20444-exec-9 - [01/Feb/2019:15:40:38 EST] [14] [6] [AuditEvent=FULL_CRL_GENERATION][SubjectID=caadmin][Outcome=Failure][FailureReason=Record not found] Full CRL generation
FDP_OCSPG_EXT.1
- Failure to generate certificate status information.
OCSP_GENERATION (failure)
FIA_AFL.1
- The reaching of the threshold for the Unsuccessful Authentication Attempts. The action Taken. The re-enablement of disabled non-administrative accounts.Not available. For password authentication only. Certificate System provides certificate-based authentication only.
FIA_CMCS_EXT.1
- CMC requests (generated or received) containing certificate requests or revocation requests. CMC responses issued.
CMC_SIGNED_REQUEST_SIG_VERIFY
0.http-bio-20080-exec-22 - [24/Jan/2019:08:44:51 EST] [14] [6] [AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY][SubjectID=$NonRoleUser$][Outcome=Failure][ReqType=$Unidentified$][CertSubject=$Unidentified$][SignerInfo=$Unidentified$] agent signed CMC request signature verification
CMC_USER_SIGNED_REQUEST_SIG_VERIFY
- Successful request:
0.http-bio-20443-exec-1 - [18/Feb/2019:12:07:20 EST] [14] [6] [AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY][SubjectID=UID=test10,CN=test10,O=example.org][Outcome=Success][ReqType=enrollment][CertSubject=<null>][SignerInfo=UID=test10,CN=test10,O=example.org] User signed CMC request signature verification success
CMC_REQUEST_RECEIVED
- Successful request:
0.http-bio-20443-exec-13 - [29/Jan/2019:04:26:49 EST] [14] [6] [AuditEvent=CMC_REQUEST_RECEIVED][SubjectID=$Unidentified$][Outcome=Success][CMCRequest=MIICoAYJKoZIhv...] CMC request received
- Failed request:
0.http-bio-20443-exec-14 - [29/Jan/2019:07:15:27 EST] [14] [6] [AuditEvent=CMC_REQUEST_RECEIVED][SubjectID=$Unidentified$][Outcome=Success][CMCRequest=MIGOBgkqhkiG9w...] CMC request received
PROOF_OF_POSSESSION
(Enrollment Event)0.http-bio-20443-exec-13 - [29/Jan/2019:04:26:49 EST] [14] [6] [AuditEvent=PROOF_OF_POSSESSION][SubjectID=user1a][Outcome=Success][Info=method=EnrollProfile: verifyPOP: ] proof of possession
PROFILE_CERT_REQUEST
(Enrollment Event)0.http-bio-20443-exec-13 - [29/Jan/2019:04:26:49 EST] [14] [6] [AuditEvent=PROFILE_CERT_REQUEST][SubjectID=user1a][Outcome=Success][ReqID=31][ProfileID=caECFullCMCSharedTokenCert][CertSubject=UID=user1a,OU=People,DC=rhel76,DC=test] certificate request made with certificate profiles
CERT_STATUS_CHANGE_REQUEST
- Success:
0.http-bio-20443-exec-5 - [05/Feb/2019:05:57:12 EST] [14] [6] [AuditEvent=CERT_STATUS_CHANGE_REQUEST][SubjectID=caadmin][Outcome=Success][ReqID=121][CertSerialNum=0x67][RequestType=on-hold] certificate revocation/unrevocation request made
- Failure:
0.http-bio-20443-exec-13 - [05/Feb/2019:05:58:55 EST] [14] [6] [AuditEvent=CERT_STATUS_CHANGE_REQUEST][SubjectID=caadmin][Outcome=Failure][ReqID=<null>][CertSerialNum=0x67][RequestType=on-hold] certificate revocation/unrevocation request made
CERT_REQUEST_PROCESSED
- Successful request:
0.http-bio-20443-exec-13 - [29/Jan/2019:04:26:49 EST] [14] [6] [AuditEvent=CERT_REQUEST_PROCESSED][SubjectID=$Unidentified$][Outcome=Success][ReqID=31][CertSerialNum=20] certificate request processed
CERT_STATUS_CHANGE_REQUEST_PROCESSED
- Successful request:
0.http-bio-20443-exec-9 - [29/Jan/2019:07:43:36 EST] [14] [6] [AuditEvent=CERT_STATUS_CHANGE_REQUEST_PROCESSED][SubjectID=UID=user1a,OU=People,DC=rhel76,DC=test][Outcome=Success][ReqID=32][CertSerialNum=20][RequestType=revoke][RevokeReasonNum=Certificate_Hold][Approval=complete] certificate status change request processed
- Failed request:
0.http-bio-20443-exec-14 - [29/Jan/2019:07:15:27 EST] [14] [6] [AuditEvent=CERT_STATUS_CHANGE_REQUEST_PROCESSED][SubjectID=<null>][Outcome=Failure][ReqID=<null>][CertSerialNum=20][RequestType=revoke][RevokeReasonNum=Certificate_Hold][Approval=rejected][Info=CMCOutputTemplate: SharedSecret.getSharedToken(BigInteger serial): shrTok not found in metaInfo] certificate status change request processed
0.http-bio-20443-exec-20 - [29/Jan/2019:07:30:41 EST] [14] [6] [AuditEvent=CERT_STATUS_CHANGE_REQUEST_PROCESSED][SubjectID=UID=user1a,OU=People,DC=rhel76,DC=test][Outcome=Failure][ReqID=<null>][CertSerialNum=20][RequestType=revoke][RevokeReasonNum=Certificate_Hold][Approval=rejected][Info= certificate issuer DN and revocation request issuer DN do not match] certificate status change request processed
0.http-bio-20443-exec-16 - [29/Jan/2019:07:55:27 EST] [14] [6] [AuditEvent=CERT_STATUS_CHANGE_REQUEST_PROCESSED][SubjectID=<null>][Outcome=Failure][ReqID=<null>][CertSerialNum=20][RequestType=revoke][RevokeReasonNum=Certificate_Hold][Approval=rejected][Info= shared secret not found] certificate status change request processed
CMC_RESPONSE_SENT
- Enrollment
- Successful response
0.http-bio-20443-exec-13 - [29/Jan/2019:04:26:49 EST] [14] [6] [AuditEvent=CMC_RESPONSE_SENT][SubjectID=user1a][Outcome=Success][CMCResponse=MIIHTAYJKoZI...] CMC response sent
- Revocation
- Successful revocation
0.http-bio-20443-exec-9 - [29/Jan/2019:07:43:36 EST] [14] [6] [AuditEvent=CMC_RESPONSE_SENT][SubjectID=$Unidentified$][Outcome=Success][CMCResponse=MIIExgYJKoZ...] CMC response sent
- Failed revocation
- Revocation does not happen
0.http-bio-20443-exec-20 - [29/Jan/2019:07:30:41 EST] [14] [6] [AuditEvent=CMC_RESPONSE_SENT][SubjectID=$Unidentified$][Outcome=Success][CMCResponse=MIIFDgYJKoZIh...] CMC response sent
FPT_SKY_EXT.1(2)/OTH
AUTHZ
- Failure: Agent user attempts to retrieve audit log:
0.http-bio-8443-exec-2 - [22/Feb/2019:15:03:38 PST] [14] [6] [AuditEvent=AUTHZ][SubjectID=EC-CA-agent-2][Outcome=Failure][aclResource=certServer.log.content.signedAudit][Op=read][Info=Authorization Error] authorization failure
- Success: Auditor user retrieved audit log:
0.http-bio-8443-exec-13 - [22/Feb/2019:15:25:34 PST] [14] [6] [AuditEvent=AUTHZ][SubjectID=EC-CA-auditor][Outcome=Success][aclResource=certServer.log.content.signedAudit][Op=read][Info=AuditResource.getAuditFile] authorization success
FTP_ITC.1
- Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions.
- See FCS_HTTPS_EXT.1
- See FCS_TLSC_EXT.2
E.2. Audit Event Descriptions
####################### SIGNED AUDIT EVENTS ############################# # Common fields: # - Outcome: "Success" or "Failure" # - SubjectID: The UID of the user responsible for the operation # "$System$" or "SYSTEM" if system-initiated operation (e.g. log signing). # ######################################################################### # Required Audit Events # # Event: ACCESS_SESSION_ESTABLISH with [Outcome=Failure] # Description: This event is used when access session failed to establish. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientIP: Client IP address. # - ServerIP: Server IP address. # - SubjectID: Client certificate subject DN. # - Outcome: Failure # - Info: Failure reason. # LOGGING_SIGNED_AUDIT_ACCESS_SESSION_ESTABLISH_FAILURE=\ <type=ACCESS_SESSION_ESTABLISH>:[AuditEvent=ACCESS_SESSION_ESTABLISH]{0} access session establish failure # # Event: ACCESS_SESSION_ESTABLISH with [Outcome=Success] # Description: This event is used when access session was established successfully. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientIP: Client IP address. # - ServerIP: Server IP address. # - SubjectID: Client certificate subject DN. # - Outcome: Success # LOGGING_SIGNED_AUDIT_ACCESS_SESSION_ESTABLISH_SUCCESS=\ <type=ACCESS_SESSION_ESTABLISH>:[AuditEvent=ACCESS_SESSION_ESTABLISH]{0} access session establish success # # Event: ACCESS_SESSION_TERMINATED # Description: This event is used when access session was terminated. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientIP: Client IP address. # - ServerIP: Server IP address. # - SubjectID: Client certificate subject DN. # - Info: The TLS Alert received from NSS # - Outcome: Success # - Info: The TLS Alert received from NSS # LOGGING_SIGNED_AUDIT_ACCESS_SESSION_TERMINATED=\ <type=ACCESS_SESSION_TERMINATED>:[AuditEvent=ACCESS_SESSION_TERMINATED]{0} access session terminated # # Event: AUDIT_LOG_SIGNING # Description: This event is used when a signature on the audit log is generated (same as "flush" time). # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: Predefined to be "$System$" because this operation # associates with no user. # - Outcome: Success # - sig: The base-64 encoded signature of the buffer just flushed. # LOGGING_SIGNED_AUDIT_AUDIT_LOG_SIGNING_3=[AuditEvent=AUDIT_LOG_SIGNING][SubjectID={0}][Outcome={1}] signature of audit buffer just flushed: sig: {2} # # Event: AUDIT_LOG_STARTUP # Description: This event is used at audit function startup. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: # LOGGING_SIGNED_AUDIT_AUDIT_LOG_STARTUP_2=<type=AUDIT_LOG_STARTUP>:[AuditEvent=AUDIT_LOG_STARTUP][SubjectID={0}][Outcome={1}] audit function startup # # Event: AUTH with [Outcome=Failure] # Description: This event is used when authentication fails. # In case of TLS-client auth, only webserver env can pick up the TLS violation. # CS authMgr can pick up certificate mismatch, so this event is used. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: # - Outcome: Failure # (obviously, if authentication failed, you won't have a valid SubjectID, so # in this case, SubjectID should be $Unidentified$) # - AuthMgr: The authentication manager instance name that did # this authentication. # - AttemptedCred: The credential attempted and failed. # LOGGING_SIGNED_AUDIT_AUTH_FAIL=<type=AUTH>:[AuditEvent=AUTH]{0} authentication failure # # Event: AUTH with [Outcome=Success] # Description: This event is used when authentication succeeded. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of user who has been authenticated # - Outcome: Success # - AuthMgr: The authentication manager instance name that did # this authentication. # LOGGING_SIGNED_AUDIT_AUTH_SUCCESS=<type=AUTH>:[AuditEvent=AUTH]{0} authentication success # # Event: AUTHZ with [Outcome=Failure] # Description: This event is used when authorization has failed. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of user who has failed to be authorized for an action # - Outcome: Failure # - aclResource: The ACL resource ID as defined in ACL resource list. # - Op: One of the operations as defined with the ACL statement # e.g. "read" for an ACL statement containing "(read,write)". # - Info: # LOGGING_SIGNED_AUDIT_AUTHZ_FAIL=<type=AUTHZ>:[AuditEvent=AUTHZ]{0} authorization failure # # Event: AUTHZ with [Outcome=Success] # Description: This event is used when authorization is successful. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of user who has been authorized for an action # - Outcome: Success # - aclResource: The ACL resource ID as defined in ACL resource list. # - Op: One of the operations as defined with the ACL statement # e.g. "read" for an ACL statement containing "(read,write)". # LOGGING_SIGNED_AUDIT_AUTHZ_SUCCESS=<type=AUTHZ>:[AuditEvent=AUTHZ]{0} authorization success # # Event: CERT_PROFILE_APPROVAL # Description: This event is used when an agent approves/disapproves a certificate profile set by the # administrator for automatic approval. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id of the CA agent who approved the certificate enrollment profile # - Outcome: # - ProfileID: One of the profiles defined by the administrator # and to be approved by an agent. # - Op: "approve" or "disapprove". # LOGGING_SIGNED_AUDIT_CERT_PROFILE_APPROVAL_4=<type=CERT_PROFILE_APPROVAL>:[AuditEvent=CERT_PROFILE_APPROVAL][SubjectID={0}][Outcome={1}][ProfileID={2}][Op={3}] certificate profile approval # # Event: CERT_REQUEST_PROCESSED # Description: This event is used when certificate request has just been through the approval process. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of the agent who approves, rejects, or cancels # the certificate request. # - Outcome: # - ReqID: The request ID. # - InfoName: "certificate" (in case of approval), "rejectReason" # (in case of reject), or "cancelReason" (in case of cancel) # - InfoValue: The certificate (in case of success), a reject reason in # text, or a cancel reason in text. # - CertSerialNum: # LOGGING_SIGNED_AUDIT_CERT_REQUEST_PROCESSED=<type=CERT_REQUEST_PROCESSED>:[AuditEvent=CERT_REQUEST_PROCESSED]{0} certificate request processed # # Event: CERT_SIGNING_INFO # Description: This event indicates which key is used to sign certificates. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: Success # - SKI: Subject Key Identifier of the certificate signing certificate # - AuthorityID: (applicable only to lightweight CA) # LOGGING_SIGNED_AUDIT_CERT_SIGNING_INFO=<type=CERT_SIGNING_INFO>:[AuditEvent=CERT_SIGNING_INFO]{0} certificate signing info # # Event: CERT_STATUS_CHANGE_REQUEST # Description: This event is used when a certificate status change request (e.g. revocation) # is made (before approval process). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id of uer who performed the action # - Outcome: # - ReqID: The request ID. # - CertSerialNum: The serial number (in hex) of the certificate to be revoked. # - RequestType: "revoke", "on-hold", "off-hold" # LOGGING_SIGNED_AUDIT_CERT_STATUS_CHANGE_REQUEST=<type=CERT_STATUS_CHANGE_REQUEST>:[AuditEvent=CERT_STATUS_CHANGE_REQUEST]{0} certificate revocation/unrevocation request made # # Event: CERT_STATUS_CHANGE_REQUEST_PROCESSED # Description: This event is used when certificate status is changed (revoked, expired, on-hold, # off-hold). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of the agent that processed the request. # - Outcome: # - ReqID: The request ID. # - RequestType: "revoke", "on-hold", "off-hold" # - Approval: "complete", "rejected", or "canceled" # (note that "complete" means "approved") # - CertSerialNum: The serial number (in hex). # - RevokeReasonNum: One of the following number: # reason number reason # -------------------------------------- # 0 Unspecified # 1 Key compromised # 2 CA key compromised (should not be used) # 3 Affiliation changed # 4 Certificate superceded # 5 Cessation of operation # 6 Certificate is on-hold # - Info: # LOGGING_SIGNED_AUDIT_CERT_STATUS_CHANGE_REQUEST_PROCESSED=<type=CERT_STATUS_CHANGE_REQUEST_PROCESSED>:[AuditEvent=CERT_STATUS_CHANGE_REQUEST_PROCESSED]{0} certificate status change request processed # # Event: CLIENT_ACCESS_SESSION_ESTABLISH with [Outcome=Failure] # Description: This event is when access session failed to establish when Certificate System acts as client. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientHost: Client hostname. # - ServerHost: Server hostname. # - ServerPort: Server port. # - SubjectID: SYSTEM # - Outcome: Failure # - Info: # LOGGING_SIGNED_AUDIT_CLIENT_ACCESS_SESSION_ESTABLISH_FAILURE=\ <type=CLIENT_ACCESS_SESSION_ESTABLISH>:[AuditEvent=CLIENT_ACCESS_SESSION_ESTABLISH]{0} access session failed to establish when Certificate System acts as client # # Event: CLIENT_ACCESS_SESSION_ESTABLISH with [Outcome=Success] # Description: This event is used when access session was established successfully when # Certificate System acts as client. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientHost: Client hostname. # - ServerHost: Server hostname. # - ServerPort: Server port. # - SubjectID: SYSTEM # - Outcome: Success # LOGGING_SIGNED_AUDIT_CLIENT_ACCESS_SESSION_ESTABLISH_SUCCESS=\ <type=CLIENT_ACCESS_SESSION_ESTABLISH>:[AuditEvent=CLIENT_ACCESS_SESSION_ESTABLISH]{0} access session establish successfully when Certificate System acts as client # # Event: CLIENT_ACCESS_SESSION_TERMINATED # Description: This event is used when access session was terminated when Certificate System acts as client. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientHost: Client hostname. # - ServerHost: Server hostname. # - ServerPort: Server port. # - SubjectID: SYSTEM # - Outcome: Success # - Info: The TLS Alert received from NSS # LOGGING_SIGNED_AUDIT_CLIENT_ACCESS_SESSION_TERMINATED=\ <type=CLIENT_ACCESS_SESSION_TERMINATED>:[AuditEvent=CLIENT_ACCESS_SESSION_TERMINATED]{0} access session terminated when Certificate System acts as client # # Event: CMC_REQUEST_RECEIVED # Description: This event is used when a CMC request is received. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of user that triggered this event. # If CMC requests is signed by an agent, SubjectID should # be that of the agent. # In case of an unsigned request, it would bear $Unidentified$. # - Outcome: # - CMCRequest: Base64 encoding of the CMC request received # LOGGING_SIGNED_AUDIT_CMC_REQUEST_RECEIVED_3=<type=CMC_REQUEST_RECEIVED>:[AuditEvent=CMC_REQUEST_RECEIVED][SubjectID={0}][Outcome={1}][CMCRequest={2}] CMC request received # # Event: CMC_RESPONSE_SENT # Description: This event is used when a CMC response is sent. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of user that triggered this event. # - Outcome: # - CMCResponse: Base64 encoding of the CMC response sent # LOGGING_SIGNED_AUDIT_CMC_RESPONSE_SENT_3=<type=CMC_RESPONSE_SENT>:[AuditEvent=CMC_RESPONSE_SENT][SubjectID={0}][Outcome={1}][CMCResponse={2}] CMC response sent # # Event: CMC_SIGNED_REQUEST_SIG_VERIFY # Description: This event is used when agent signed CMC certificate requests or revocation requests # are submitted and signature is verified. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: the user who signed the CMC request (success case) # - Outcome: # - ReqType: The request type (enrollment, or revocation). # - CertSubject: The certificate subject name of the certificate request. # - SignerInfo: A unique String representation for the signer. # LOGGING_SIGNED_AUDIT_CMC_SIGNED_REQUEST_SIG_VERIFY=<type=CMC_SIGNED_REQUEST_SIG_VERIFY>:[AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY]{0} agent signed CMC request signature verification # # Event: CMC_USER_SIGNED_REQUEST_SIG_VERIFY # Description: This event is used when CMC (user-signed or self-signed) certificate requests or revocation requests # are submitted and signature is verified. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: the user who signed the CMC request (success case) # - Outcome: # - ReqType: The request type (enrollment, or revocation). # - CertSubject: The certificate subject name of the certificate request. # - CMCSignerInfo: A unique String representation for the CMC request signer. # - info: # LOGGING_SIGNED_AUDIT_CMC_USER_SIGNED_REQUEST_SIG_VERIFY_FAILURE=<type=CMC_USER_SIGNED_REQUEST_SIG_VERIFY>:[AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY]{0} User signed CMC request signature verification failure LOGGING_SIGNED_AUDIT_CMC_USER_SIGNED_REQUEST_SIG_VERIFY_SUCCESS=<type=CMC_USER_SIGNED_REQUEST_SIG_VERIFY>:[AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY]{0} User signed CMC request signature verification success # # Event: CONFIG_ACL # Description: This event is used when configuring ACL information. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_ACL_3=<type=CONFIG_ACL>:[AuditEvent=CONFIG_ACL][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] ACL configuration parameter(s) change # # Event: CONFIG_AUTH # Description: This event is used when configuring authentication. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # --- Password MUST NOT be logged --- # LOGGING_SIGNED_AUDIT_CONFIG_AUTH_3=<type=CONFIG_AUTH>:[AuditEvent=CONFIG_AUTH][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] authentication configuration parameter(s) change # # Event: CONFIG_CERT_PROFILE # Description: This event is used when configuring certificate profile # (general settings and certificate profile). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_CERT_PROFILE_3=<type=CONFIG_CERT_PROFILE>:[AuditEvent=CONFIG_CERT_PROFILE][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] certificate profile configuration parameter(s) change # # Event: CONFIG_CRL_PROFILE # Description: This event is used when configuring CRL profile # (extensions, frequency, CRL format). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_CRL_PROFILE_3=<type=CONFIG_CRL_PROFILE>:[AuditEvent=CONFIG_CRL_PROFILE][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] CRL profile configuration parameter(s) change # # Event: CONFIG_DRM # Description: This event is used when configuring KRA. # This includes key recovery scheme, change of any secret component. # Applicable subsystems: KRA # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # --- secret component (password) MUST NOT be logged --- # LOGGING_SIGNED_AUDIT_CONFIG_DRM_3=<type=CONFIG_DRM>:[AuditEvent=CONFIG_DRM][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] DRM configuration parameter(s) change # # Event: CONFIG_OCSP_PROFILE # Description: This event is used when configuring OCSP profile # (everything under Online Certificate Status Manager). # Applicable subsystems: OCSP # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_OCSP_PROFILE_3=<type=CONFIG_OCSP_PROFILE>:[AuditEvent=CONFIG_OCSP_PROFILE][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] OCSP profile configuration parameter(s) change # # Event: CONFIG_ROLE # Description: This event is used when configuring role information. # This includes anything under users/groups, add/remove/edit a role, etc. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_ROLE=<type=CONFIG_ROLE>:[AuditEvent=CONFIG_ROLE]{0} role configuration parameter(s) change # # Event: CONFIG_SERIAL_NUMBER # Description: This event is used when configuring serial number ranges # (when requesting a serial number range when cloning, for example). # Applicable subsystems: CA, KRA # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_SERIAL_NUMBER_1=<type=CONFIG_SERIAL_NUMBER>:[AuditEvent=CONFIG_SERIAL_NUMBER][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] serial number range update # # Event: CONFIG_SIGNED_AUDIT # Description: This event is used when configuring signedAudit. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_SIGNED_AUDIT=<type=CONFIG_SIGNED_AUDIT>:[AuditEvent=CONFIG_SIGNED_AUDIT]{0} signed audit configuration parameter(s) change # # Event: CONFIG_TRUSTED_PUBLIC_KEY # Description: This event is used when: # 1. "Manage Certificate" is used to edit the trustness of certificates # and deletion of certificates # 2. "Certificate Setup Wizard" is used to import CA certificates into the # certificate database (Although CrossCertificatePairs are stored # within internaldb, audit them as well) # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: ID of administrator who performed this configuration # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_TRUSTED_PUBLIC_KEY=<type=CONFIG_TRUSTED_PUBLIC_KEY>:[AuditEvent=CONFIG_TRUSTED_PUBLIC_KEY]{0} certificate database configuration # # Event: CRL_SIGNING_INFO # Description: This event indicates which key is used to sign CRLs. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: # - SKI: Subject Key Identifier of the CRL signing certificate # LOGGING_SIGNED_AUDIT_CRL_SIGNING_INFO=<type=CRL_SIGNING_INFO>:[AuditEvent=CRL_SIGNING_INFO]{0} CRL signing info # # Event: DELTA_CRL_GENERATION # Description: This event is used when delta CRL generation is complete. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: $Unidentified$ # - Outcome: "Success" when delta CRL is generated successfully, "Failure" otherwise. # - CRLnum: The CRL number that identifies the CRL # - Info: # - FailureReason: # LOGGING_SIGNED_AUDIT_DELTA_CRL_GENERATION=<type=DELTA_CRL_GENERATION>:[AuditEvent=DELTA_CRL_GENERATION]{0} Delta CRL generation # # Event: FULL_CRL_GENERATION # Description: This event is used when full CRL generation is complete. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: "Success" when full CRL is generated successfully, "Failure" otherwise. # - CRLnum: The CRL number that identifies the CRL # - Info: # - FailureReason: # LOGGING_SIGNED_AUDIT_FULL_CRL_GENERATION=<type=FULL_CRL_GENERATION>:[AuditEvent=FULL_CRL_GENERATION]{0} Full CRL generation # # Event: PROFILE_CERT_REQUEST # Description: This event is used when a profile certificate request is made (before approval process). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of user that triggered this event. # If CMC enrollment requests signed by an agent, SubjectID should # be that of the agent. # - Outcome: # - CertSubject: The certificate subject name of the certificate request. # - ReqID: The certificate request ID. # - ProfileID: One of the certificate profiles defined by the # administrator. # LOGGING_SIGNED_AUDIT_PROFILE_CERT_REQUEST_5=<type=PROFILE_CERT_REQUEST>:[AuditEvent=PROFILE_CERT_REQUEST][SubjectID={0}][Outcome={1}][ReqID={2}][ProfileID={3}][CertSubject={4}] certificate request made with certificate profiles # # Event: PROOF_OF_POSSESSION # Description: This event is used for proof of possession during certificate enrollment processing. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id that represents the authenticated user # - Outcome: # - Info: some information on when/how it occurred # LOGGING_SIGNED_AUDIT_PROOF_OF_POSSESSION_3=<type=PROOF_OF_POSSESSION>:[AuditEvent=PROOF_OF_POSSESSION][SubjectID={0}][Outcome={1}][Info={2}] proof of possession # # Event: OCSP_ADD_CA_REQUEST_PROCESSED # Description: This event is used when an add CA request to the OCSP Responder is processed. # Applicable subsystems: OCSP # Enabled by default: Yes # Fields: # - SubjectID: OCSP administrator user id # - Outcome: "Success" when CA is added successfully, "Failure" otherwise. # - CASubjectDN: The subject DN of the leaf CA cert in the chain. # LOGGING_SIGNED_AUDIT_OCSP_ADD_CA_REQUEST_PROCESSED=<type=OCSP_ADD_CA_REQUEST_PROCESSED>:[AuditEvent=OCSP_ADD_CA_REQUEST_PROCESSED]{0} Add CA for OCSP Responder # # Event: OCSP_GENERATION # Description: This event is used when an OCSP response generated is complete. # Applicable subsystems: CA, OCSP # Enabled by default: Yes # Fields: # - SubjectID: $NonRoleUser$ # - Outcome: "Success" when OCSP response is generated successfully, "Failure" otherwise. # - FailureReason: # LOGGING_SIGNED_AUDIT_OCSP_GENERATION=<type=OCSP_GENERATION>:[AuditEvent=OCSP_GENERATION]{0} OCSP response generation # # Event: OCSP_REMOVE_CA_REQUEST_PROCESSED with [Outcome=Failure] # Description: This event is used when a remove CA request to the OCSP Responder is processed and failed. # Applicable subsystems: OCSP # Enabled by default: Yes # Fields: # - SubjectID: OCSP administrator user id # - Outcome: Failure # - CASubjectDN: The subject DN of the leaf CA certificate in the chain. # LOGGING_SIGNED_AUDIT_OCSP_REMOVE_CA_REQUEST_PROCESSED_FAILURE=<type=OCSP_REMOVE_CA_REQUEST_PROCESSED>:[AuditEvent=OCSP_REMOVE_CA_REQUEST_PROCESSED]{0} Remove CA for OCSP Responder has failed # # Event: OCSP_REMOVE_CA_REQUEST_PROCESSED with [Outcome=Success] # Description: This event is used when a remove CA request to the OCSP Responder is processed successfully. # Applicable subsystems: OCSP # Enabled by default: Yes # Fields: # - SubjectID: OCSP administrator user id # - Outcome: "Success" when CA is removed successfully, "Failure" otherwise. # - CASubjectDN: The subject DN of the leaf CA certificate in the chain. # LOGGING_SIGNED_AUDIT_OCSP_REMOVE_CA_REQUEST_PROCESSED_SUCCESS=<type=OCSP_REMOVE_CA_REQUEST_PROCESSED>:[AuditEvent=OCSP_REMOVE_CA_REQUEST_PROCESSED]{0} Remove CA for OCSP Responder is successful # # Event: OCSP_SIGNING_INFO # Description: This event indicates which key is used to sign OCSP responses. # Applicable subsystems: CA, OCSP # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: # - SKI: Subject Key Identifier of the OCSP signing certificate # - AuthorityID: (applicable only to lightweight CA) # LOGGING_SIGNED_AUDIT_OCSP_SIGNING_INFO=<type=OCSP_SIGNING_INFO>:[AuditEvent=OCSP_SIGNING_INFO]{0} OCSP signing info # # Event: ROLE_ASSUME # Description: This event is used when a user assumes a role. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: # - Outcome: # - Role: One of the valid roles: # "Administrators", "Certificate Manager Agents", or "Auditors". # Note that customized role names can be used once configured. # LOGGING_SIGNED_AUDIT_ROLE_ASSUME=<type=ROLE_ASSUME>:[AuditEvent=ROLE_ASSUME]{0} assume privileged role # # Event: SECURITY_DOMAIN_UPDATE # Description: This event is used when updating contents of security domain # (add/remove a subsystem). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: CA administrator user ID # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_SECURITY_DOMAIN_UPDATE_1=<type=SECURITY_DOMAIN_UPDATE>:[AuditEvent=SECURITY_DOMAIN_UPDATE][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] security domain update # # Event: SELFTESTS_EXECUTION # Description: This event is used when self tests are run. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: # LOGGING_SIGNED_AUDIT_SELFTESTS_EXECUTION_2=<type=SELFTESTS_EXECUTION>:[AuditEvent=SELFTESTS_EXECUTION][SubjectID={0}][Outcome={1}] self tests execution (see selftests.log for details)
Glossary
A
- access control
- The process of controlling what particular users are allowed to do. For example, access control to servers is typically based on an identity, established by a password or a certificate, and on rules regarding what that entity can do. See also access control list (ACL).
- access control instructions (ACI)
- An access rule that specifies how subjects requesting access are to be identified or what rights are allowed or denied for a particular subject. See access control list (ACL).
- access control list (ACL)
- A collection of access control entries that define a hierarchy of access rules to be evaluated when a server receives a request for access to a particular resource. See access control instructions (ACI).
- administrator
- The person who installs and configures one or more Certificate System managers and sets up privileged users, or agents, for them. See also agent.
- Advanced Encryption Standard (AES)
- The Advanced Encryption Standard (AES), like its predecessor Data Encryption Standard (DES), is a FIPS-approved symmetric-key encryption standard. AES was adopted by the US government in 2002. It defines three block ciphers, AES-128, AES-192 and AES-256. The National Institute of Standards and Technology (NIST) defined the AES standard in U.S. FIPS PUB 197. For more information, see http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.
- agent
- A user who belongs to a group authorized to manage agent services for a Certificate System manager. See also Certificate Manager agent, Key Recovery Authority agent.
- agent services
- 1. Services that can be administered by a Certificate System agent through HTML pages served by the Certificate System subsystem for which the agent has been assigned the necessary privileges.2. The HTML pages for administering such services.
- agent-approved enrollment
- An enrollment that requires an agent to approve the request before the certificate is issued.
- APDU
- Application protocol data unit. A communication unit (analogous to a byte) that is used in communications between a smart card and a smart card reader.
- attribute value assertion (AVA)
- An assertion of the form attribute = value, where attribute is a tag, such as
o
(organization) oruid
(user ID), and value is a value such as "Red Hat, Inc." or a login name. AVAs are used to form the distinguished name (DN) that identifies the subject of a certificate, called the subject name of the certificate. - audit log
- A log that records various system events. This log can be signed, providing proof that it was not tampered with, and can only be read by an auditor user.
- auditor
- A privileged user who can view the signed audit logs.
- authentication
- Confident identification; assurance that a party to some computerized transaction is not an impostor. Authentication typically involves the use of a password, certificate, PIN, or other information to validate identity over a computer network. See also password-based authentication, certificate-based authentication, client authentication, server authentication.
- authentication module
- A set of rules (implemented as a Java™ class) for authenticating an end entity, agent, administrator, or any other entity that needs to interact with a Certificate System subsystem. In the case of typical end-user enrollment, after the user has supplied the information requested by the enrollment form, the enrollment servlet uses an authentication module associated with that form to validate the information and authenticate the user's identity. See servlet.
- authorization
- Permission to access a resource controlled by a server. Authorization typically takes place after the ACLs associated with a resource have been evaluated by a server. See access control list (ACL).
- automated enrollment
- A way of configuring a Certificate System subsystem that allows automatic authentication for end-entity enrollment, without human intervention. With this form of authentication, a certificate request that completes authentication module processing successfully is automatically approved for profile processing and certificate issuance.
B
- bind DN
- A user ID, in the form of a distinguished name (DN), used with a password to authenticate to Red Hat Directory Server.
C
- CA certificate
- A certificate that identifies a certificate authority. See also certificate authority (CA), subordinate CA, root CA.
- CA hierarchy
- A hierarchy of CAs in which a root CA delegates the authority to issue certificates to subordinate CAs. Subordinate CAs can also expand the hierarchy by delegating issuing status to other CAs. See also certificate authority (CA), subordinate CA, root CA.
- CA server key
- The TLS server key of the server providing a CA service.
- CA signing key
- The private key that corresponds to the public key in the CA certificate. A CA uses its signing key to sign certificates and CRLs.
- certificate
- Digital data, formatted according to the X.509 standard, that specifies the name of an individual, company, or other entity (the subject name of the certificate) and certifies that a public key, which is also included in the certificate, belongs to that entity. A certificate is issued and digitally signed by a certificate authority (CA). A certificate's validity can be verified by checking the CA's digital signature through public-key cryptography techniques. To be trusted within a public-key infrastructure (PKI), a certificate must be issued and signed by a CA that is trusted by other entities enrolled in the PKI.
- certificate authority (CA)
- A trusted entity that issues a certificate after verifying the identity of the person or entity the certificate is intended to identify. A CA also renews and revokes certificates and generates CRLs. The entity named in the issuer field of a certificate is always a CA. Certificate authorities can be independent third parties or a person or organization using certificate-issuing server software, such as Red Hat Certificate System.
- certificate chain
- A hierarchical series of certificates signed by successive certificate authorities. A CA certificate identifies a certificate authority (CA) and is used to sign certificates issued by that authority. A CA certificate can in turn be signed by the CA certificate of a parent CA, and so on up to a root CA. Certificate System allows any end entity to retrieve all the certificates in a certificate chain.
- certificate extensions
- An X.509 v3 certificate contains an extensions field that permits any number of additional fields to be added to the certificate. Certificate extensions provide a way of adding information such as alternative subject names and usage restrictions to certificates. A number of standard extensions have been defined by the PKIX working group.
- certificate fingerprint
- A one-way hash associated with a certificate. The number is not part of the certificate itself, but is produced by applying a hash function to the contents of the certificate. If the contents of the certificate changes, even by a single character, the same function produces a different number. Certificate fingerprints can therefore be used to verify that certificates have not been tampered with.
- Certificate Management Message Formats (CMMF)
- Message formats used to convey certificate requests and revocation requests from end entities to a Certificate Manager and to send a variety of information to end entities. A proposed standard from the Internet Engineering Task Force (IETF) PKIX working group. CMMF is subsumed by another proposed standard, Certificate Management Messages over Cryptographic Message Syntax (CMC). For detailed information, see https://tools.ietf.org/html/draft-ietf-pkix-cmmf-02.
- Certificate Management Messages over Cryptographic Message Syntax (CMC)
- Message format used to convey a request for a certificate to a Certificate Manager. A proposed standard from the Internet Engineering Task Force (IETF) PKIX working group. For detailed information, see https://tools.ietf.org/html/draft-ietf-pkix-cmc-02.
- Certificate Manager
- An independent Certificate System subsystem that acts as a certificate authority. A Certificate Manager instance issues, renews, and revokes certificates, which it can publish along with CRLs to an LDAP directory. It accepts requests from end entities. See certificate authority (CA).
- Certificate Manager agent
- A user who belongs to a group authorized to manage agent services for a Certificate Manager. These services include the ability to access and modify (approve and reject) certificate requests and issue certificates.
- certificate profile
- A set of configuration settings that defines a certain type of enrollment. The certificate profile sets policies for a particular type of enrollment along with an authentication method in a certificate profile.
- Certificate Request Message Format (CRMF)
- Format used for messages related to management of X.509 certificates. This format is a subset of CMMF. See also Certificate Management Message Formats (CMMF). For detailed information, see https://tools.ietf.org/html/rfc2511.
- certificate revocation list (CRL)
- As defined by the X.509 standard, a list of revoked certificates by serial number, generated and signed by a certificate authority (CA).
- Certificate System
- Certificate System console
- A console that can be opened for any single Certificate System instance. A Certificate System console allows the Certificate System administrator to control configuration settings for the corresponding Certificate System instance.
- Certificate System subsystem
- One of the five Certificate System managers: Certificate Manager, Online Certificate Status Manager, Key Recovery Authority, Token Key Service, or Token Processing System.
- certificate-based authentication
- Authentication based on certificates and public-key cryptography. See also password-based authentication.
- chain of trust
- See certificate chain.
- chained CA
- See linked CA.
- cipher
- client authentication
- The process of identifying a client to a server, such as with a name and password or with a certificate and some digitally signed data. See certificate-based authentication, password-based authentication, server authentication.
- client TLS certificate
- A certificate used to identify a client to a server using the TLS protocol. See Transport Layer Security (TLS).
- CMC
- CMC Enrollment
- Features that allow either signed enrollment or signed revocation requests to be sent to a Certificate Manager using an agent's signing certificate. These requests are then automatically processed by the Certificate Manager.
- CMMF
- Common Criteria
- A certification standard that evaluates computer security, both for software and hardware components. The software or hardware vendor defines the operating environment and specified configuration, identifies any threats, and outlines both the development and deployment processes for the target of evaluation (the thing being evaluated). The Common Criteria certification laboratory then tests the implementation design to look for any vulnerabilities.
- CRL
- CRMF
- cross-certification
- The exchange of certificates by two CAs in different certification hierarchies, or chains. Cross-certification extends the chain of trust so that it encompasses both hierarchies. See also certificate authority (CA).
- cross-pair certificate
- A certificate issued by one CA to another CA which is then stored by both CAs to form a circle of trust. The two CAs issue certificates to each other, and then store both cross-pair certificates as a certificate pair.
- cryptographic algorithm
- A set of rules or directions used to perform cryptographic operations such as encryption and decryption.
- Cryptographic Message Syntax (CS)
- The syntax used to digitally sign, digest, authenticate, or encrypt arbitrary messages, such as CMMF.
- cryptographic module
- See PKCS #11 module.
- cryptographic service provider (CSP)
- A cryptographic module that performs cryptographic services, such as key generation, key storage, and encryption, on behalf of software that uses a standard interface such as that defined by PKCS #11 to request such services.
- CSP
D
- decryption
- Unscrambling data that has been encrypted. See encryption.
- delta CRL
- A CRL containing a list of those certificates that have been revoked since the last full CRL was issued.
- digital ID
- See certificate.
- digital signature
- To create a digital signature, the signing software first creates a one-way hash from the data to be signed, such as a newly issued certificate. The one-way hash is then encrypted with the private key of the signer. The resulting digital signature is unique for each piece of data signed. Even a single comma added to a message changes the digital signature for that message. Successful decryption of the digital signature with the signer's public key and comparison with another hash of the same data provides tamper detection. Verification of the certificate chain for the certificate containing the public key provides authentication of the signer. See also nonrepudiation, encryption.
- distinguished name (DN)
- A series of AVAs that identify the subject of a certificate. See attribute value assertion (AVA).
- distribution points
- Used for CRLs to define a set of certificates. Each distribution point is defined by a set of certificates that are issued. A CRL can be created for a particular distribution point.
- dual key pair
- Two public-private key pairs, four keys altogether, corresponding to two separate certificates. The private key of one pair is used for signing operations, and the public and private keys of the other pair are used for encryption and decryption operations. Each pair corresponds to a separate certificate. See also encryption key, public-key cryptography, signing key.
- Key Recovery Authority
- An optional, independent Certificate System subsystem that manages the long-term archival and recovery of RSA encryption keys for end entities. A Certificate Manager can be configured to archive end entities' encryption keys with a Key Recovery Authority before issuing new certificates. The Key Recovery Authority is useful only if end entities are encrypting data, such as sensitive email, that the organization may need to recover someday. It can be used only with end entities that support dual key pairs: two separate key pairs, one for encryption and one for digital signatures.
- Key Recovery Authority agent
- A user who belongs to a group authorized to manage agent services for a Key Recovery Authority, including managing the request queue and authorizing recovery operation using HTML-based administration pages.
- Key Recovery Authority recovery agent
- One of the m of n people who own portions of the storage key for the Key Recovery Authority.
- Key Recovery Authority storage key
- Special key used by the Key Recovery Authority to encrypt the end entity's encryption key after it has been decrypted with the Key Recovery Authority's private transport key. The storage key never leaves the Key Recovery Authority.
- Key Recovery Authority transport certificate
- Certifies the public key used by an end entity to encrypt the entity's encryption key for transport to the Key Recovery Authority. The Key Recovery Authority uses the private key corresponding to the certified public key to decrypt the end entity's key before encrypting it with the storage key.
E
- eavesdropping
- Surreptitious interception of information sent over a network by an entity for which the information is not intended.
- Elliptic Curve Cryptography (ECC)
- A cryptographic algorithm which uses elliptic curves to create additive logarithms for the mathematical problems which are the basis of the cryptographic keys. ECC ciphers are more efficient to use than RSA ciphers and, because of their intrinsic complexity, are stronger at smaller bits than RSA ciphers.
- encryption
- Scrambling information in a way that disguises its meaning. See decryption.
- encryption key
- A private key used for encryption only. An encryption key and its equivalent public key, plus a signing key and its equivalent public key, constitute a dual key pair.
- end entity
- In a public-key infrastructure (PKI), a person, router, server, or other entity that uses a certificate to identify itself.
- enrollment
- The process of requesting and receiving an X.509 certificate for use in a public-key infrastructure (PKI). Also known as registration.
- extensions field
F
- Federal Bridge Certificate Authority (FBCA)
- A configuration where two CAs form a circle of trust by issuing cross-pair certificates to each other and storing the two cross-pair certificates as a single certificate pair.
- fingerprint
- FIPS PUBS 140
- Federal Information Standards Publications (FIPS PUBS) 140 is a US government standard for implementations of cryptographic modules, hardware or software that encrypts and decrypts data or performs other cryptographic operations, such as creating or verifying digital signatures. Many products sold to the US government must comply with one or more of the FIPS standards. See http://www.nist.gov/itl/fipscurrent.cfm.
- firewall
- A system or combination of systems that enforces a boundary between two or more networks.
I
- impersonation
- The act of posing as the intended recipient of information sent over a network. Impersonation can take two forms: spoofing and misrepresentation.
- input
- In the context of the certificate profile feature, it defines the enrollment form for a particular certificate profile. Each input is set, which then dynamically creates the enrollment form from all inputs configured for this enrollment.
- intermediate CA
- A CA whose certificate is located between the root CA and the issued certificate in a certificate chain.
- IP spoofing
- The forgery of client IP addresses.
J
- JAR file
- A digital envelope for a compressed collection of files organized according to the Java™ archive (JAR) format.
- Java™ archive (JAR) format
- A set of conventions for associating digital signatures, installer scripts, and other information with files in a directory.
- Java™ Cryptography Architecture (JCA)
- The API specification and reference developed by Sun Microsystems for cryptographic services. See http://java.sun.com/products/jdk/1.2/docs/guide/security/CryptoSpec.Introduction.
- Java™ Development Kit (JDK)
- Software development kit provided by Sun Microsystems for developing applications and applets using the Java™ programming language.
- Java™ Native Interface (JNI)
- A standard programming interface that provides binary compatibility across different implementations of the Java™ Virtual Machine (JVM) on a given platform, allowing existing code written in a language such as C or C++ for a single platform to bind to Java™. See http://java.sun.com/products/jdk/1.2/docs/guide/jni/index.html.
- Java™ Security Services (JSS)
- A Java™ interface for controlling security operations performed by Network Security Services (NSS).
K
- KEA
- key
- A large number used by a cryptographic algorithm to encrypt or decrypt data. A person's public key, for example, allows other people to encrypt messages intended for that person. The messages must then be decrypted by using the corresponding private key.
- key exchange
- A procedure followed by a client and server to determine the symmetric keys they will both use during a TLS session.
- Key Exchange Algorithm (KEA)
- An algorithm used for key exchange by the US Government.
L
- Lightweight Directory Access Protocol (LDAP)
- A directory service protocol designed to run over TCP/IP and across multiple platforms. LDAP is a simplified version of Directory Access Protocol (DAP), used to access X.500 directories. LDAP is under IETF change control and has evolved to meet Internet requirements.
- linked CA
- An internally deployed certificate authority (CA) whose certificate is signed by a public, third-party CA. The internal CA acts as the root CA for certificates it issues, and the third- party CA acts as the root CA for certificates issued by other CAs that are linked to the same third-party root CA. Also known as "chained CA" and by other terms used by different public CAs.
M
- manual authentication
- A way of configuring a Certificate System subsystem that requires human approval of each certificate request. With this form of authentication, a servlet forwards a certificate request to a request queue after successful authentication module processing. An agent with appropriate privileges must then approve each request individually before profile processing and certificate issuance can proceed.
- MD5
- A message digest algorithm that was developed by Ronald Rivest. See also one-way hash.
- message digest
- See one-way hash.
- misrepresentation
- The presentation of an entity as a person or organization that it is not. For example, a website might pretend to be a furniture store when it is really a site that takes credit-card payments but never sends any goods. Misrepresentation is one form of impersonation. See also spoofing.
N
- Network Security Services (NSS)
- A set of libraries designed to support cross-platform development of security-enabled communications applications. Applications built using the NSS libraries support the Transport Layer Security (TLS) protocol for authentication, tamper detection, and encryption, and the PKCS #11 protocol for cryptographic token interfaces. NSS is also available separately as a software development kit.
- non-TMS
- Non-token management system. Refers to a configuration of subsystems (the CA and, optionally, KRA and OCSP) which do not handle smart cards directly.
See Also token management system (TMS).
- nonrepudiation
- The inability by the sender of a message to deny having sent the message. A digital signature provides one form of nonrepudiation.
O
- object signing
- A method of file signing that allows software developers to sign Java code, JavaScript scripts, or any kind of file and allows users to identify the signers and control access by signed code to local system resources.
- object-signing certificate
- A certificate whose associated private key is used to sign objects; related to object signing.
- OCSP
- Online Certificate Status Protocol.
- one-way hash
- 1. A number of fixed-length generated from data of arbitrary length with the aid of a hashing algorithm. The number, also called a message digest, is unique to the hashed data. Any change in the data, even deleting or altering a single character, results in a different value.2. The content of the hashed data cannot be deduced from the hash.
- operation
- The specific operation, such as read or write, that is being allowed or denied in an access control instruction.
- output
- In the context of the certificate profile feature, it defines the resulting form from a successful certificate enrollment for a particular certificate profile. Each output is set, which then dynamically creates the form from all outputs configured for this enrollment.
P
- password-based authentication
- Confident identification by means of a name and password. See also authentication, certificate-based authentication.
- PKCS #10
- The public-key cryptography standard that governs certificate requests.
- PKCS #11
- The public-key cryptography standard that governs cryptographic tokens such as smart cards.
- PKCS #11 module
- A driver for a cryptographic device that provides cryptographic services, such as encryption and decryption, through the PKCS #11 interface. A PKCS #11 module, also called a cryptographic module or cryptographic service provider, can be implemented in either hardware or software. A PKCS #11 module always has one or more slots, which may be implemented as physical hardware slots in some form of physical reader, such as for smart cards, or as conceptual slots in software. Each slot for a PKCS #11 module can in turn contain a token, which is the hardware or software device that actually provides cryptographic services and optionally stores certificates and keys. Red Hat provides a built-in PKCS #11 module with Certificate System.
- PKCS #12
- The public-key cryptography standard that governs key portability.
- PKCS #7
- The public-key cryptography standard that governs signing and encryption.
- private key
- One of a pair of keys used in public-key cryptography. The private key is kept secret and is used to decrypt data encrypted with the corresponding public key.
- proof-of-archival (POA)
- Data signed with the private Key Recovery Authority transport key that contains information about an archived end-entity key, including key serial number, name of the Key Recovery Authority, subject name of the corresponding certificate, and date of archival. The signed proof-of-archival data are the response returned by the Key Recovery Authority to the Certificate Manager after a successful key archival operation. See also Key Recovery Authority transport certificate.
- public key
- One of a pair of keys used in public-key cryptography. The public key is distributed freely and published as part of a certificate. It is typically used to encrypt data sent to the public key's owner, who then decrypts the data with the corresponding private key.
- public-key cryptography
- A set of well-established techniques and standards that allow an entity to verify its identity electronically or to sign and encrypt electronic data. Two keys are involved, a public key and a private key. A public key is published as part of a certificate, which associates that key with a particular identity. The corresponding private key is kept secret. Data encrypted with the public key can be decrypted only with the private key.
- public-key infrastructure (PKI)
- The standards and services that facilitate the use of public-key cryptography and X.509 v3 certificates in a networked environment.
R
- RC2, RC4
- Cryptographic algorithms developed for RSA Data Security by Rivest. See also cryptographic algorithm.
- Red Hat Certificate System
- A highly configurable set of software components and tools for creating, deploying, and managing certificates. Certificate System is comprised of five major subsystems that can be installed in different Certificate System instances in different physical locations: Certificate Manager, Online Certificate Status Manager, Key Recovery Authority, Token Key Service, and Token Processing System.
- registration
- See enrollment.
- root CA
- The certificate authority (CA) with a self-signed certificate at the top of a certificate chain. See also CA certificate, subordinate CA.
- RSA algorithm
- Short for Rivest-Shamir-Adleman, a public-key algorithm for both encryption and authentication. It was developed by Ronald Rivest, Adi Shamir, and Leonard Adleman and introduced in 1978.
- RSA key exchange
- A key-exchange algorithm for TLS based on the RSA algorithm.
S
- sandbox
- A Java™ term for the carefully defined limits within which Java™ code must operate.
- secure channel
- A security association between the TPS and the smart card which allows encrypted communciation based on a shared master key generated by the TKS and the smart card APDUs.
- security domain
- A centralized repository or inventory of PKI subsystems. Its primary purpose is to facilitate the installation and configuration of new PKI services by automatically establishing trusted relationships between subsystems.
- self tests
- A feature that tests a Certificate System instance both when the instance starts up and on-demand.
- server authentication
- The process of identifying a server to a client. See also client authentication.
- server TLS certificate
- A certificate used to identify a server to a client using the Transport Layer Security (TLS) protocol.
- servlet
- Java™ code that handles a particular kind of interaction with end entities on behalf of a Certificate System subsystem. For example, certificate enrollment, revocation, and key recovery requests are each handled by separate servlets.
- SHA-1
- Secure Hash Algorithm, a hash function used by the US government.
- signature algorithm
- A cryptographic algorithm used to create digital signatures. Certificate System supports the MD5 and SHA-1 signing algorithms. See also cryptographic algorithm, digital signature.
- signed audit log
- See audit log.
- signing certificate
- A certificate whose public key corresponds to a private key used to create digital signatures. For example, a Certificate Manager must have a signing certificate whose public key corresponds to the private key it uses to sign the certificates it issues.
- signing key
- A private key used for signing only. A signing key and its equivalent public key, plus an encryption key and its equivalent public key, constitute a dual key pair.
- single sign-on
- 1. In Certificate System, a password that simplifies the way to sign on to Red Hat Certificate System by storing the passwords for the internal database and tokens. Each time a user logs on, he is required to enter this single password.2. The ability for a user to log in once to a single computer and be authenticated automatically by a variety of servers within a network. Partial single sign-on solutions can take many forms, including mechanisms for automatically tracking passwords used with different servers. Certificates support single sign-on within a public-key infrastructure (PKI). A user can log in once to a local client's private-key database and, as long as the client software is running, rely on certificate-based authentication to access each server within an organization that the user is allowed to access.
- slot
- The portion of a PKCS #11 module, implemented in either hardware or software, that contains a token.
- smart card
- A small device that contains a microprocessor and stores cryptographic information, such as keys and certificates, and performs cryptographic operations. Smart cards implement some or all of the PKCS #11 interface.
- spoofing
- Pretending to be someone else. For example, a person can pretend to have the email address
jdoe@example.com
, or a computer can identify itself as a site calledwww.redhat.com
when it is not. Spoofing is one form of impersonation. See also misrepresentation. - subject
- The entity identified by a certificate. In particular, the subject field of a certificate contains a subject name that uniquely describes the certified entity.
- subject name
- subordinate CA
- A certificate authority whose certificate is signed by another subordinate CA or by the root CA. See CA certificate, root CA.
- symmetric encryption
- An encryption method that uses the same cryptographic key to encrypt and decrypt a given message.
- TLS
T
- tamper detection
- A mechanism ensuring that data received in electronic form entirely corresponds with the original version of the same data.
- token
- A hardware or software device that is associated with a slot in a PKCS #11 module. It provides cryptographic services and optionally stores certificates and keys.
- token key service (TKS)
- A subsystem in the token management system which derives specific, separate keys for every smart card based on the smart card APDUs and other shared information, like the token CUID.
- token management system (TMS)
- The interrelated subsystems — CA, TKS, TPS, and, optionally, the KRA — which are used to manage certificates on smart cards (tokens).
- token processing system (TPS)
- A subsystem which interacts directly the Enterprise Security Client and smart cards to manage the keys and certificates on those smart cards.
- Transport Layer Security (TLS)
- A protocol that allows mutual authentication between a client and server and the establishment of an authenticated and encrypted connection. TLS runs above TCP/IP and below HTTP, LDAP, IMAP, NNTP, and other high-level network protocols.
- tree hierarchy
- The hierarchical structure of an LDAP directory.
- trust
- Confident reliance on a person or other entity. In a public-key infrastructure (PKI), trust refers to the relationship between the user of a certificate and the certificate authority (CA) that issued the certificate. If a CA is trusted, then valid certificates issued by that CA can be trusted.
V
- virtual private network (VPN)
- A way of connecting geographically distant divisions of an enterprise. The VPN allows the divisions to communicate over an encrypted channel, allowing authenticated, confidential transactions that would normally be restricted to a private network.
Index
A
- adding
- extensions
- to CRLs, Setting CRL Extensions
- administrators
- creating, Creating Users
- deleting, Deleting a Certificate System User
- modifying
- group membership, Changing Members in a Group
- tools provided
- Certificate System console, Using pkiconsole for CA, OCSP, KRA, and TKS Subsystems
- agents
- creating, Creating Users
- deleting, Deleting a Certificate System User
- modifying
- group membership, Changing Members in a Group
- role defined, Agents
- See also Agent Services interface, Agents
- archiving
- users' private encryption keys, Setting up Key Archival and Recovery
- auditors
- creating, Creating Users
- authorityInfoAccess, authorityInfoAccess
- authorityKeyIdentifier, Setting Restrictions on CA Certificates , authorityKeyIdentifier, authorityKeyIdentifier
B
- base-64 encoded file
- viewing content, Viewing Certificates and CRLs Published to File
- basicConstraints, basicConstraints
C
- CA
- configuring ECC signing algorithm, Setting the Signing Algorithms for Certificates
- CA certificate mapper, LdapCaSimpleMap
- CA certificate publisher, LdapCaCertPublisher, LdapCertificatePairPublisher
- CA signing certificate, CA Signing Key Pair and Certificate
- changing trust settings of, Changing the Trust Settings of a CA Certificate
- deleting, Deleting Certificates from the Database
- nickname, CA Signing Key Pair and Certificate
- viewing details of, Viewing Database Content through the Console
- certificate
- viewing content, Viewing Certificates and CRLs Published to File
- certificate chains
- installing in the certificate database, Installing Certificates through the Console
- why install, About CA Certificate Chains
- certificate database
- how to manage, Managing the Certificate Database
- what it contains, Managing the Certificate Database
- where it is maintained, Managing the Certificate Database
- Certificate Manager
- administrators
- creating, Creating Users
- agents
- creating, Creating Users
- key pairs and certificates
- CA signing certificate, CA Signing Key Pair and Certificate
- OCSP signing certificate, OCSP Signing Key Pair and Certificate
- subsystem certificate, Subsystem Certificate
- TLS CA signing certificate, OCSP Signing Key Pair and Certificate
- TLS server certificate, TLS Server Key Pair and Certificate
- manual updates to publishing directory, Updating Certificates and CRLs in a Directory
- serial number range, Changing the Restrictions for CAs on Issuing Certificates
- certificate profiles
- signing algorithms, Setting the Signing Algorithms for Certificates
- certificate renewal, Configuring Profiles to Enable Renewal
- Certificate Setup Wizard
- using to install certificate chains, Installing Certificates through the Console
- using to install certificates, Installing Certificates through the Console
- Certificate System console
- Configuration tab, Using pkiconsole for CA, OCSP, KRA, and TKS Subsystems
- managing logs, Viewing Logs in the Console
- Status tab, Using pkiconsole for CA, OCSP, KRA, and TKS Subsystems
- certificateIssuer, certificateIssuer
- certificatePolicies, certificatePoliciesExt
- certificates
- extensions for, Setting Restrictions on CA Certificates , Defaults, Constraints, and Extensions for Certificates and CRLs
- finding , Performing Revocation as an Agent from the Web UI
- installing, Installing Certificates in the Certificate System Database
- publishing to files, Publishing to Files
- publishing to LDAP directory
- required schema, Configuring the LDAP Directory
- searching for , Searching for Certificates (Advanced)
- signing algorithms, Setting the Signing Algorithms for Certificates
- taking off hold, Taking Ceritificates Off Hold
- certutil
- requesting certificates, Creating Certificate Signing Requests
- changing
- group members, Changing Members in a Group
- trust settings in certificates, Changing the Trust Settings of a CA Certificate
- why would you change, Changing the Trust Settings of a CA Certificate
- Configuration tab, Using pkiconsole for CA, OCSP, KRA, and TKS Subsystems
- CRL
- viewing content, Viewing Certificates and CRLs Published to File
- CRL Distribution Point extension, CRL Issuing Points
- CRL extension modules
- CRLReason, Freshest CRL Extension Default
- CRL publisher, LdapCrlPublisher
- CRL signing certificate, About Revoking Certificates
- cRLDistributionPoints, CRLDistributionPoints
- CRLNumber, CRLNumber
- CRLReason, CRLReason
- CRLs
- defined, About Revoking Certificates
- entering multiple update times, Configuring CRLs for Each Issuing Point
- entering update period, Configuring CRLs for Each Issuing Point
- extension-specific modules, About CRL Extensions
- extensions for, Standard X.509 v3 CRL Extensions Reference
- issuing or distribution points, CRL Issuing Points
- publishing of, About Revoking Certificates
- publishing to files, Publishing to Files
- publishing to LDAP directory, Publishing CRLs, LDAP Publishing
- required schema, Configuring the LDAP Directory
- supported extensions, About Revoking Certificates
- when automated updates take place, About Revoking Certificates
- when generated, About Revoking Certificates
- who generates it, About Revoking Certificates
D
- deleting
- privileged users, Deleting a Certificate System User
- deltaCRLIndicator, deltaCRLIndicator
- DER-encoded file
- viewing content, Viewing Certificates and CRLs Published to File
- DN components mapper, LdapDNCompsMap
- downloading certificates, Installing Certificates in the Certificate System Database
E
- ECC
- configuring, Setting the Signing Algorithms for Certificates
- requesting, Creating Certificate Signing Requests
- encrypted file system (EFS), Extended Key Usage Extension Default
- end-entity certificate publisher, LdapUserCertPublisher
- end-entity certificates
- Extended Key Usage extension
- OIDs for encrypted file system, Extended Key Usage Extension Default
- extensions, Setting Restrictions on CA Certificates , Defaults, Constraints, and Extensions for Certificates and CRLs
- an example, Standard X.509 v3 Certificate Extension Reference
- authorityInfoAccess, authorityInfoAccess
- authorityKeyIdentifier, Setting Restrictions on CA Certificates , authorityKeyIdentifier, authorityKeyIdentifier
- basicConstraints, basicConstraints
- CA certificates and, Setting Restrictions on CA Certificates
- certificateIssuer, certificateIssuer
- certificatePolicies, certificatePoliciesExt
- cRLDistributionPoints, CRLDistributionPoints
- CRLNumber, CRLNumber
- CRLReason, CRLReason
- deltaCRLIndicator, deltaCRLIndicator
- extKeyUsage, extKeyUsage
- invalidityDate, invalidityDate
- issuerAltName, issuerAltName Extension, issuerAltName
- issuingDistributionPoint, issuingDistributionPoint
- keyUsage, keyUsage
- nameConstraints, nameConstraints
- netscape-cert-type, netscape-cert-type
- Netscape-defined, Netscape-Defined Certificate Extensions Reference
- policyConstraints, policyConstraints
- policyMappings, policyMappings
- privateKeyUsagePeriod, privateKeyUsagePeriod
- subjectAltName, subjectAltName
- subjectDirectoryAttributes, subjectDirectoryAttributes
- X.509 certificate, summarized, Standard X.509 v3 Certificate Extension Reference
- X.509 CRL, summarized, Standard X.509 v3 CRL Extensions Reference
- extKeyUsage, extKeyUsage
F
- file-based publisher, FileBasedPublisher
G
- groups
- changing members, Changing Members in a Group
I
- installing certificates, Installing Certificates in the Certificate System Database
- invalidityDate, invalidityDate
- issuerAltName, issuerAltName Extension, issuerAltName
- issuingDistributionPoint, issuingDistributionPoint
K
- key archival
- how keys are stored, Key Archival
- reasons to archive, Key Archival
- key recovery, Key Archival
- Key Recovery Authority
- administrators
- creating, Creating Users
- agents
- creating, Creating Users
- key pairs and certificates
- list of, Key Recovery Authority Certificates
- storage key pair, Storage Key Pair
- subsystem certificate, Subsystem Certificate
- transport certificate, Transport Key Pair and Certificate
- keyUsage, keyUsage
L
- LDAP publishing
- defined, LDAP Publishing
- manual updates, Updating Certificates and CRLs in a Directory
- when to do, Manually Updating Certificates in the Directory
- who can do this, Updating Certificates and CRLs in a Directory
- logging
- managing from Certificate System console, Viewing Logs in the Console
M
- managing
- certificate database, Managing the Certificate Database
- mappers
- created during installation, Creating Mappers, LdapCaSimpleMap, LdapSimpleMap
- mappers that use
- CA certificate, LdapCaSimpleMap
- DN components, LdapDNCompsMap
- modifying
- privileged user's group membership, Changing Members in a Group
N
- Name extension modules
- Issuer Alternative Name, Issuer Alternative Name Extension Default
- nameConstraints, nameConstraints
- netscape-cert-type, netscape-cert-type
- nickname
- for CA signing certificate, CA Signing Key Pair and Certificate
- for OCSP signing certificate, OCSP Signing Key Pair and Certificate
- for signing certificate, OCSP Signing Key Pair and Certificate
- for subsystem certificate, Subsystem Certificate, Subsystem Certificate, Subsystem Certificate
- for TLS server certificate, TLS Server Key Pair and Certificate, TLS Server Key Pair and Certificate
- for TLS signing certificate, OCSP Signing Key Pair and Certificate
O
- OCSP publisher, OCSPPublisher
- OCSP signing certificate, OCSP Signing Key Pair and Certificate
- nickname, OCSP Signing Key Pair and Certificate
- Online Certificate Status Manager
- administrators
- creating, Creating Users
- agents
- creating, Creating Users
- key pairs and certificates
- signing certificate, OCSP Signing Key Pair and Certificate
- subsystem certificate, Subsystem Certificate
- TLS server certificate, TLS Server Key Pair and Certificate
P
- plug-in modules
- for CRL extensions
- CRLReason, Freshest CRL Extension Default
- for publishing
- FileBasedPublisher, FileBasedPublisher
- LdapCaCertPublisher, LdapCaCertPublisher, LdapCertificatePairPublisher
- LdapCaSimpleMap, LdapCaSimpleMap
- LdapCrlPublisher, LdapCrlPublisher
- LdapDNCompsMap, LdapDNCompsMap
- LdapUserCertPublisher, LdapUserCertPublisher
- OCSPPublisher, OCSPPublisher
- Issuer Alternative Name, Issuer Alternative Name Extension Default
- policyConstraints, policyConstraints
- policyMappings, policyMappings
- privateKeyUsagePeriod, privateKeyUsagePeriod
- privileged users
- deleting, Deleting a Certificate System User
- modifying privileges
- group membership, Changing Members in a Group
- types
- agents, Agents
- profiles
- how profiles work , The Enrollment Profile
- publishers
- created during installation, Configuring LDAP Publishers, LdapCaCertPublisher, LdapUserCertPublisher, LdapCertificatePairPublisher
- publishers that can publish to
- CA's entry in the directory, LdapCaCertPublisher, LdapCrlPublisher, LdapCertificatePairPublisher
- files, FileBasedPublisher
- OCSP responder, OCSPPublisher
- users' entries in the directory, LdapUserCertPublisher
- publishing
- of certificates
- to files, Publishing to Files
- of CRLs, About Revoking Certificates
- to files, Publishing to Files
- to LDAP directory, Publishing CRLs, LDAP Publishing
- viewing content, Viewing Certificates and CRLs Published to File
- publishing directory
- defined, LDAP Publishing
R
- recovering users' private keys, Key Archival
- registering
- custom OIDs, Standard X.509 v3 Certificate Extension Reference
- requesting certificates
- ECC certificates, Creating Certificate Signing Requests
- using certutil, Creating Certificate Signing Requests
- revoking certificates
- taking certificate off hold, Taking Ceritificates Off Hold
- roles
- agent, Agents
- RSA
- configuring, Setting the Signing Algorithms for Certificates
S
- setting CRL extensions, Setting CRL Extensions
- signing algorithms, Setting the Signing Algorithms for Certificates
- ECC certificates, Setting the Signing Algorithms for Certificates
- RSA certificates, Setting the Signing Algorithms for Certificates
- signing certificate, OCSP Signing Key Pair and Certificate
- changing trust settings of, Changing the Trust Settings of a CA Certificate
- deleting, Deleting Certificates from the Database
- nickname, OCSP Signing Key Pair and Certificate
- viewing details of, Viewing Database Content through the Console
- Status tab, Using pkiconsole for CA, OCSP, KRA, and TKS Subsystems
- storage key pair, Storage Key Pair
- subjectAltName, subjectAltName
- subjectDirectoryAttributes, subjectDirectoryAttributes
- subjectKeyIdentifier
- subjectKeyIdentifier, subjectKeyIdentifier
- subsystem certificate, Subsystem Certificate, Subsystem Certificate, Subsystem Certificate
T
- TLS CA signing certificate, OCSP Signing Key Pair and Certificate
- nickname, OCSP Signing Key Pair and Certificate
- TLS server certificate, TLS Server Key Pair and Certificate, TLS Server Key Pair and Certificate
- changing trust settings of, Changing the Trust Settings of a CA Certificate
- deleting, Deleting Certificates from the Database
- nickname, TLS Server Key Pair and Certificate, TLS Server Key Pair and Certificate
- viewing details of, Viewing Database Content through the Console
- Token Key Service
- administrators
- creating, Creating Users
- agents
- creating, Creating Users
- tokens
- changing password of, Changing a Token's Password
- managing, Managing Tokens Used by the Subsystems
- viewing which tokens are installed, Viewing Tokens
- transport certificate, Transport Key Pair and Certificate
- changing trust settings of, Changing the Trust Settings of a CA Certificate
- deleting, Deleting Certificates from the Database
- viewing details of, Viewing Database Content through the Console
- when used, Key Archival
- trusted managers
- deleting, Deleting a Certificate System User
- modifying
- group membership, Changing Members in a Group
U
- users
- creating, Creating Users
Appendix F. Revision History
Revision History | |||
---|---|---|---|
Revision 9.4-1 | Thu Feb 11, 2021 | ||
| |||
Revision 9.4-0 | Wed Apr 10, 2019 | ||
|