Managing certificates in IdM

Procedure

1. Under the Identity tab, select the Users, Hosts, or Services subtab.

2. Click the name of the user, host, or service to open its configuration page.

   Figure 2.1. List of Hosts

   
3. Click Actions → New Certificate.
4. Optional: Select the issuing CA and profile ID.
5. Follow the instructions for using the certutil command-line (CLI) utility on the screen.
6. Click Issue.

Procedure

1. Create a temporary directory for the certificate database:

   # mkdir ~/certdb/

2. Create a new temporary certificate database, for example:

   # certutil -N -d ~/certdb/

3. Create the CSR and redirect the output to a file. For example, to create a CSR for a 4096 bit certificate and to set the subject to CN=server.example.com,O=EXAMPLE.COM:

   # certutil -R -d ~/certdb/ -a -g 4096 -s "CN=server.example.com,O=EXAMPLE.COM" -8 server.example.com > certificate_request.csr

4. Submit the certificate request file to the CA running on the IdM server. Specify the Kerberos principal to associate with the newly-issued certificate:

   # ipa cert-request certificate_request.csr --principal=host/server.example.com

   The ipa cert-request command in IdM uses the following defaults:

   • The caIPAserviceCert certificate profile

     To select a custom profile, use the --profile-id option.

   • The integrated IdM root CA, ipa

     To select a sub-CA, use the --ca option.

Procedure

1. Create one or more aliases for your Kerberos principal test/server.example.com. For example, test1/server.example.com and test2/server.example.com.

2. In the CSR, add a subjectAltName for dnsName (server.example.com) and otherName (test2/server.example.com). To do this, configure the openssl.conf file to include the following line specifying the UPN otherName and subjectAltName:

   otherName=1.3.6.1.4.1.311.20.2.3;UTF8:test2/server.example.com@EXAMPLE.COM
   DNS.1 = server.example.com

3. Create a certificate request using openssl:

   openssl req -new -newkey rsa:2048 -keyout test2service.key -sha256 -nodes -out certificate_request.csr -config openssl.conf

4. Submit the certificate request file to the CA running on the IdM server. Specify the Kerberos principal to associate with the newly-issued certificate:

   # ipa cert-request certificate_request.csr --principal=host/server.example.com

   The ipa cert-request command in IdM uses the following defaults:

   • The caIPAserviceCert certificate profile

     To select a custom profile, use the --profile-id option.

   • The integrated IdM root CA, ipa

     To select a sub-CA, use the --ca option.

Procedure

1. Generate a certificate-signing request (CSR) for your user, host or service. For example, to use the openssl utility to generate a CSR for the HTTP service running on client.idm.example.com, enter:

   # openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout new.key -out new.csr -subj '/CN=client.idm.example.com,O=IDM.EXAMPLE.COM'

   As a result, the CSR is stored in new.csr.

2. Create your Ansible playbook file request-certificate.yml with the following content:

   ---
   - name: Playbook to request a certificate
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
     - name: Request a certificate for a web server
       ipacert:
         ipaadmin_password: "{{ ipaadmin_password }}"
         state: requested
         csr: |
           -----BEGIN CERTIFICATE REQUEST-----
           MIGYMEwCAQAwGTEXMBUGA1UEAwwOZnJlZWlwYSBydWxlcyEwKjAFBgMrZXADIQBs
           HlqIr4b/XNK+K8QLJKIzfvuNK0buBhLz3LAzY7QDEqAAMAUGAytlcANBAF4oSCbA
           5aIPukCidnZJdr491G4LBE+URecYXsPknwYb+V+ONnf5ycZHyaFv+jkUBFGFeDgU
           SYaXm/gF8cDYjQI=
           -----END CERTIFICATE REQUEST-----
         principal: HTTP/client.idm.example.com
       register: cert

   Replace the certificate request with the CSR from new.csr.

3. Request the certificate:

   $ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/request-certificate.yml

Procedure

1. Create your Ansible playbook file revoke-certificate.yml with the following content:

   ---
   - name: Playbook to revoke a certificate
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
     - name: Revoke a certificate for a web server
       ipacert:
         ipaadmin_password: "{{ ipaadmin_password }}"
         serial_number: 123456789
         revocation_reason: "keyCompromise"
         state: revoked

2. Revoke the certificate:

   $ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/revoke-certificate.yml

Procedure

1. Create your Ansible playbook file restore-certificate.yml with the following content:

   ---
   - name: Playbook to restore a certificate
     hosts: ipaserver
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
     - name: Restore a certificate for a web service
       ipacert:
         ipaadmin_password: "{{ ipaadmin_password }}"
         serial_number: 123456789
         state: released

2. Run the playbook:

   $ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/restore-certificate.yml

Procedure

1. Create your Ansible playbook file retrieve-certificate.yml with the following content:

   ---
   - name: Playbook to retrieve a certificate and store it locally on the managed node
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
     - name: Retrieve a certificate and save it to file 'cert.pem'
       ipacert:
         ipaadmin_password: "{{ ipaadmin_password }}"
         serial_number: 123456789
         certificate_out: cert.pem
         state: retrieved

2. Retrieve the certificate:

   $ ansible-playbook --vault-password-file=password_file -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/retrieve-certificate.yml

Procedure

1. Open the Identity tab, and select the Users, Hosts, or Services subtab.
2. Click the name of the user, host, or service to open its configuration page.

3. Click Add next to the Certificates entry.

   Figure 4.1. Adding a certificate to a user account

   
4. Paste the certificate in Base64 or PEM encoded format into the text field, and click Add.
5. Click Save to store the changes.

Procedure

1. Open the Identity tab, and select the Users, Hosts, or Services subtab.
2. Click the name of the user, host, or service to open its configuration page.
3. Click the Actions next to the certificate to delete, and select Delete.
4. Click Save to store the changes.

Procedure

1. Create a custom profile by copying an existing default profile:

   $ ipa certprofile-show --out smime.cfg caIPAserviceCert
   ------------------------------------------------
   Profile configuration stored in file 'smime.cfg'
   ------------------------------------------------
     Profile ID: caIPAserviceCert
     Profile description: Standard profile for network services
     Store issued certificates: TRUE

2. Open the newly created profile configuration file in a text editor.

   $ vi  smime.cfg

3. Change the Profile ID to a name that reflects the usage of the profile, for example smime.

   Note

   When you are importing a newly created profile, the profileId field, if present, must match the ID specified on the command line.

4. Update the Extended Key Usage configuration. The default Extended Key Usage extension configuration is for TLS server and client authentication. For example for S/MIME, the Extended Key Usage must be configured for email protection:

   policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.4

5. Import the new profile:

   $ ipa certprofile-import smime --file smime.cfg \
     --desc "S/MIME certificates" --store TRUE
   
   ------------------------
   Imported profile "smime"
   ------------------------
     Profile ID: smime
     Profile description: S/MIME certificates
     Store issued certificates: TRUE

Procedure

1. Create a new group for the users of the certificate profile:

   $ ipa group-add smime_users_group
   ---------------------------------
   Added group "smime users group"
   ---------------------------------
     Group name: smime_users_group
     GID: 75400001

2. Create a new user to add to the smime_user_group group:

   $ ipa user-add smime_user
   First name: smime
   Last name: user
   ----------------------
   Added user "smime_user"
   ----------------------
     User login: smime_user
     First name: smime
     Last name: user
     Full name: smime user
     Display name: smime user
     Initials: TU
     Home directory: /home/smime_user
     GECOS: smime user
     Login shell: /bin/sh
     Principal name: smime_user@IDM.EXAMPLE.COM
     Principal alias: smime_user@IDM.EXAMPLE.COM
     Email address: smime_user@idm.example.com
     UID: 1505000004
     GID: 1505000004
     Password: False
     Member of groups: ipausers
     Kerberos keys available: False

3. Add the smime_user to the smime_users_group group:

   $ ipa group-add-member smime_users_group --users=smime_user
     Group name: smime_users_group
     GID: 1505000003
     Member users: smime_user
   -------------------------
   Number of members added 1
   -------------------------

4. Create the CA ACL to allow users in the group to access the certificate profile:

   $ ipa caacl-add smime_acl
   ------------------------
   Added CA ACL "smime_acl"
   ------------------------
     ACL name: smime_acl
     Enabled: TRUE

5. Add the user group to the CA ACL:

   $ ipa caacl-add-user smime_acl --group smime_users_group
     ACL name: smime_acl
     Enabled: TRUE
     User Groups: smime_users_group
   -------------------------
   Number of members added 1
   -------------------------

6. Add the certificate profile to the CA ACL:

   $ ipa caacl-add-profile smime_acl --certprofile smime
     ACL name: smime_acl
     Enabled: TRUE
     Profiles: smime
     User Groups: smime_users_group
   -------------------------
   Number of members added 1
   -------------------------

Procedure

1. Generate a certificate request for the user. For example, using OpenSSL:

   $ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=smime_user'

2. Request a new certificate for the user from the IdM CA:

   $ ipa cert-request cert.csr --principal=smime_user --profile-id=smime

   Optionally pass the --ca sub-CA_name option to the command to request the certificate from a sub-CA instead of the root CA.

Procedure

1. Determine the certificate profile ID for the certificate profile you are modifying. To display all certificate profiles currently stored in IdM:

   # ipa certprofile-find
   
   ------------------
   4 profiles matched
   ------------------
     Profile ID: caIPAserviceCert
     Profile description: Standard profile for network services
     Store issued certificates: TRUE
   
     Profile ID: IECUserRoles
     ...
   
     Profile ID: smime
     Profile description: S/MIME certificates
     Store issued certificates: TRUE
   --------------------------
   Number of entries returned
   --------------------------

2. Modify the certificate profile description. For example, if you created a custom certificate profile for S/MIME certificates using an existing profile, change the description in line with the new usage:

   # ipa certprofile-mod smime --desc "New certificate profile description"
   ------------------------------------
   Modified Certificate Profile "smime"
   ------------------------------------
       Profile ID: smime
       Profile description: New certificate profile description
       Store issued certificates: TRUE

3. Open your customer certificate profile file in a text editor and modify to suit your requirements:

   # vi smime.cfg

   For details on the options which can be configured in the certificate profile configuration file, see Certificate profile configuration parameters.

4. Update the existing certificate profile configuration file:

   # ipa certprofile-mod _profile_ID_ --file=smime.cfg

Procedure

1. In the Authentication menu, click Certificates > Certificates.

2. Click the serial number of the certificate to open the certificate information page.

   Figure 7.1. List of Certificates

   
3. In the certificate information page, locate the Expires On information.

1. Obtain files with the CA certificates in the PEM format.
2. Run the built-in ipa-advise script.
3. Reload the system configuration.

Procedure

1. Create a directory in which you will do the configuration:

   [root@server]# mkdir ~/SmartCard/

2. Navigate to the directory:

   [root@server]# cd ~/SmartCard/

3. Obtain the relevant CA certificates stored in files in PEM format. If your CA certificate is stored in a file of a different format, such as DER, convert it to PEM format. The IdM Certificate Authority certificate is in PEM format and is located in the /etc/ipa/ca.crt file.

   Convert a DER file to a PEM file:

   # openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM

4. For convenience, copy the certificates to the directory in which you want to do the configuration:

   [root@server SmartCard]# cp /tmp/rootca.pem ~/SmartCard/
   [root@server SmartCard]# cp /tmp/subca.pem ~/SmartCard/
   [root@server SmartCard]# cp /tmp/issuingca.pem ~/SmartCard/

5. Optional: If you use certificates of external certificate authorities, use the openssl x509 utility to view the contents of the files in the PEM format to check that the Issuer and Subject values are correct:

   [root@server SmartCard]# openssl x509 -noout -text -in rootca.pem | more

6. Generate a configuration script with the in-built ipa-advise utility, using the administrator’s privileges:

   [root@server SmartCard]# kinit admin
   [root@server SmartCard]# ipa-advise config-server-for-smart-card-auth > config-server-for-smart-card-auth.sh

   The config-server-for-smart-card-auth.sh script performs the following actions:

   • It configures the IdM Apache HTTP Server.
   • It enables Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) on the Key Distribution Center (KDC).
   • It configures the IdM Web UI to accept smart card authorization requests.

7. Execute the script, adding the PEM files containing the root CA and sub CA certificates as arguments:

   [root@server SmartCard]# chmod +x config-server-for-smart-card-auth.sh
   [root@server SmartCard]# ./config-server-for-smart-card-auth.sh rootca.pem subca.pem issuingca.pem
   Ticket cache:KEYRING:persistent:0:0
   Default principal: admin@IDM.EXAMPLE.COM
   [...]
   Systemwide CA database updated.
   The ipa-certupdate command was successful

   Note

   Ensure that you add the root CA’s certificate as an argument before any sub CA certificates and that the CA or sub CA certificates have not expired.

8. Optional: If the certificate authority that issued the user certificate does not provide any Online Certificate Status Protocol (OCSP) responder, you may need to disable OCSP check for authentication to the IdM Web UI:

   1. Set the SSLOCSPEnable parameter to off in the /etc/httpd/conf.d/ssl.conf file:

      SSLOCSPEnable off

   2. Restart the Apache daemon (httpd) for the changes to take effect immediately:

      [root@server SmartCard]# systemctl restart httpd

   Warning

   Do not disable the OCSP check if you only use user certificates issued by the IdM CA. OCSP responders are part of IdM.

   For instructions on how to keep the OCSP check enabled, and yet prevent a user certificate from being rejected by the IdM server if it does not contain the information about the location at which the CA that issued the user certificate listens for OCSP service requests, see the SSLOCSPDefaultResponder directive in Apache mod_ssl configuration options.

Procedure

1. If your CA certificates are stored in files of a different format, such as DER, convert them to PEM format:

   # openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM

   The IdM Certificate Authority certificate is in PEM format and is located in the /etc/ipa/ca.crt file.

2. Optional: Use the openssl x509 utility to view the contents of the files in the PEM format to check that the Issuer and Subject values are correct:

   # openssl x509 -noout -text -in root-ca.pem | more

3. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

4. Create a subdirectory dedicated to the CA certificates:

   $ mkdir SmartCard/

5. For convenience, copy all the required certificates to the ~/MyPlaybooks/SmartCard/ directory:

   # cp /tmp/root-ca.pem ~/MyPlaybooks/SmartCard/
   # cp /tmp/intermediate-ca.pem ~/MyPlaybooks/SmartCard/
   # cp /etc/ipa/ca.crt ~/MyPlaybooks/SmartCard/ipa-ca.crt

6. In your Ansible inventory file, specify the following:

   • The IdM servers that you want to configure for smart card authentication.
   • The IdM administrator password.

   • The paths to the certificates of the CAs in the following order:

     • The root CA certificate file
     • The intermediate CA certificates files
     • The IdM CA certificate file

   The file can look as follows:

   [ipaserver]
   ipaserver.idm.example.com
   
   [ipareplicas]
   ipareplica1.idm.example.com
   ipareplica2.idm.example.com
   
   [ipacluster:children]
   ipaserver
   ipareplicas
   
   [ipacluster:vars]
   ipaadmin_password= "{{ ipaadmin_password }}"
   ipasmartcard_server_ca_certs=/home/<user_name>/MyPlaybooks/SmartCard/root-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/intermediate-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/ipa-ca.crt

7. Create an install-smartcard-server.yml playbook with the following content:

   ---
   - name: Playbook to set up smart card authentication for an IdM server
     hosts: ipaserver
     become: true
   
     roles:
     - role: ipasmartcard_server
       state: present

8. Save the file.

9. Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:

   $ ansible-playbook --vault-password-file=password_file -v -i inventory install-smartcard-server.yml

   The ipasmartcard_server Ansible role performs the following actions:

   • It configures the IdM Apache HTTP Server.
   • It enables Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) on the Key Distribution Center (KDC).
   • It configures the IdM Web UI to accept smart card authorization requests.

10. Optional: If the certificate authority that issued the user certificate does not provide any Online Certificate Status Protocol (OCSP) responder, you may need to disable OCSP check for authentication to the IdM Web UI:

    1. Connect to the IdM server as root:

       ssh root@ipaserver.idm.example.com

    2. Set the SSLOCSPEnable parameter to off in the /etc/httpd/conf.d/ssl.conf file:

       SSLOCSPEnable off

    3. Restart the Apache daemon (httpd) for the changes to take effect immediately:

       # systemctl restart httpd

    Warning

    Do not disable the OCSP check if you only use user certificates issued by the IdM CA. OCSP responders are part of IdM.

    For instructions on how to keep the OCSP check enabled, and yet prevent a user certificate from being rejected by the IdM server if it does not contain the information about the location at which the CA that issued the user certificate listens for OCSP service requests, see the SSLOCSPDefaultResponder directive in Apache mod_ssl configuration options.

Procedure

1. On an IdM server, generate a configuration script with ipa-advise using the administrator’s privileges:

   [root@server SmartCard]# kinit admin
   [root@server SmartCard]# ipa-advise config-client-for-smart-card-auth > config-client-for-smart-card-auth.sh

   The config-client-for-smart-card-auth.sh script performs the following actions:

   • It configures the smart card daemon.
   • It sets the system-wide truststore.
   • It configures the System Security Services Daemon (SSSD) to allow users to authenticate with either their user name and password or with their smart card. For more details on SSSD profile options for smart card authentication, see Smart card authentication options in RHEL.

2. From the IdM server, copy the script to a directory of your choice on the IdM client machine:

   [root@server SmartCard]# scp config-client-for-smart-card-auth.sh root@client.idm.example.com:/root/SmartCard/
   Password:
   config-client-for-smart-card-auth.sh        100%   2419       3.5MB/s   00:00

3. From the IdM server, copy the CA certificate files in PEM format for convenience to the same directory on the IdM client machine as used in the previous step:

   [root@server SmartCard]# scp {rootca.pem,subca.pem,issuingca.pem} root@client.idm.example.com:/root/SmartCard/
   Password:
   rootca.pem                          100%   1237     9.6KB/s   00:00
   subca.pem                           100%   2514    19.6KB/s   00:00
   issuingca.pem                       100%   2514    19.6KB/s   00:00

4. On the client machine, execute the script, adding the PEM files containing the CA certificates as arguments:

   [root@client SmartCard]# kinit admin
   [root@client SmartCard]# chmod +x config-client-for-smart-card-auth.sh
   [root@client SmartCard]# ./config-client-for-smart-card-auth.sh rootca.pem subca.pem issuingca.pem
   Ticket cache:KEYRING:persistent:0:0
   Default principal: admin@IDM.EXAMPLE.COM
   [...]
   Systemwide CA database updated.
   The ipa-certupdate command was successful

   Note

   Ensure that you add the root CA’s certificate as an argument before any sub CA certificates and that the CA or sub CA certificates have not expired.

Procedure

1. If your CA certificates are stored in files of a different format, such as DER, convert them to PEM format:

   # openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM

   The IdM CA certificate is in PEM format and is located in the /etc/ipa/ca.crt file.

2. Optional: Use the openssl x509 utility to view the contents of the files in the PEM format to check that the Issuer and Subject values are correct:

   # openssl x509 -noout -text -in root-ca.pem | more

3. On your Ansible control node, navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

4. Create a subdirectory dedicated to the CA certificates:

   $ mkdir SmartCard/

5. For convenience, copy all the required certificates to the ~/MyPlaybooks/SmartCard/ directory, for example:

   # cp /tmp/root-ca.pem ~/MyPlaybooks/SmartCard/
   # cp /tmp/intermediate-ca.pem ~/MyPlaybooks/SmartCard/
   # cp /etc/ipa/ca.crt ~/MyPlaybooks/SmartCard/ipa-ca.crt

6. In your Ansible inventory file, specify the following:

   • The IdM clients that you want to configure for smart card authentication.
   • The IdM administrator password.

   • The paths to the certificates of the CAs in the following order:

     • The root CA certificate file
     • The intermediate CA certificates files
     • The IdM CA certificate file

   The file can look as follows:

   [ipaclients]
   ipaclient1.example.com
   ipaclient2.example.com
   
   [ipaclients:vars]
   ipaadmin_password=SomeADMINpassword
   ipasmartcard_client_ca_certs=/home/<user_name>/MyPlaybooks/SmartCard/root-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/intermediate-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/ipa-ca.crt

7. Create an install-smartcard-clients.yml playbook with the following content:

   ---
   - name: Playbook to set up smart card authentication for an IdM client
     hosts: ipaclients
     become: true
   
     roles:
     - role: ipasmartcard_client
       state: present

8. Save the file.

9. Run the Ansible playbook. Specify the playbook and inventory files:

   $ ansible-playbook --vault-password-file=password_file -v -i inventory install-smartcard-clients.yml

   The ipasmartcard_client Ansible role performs the following actions:

   • It configures the smart card daemon.
   • It sets the system-wide truststore.
   • It configures the System Security Services Daemon (SSSD) to allow users to authenticate with either their user name and password or their smart card. For more details on SSSD profile options for smart card authentication, see Smart card authentication options in RHEL.

Procedure

1. Log into the IdM Web UI as an administrator if you want to add a certificate to another user. For adding a certificate to your own profile, you do not need the administrator’s credentials.
2. Navigate to Users → Active users → sc_user.
3. Find the Certificate option and click Add.

4. In the command-line interface, display the certificate in the PEM format using the cat utility or a text editor:

   [user@client SmartCard]$ cat testuser.crt

5. Copy and paste the certificate from the CLI into the window that has opened in the Web UI.

6. Click Add.

   Figure 8.1. Adding a new certificate in the IdM Web UI

   

Procedure

1. Log into the IdM CLI as an administrator if you want to add a certificate to another user:

   [user@client SmartCard]$ kinit admin

   For adding a certificate to your own profile, you do not need the administrator’s credentials:

   [user@client SmartCard]$ kinit sc_user

2. Create an environment variable containing the certificate with the header and footer removed and concatenated into a single line, which is the format expected by the ipa user-add-cert command:

   [user@client SmartCard]$ export CERT=`openssl x509 -outform der -in testuser.crt | base64 -w0 -`

   Note that certificate in the testuser.crt file must be in the PEM format.

3. Add the certificate to the profile of sc_user using the ipa user-add-cert command:

   [user@client SmartCard]$ ipa user-add-cert sc_user --certificate=$CERT

Procedure

1. Install the opensc and gnutls-utils packages:

   # dnf -y install opensc gnutls-utils

2. Start the pcscd service.

   # systemctl start pcscd

Procedure

1. Erase your smart card and authenticate yourself with your PIN:

   $ pkcs15-init --erase-card --use-default-transport-keys
   Using reader with a card: Reader name
   PIN [Security Officer PIN] required.
   Please enter PIN [Security Officer PIN]:

   The card has been erased.

2. Initialize your smart card, set your user PIN and PUK, and your Security Officer PIN and PUK:

   $ pkcs15-init --create-pkcs15 --use-default-transport-keys \ --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123
   Using reader with a card: Reader name

   The pcks15-init tool creates a new slot on the smart card.

3. Set a label and the authentication ID for the slot:

   $ pkcs15-init --store-pin --label testuser \ --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478
   Using reader with a card: Reader name

   The label is set to a human-readable value, in this case, testuser. The auth-id must be two hexadecimal values, in this case it is set to 01.

4. Store and label the private key in the new slot on the smart card:

   $ pkcs15-init --store-private-key testuser.key --label testuser_key \ --auth-id 01 --id 01 --pin 963214
   Using reader with a card: Reader name

   Note

   The value you specify for --id must be the same when storing your private key and storing your certificate in the next step. Specifying your own value for --id is recommended as otherwise a more complicated value is calculated by the tool.

5. Store and label the certificate in the new slot on the smart card:

   $ pkcs15-init --store-certificate testuser.crt --label testuser_crt \ --auth-id 01 --id 01 --format pem --pin 963214
   Using reader with a card: Reader name

6. Optional: Store and label the public key in the new slot on the smart card:

   $ pkcs15-init --store-public-key testuserpublic.key --label testuserpublic_key --auth-id 01 --id 01 --pin 963214
   Using reader with a card: Reader name

   Note

   If the public key corresponds to a private key or certificate, specify the same ID as the ID of the private key or certificate.

7. Optional: Certain smart cards require you to finalize the card by locking the settings:

   $ pkcs15-init -F

   At this stage, your smart card includes the certificate, private key, and public key in the newly created slot. You have also created your user PIN and PUK and the Security Officer PIN and PUK.

Procedure

1. Open the IdM Web UI in the browser.

2. Click Log In Using Certificate.

   

3. If the Password Required dialog box opens, add the PIN to unlock the smart card and click the OK button.

   The User Identification Request dialog box opens.

   If the smart card contains more than one certificate, select the certificate you want to use for authentication in the drop down list below Choose a certificate to present as identification.

4. Click the OK button.

Procedure

1. Insert the smart card in the reader.
2. Enter the smart card PIN.
3. Click Sign In.

Procedure

1. Connect from the IdM server and copy the adcs-winserver-ca.cer root certificate to the IdM server:

   root@idmserver ~]# sftp Administrator@winserver.ad.example.com
   Administrator@winserver.ad.example.com's password:
   Connected to Administrator@winserver.ad.example.com.
   sftp> cd <Path to certificates>
   sftp> ls
   adcs-winserver-ca.cer    aduser1.pfx
   sftp>
   sftp> get adcs-winserver-ca.cer
   Fetching <Path to certificates>/adcs-winserver-ca.cer to adcs-winserver-ca.cer
   <Path to certificates>/adcs-winserver-ca.cer                 100%  1254    15KB/s 00:00
   sftp quit

2. Connect from the IdM client and copy the aduser1.pfx user certificate to the client:

   [root@client1 ~]# sftp Administrator@winserver.ad.example.com
   Administrator@winserver.ad.example.com's password:
   Connected to Administrator@winserver.ad.example.com.
   sftp> cd /<Path to certificates>
   sftp> get aduser1.pfx
   Fetching <Path to certificates>/aduser1.pfx to aduser1.pfx
   <Path to certificates>/aduser1.pfx                 100%  1254    15KB/s 00:00
   sftp quit

Procedure

1. On the IdM server, use the ipa-advise script for configuring a client:

   [root@idmserver ~]# ipa-advise config-client-for-smart-card-auth > sc_client.sh

2. On the IdM server, use the ipa-advise script for configuring a server:

   [root@idmserver ~]# ipa-advise config-server-for-smart-card-auth > sc_server.sh

3. On the IdM server, execute the script:

   [root@idmserver ~]# sh -x sc_server.sh adcs-winserver-ca.cer

   • It configures the IdM Apache HTTP Server.
   • It enables Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) on the Key Distribution Center (KDC).
   • It configures the IdM Web UI to accept smart card authorization requests.

4. Copy the sc_client.sh script to the client system:

   [root@idmserver ~]# scp sc_client.sh root@client1.idm.example.com:/root
   Password:
   sc_client.sh                  100%  2857   1.6MB/s   00:00

5. Copy the Windows certificate to the client system:

   [root@idmserver ~]# scp adcs-winserver-ca.cer root@client1.idm.example.com:/root
   Password:
   adcs-winserver-ca.cer                 100%  1254   952.0KB/s   00:00

6. On the client system, run the client script:

   [root@idmclient1 ~]# sh -x sc_client.sh adcs-winserver-ca.cer

Procedure

1. On the IdM client, into the PEM format:

   [root@idmclient1 ~]# openssl pkcs12 -in aduser1.pfx -out aduser1_cert_only.pem -clcerts -nodes
   Enter Import Password:

2. Extract the key into the separate file:

   [root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -nocerts -out adduser1.pem > aduser1.key

3. Extract the public certificate into the separate file:

   [root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -clcerts -nokeys -out aduser1_cert_only.pem > aduser1.crt

Procedure

1. Install the opensc and gnutls-utils packages:

   # dnf -y install opensc gnutls-utils

2. Start the pcscd service.

   # systemctl start pcscd

Procedure

1. Erase your smart card and authenticate yourself with your PIN:

   $ pkcs15-init --erase-card --use-default-transport-keys
   Using reader with a card: Reader name
   PIN [Security Officer PIN] required.
   Please enter PIN [Security Officer PIN]:

   The card has been erased.

2. Initialize your smart card, set your user PIN and PUK, and your Security Officer PIN and PUK:

   $ pkcs15-init --create-pkcs15 --use-default-transport-keys \ --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123
   Using reader with a card: Reader name

   The pcks15-init tool creates a new slot on the smart card.

3. Set a label and the authentication ID for the slot:

   $ pkcs15-init --store-pin --label testuser \ --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478
   Using reader with a card: Reader name

   The label is set to a human-readable value, in this case, testuser. The auth-id must be two hexadecimal values, in this case it is set to 01.

4. Store and label the private key in the new slot on the smart card:

   $ pkcs15-init --store-private-key testuser.key --label testuser_key \ --auth-id 01 --id 01 --pin 963214
   Using reader with a card: Reader name

   Note

   The value you specify for --id must be the same when storing your private key and storing your certificate in the next step. Specifying your own value for --id is recommended as otherwise a more complicated value is calculated by the tool.

5. Store and label the certificate in the new slot on the smart card:

   $ pkcs15-init --store-certificate testuser.crt --label testuser_crt \ --auth-id 01 --id 01 --format pem --pin 963214
   Using reader with a card: Reader name

6. Optional: Store and label the public key in the new slot on the smart card:

   $ pkcs15-init --store-public-key testuserpublic.key --label testuserpublic_key --auth-id 01 --id 01 --pin 963214
   Using reader with a card: Reader name

   Note

   If the public key corresponds to a private key or certificate, specify the same ID as the ID of the private key or certificate.

7. Optional: Certain smart cards require you to finalize the card by locking the settings:

   $ pkcs15-init -F

   At this stage, your smart card includes the certificate, private key, and public key in the newly created slot. You have also created your user PIN and PUK and the Security Officer PIN and PUK.

Procedure

1. Open the sssd.conf file:

   [root@idmclient1 ~]# vim /etc/sssd/sssd.conf

2. Change the value of p11_child_timeout:

   [pam]
   p11_child_timeout = 60

3. Change the value of krb5_auth_timeout:

   [domain/IDM.EXAMPLE.COM]
   krb5_auth_timeout = 60

4. Save the settings.

1. An administrator has to load the certificate mapping data or the full certificate into a user account.
2. An administrator has to create a certificate mapping rule to allow successful logging into IdM for a user whose account contains a certificate mapping data entry that matches the information on the certificate.

Procedure

1. Create a variable pointing to your certificate that also ensures it is correctly encoded so you can retrieve the required data.

   # CERT=$(openssl x509 -in /path/to/certificate -outform der|base64 -w0)

2. Use the sssctl cert-eval-rule to determine the matching data. In the following example the certificate serial number is used.

   # sssctl cert-eval-rule $CERT --match='<ISSUER>CN=adcs19-WIN1-CA,DC=AD,DC=EXAMPLE,DC=COM' --map='LDAPU1:(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<SR>{serial_number!hex_ur})'
   Certificate matches rule.
   Mapping filter:
   
       (altSecurityIdentities=X509:<I>DC=com,DC=example,DC=ad,CN=adcs19-WIN1-CA<SR>0F0000000000DB8852DD7B246C9C0F0000003B)

   In this case, add everything after altSecurityIdentities= to the altSecurityIdentities attribute in AD for the user. If using SKI mapping, use --map='LDAPU1:(altSecurityIdentities=X509:<SKI>{subject_key_id!hex_u})'.

3. Optional: To create a new mapping rule in the CLI based on a matching rule which specifies that the certificate issuer must match adcs19-WIN1-CA of the ad.example.com domain and the serial number of the certificate must match the altSecurityIdentities entry in a user account:

   # ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=adcs19-WIN1-CA,DC=AD,DC=EXAMPLE,DC=COM' --maprule 'LDAPU1:(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<SR>{serial_number!hex_ur})'

1. On an Identity Management server, obtain administrator privileges and create a shell script to configure the server.

   1. Run the ipa-advise config-server-for-smart-card-auth command, and save its output to a file, for example server_certificate_script.sh:

      # kinit admin
      # ipa-advise config-server-for-smart-card-auth > server_certificate_script.sh

   2. Add execute permissions to the file using the chmod utility:

      # chmod +x server_certificate_script.sh

2. On all the servers in the Identity Management domain, run the server_certificate_script.sh script

   1. with the path of the IdM Certificate Authority certificate, /etc/ipa/ca.crt, as input if the IdM CA is the only certificate authority that has issued the certificates of the users you want to enable certificate authentication for:

      # ./server_certificate_script.sh /etc/ipa/ca.crt

   2. with the paths leading to the relevant CA certificates as input if different external CAs signed the certificates of the users who you want to enable certificate authentication for:

      # ./server_certificate_script.sh /tmp/ca1.pem /tmp/ca2.pem

Procedure

1. Optional: Create a new directory, for example ~/certdb/, and make it a temporary certificate database. When asked, create an NSS Certificate DB password to encrypt the keys to the certificate to be generated in a subsequent step:

   # mkdir ~/certdb/
   # certutil -N -d ~/certdb/
   Enter a password which will be used to encrypt your keys.
   The password should be at least 8 characters long,
   and should contain at least one non-alphabetic character.
   
   Enter new password:
   Re-enter password:

2. Create the certificate signing request (CSR) and redirect the output to a file. For example, to create a CSR with the name certificate_request.csr for a 4096 bit certificate for the idm_user user in the IDM.EXAMPLE.COM realm, setting the nickname of the certificate private keys to idm_user for easy findability, and setting the subject to CN=idm_user,O=IDM.EXAMPLE.COM:

   # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr

3. When prompted, enter the same password that you entered when using certutil to create the temporary database. Then continue typing randlomly until told to stop:

   Enter Password or Pin for "NSS Certificate DB":
   
   A random seed must be generated that will be used in the
   creation of your key.  One of the easiest ways to create a
   random seed is to use the timing of keystrokes on a keyboard.
   
   To begin, type keys on the keyboard until this progress meter
   is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
   
   
   Continue typing until the progress meter is full:

4. Submit the certificate request file to the server. Specify the Kerberos principal to associate with the newly-issued certificate, the output file to store the certificate, and optionally the certificate profile. For example, to obtain a certificate of the IECUserRoles profile, a profile with added user roles extension, for the idm_user@IDM.EXAMPLE.COM principal, and save it in the ~/idm_user.pem file:

   # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --certificate-out=~/idm_user.pem

5. Add the certificate to the NSS database. Use the -n option to set the same nickname that you used when creating the CSR previously so that the certificate matches the private key in the NSS database. The -t option sets the trust level. For details, see the certutil(1) man page. The -i option specifies the input certificate file. For example, to add to the NSS database a certificate with the idm_user nickname that is stored in the ~/idm_user.pem file in the ~/certdb/ database:

   # certutil -A -d ~/certdb/ -n idm_user -t "P,," -i ~/idm_user.pem

6. Verify that the key in the NSS database does not show (orphan) as its nickname. For example, to verify that the certificate stored in the ~/certdb/ database is not orphaned:

   # certutil -K -d ~/certdb/
   < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user

7. Use the pk12util command to export the certificate from the NSS database to the PKCS12 format. For example, to export the certificate with the idm_user nickname from the /root/certdb NSS database into the ~/idm_user.p12 file:

   # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
   Enter Password or Pin for "NSS Certificate DB":
   Enter password for PKCS12 file:
   Re-enter password:
   pk12util: PKCS12 EXPORT SUCCESSFUL

8. Transfer the certificate to the host on which you want the certificate authentication for idm_user to be enabled:

   # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/

9. On the host to which the certificate has been transferred, make the directory in which the .pkcs12 file is stored inaccessible to the 'other' group for security reasons:

   # chmod o-rwx /home/idm_user/

10. For security reasons, remove the temporary NSS database and the .pkcs12 file from the server:

    # rm ~/certdb/
    # rm ~/idm_user.p12

Procedure

1. Open Firefox, then navigate to Preferences → Privacy & Security.

   Figure 11.1. Privacy and Security section in Preferences

   

2. Click View Certificates.

   Figure 11.2. View Certificates in Privacy and Security

   
3. In the Your Certificates tab, click Import. Locate and open the certificate of the user in the PKCS12 format, then click OK and OK.

4. Make sure that the Identity Management Certificate Authority is recognized by Firefox as a trusted authority:

   1. Save the IdM CA certificate locally:

      • Navigate to the IdM web UI by writing the name of your IdM server in the Firefox address bar. Click Advanced on the Insecure Connection warning page.

        Figure 11.3. Insecure Connection

        

      • Add Exception. Click View.

        Figure 11.4. View the Details of a Certificate

        

      • In the Details tab, highlight the Certificate Authority fields.

        Figure 11.5. Exporting the CA Certificate

        
      • Click Export. Save the CA certificate, for example as the CertificateAuthority.crt file, then click Close, and Cancel.

   2. Import the IdM CA certificate to Firefox as a trusted certificate authority certificate:

      • Open Firefox, navigate to Preferences and click Privacy & Security.

        Figure 11.6. Privacy and Security section in Preferences

        

      • Click View Certificates.

        Figure 11.7. View Certificates in Privacy and Security

        
      • In the Authorities tab, click Import. Locate and open the CA certificate that you saved in the previous step in the CertificateAuthority.crt file. Trust the certificate to identify websites, then click OK and OK.
5. Continue to Authenticating to the Identity Management Web UI with a Certificate as an Identity Management User.

Procedure

1. In the browser, navigate to the Identity Management web UI at, for example, https://server.idm.example.com/ipa/ui.

2. Click Login Using Certificate.

   Figure 11.8. Login Using Certificate in the Identity Management web UI

   
3. The user’s certificate should already be selected. Uncheck Remember this decision, then click OK.

Procedure

1. Obtain the IdM administrator credentials:

   ~]$ kinit admin
   Password for admin@IDM.EXAMPLE.COM:

2. Optional: To find out which IdM servers in the deployment have the CA role necessary to be eligible to become the new CA renewal server:

   ~]$ ipa server-role-find --role 'CA server'
   ----------------------
   2 server roles matched
   ----------------------
     Server name: server.idm.example.com
     Role name: CA server
     Role status: enabled
   
     Server name: replica.idm.example.com
     Role name: CA server
     Role status: enabled
   ----------------------------
   Number of entries returned 2
   ----------------------------

   There are two CA servers in the deployment.

3. Optionall: To find out which CA server is the current CA renewal server, enter:

   ~]$ ipa config-show | grep 'CA renewal'
     IPA CA renewal master: server.idm.example.com

   The current renewal server is server.idm.example.com.

4. To change the renewal server configuration, use the ipa config-mod utility with the --ca-renewal-master-server option:

   ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com | grep 'CA renewal'
     IPA CA renewal master: replica.idm.example.com

   Important

   You can also switch to a new CA renewal server using:

   • The ipa-cacert-manage --renew command. This command both renews the CA certificate and makes the CA server on which you execute the command the new CA renewal server.

   • The ipa-cert-fix command. This command recovers the deployment when expired certificates are causing failures. It also makes the CA server on which you execute the command the new CA renewal server.

     For details, see Renewing expired system certificates when IdM is offline.

Procedure

1. On the IdM CA renewal server, renew the CA certificate as self-signed:

   # ipa-cacert-manage renew --self-signed
   Renewing CA certificate, please wait
   CA certificate successfully renewed
   The ipa-cacert-manage command was successful

2. SSH to all the remaining IdM servers and clients as root. For example:

   # ssh root@idmclient01.idm.example.com

3. On the IdM client, update the local IdM certificate databases with the certificates from the server:

   [idmclient01 ~]# ipa-certupdate
   Systemwide CA database updated.
   Systemwide CA database updated.
   The ipa-certupdate command was successful

Verification

1. To check if your update has been successful and the new CA certificate has been added to the /etc/ipa/ca.crt file:

   [idmclient01 ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
   [...]
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number: 39 (0x27)
           Signature Algorithm: sha256WithRSAEncryption
           Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
           Validity
               Not Before: Jul  1 16:32:45 2019 GMT
               Not After : Jul  1 16:32:45 2039 GMT
           Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
   [...]

   The output shows that the update has been successful as the new CA certificate is listed with the older CA certificates.

1. Create a CSR to be submitted to the external CA:

   • If the external CA is an AD CS, use the --external-ca-type=ms-cs option. If you want a different template than the default subCA template, specify it using the --external-ca-profile option:

     ~]# ipa-cacert-manage renew --external-ca --external-ca-type=ms-cs [--external-ca-profile=PROFILE]
     Exporting CA certificate signing request, please wait
     The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
     ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
     The ipa-cacert-manage command was successful

   • If the external CA is not an AD CS:

     ~]# ipa-cacert-manage renew --external-ca
     Exporting CA certificate signing request, please wait
     The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
     ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
     The ipa-cacert-manage command was successful

     The output shows that a CSR has been created and is stored in the /var/lib/ipa/ca.csr file.

2. Submit the CSR located in /var/lib/ipa/ca.csr to the external CA. The process differs depending on the service to be used as the external CA.

3. Retrieve the issued certificate and the CA certificate chain for the issuing CA in a base 64-encoded blob, which is:

   • A PEM file if the external CA is not an AD CS.

   • A Base_64 certificate if the external CA is an AD CS.

     The process differs for every certificate service. Usually, a download link on a web page or in the notification email allows the administrator to download all the required certificates.

     If the external CA is an AD CS and you have submitted the CSR with a known template through the Microsoft Windows Certification Authority management window, the AD CS issues the certificate immediately and the Save Certificate dialog appears in the AD CS web interface, asking where to save the issued certificate.

4. Run the ipa-cacert-manage renew command again, adding all the CA certificate files required to supply a full certificate chain. Specify as many files as you need, using the --external-cert-file option multiple times:

   ~]# ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate_1 --external-cert-file=/path/to/external_ca_certificate_2

5. On all the IdM servers and clients, update the local IdM certificate databases with the certificates from the server:

   [client ~]$ ipa-certupdate
   Systemwide CA database updated.
   Systemwide CA database updated.
   The ipa-certupdate command was successful

Verification

1. To check if your update has been successful and the new CA certificate has been added to the /etc/ipa/ca.crt file:

   [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
   [...]
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number: 39 (0x27)
           Signature Algorithm: sha256WithRSAEncryption
           Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
           Validity
               Not Before: Jul  1 16:32:45 2019 GMT
               Not After : Jul  1 16:32:45 2039 GMT
           Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
   [...]

   The output shows that the update has been successful as the new CA certificate is listed with the older CA certificates.

Procedure

1. Optional: Backup the system. This is heavily recommended, as ipa-cert-fix makes irreversible changes to nssdbs. Because ipa-cert-fix also makes changes to the LDAP, it is recommended to backup the entire cluster as well.

2. Start the ipa-cert-fix tool to analyze the system and list expired certificates that require renewal:

   # ipa-cert-fix
   ...
   The following certificates will be renewed:
   
   Dogtag sslserver certificate:
     Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
     Serial:  13
     Expires: 2019-05-12 05:55:47
   ...
   Enter "yes" to proceed:

3. Enter yes to start the renewal process:

   Enter "yes" to proceed: true
   Proceeding.
   Renewed Dogtag sslserver certificate:
     Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
     Serial:  268369925
     Expires: 2021-08-14 02:19:33
   ...
   
   Becoming renewal master.
   The ipa-cert-fix command was successful

   It can take up to one minute before ipa-cert-fix renews all expired certificates.

Verification

1. Verify that all services are now running:

   # ipactl status
   Directory Service: RUNNING
   krb5kdc Service: RUNNING
   kadmin Service: RUNNING
   httpd Service: RUNNING
   ipa-custodia Service: RUNNING
   pki-tomcatd Service: RUNNING
   ipa-otpd Service: RUNNING
   ipa: INFO: The ipactl command was successful

Procedure

1. Restart IdM with the --force parameter:

   # ipactl restart --force

   With the --force parameter, the ipactl utility ignores individual service startup failures. For example, if the server is also a CA with expired certificates, the pki-tomcat service fails to start. This is expected and ignored because of using the --force parameter.

2. After the restart, verify that the certmonger service renewed the certificates (certificate status says MONITORING):

   # getcert list | egrep '^Request|status:|subject:'
   Request ID '20190522120745':
           status: MONITORING
           subject: CN=IPA RA,O=EXAMPLE.COM 201905222205
   Request ID '20190522120834':
           status: MONITORING
           subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205
   ...

   It can take some time before certmonger renews the shared certificates on the replica.

3. If the server is also a CA, the previous command reports CA_UNREACHABLE for the certificate the pki-tomcat service uses:

   Request ID '20190522120835':
           status: CA_UNREACHABLE
           subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
   ...

4. To renew this certificate, use the ipa-cert-fix utility:

   # ipa-cert-fix
   Dogtag sslserver certificate:
     Subject: CN=ca2.example.com,O=EXAMPLE.COM
     Serial:  3
     Expires: 2019-05-11 12:07:11
   
   Enter "yes" to proceed: true
   Proceeding.
   Renewed Dogtag sslserver certificate:
     Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
     Serial:  15
     Expires: 2019-08-14 04:25:05
   
   The ipa-cert-fix command was successful

Procedure

1. Check if your server is generating the CRL:

   [root@server ~]# ipa-crlgen-manage status
   CRL generation: enabled
   Last CRL update: 2019-10-31 12:00:00
   Last CRL Number: 6
   The ipa-crlgen-manage command was successful

2. Stop generating the CRL on the server:

   [root@server ~]# ipa-crlgen-manage disable
   Stopping pki-tomcatd
   Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
   Starting pki-tomcatd
   Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
   Restarting httpd
   CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
   The ipa-crlgen-manage command was successful

3. Check if the server stopped generating CRL:

   [root@server ~]# ipa-crlgen-manage status

Procedure

1. Start generating the CRL:

   [root@replica1 ~]# ipa-crlgen-manage enable
   Stopping pki-tomcatd
   Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
   Starting pki-tomcatd
   Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
   Restarting httpd
   Forcing CRL update
   CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
   The ipa-crlgen-manage command was successful

2. Check if the CRL is generated:

   [root@replica1 ~]# ipa-crlgen-manage status
   CRL generation: enabled
   Last CRL update: 2019-10-31 12:10:00
   Last CRL Number: 7
   The ipa-crlgen-manage command was successful

Procedure

1. Stop the CRL generation server:

   # systemctl stop pki-tomcatd@pki-tomcat.service

2. Open the /var/lib/pki/pki-tomcat/conf/ca/CS.cfg file, and change the ca.crl.MasterCRL.autoUpdateInterval value to the new interval setting. For example, to generate the CRL every 60 minutes:

   ca.crl.MasterCRL.autoUpdateInterval=60

   Note

   If you update the ca.crl.MasterCRL.autoUpdateInterval parameter, the change will become effective after the next already scheduled CRL update.

3. Start the CRL generation server:

   # systemctl start pki-tomcatd@pki-tomcat.service

Procedure

1. On the my_company.idm.example.com IdM client on which the HTTP service is running, request a certificate for the service corresponding to the HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM principal, and specify that

   • The certificate is to be stored in the local /etc/pki/tls/certs/httpd.pem file
   • The private key is to be stored in the local /etc/pki/tls/private/httpd.key file

   • That an extensionRequest for a SubjectAltName be added to the signing request with the DNS name of my_company.idm.example.com:

     # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -C "systemctl restart httpd"
     New signing request "20190604065735" added.

     In the command above:

     • The ipa-getcert request command specifies that the certificate is to be obtained from the IdM CA. The ipa-getcert request command is a shortcut for getcert request -c IPA.
     • The -g option specifies the size of key to be generated if one is not already in place.
     • The -D option specifies the SubjectAltName DNS value to be added to the request.
     • The -C option instructs certmonger to restart the httpd service after obtaining the certificate.
     • To specify that the certificate be issued with a particular profile, use the -T option.
     • To request a certificate using the named issuer from the specified CA, use the -X ISSUER option.

2. Optional: To check the status of your request:

   # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
   Number of certificates and requests being tracked: 3.
   Request ID '20190604065735':
       status: MONITORING
       stuck: no
       key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
       certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
       CA: IPA
   [...]

   The output shows that the request is in the MONITORING status, which means that a certificate has been obtained. The locations of the key pair and the certificate are those requested.

1. On the IdM server, you create a certificate for a system that does not exist yet.
2. You create the new system.
3. You enroll the new system as an IdM client.
4. You import the certificate and the key from the IdM server on to the IdM client.
5. You start tracking the certificate using certmonger to ensure that it gets renewed when it is due to expire.

Procedure

1. Get the PIN for the subsystem CA certificates:

   # grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf

2. Add tracking to the subsystem CA certificates, replacing [internal PIN] in the commands below with the PIN obtained in the previous step:

   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"' -T caCACert
   
   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"' -T caSignedLogCert
   
   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"' -T caOCSPCert
   
   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"' -T caSubsystemCert
   
   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -T caServerCert

3. Add tracking for the remaining IdM certificates, the HTTP, LDAP, IPA renewal agent and PKINIT certificates:

   # getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/idm.example.com-443-RSA -c IPA -C /usr/libexec/ipa/certmonger/restart_httpd -T caIPAserviceCert
   
   # getcert start-tracking -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM -n "Server-Cert" -c IPA -p /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt -C '/usr/libexec/ipa/certmonger/restart_dirsrv "IDM-EXAMPLE-COM"' -T caIPAserviceCert
   
   # getcert start-tracking -f /var/lib/ipa/ra-agent.pem -k /var/lib/ipa/ra-agent.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_ra_cert -T caSubsystemCert
   
   # getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -k /var/kerberos/krb5kdc/kdc.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_kdc_cert -T KDCs_PKINIT_Certs

4. Restart certmonger:

   # systemctl restart certmonger

5. Wait for one minute after certmonger has started and then check the statuses of the new certificates:

   # getcert list

Procedure

1. Enable ACME across the whole IdM deployment:

   # ipa-acme-manage enable
   The ipa-acme-manage command was successful

2. Set ACME to automatically remove expired certificates from the CA:

   # ipa-acme-manage pruning --enable --cron "0 0 1 * *"

   Note

   Expired certificates are removed after their retention period. By default, this is 30 days after expiry.

Procedure

1. Disable ACME across the whole IdM deployment:

   # ipa-acme-manage disable
   The ipa-acme-manage command was successful

2. Optional: Disable automatic removal of expired certificates:

   ipa-acme-manage pruning --disable

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create certificates
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a self-signed certificate
         ansible.builtin.include_role:
           name: rhel-system-roles.certificate
         vars:
           certificate_requests:
             - name: web-server
               ca: ipa
               dns: www.example.com
               principal: HTTP/www.example.com@EXAMPLE.COM
               run_before: systemctl stop httpd.service
               run_after: systemctl start httpd.service

   The settings specified in the example playbook include the following:

   name: <path_or_file_name>

   Defines the name or path of the generated private key and certificate file:

   • If you set the variable to web-server, the role stores the private key in the /etc/pki/tls/private/web-server.key and the certificate in the /etc/pki/tls/certs/web-server.crt files.

   • If you set the variable to a path, such as /tmp/web-server, the role stores the private key in the /tmp/web-server.key and the certificate in the /tmp/web-server.crt files.

     Note that the directory you use must have the cert_t SELinux context set. You can use the selinux RHEL system role to manage SELinux contexts.

   ca: ipa

   Defines that the role requests the certificate from an IdM CA.

   dns: <hostname_or_list_of_hostnames>

   Sets the hostnames that the Subject Alternative Names (SAN) field in the issued certificate contains. You can use a wildcard (*) or specify multiple names in YAML list format.

   principal: <kerberos_principal>

   Optional: Sets the Kerberos principal that should be included in the certificate.

   run_before: <command>

   Optional: Defines a command that certmonger should execute before requesting the certificate from the CA.

   run_after: <command>

   Optional: Defines a command that certmonger should execute after it received the issued certificate from the CA.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.certificate/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create certificates
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a self-signed certificate
         ansible.builtin.include_role:
           name: rhel-system-roles.certificate
         vars:
           certificate_requests:
             - name: web-server
               ca: self-sign
               dns: test.example.com

   The settings specified in the example playbook include the following:

   name: <path_or_file_name>

   Defines the name or path of the generated private key and certificate file:

   • If you set the variable to web-server, the role stores the private key in the /etc/pki/tls/private/web-server.key and the certificate in the /etc/pki/tls/certs/web-server.crt files.

   • If you set the variable to a path, such as /tmp/web-server, the role stores the private key in the /tmp/web-server.key and the certificate in the /tmp/web-server.crt files.

     Note that the directory you use must have the cert_t SELinux context set. You can use the selinux RHEL system role to manage SELinux contexts.

   ca: self-sign

   Defines that the role created a self-signed certificate.

   dns: <hostname_or_list_of_hostnames>

   Sets the hostnames that the Subject Alternative Names (SAN) field in the issued certificate contains. You can use a wildcard (*) or specify multiple names in YAML list format.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.certificate/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. In the Authentication menu, click Certificates > Certificates.

   Figure 22.2. sub-CA certificate in the list of certificates

   
2. Click the serial number of the sub-CA certificate to open the certificate information page.
3. In the certificate information page, click Actions > Download.

4. In the CLI, move the sub-CA certificate to the /etc/pki/tls/private/ directory:

   # mv path/to/the/downloaded/certificate /etc/pki/tls/private/sub-ca.crt

Procedure

1. On the my_company.idm.example.com IdM client on which the HTTP service is running, request a certificate for the service corresponding to the HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM principal, and specify that

   • The certificate is to be stored in the local /etc/pki/tls/certs/httpd.pem file
   • The private key is to be stored in the local /etc/pki/tls/private/httpd.key file
   • The webserver-ca sub-CA is to be the issuing certificate authority

   • That an extensionRequest for a SubjectAltName be added to the signing request with the DNS name of my_company.idm.example.com:

     # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -X webserver-ca -C "systemctl restart httpd"
     New signing request "20190604065735" added.

     In the command above:

     • The ipa-getcert request command specifies that the certificate is to be obtained from the IdM CA. The ipa-getcert request command is a shortcut for getcert request -c IPA.
     • The -g option specifies the size of key to be generated if one is not already in place.
     • The -D option specifies the SubjectAltName DNS value to be added to the request.
     • The -X option specifies that the issuer of the certificate must be webserver-ca, not ipa.
     • The -C option instructs certmonger to restart the httpd service after obtaining the certificate.
     • To specify that the certificate be issued with a particular profile, use the -T option.

2. Optional: To check the status of your request:

   # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
   Number of certificates and requests being tracked: 3.
   Request ID '20190604065735':
       status: MONITORING
       stuck: no
       key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
       certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
       CA: IPA
       issuer: CN=WEBSERVER,O=IDM.EXAMPLE.COM
   
   [...]

   The output shows that the request is in the MONITORING status, which means that a certificate has been obtained. The locations of the key pair and the certificate are those requested.

Procedure

1. Install the httpd package:

   # dnf install httpd

2. If you use firewalld, open the TCP port 80 in the local firewall:

   # firewall-cmd --permanent --add-port=80/tcp
   # firewall-cmd --reload

3. Enable and start the httpd service:

   # systemctl enable --now httpd

4. Optional: Add HTML files to the /var/www/html/ directory.

   Note

   When adding content to /var/www/html/, files and directories must be readable by the user under which httpd runs by default. The content owner can be the either the root user and root user group, or another user or group of the administrator’s choice. If the content owner is the root user and root user group, the files must be readable by other users. The SELinux context for all the files and directories must be httpd_sys_content_t, which is applied by default to all content within the /var/www directory.

Procedure

1. Install the mod_ssl package:

   # dnf install mod_ssl

2. Edit the /etc/httpd/conf.d/ssl.conf file and add the following settings to the <VirtualHost _default_:443> directive:

   1. Set the server name:

      ServerName my_company.idm.example.com

   Important

   The server name must match the entry set in the Common Name field of the certificate.

   1. Optional: If the certificate contains additional host names in the Subject Alt Names (SAN) field, you can configure mod_ssl to provide TLS encryption also for these host names. To configure this, add the ServerAliases parameter with corresponding names:

      ServerAlias www.my_company.idm.example.com server.my_company.idm.example.com

   2. Set the paths to the private key, the server certificate, and the CA certificate:

      SSLCertificateKeyFile "/etc/pki/tls/private/httpd.key"
      SSLCertificateFile "/etc/pki/tls/certs/httpd.pem"
      SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"

3. For security reasons, configure that only the root user can access the private key file:

   # chown root:root /etc/pki/tls/private/httpd.key
   # chmod 600 //etc/pki/tls/private/httpd.key

   Warning

   If the private key was accessed by unauthorized users, revoke the certificate, create a new private key, and request a new certificate. Otherwise, the TLS connection is no longer secure.

4. If you use firewalld, open port 443 in the local firewall:

   # firewall-cmd --permanent --add-port=443/tcp
   # firewall-cmd --reload

5. Restart the httpd service:

   # systemctl restart httpd

   Note

   If you protected the private key file with a password, you must enter this password each time when the httpd service starts.

   • Use a browser and connect to https://my_company.idm.example.com.

Procedure

1. Edit the /etc/httpd/conf/httpd.conf file, and add the following setting to the <VirtualHost> directive for which you want to set the TLS protocol version. For example, to enable only the TLSv1.3 protocol:

   SSLProtocol -All TLSv1.3

2. Restart the httpd service:

   # systemctl restart httpd

Verification

1. Use the following command to verify that the server supports TLSv1.3:

   # openssl s_client -connect example.com:443 -tls1_3

2. Use the following command to verify that the server does not support TLSv1.2:

   # openssl s_client -connect example.com:443 -tls1_2

   If the server does not support the protocol, the command returns an error:

   140111600609088:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70

3. Optional: Repeat the command for other TLS protocol versions.

Procedure

1. Edit the /etc/httpd/conf/httpd.conf file, and add the SSLCipherSuite parameter to the <VirtualHost> directive for which you want to set the TLS ciphers:

   SSLCipherSuite "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!SHA1:!SHA256"

   This example enables only the EECDH+AESGCM, EDH+AESGCM, AES256+EECDH, and AES256+EDH ciphers and disables all ciphers which use the SHA1 and SHA256 message authentication code (MAC).

2. Restart the httpd service:

   # systemctl restart httpd

Verification

1. To display the list of ciphers the Apache HTTP Server supports:

   1. Install the nmap package:

      # dnf install nmap

   2. Use the nmap utility to display the supported ciphers:

      # nmap --script ssl-enum-ciphers -p 443 example.com
      ...
      PORT    STATE SERVICE
      443/tcp open  https
      | ssl-enum-ciphers:
      |   TLSv1.2:
      |     ciphers:
      |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
      |       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
      |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
      ...

Procedure

1. Edit the /etc/httpd/conf/httpd.conf file and add the following settings to the <VirtualHost> directive for which you want to configure client authentication:

   <Directory "/var/www/html/Example/">
     SSLVerifyClient require
   </Directory>

   The SSLVerifyClient require setting defines that the server must successfully validate the client certificate before the client can access the content in the /var/www/html/Example/ directory.

2. Restart the httpd service:

   # systemctl restart httpd

Verification

1. Use the curl utility to access the https://my_company.idm.example.com/Example/ URL without client authentication:

   $ curl https://my_company.idm.example.com/Example/
   curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0

   The error indicates that the my_company.idm.example.com web server requires a client certificate authentication.

2. Pass the client private key and certificate, as well as the CA certificate to curl to access the same URL with client authentication:

   $ curl --cacert ca.crt --key client.key --cert client.crt https://my_company.idm.example.com/Example/

   If the request succeeds, curl displays the index.html file stored in the /var/www/html/Example/ directory.

Procedure

1. Optional: Create a new directory, for example ~/certdb/, and make it a temporary certificate database. When asked, create an NSS Certificate DB password to encrypt the keys to the certificate to be generated in a subsequent step:

   # mkdir ~/certdb/
   # certutil -N -d ~/certdb/
   Enter a password which will be used to encrypt your keys.
   The password should be at least 8 characters long,
   and should contain at least one non-alphabetic character.
   
   Enter new password:
   Re-enter password:

2. Create the certificate signing request (CSR) and redirect the output to a file. For example, to create a CSR with the name certificate_request.csr for a 4096 bit certificate for the idm_user user in the IDM.EXAMPLE.COM realm, setting the nickname of the certificate private keys to idm_user for easy findability, and setting the subject to CN=idm_user,O=IDM.EXAMPLE.COM:

   # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr

3. When prompted, enter the same password that you entered when using certutil to create the temporary database. Then continue typing randlomly until told to stop:

   Enter Password or Pin for "NSS Certificate DB":
   
   A random seed must be generated that will be used in the
   creation of your key.  One of the easiest ways to create a
   random seed is to use the timing of keystrokes on a keyboard.
   
   To begin, type keys on the keyboard until this progress meter
   is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
   
   
   Continue typing until the progress meter is full:

4. Submit the certificate request file to the server. Specify the Kerberos principal to associate with the newly-issued certificate, the output file to store the certificate, and optionally the certificate profile. Specify the IdM sub-CA that you want to issue the certificate. For example, to obtain a certificate of the IECUserRoles profile, a profile with added user roles extension, for the idm_user@IDM.EXAMPLE.COM principal from webclient-ca, and save the certificate in the ~/idm_user.pem file:

   # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --ca=webclient-ca --certificate-out=~/idm_user.pem

5. Add the certificate to the NSS database. Use the -n option to set the same nickname that you used when creating the CSR previously so that the certificate matches the private key in the NSS database. The -t option sets the trust level. For details, see the certutil(1) man page. The -i option specifies the input certificate file. For example, to add to the NSS database a certificate with the idm_user nickname that is stored in the ~/idm_user.pem file in the ~/certdb/ database:

   # certutil -A -d ~/certdb/ -n idm_user -t "P,," -i ~/idm_user.pem

6. Verify that the key in the NSS database does not show (orphan) as its nickname. For example, to verify that the certificate stored in the ~/certdb/ database is not orphaned:

   # certutil -K -d ~/certdb/
   < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user

7. Use the pk12util command to export the certificate from the NSS database to the PKCS12 format. For example, to export the certificate with the idm_user nickname from the /root/certdb NSS database into the ~/idm_user.p12 file:

   # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
   Enter Password or Pin for "NSS Certificate DB":
   Enter password for PKCS12 file:
   Re-enter password:
   pk12util: PKCS12 EXPORT SUCCESSFUL

8. Transfer the certificate to the host on which you want the certificate authentication for idm_user to be enabled:

   # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/

9. On the host to which the certificate has been transferred, make the directory in which the .pkcs12 file is stored inaccessible to the 'other' group for security reasons:

   # chmod o-rwx /home/idm_user/

10. For security reasons, remove the temporary NSS database and the .pkcs12 file from the server:

    # rm ~/certdb/
    # rm ~/idm_user.p12