Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 22. 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.

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

  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: redhat.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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

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

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: redhat.rhel_system_roles.certificate
      vars:
        certificate_requests:
          - name: web-server
            ca: self-sign
            dns: test.example.com
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat