Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 73. Replacing the web server and LDAP server certificates if they have expired in the whole IdM deployment

Identity Management (IdM) uses the following service certificates:

  • The LDAP (or Directory) server certificate
  • The web (or httpd) server certificate
  • The PKINIT certificate

In an IdM deployment without a CA, certmonger does not by default track IdM service certificates or notify of their expiration. If the IdM system administrator does not manually set up notifications for these certificates, or configure certmonger to track them, the certificates will expire without notice.

Follow this procedure to manually replace expired certificates for the httpd and LDAP services running on the server.idm.example.com IdM server.

Note

The HTTP and LDAP service certificates have different keypairs and subject names on different IdM servers. Therefore, you must renew the certificates on each IdM server individually.

Prerequisites

Procedure

  1. If you are not using the same CA to sign the new certificates or if the already installed CA certificate is no longer valid, update the information about the external CA in your local database with a file that contains a valid CA certificate chain of the external CA. The file is accepted in PEM and DER certificate, PKCS#7 certificate chain, PKCS#8 and raw private key and PKCS#12 formats.

    1. Install the certificates available in ca_certificate_chain_file.crt as additional CA certificates into IdM:

      # ipa-cacert-manage install ca_certificate_chain_file.crt
    2. Update the local IdM certificate databases with certificates from ca_certicate_chain_file.crt:

      # ipa-certupdate
  2. Request the certificates for httpd and LDAP:

    1. Create a certificate signing request (CSR) for the Apache web server running on your IdM instances to your third party CA using the OpenSSL utility:

      $ openssl req -new -newkey rsa:2048 -nodes -keyout /var/lib/ipa/private/httpd.key -out /tmp/http.csr -addext 'subjectAltName = DNS:server.idm.example.com, otherName:1.3.6.1.4.1.311.20.2.3;UTF8:HTTP/server.idm.example.com@IDM.EXAMPLE.COM' -subj '/O=IDM.EXAMPLE.COM/CN=server.idm.example.com'

      The creation of a new private key is optional. If you still have the original private key, you can use the -in option with the openssl req command to specify the input file name to read the request from.

    2. Create a certificate signing request (CSR) for the LDAP server running on your IdM instances to your third party CA using the OpenSSL utility:

      $ openssl req -new -newkey rsa:2048 -nodes -keyout ~/ldap.key -out /tmp/ldap.csr -addext 'subjectAltName = DNS:server.idm.example.com, otherName:1.3.6.1.4.1.311.20.2.3;UTF8:ldap/server.idm.example.com@IDM.EXAMPLE.COM' -subj '/O=IDM.EXAMPLE.COM/CN=server.idm.example.com'

      The creation of a new private key is optional. If you still have the original private key, you can use the -in option with the openssl req command to specify the input file name to read the request from.

    3. Submit the CSRs, /tmp/http.csr and tmp/ldap.csr, to the external CA, and obtain a certificate for httpd and a certificate for LDAP. The process differs depending on the service to be used as the external CA.
  3. Install the certificate for httpd :

    # cp /path/to/httpd.crt /var/lib/ipa/certs/
  4. Install the LDAP certificate into an NSS database:

    1. [Optional] List the available certificates:

      # certutil -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ -L
      Certificate Nickname                                         Trust Attributes
                                                                   SSL,S/MIME,JAR/XPI
      
      Server-Cert                                                  u,u,u

      The default certificate nickname is Server-Cert, but it is possible that a different name was applied.

    2. Remove the old invalid certificate from the NSS database (NSSDB) by using the certificate nickname from the previous step:

      # certutil -D -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ -n 'Server-Cert' -f /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt
    3. Create a PKCS12 file to ease the import process into NSSDB:

      # openssl pkcs12 -export -in ldap.crt -inkey ldap.key -out ldap.p12 -name Server-Cert
    4. Install the created PKCS#12 file into the NSSDB:

      # pk12util -i ldap.p12 -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ -k /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt
    5. Check that the new certificate has been successfully imported:

      # certutil -L -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM/
  5. Restart the httpd service:

    # systemctl restart httpd.service
  6. Restart the Directory service:

    # systemctl restart dirsrv@IDM-EXAMPLE-COM.service
  7. Perform all the previous steps on all your IdM replicas. This is a prerequisite for establishing TLS connections between the replicas.
  8. Enroll the new certificates to LDAP storage:

    1. Replace the Apache web server’s old private key and certificate with the new key and the newly-signed certificate:

      # ipa-server-certinstall -w --pin=password /var/lib/ipa/private/httpd.key /var/lib/ipa/certs/httpd.crt

      In the command above:

      • The -w option specifies that you are installing a certificate into the web server.
      • The --pin option specifies the password protecting the private key.
    2. When prompted, enter the Directory Manager password.
    3. Replace the LDAP server’s old private key and certificate with the new key and the newly-signed certificate:

      # ipa-server-certinstall -d --pin=password /etc/dirsrv/slapd-IDM-EXAMPLE-COM/ldap.key /path/to/ldap.crt

      In the command above:

      • The -d option specifies that you are installing a certificate into the LDAP server.
      • The --pin option specifies the password protecting the private key.
    4. When prompted, enter the Directory Manager password.
    5. Restart the httpd service:

      # systemctl restart httpd.service
    6. Restart the Directory service:

      # systemctl restart dirsrv@IDM-EXAMPLE-COM.service
  9. Execute the commands from the previous step on all the other affected replicas.