Chapter 15. Certificate Profiles Configuration

download PDF

15.1. Creating and Editing Certificate Profiles Directly on the File System

As part of the installation process of a CA, the certificate enrollment profiles can be modified directly on the file system by modifying the profiles' configuration files. Default files exist for the default profiles at installation; when new profiles are needed, new profile configuration files are to be created. The configuration files are stored in the CA profile directory, instance_directory/ca/profiles/ca/, such as /var/lib/pki/pki-ca/ca/profiles/ca/. The file is named profile_name.cfg. All of the parameters for profile rules can be set or modified in those profile configuration files. Profile rules can be inputs, outputs, authentication, authorization, defaults, and constraints.
The enrollment profiles for the CA certificates are located in the /var/lib/pki/instance_name/ca/conf directory with the name *.profile.


For audit reasons, use this method only during the CA installation prior to deployment.
Restart the server after editing the profile configuration file for the changes to take effect.

15.1.1. Configuring non-CA System Certificate Profiles Profile Configuration Parameters

All of the parameters for a profile rule - defaults, inputs, outputs, and constraints - are configured within a single policy set. A policy set for a profile has the name policyset.policyName.policyNumber. For example:
policyset.cmcUserCertSet.6.constraint.class_id=noConstraintImpl Constraint
policyset.cmcUserCertSet.6.default.class_id=userExtensionDefaultImpl Supplied Key Default
The common profile configuration parameters are described in Table 15.1, “Profile Configuration File Parameters”.
Table 15.1. Profile Configuration File Parameters
Parameter Description
desc Gives a free text description of the certificate profile, which is shown on the end-entities page. For example, desc=This certificate profile is for enrolling server certificates with agent authentication.
enable Sets whether the profile is enabled, and therefore accessible through the end-entities page. For example, enable=true.
auth.instance_id Sets which authentication manager plug-in to use to authenticate the certificate request submitted through the profile. For automatic enrollment, the CA issues a certificate immediately if the authentication is successful. If authentication fails or there is no authentication plug-in specified, the request is queued to be manually approved by an agent. For example, auth.instance_id=CMCAuth. The authentication method must be one of the registered authentication instances from CS.cfg.
Specifies the authorization constraint. Most commonly, this us used to set the group evaluation ACL. For example, this caCMCUserCert parameter requires that the signer of the CMC request belong to the Certificate Manager Agents group:
authz.acl=group="Certificate Manager Agents"
In directory-based user certificate renewal, this option is used to ensure that the original requester and the currently-authenticated user are the same.
An entity must authenticate (bind or, essentially, log into the system) before authorization can be evaluated. The authorization method specified must be one of the registered authorization instances from CS.cfg.
name Gives the name of the profile. For example, name=Agent-Authenticated Server Certificate Enrollment. This name is displayed in the end users enrollment or renewal page.
input.list Lists the allowed inputs for the profile by name. For example, input.list=i1,i2.
input.input_id.class_id Gives the java class name for the input by input ID (the name of the input listed in input.list). For example, input.i1.class_id=cmcCertReqInputImpl.
output.list Lists the possible output formats for the profile by name. For example, output.list=o1.
output.output_id.class_id Gives the java class name for the output format named in output.list. For example, output.o1.class_id=certOutputImpl.
policyset.list Lists the configured profile rules. For dual certificates, one set of rules applies to the signing key and the other to the encryption key. Single certificates use only one set of profile rules. For example, policyset.list=serverCertSet.
policyset.policyset_id.list Lists the policies within the policy set configured for the profile by policy ID number in the order in which they should be evaluated. For example, policyset.serverCertSet.list=1,2,3,4,5,6,7,8.
policyset.policyset_id.policy_number.constraint.class_id Gives the java class name of the constraint plug-in set for the default configured in the profile rule. For example, policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl. Gives the user-defined name of the constraint. For example, Name Constraint.
policyset.policyset_id.policy_number.constraint.params.attribute Specifies a value for an allowed attribute for the constraint. The possible attributes vary depending on the type of constraint. For example, policyset.serverCertSet.1.constraint.params.pattern=CN=.*.
policyset.policyset_id.policy_number.default.class_id Gives the java class name for the default set in the profile rule. For example, policyset.serverCertSet.1.default.class_id=userSubjectNameDefaultImpl Gives the user-defined name of the default. For example, Name Default
policyset.policyset_id.policy_number.default.params.attribute Specifies a value for an allowed attribute for the default. The possible attributes vary depending on the type of default. For example,$request.requestor_name$. Modifying Certificate Extensions Directly on the File System

Changing constraints changes the restrictions on the type of information which can be supplied. Changing the defaults and constraints can also add, delete, or modify the extensions which are accepted or required from a certificate request.
For example, the default caFullCMCUserCert profile is set to create a Key Usage extension from information in the request.
 policyset.cmcUserCertSet.6.constraint.class_id=keyUsageExtConstraintImpl Usage Extension Constraint  
policyset.cmcUserCertSet.6.default.class_id=keyUsageExtDefaultImpl Usage Default
The default is updated to allow user-supplied key extensions:
policyset.cmcUserCertSet.6.default.class_id=userExtensionDefaultImpl Supplied Key Default
This sets the server to accept the extension OID in the certificate request.
Other constraints and defaults can be changed similarly. Make sure that any required constraints are included with appropriate defaults, that defaults are changed when a different constraint is required, and that only allowed constraints are used with the default. For more information, see the Defaults Reference section and the Constraints Reference section in the Red Hat Certificate System Administration Guide. Key Usage and Extended Key Usage Consistency
Red Hat Certificate System provides a flexible infrastructure for administrators to create customized enrollment profiles to meet the requirements of their environment. However, it is important that profiles do not allow issuing certificates that violate the requirements defined in RFC 5280. When creating an enrollment profile where both Key Usage (KU) and Extended Key Usage (EKU) extensions are present, it is important to make sure that the consistency between the two extensions is maintained as per section Extended Key Usage of RFC 5280.
For details about the KU extension, see:
The following table provides the guidelines that maps consistent Key Usage bits to the Extended Key Usage Extension for each purpose:
Purpose / Extended Key Usages Key Usages
TLS Server Authentication command
digitalSignature, keyEncipherment, or KeyAgreement
TLS Client (Mutual) Authentication
digitalSignature, keyEncipherment, and/or KeyAgreement
Code Signing
Email Protection
digitalSignature, nonRepudiation, and/or (keyEncipherment or keyAgreement)
OCSP Response Signing
KeyAgreement and/or nonRepudiation
The following shows two examples of inconsistent EKU/KU:
  • An enrollment profile that is intended for purpose of OCSP response signing contains Extended key usage id-kp-OCSPSigning but with keyEncipherment key usage bit:
    policyset.ocspCertSet.6.default.class_id=keyUsageExtDefaultImpl Usage Default
    policyset.ocspCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl Key Usage Default
  • An enrollment profile that is intended for the purpose of TLS server authentication contains Extended key usage id-kp-serverAuth but with CRL signing key usage bit: Usage Default
    policyset.cmcUserCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl Key Usage Extension Default
For details about the EKU extension, see: Configuring Cross-Pair Profiles
Cross-pair certificates are distinct CA signing certificates that establish a trust partner relationship whereby entities from these two distinct PKIs will trust each other. Both partner CAs store the other CA signing certificate in its database, so all of the certificates issued within the other PKI are trusted and recognized.
Two extensions supported by the Certificate System can be used to establish such a trust partner relationship (cross-certification):
  • The Certificate Policies Extension (CertificatePoliciesExtension) specifies the terms that the certificate fall under, which is often unique for each PKI.
  • The Policy Mapping Extension (PolicyMappingExtension) seals the trust between two PKI’s by mapping the certificate profiles of the two environments.
Issuing cross-pair certificates requires the Certificate Policies Extension, explained in certificatePoliciesExt annex in the Red Hat Certificate System Administration Guide.
To ensure that the issued certificate contains the CertificatePoliciesExtension, the enrollment profile needs to include an appropriate policy rule, for example:
policyset.userCertSet.p7.constraint.class_id=noConstraintImpl Constraint
policyset.userCertSet.p7.default.class_id=certificatePoliciesExtDefaultImpl Policies Extension Default
Certificates issued with the enrollment profile in this example would contain the following information:
Identifier: Certificate Policies: -
Critical: no
Certificate Policies:
Policy Identifier:
For more information on using cross-pair certificates, see the Using Cross-Pair Certificates section in the Red Hat Certificate System Administration Guide.
For more information on publishing cross-pair certificates, see the see the Publishing Cross-Pair Certificates section in the Red Hat Certificate System Administration Guide. Adding Profile Inputs Directly on the File System

The certificate profile configuration file in the CA's profiles/ca directory contains the input information for that particular certificate profile form. Inputs are the fields in the end-entities page enrollment forms. There is a parameter, input.list, which lists the inputs included in that profile. Other parameters define the inputs; these are identified by the format input.ID. For example, this adds a generic input to a profile:
For more information on what inputs, or form fields, are available, see Input Reference.

15.1.2. Changing the Default Validity Time of Certificates

In each profile on a Certificate Authority (CA), you can set how long certificates issued using a profile are valid. You can change this value for security reasons.
For example, to set the validity of the generated Certificate Authority (CA) signing certificate to 825 days (approximately 27 months), open the /var/lib/pki/instance_name/ca/profiles/ca/caCACert.cfg file in an editor and set:

15.1.3. Configuring CA System Certificate Profiles

Unlike the non-CA subsystems, the enrollment profiles for CA's own system certificates are kept in the /var/lib/pki/[instance name]/ca/conf file. Those profiles are:
  • caAuditSigningCert.profile
  • eccAdminCert.profile
  • rsaAdminCert.profile
  • caCert.profile
  • eccServerCert.profile
  • saServerCert.profile
  • caOCSPCert.profile
  • eccSubsystemCert.profile
  • rsaSubsystemCert.profile
If you wish to change the default values in the profiles above, make changes to the profiles before Section 7.7.6, “Starting the Configuration Step” procedure is performed. The following is an example that demonstrates:
  • How to change validity to CA signing certificate.
  • How to add extensions (e.g. Certificate policies extension).
  1. Back up the original CA certificate profile used by pkispawn.
    # cp -p /usr/share/pki/ca/conf/caCert.profile /usr/share/pki/ca/conf/caCert.profile.orig
  2. Open the CA certificate profile used by the configuration wizard.
    # vim /usr/share/pki/ca/conf/caCert.profile
  3. Reset the validity period in the Validity Default to whatever you want. For example, to change the period to two years:
    2.default.class=com.netscape.cms.profile.def.ValidityDefault Default
  4. Add any extensions by creating a new default entry in the profile and adding it to the list. For example, to add the Certificate Policies Extension, add the default (which, in this example, is default #9):
    9.default.class_id=certificatePoliciesExtDefaultImpl Policies Extension Default
    Then, add the default number to the list of defaults to use the new default:

15.1.4. Managing Smart Card CA Profiles


Features in this section on TMS are not tested in the evaluation. This section is for reference only.
The TPS does not generate or approve certificate requests; it sends any requests approved through the Enterprise Security Client to the configured CA to issue the certificate. This means that the CA actually contains the profiles to use for tokens and smart cards. The profiles to use can be automatically assigned, based on the card type.
The profile configuration files are in the /var/lib/pki/instance_name/profiles/ca/ directory with the other CA profiles. The default profiles are listed in Table 15.2, “Default Token Certificate Profiles”.
Table 15.2. Default Token Certificate Profiles
Profile Name Configuration File Description
Regular Enrollment Profiles
Token Device Key Enrollment caTokenDeviceKeyEnrollment.cfg For enrolling tokens used for devices or servers.
Token User Encryption Certificate Enrollment caTokenUserEncryptionKeyEnrollment.cfg For enrolling encryption certificates on the token for a user.
Token User Signing Certificate Enrollment caTokenUserSigningKeyEnrollment.cfg For enrolling signing certificates on the token for a user.
Token User MS Login Certificate Enrollment caTokenMSLoginEnrollment.cfg For enrolling user certificates to use for single sign-on to a Windows domain or PC.
Temporary Token Profiles
Temporary Device Certificate Enrollment caTempTokenDeviceKeyEnrollment.cfg For enrolling certificates for a device on a temporary token.
Temporary Token User Encryption Certificate Enrollment caTempTokenUserEncryptionKeyEnrollment.cfg For enrolling an encryption certificate on a temporary token for a user.
Temporary Token User Signing Certificate Enrollment caTempTokenUserSigningKeyEnrollment.cfg For enrolling a signing certificates on a temporary token for a user.
Renewal Profiles[a]
Token User Encryption Certificate Enrollment (Renewal) caTokenUserEncryptionKeyRenewal.cfg For renewing encryption certificates on the token for a user, if renewal is allowed.
Token User Signing Certificate Enrollment (Renewal) caTokenUserSigningKeyRenewal.cfg For renewing signing certificates on the token for a user, if renewal is allowed.
[a] Renewal profiles can only be used in conjunction with the profile that issued the original certificate. There are two settings that are beneficial:
  • It is important the original enrollment profile name does not change.
  • The Renew Grace Period Constraint should be set in the original enrollment profile. This defines the amount of time before and after the certificate's expiration date when the user is allowed to renew the certificate. There are only a few examples of these in the default profiles, and they are mostly not enabled by default. Editing Enrollment Profiles for the TPS

Administrators have the ability to customize the default smart card enrollment profiles, used with the TPS. For instance, a profile could be edited to include the user's email address in the Subject Alternative Name extension. The email address for the user is retrieved from the authentication directory. To configure the CA for LDAP access, change the following parameters in the profile files, with the appropriate directory information:
policyset.set1.p1.default.params.dnpattern=UID=$request.uid$, O=Token Key User
These CA profiles come with LDAP lookup disabled by default. The ldapStringAttributes parameter tells the CA which LDAP attributes to retrieve from the company directory. For example, if the directory contains uid as an LDAP attribute name, and this will be used in the subject name of the certificate, then uid must be listed in the ldapStringAttributes parameter, and request.uid listed as one of the components in the dnpattern.
Editing certificate profiles is covered in the Setting up Certificate Profiles section in the Red Hat Certificate System Administration Guide.
The format for the dnpattern parameter is covered in the Subject Name Constraint section and the Subject Name Default section in the Red Hat Certificate System Administration Guide. Creating Custom TPS Profiles

Certificate profiles are created as normal in the CA, but they also have to be configured in the TPS for it to be available for token enrollments.


New profiles are added with new releases of Red Hat Certificate System. If an instance is migrated to Certificate System 9.0, then the new profiles need to be added to the migrated instance as if they are custom profiles.
  1. Create a new token profile for the issuing CA. Setting up profiles is covered in the Setting up Certificate Profiles section in the Red Hat Certificate System Administration Guide.
  2. Copy the profile into the CA's profiles directory, /var/lib/instance_name/ca/profiles/ca/.
  3. Edit the CA's CS.cfg file, and add the new profile references and the profile name to the CA's list of profiles. For example:
    # vim etc/pki/instance_name/ca/CS.cfg
  4. Edit the TPS CS.cfg file, and add a line to point to the new CA enrollment profile. For example:
    # vim /etc/pki/instance_name/tps/CS.cfg
  5. Restart the instance after editing the smart card profiles:
    # systemctl restart pki-tomcatd-nuxwdog@instance_name.service
    If the CA and TPS are in separate instances, restart both instances.


Enrollment profiles for the External Registration (externalReg) setting are configured in the user LDAP entry. Using the Windows Smart Card Logon Profile

The TPS uses a profile to generate certificates to use for single sign-on to a Windows domain or PC; this is the Token User MS Login Certificate Enrollment profile (caTokenMSLoginEnrollment.cfg).
However, there are some special considerations that administrators must account for when configuring Windows smart card login.
  • Issue a certificate to the domain controller, if it is not already configured for TLS.
  • Configure the smart card login per user, rather than as a global policy, to prevent locking out the domain administrator.
  • Enable CRL publishing to the Active Directory server because the domain controller checks the CRL at every login.

15.1.5. Disabling Certificate Enrolment Profiles

This section provides instructions on how to disable selected profiles.
To disable a certificate profile, edit the corresponding *.cfg file in the /var/lib/pki/instance_name/ca/profiles/ca/ directory and set the visible and enable parameters to false.
For example, to disable all non-CMC profiles:
  1. List all non-CMC profiles:
    # ls -l /var/lib/pki/instance_name/ca/profiles/ca/ | grep -v "CMC"
  2. In each of the displayed files, set the following parameters to false:
Additionally, set visible=false in all CMC profiles to make them invisible on the end entity page:
  1. List all CMC profiles:
    # ls -l /var/lib/pki/instance_name/ca/profiles/ca/*CMC*
  2. In each of the displayed files, set:
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.