此内容没有您所选择的语言版本。
Chapter 15. Certificate Profiles Configuration
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.
Note
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
15.1.1.1. 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 policyset.cmcUserCertSet.6.constraint.name=No Constraint policyset.cmcUserCertSet.6.default.class_id=userExtensionDefaultImpl policyset.cmcUserCertSet.6.default.name=User Supplied Key Default policyset.cmcUserCertSet.6.default.params.userExtOID=2.5.29.15
The common profile configuration parameters are described in 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. |
| authz.acl |
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. |
| policyset.policyset_id.policy_number.constraint.name | Gives the user-defined name of the constraint. For example, policyset.serverCertSet.1.constraint.name=Subject 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 |
| policyset.policyset_id.policy_number.default.name | Gives the user-defined name of the default. For example, policyset.serverCertSet.1.default.name=Subject 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, policyset.serverCertSet.1.default.params.name=CN=(Name)$request.requestor_name$. |
15.1.1.2. 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=keyUsageExtConstraintImplpolicyset.cmcUserCertSet.6.constraint.name=Key Usage Extension Constraintpolicyset.cmcUserCertSet.6.constraint.params.keyUsageCritical=truepolicyset.cmcUserCertSet.6.constraint.params.keyUsageCrlSign=falsepolicyset.cmcUserCertSet.6.constraint.params.keyUsageDataEncipherment=falsepolicyset.cmcUserCertSet.6.constraint.params.keyUsageDecipherOnly=falsepolicyset.cmcUserCertSet.6.constraint.params.keyUsageDigitalSignature=truepolicyset.cmcUserCertSet.6.constraint.params.keyUsageEncipherOnly=falsepolicyset.cmcUserCertSet.6.constraint.params.keyUsageKeyAgreement=falsepolicyset.cmcUserCertSet.6.constraint.params.keyUsageKeyCertSign=falsepolicyset.cmcUserCertSet.6.constraint.params.keyUsageKeyEncipherment=truepolicyset.cmcUserCertSet.6.constraint.params.keyUsageNonRepudiation=truepolicyset.cmcUserCertSet.6.default.class_id=keyUsageExtDefaultImpl policyset.cmcUserCertSet.6.default.name=Key Usage Default policyset.cmcUserCertSet.6.default.params.keyUsageCritical=true policyset.cmcUserCertSet.6.default.params.keyUsageCrlSign=false policyset.cmcUserCertSet.6.default.params.keyUsageDataEncipherment=false policyset.cmcUserCertSet.6.default.params.keyUsageDecipherOnly=false policyset.cmcUserCertSet.6.default.params.keyUsageDigitalSignature=true policyset.cmcUserCertSet.6.default.params.keyUsageEncipherOnly=false policyset.cmcUserCertSet.6.default.params.keyUsageKeyAgreement=false policyset.cmcUserCertSet.6.default.params.keyUsageKeyCertSign=false policyset.cmcUserCertSet.6.default.params.keyUsageKeyEncipherment=true policyset.cmcUserCertSet.6.default.params.keyUsageNonRepudiation=true
The default is updated to allow user-supplied key extensions:
policyset.cmcUserCertSet.6.default.class_id=userExtensionDefaultImpl policyset.cmcUserCertSet.6.default.name=User Supplied Key Default policyset.cmcUserCertSet.6.default.params.userExtOID=2.5.29.15
This sets the server to accept the extension OID
2.5.29.15 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.
15.1.1.2.1. 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 4.2.1.12. 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
id-kp-serverAuth
| digitalSignature, keyEncipherment, or KeyAgreement |
|
TLS Client (Mutual) Authentication
id-kp-clientAuth
| digitalSignature, keyEncipherment, and/or KeyAgreement |
|
Code Signing
id-kp-codeSigning
| digitalSignature |
|
Email Protection
id-kp-emailProtection
| digitalSignature, nonRepudiation, and/or (keyEncipherment or keyAgreement) |
|
OCSP Response Signing
id-kp-OCSPSigning
| 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-OCSPSigningbut withkeyEnciphermentkey usage bit:policyset.ocspCertSet.6.default.class_id=keyUsageExtDefaultImpl policyset.ocspCertSet..6.default.name=Key Usage Default policyset.ocspCertSet..6.default.params.keyUsageCritical=true policyset.ocspCertSet..6.default.params.keyUsageCrlSign=false policyset.ocspCertSet..6.default.params.keyUsageDataEncipherment=false policyset.ocspCertSet..6.default.params.keyUsageDecipherOnly=false policyset.ocspCertSet..6.default.params.keyUsageDigitalSignature=true policyset.ocspCertSet..6.default.params.keyUsageEncipherOnly=false policyset.ocspCertSet..6.default.params.keyUsageKeyAgreement=false policyset.ocspCertSet..6.default.params.keyUsageKeyCertSign=false policyset.ocspCertSet..6.default.params.keyUsageKeyEncipherment=true policyset.ocspCertSet..6.default.params.keyUsageNonRepudiation=true policyset.ocspCertSet.7.constraint.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.9 policyset.ocspCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl policyset.ocspCertSet.7.default.name=Extended Key Usage Default policyset.ocspCertSet.7.default.params.exKeyUsageCritical=false policyset.ocspCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.9
- An enrollment profile that is intended for the purpose of TLS server authentication contains Extended key
usage id-kp-serverAuthbut with CRL signing key usage bit:policyset.serverCertSet.6.default.name=Key Usage Default policyset.serverCertSet.6.default.params.keyUsageCritical=true policyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true policyset.serverCertSet.6.default.params.keyUsageNonRepudiation=false policyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true policyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=false policyset.serverCertSet.6.default.params.keyUsageKeyAgreement=true policyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false policyset.serverCertSet.6.default.params.keyUsageCrlSign=true policyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false policyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false policyset.cmcUserCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl policyset.cmcUserCertSet.7.default.name=Extended Key Usage Extension Default policyset.cmcUserCertSet.7.default.params.exKeyUsageCritical=false policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1
- The Extended Key Usage Extension Constraint section in the Red Hat Certificate System Administration Guide.
- The keyUsage section in the Red Hat Certificate System Administration Guide.
For details about the EKU extension, see:
- The Extended Key Usage Extension Constraint section in the Red Hat Certificate System Administration Guide.
- The extKeyUsage section in the Red Hat Certificate System Administration Guide.
15.1.1.2.2. 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 policyset.userCertSet.p7.constraint.name=No Constraint policyset.userCertSet.p7.default.class_id=certificatePoliciesExtDefaultImpl policyset.userCertSet.p7.default.name=Certificate Policies Extension Default policyset.userCertSet.p7.default.params.Critical=false policyset.userCertSet.p7.default.params.PoliciesExt.num=1 policyset.userCertSet.p7.default.params.PoliciesExt.certPolicy0.enable=true policyset.userCertSet.p7.default.params.PoliciesExt.certPolicy0.policyId=1.1.1.1 policyset.userCertSet.p7.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.CPSURI.enable=false policyset.userCertSet.p7.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.CPSURI.value= policyset.userCertSet.p7.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.usernotice.enable=false policyset.userCertSet.p7.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.usernotice.explicitText.value= policyset.userCertSet.p7.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.usernotice.noticeReference.noticeNumbers= policyset.userCertSet.p7.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.usernotice.noticeReference.organization=
Certificates issued with the enrollment profile in this example would contain the following information:
Identifier: Certificate Policies: - 2.5.29.32 Critical: no Certificate Policies: Policy Identifier: 1.1.1.1
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.
15.1.1.3. 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:
input.list=i1,i2,i3,i4 ... input.i4.class_id=genericInputImpl input.i4.params.gi_display_name0=Name0 input.i4.params.gi_display_name1=Name1 input.i4.params.gi_display_name2=Name2 input.i4.params.gi_display_name3=Name3 input.i4.params.gi_param_enable0=true input.i4.params.gi_param_enable1=true input.i4.params.gi_param_enable2=true input.i4.params.gi_param_enable3=true input.i4.params.gi_param_name0=gname0 input.i4.params.gi_param_name1=gname1 input.i4.params.gi_param_name2=gname2 input.i4.params.gi_param_name3=gname3 input.i4.params.gi_num=4
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:
policyset.caCertSet.2.default.params.range=825
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.profileeccAdminCert.profilersaAdminCert.profilecaCert.profileeccServerCert.profilesaServerCert.profilecaOCSPCert.profileeccSubsystemCert.profilersaSubsystemCert.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).
- 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
- Open the CA certificate profile used by the configuration wizard.
# vim /usr/share/pki/ca/conf/caCert.profile
- 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 2.default.name=Validity Default 2.default.params.range=7200
- 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 9.default.name=Certificate Policies Extension Default 9.default.params.Critical=false 9.default.params.PoliciesExt.certPolicy0.enable=false 9.default.params.PoliciesExt.certPolicy0.policyId= 9.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.CPSURI.enable=true 9.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.CPSURI.value=CertificatePolicies.example.com 9.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.usernotice.enable=false 9.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.usernotice.explicitText.value= 9.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.usernotice.noticeReference.noticeNumbers= 9.default.params.PoliciesExt.certPolicy0.PolicyQualifiers0.usernotice.noticeReference.organization=
Then, add the default number to the list of defaults to use the new default:list=2,4,5,6,7,8,
9
15.1.4. Managing Smart Card CA Profiles
Note
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”.
| 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:
| ||
15.1.4.1. 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 policyset.set1.p1.default.params.ldap.enable=true policyset.set1.p1.default.params.ldap.basedn=ou=people,dc=host,dc=example,dc=com policyset.set1.p1.default.params.ldapStringAttributes=uid,mail policyset.set1.p1.default.params.ldap.ldapconn.host=localhost.example.com policyset.set1.p1.default.params.ldap.ldapconn.port=389
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.
15.1.4.2. 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.
Note
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.
- 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.
- Copy the profile into the CA's profiles directory,
/var/lib/instance_name/ca/profiles/ca/. - Edit the CA's
CS.cfgfile, 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 profile.list=caUserCert,...,caManualRenewal,
tpsExampleEnrollProfile... profile.caTokenMSLoginEnrollment.class_id=caUserCertEnrollImpl profile.caTokenMSLoginEnrollment.config=/var/lib/pki/instance_name/profiles/ca/tpsExampleEnrollProfile.cfg - Edit the TPS
CS.cfgfile, and add a line to point to the new CA enrollment profile. For example:# vim /etc/pki/instance_name/tps/CS.cfg op.enroll.userKey.keyGen.signing.ca.profileId=tpsExampleEnrollProfile
- 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.
Note
Enrollment profiles for the External Registration (
externalReg) setting are configured in the user LDAP entry.
15.1.4.3. 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:
- List all non-CMC profiles:
# ls -l /var/lib/pki/instance_name/ca/profiles/ca/ | grep -v "CMC"
- In each of the displayed files, set the following parameters to
false:visible=false enable=false
Additionally, set
visible=false in all CMC profiles to make them invisible on the end entity page:
- List all CMC profiles:
# ls -l /var/lib/pki/instance_name/ca/profiles/ca/*CMC*
- In each of the displayed files, set:
visible=false
