Chapter 21. 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.
21.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 theselinux
RHEL system role to manage SELinux contexts.
-
If you set the variable to
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:
$ ansible-playbook --syntax-check ~/playbook.yml
Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
$ ansible-playbook ~/playbook.yml
Verification
List the certificates that the
certmonger
service manages:# 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
Additional resources
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
file -
/usr/share/doc/rhel-system-roles/certificate/
directory
21.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 theselinux
RHEL system role to manage SELinux contexts.
-
If you set the variable to
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:
$ ansible-playbook --syntax-check ~/playbook.yml
Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
$ ansible-playbook ~/playbook.yml
Verification
List the certificates that the
certmonger
service manages:# 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
Additional resources
-
/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
file -
/usr/share/doc/rhel-system-roles/certificate/
directory