2.4. Managing Smart Card CA Profiles

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, as described in Section 5.7, “Mapping Resolver Configuration”.
The profile configuration files are in the /var/lib/instance_name/profiles/ca/ directory with the other CA profiles. The default profiles are listed in Table 2.4, “Default Token Certificate Profiles”.

Table 2.4. 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.

2.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 Section 2.2, “Setting up Certificate Profiles”.
The format for the dnpattern parameter is covered in Section B.2.11, “Subject Name Constraint” and Section B.1.27, “Subject Name Default”.

2.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.
  1. Create a new token profile for the issuing CA. Setting up profiles is covered in Section 2.2, “Setting up Certificate Profiles”.
  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
    
    profile.list=caUserCert,...,caManualRenewal,tpsExampleEnrollProfile  
    ...
    profile.caTokenMSLoginEnrollment.class_id=caUserCertEnrollImpl
    profile.caTokenMSLoginEnrollment.config=/var/lib/pki/instance_name/profiles/ca/tpsExampleEnrollProfile.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
    
    op.enroll.userKey.keyGen.signing.ca.profileId=tpsExampleEnrollProfile
  5. Restart the instance after editing the smart card profiles:
    systemctl restart pki-tomcatd@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.

2.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 SSL.
  • 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.