Chapter 20. Restricting an application to trust only a subset of certificates

Procedure

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

   Figure 20.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.
     Note

     RHEL 8 uses a different SSL module in Apache than the one used in RHEL 7. The SSL module relies on OpenSSL rather than NSS. For this reason, in RHEL 8 you cannot use an NSS database to store the HTTPS certificate and the private key.

2. Optionally, 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:

   # yum 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:

   # yum 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 steps

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 steps

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

   1. Install the nmap package:

      # yum 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 steps

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. Optionally, 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

Procedure

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

   Figure 20.8. Privacy and Security section in Preferences

   

2. Click View Certificates.

   Figure 20.9. 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. To make sure that your IdM sub-CA is recognized by Firefox as a trusted authority, import the IdM sub-CA certificate that you saved in Downloading the sub-CA certificate from IdM WebUI as a trusted certificate authority certificate:

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

      Figure 20.10. Privacy and Security section in Preferences

      

   2. Click View Certificates.

      Figure 20.11. View Certificates in Privacy and Security

      
   3. In the Authorities tab, click Import. Locate and open the sub-CA certificate. Trust the certificate to identify websites, then click OK and OK.