Chapter 79. Requesting certificates from a CA and creating self-signed certificates by using RHEL system roles
Chapter 79. Requesting certificates from a CA and creating self-signed certificates by using RHEL system roles Many services, such as web servers, use TLS to encrypt connections with clients. These services require a private key and a certificate, and a trusted certificate authority (CA) which signs the certificate. By using the certificate RHEL system role, you can automate the generation of private keys on managed nodes. Additionally, the role configures the certmonger service to send the certificate signing request (CSR) to a CA, and the service automatically renews the certificate before it expires. For testing purposes, you can use the certificate role to create self-signed certificates instead of requesting a signed certificate from a CA. 79.1. Requesting a new certificate from an IdM CA by using the certificate RHEL system role If a Red Hat Enterprise Linux host is a member of a RHEL Identity Management (IdM) environment, you can request TLS certificates from the IdM certificate authority (CA) and use them in the services that run on this host. By using the certificate RHEL system role, you can automate the process of creating a private key and letting the certmonger service request a certificate from the CA. By default, certmonger will also renew the certificate before it expires. Prerequisites You have prepared the control node and the managed nodes You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The managed node is a member of an IdM domain and the domain uses the IdM-integrated CA. Procedure 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. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Verification List the certificates that the certmonger service manages: Additional resources /usr/share/ansible/roles/rhel-system-roles.certificate/README.md file /usr/share/doc/rhel-system-roles/certificate/ directory 79.2. Requesting a new self-signed certificate by using the certificate RHEL system role If you require a TLS certificate for a test environment, you can use a self-signed certificate. By using the certificate RHEL system role, you can automate the process of creating a private key and letting the certmonger service create a self-signed certificate. By default, certmonger will also renew the certificate before it expires. Prerequisites You have prepared the control node and the managed nodes You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. Procedure 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. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Verification List the certificates that the certmonger service manages: Additional resources /usr/share/ansible/roles/rhel-system-roles.certificate/README.md file /usr/share/doc/rhel-system-roles/certificate/ directory
--- - 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 ansible-playbook --syntax-check ~/playbook.yml ansible-playbook ~/playbook.yml ansible managed-node-01.example.com -m command -a 'getcert list' Number of certificates and requests being tracked: 1. Request ID '20240918142211': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/web-server.key' certificate: type=FILE,location='/etc/pki/tls/certs/web-server.crt' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=www.example.com issued: 2024-09-18 16:22:11 CEST expires: 2025-09-18 16:22:10 CEST dns: www.example.com key usage: digitalSignature,keyEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: systemctl stop httpd.service post-save command: systemctl start httpd.service track: yes auto-renew: yes --- - 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 ansible-playbook --syntax-check ~/playbook.yml ansible-playbook ~/playbook.yml ansible managed-node-01.example.com -m command -a 'getcert list' Number of certificates and requests being tracked: 1. Request ID '20240918133610': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/web-server.key' certificate: type=FILE,location='/etc/pki/tls/certs/web-server.crt' CA: local issuer: CN=c32b16d7-5b1a4c5a-a953a711-c3ca58fb,CN=Local Signing Authority subject: CN=test.example.com issued: 2024-09-18 15:36:10 CEST expires: 2025-09-18 15:36:09 CEST dns: test.example.com key usage: digitalSignature,keyEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes