27.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.

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

    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

    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

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
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部