linux-system-roles.certificate

Rôle du Système de Certificats

Rôle pour gérer l'émission et le renouvellement de certificats TLS/SSL

Rôle système Linux pour émettre et renouveler des certificats SSL.

Utilisation de base :

---
- hosts: serveurweb

  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        ca: auto-signé

  roles:
    - linux-system-roles.certificate

Sur un système basé sur RPM, cela placera le certificat dans /etc/pki/tls/certs/moncertificat.crt et la clé dans /etc/pki/tls/private/moncertificat.key.

Exigences

Voir ci-dessous

Exigences de collection

Le rôle nécessite des collections externes uniquement pour la gestion des nœuds rpm-ostree. Veuillez exécuter la commande suivante pour les installer si vous devez gérer des nœuds rpm-ostree :

ansible-galaxy collection install -vv -r meta/collection-requirements.yml

Variables

Paramètre	Description	Type	Requis	Valeur par défaut
certificate_wait	Si la tâche doit attendre que le certificat soit émis.	bool	non	oui
certificate_requests	Une liste de dictionnaires représentant chaque certificat à émettre. Voir certificate_requests.	liste	non	-

certificate_requests

Remarque : Les champs tels que common_name, country, state, locality, organization, organizational_unit, email, key_usage et extended_key_usage qui peuvent être inclus dans la demande de certificat sont définis par la RFC 5280.

Remarque : Sachez que la CA pourrait ne pas respecter tous les champs demandés. Par exemple, même si une demande inclut country: US, la CA pourrait émettre le certificat sans country dans son sujet.

Remarque : Les champs dns, email et ip sont utilisés pour définir les Noms Alternatifs du Sujet (SAN).

Paramètre	Description	Type	Requis	Valeur par défaut
name	Nom du certificat. Un chemin complet peut être utilisé pour choisir le répertoire où les fichiers seront enregistrés.	str	oui	-
ca	CA qui émettra le certificat. Voir CAs and Providers.	str	oui	-
dns	Domaine (ou liste de domaines) à inclure dans le certificat. Peut aussi fournir la valeur par défaut pour common_name.	str ou liste	non	-
email	Email (ou liste d'emails) à inclure dans le certificat.	str ou liste	non	-
ip	IP, ou liste d'IPs, à inclure dans le certificat. Les IP peuvent être IPv4, IPv6 ou les deux. Peut aussi fournir la valeur par défaut pour common_name.	str ou liste	non	-
auto_renew	Indique si le certificat doit être renouvelé automatiquement avant son expiration.	bool	non	oui
owner	Nom d'utilisateur (ou ID utilisateur) pour les fichiers de certificat et de clé.	str	non	Utilisateur exécutant Ansible
group	Nom de groupe (ou ID de groupe) pour les fichiers de certificat et de clé.	str	non	Groupe exécutant Ansible
mode	Les permissions du système de fichiers pour les fichiers de certificat et de clé.	raw	non	-
key_size	Générer des clés avec une taille de clé spécifique en bits.	int	non	2048 - Voir key_size
common_name	Nom commun demandé pour le sujet du certificat.	str	non	Voir common_name
country	Code pays demandé pour le sujet du certificat.	str	non	-
state	État demandé pour le sujet du certificat.	str	non	-
locality	Localité demandée pour le sujet du certificat (habituellement une ville).	str	non	-
organization	Organisation demandée pour le sujet du certificat.	str	non	-
organizational_unit	Unité organisationnelle demandée pour le sujet du certificat.	str	non	-
contact_email	Email de contact demandé pour le sujet du certificat.	str	non	-
key_usage	Utilisation des clés autorisées pour le certificat. Pour les valeurs valides voir : key_usage.	liste	non	Voir key_usage
extended_key_usage	Attributs d'utilisation des clés étendues à être présents dans la demande de certificat.	liste	non	Voir extended_key_usage
run_before	Commande à exécuter avant d'enregistrer le certificat. Voir run hooks.	str	non	-
run_after	Commande à exécuter après avoir enregistré le certificat. Voir run hooks.	str	non	-
principal	Principal Kerberos.	str	non	-
provider	La méthode sous-jacente utilisée pour demander et gérer le certificat.	str	non	Varie selon la CA

common_name

Si common_name n'est pas défini, le rôle tentera d'utiliser la première valeur de dns ou ip, respectivement, comme valeur par défaut. Si dns et ip ne sont également pas définis, common_name ne sera pas inclus dans le certificat.

key_size

Les valeurs minimales recommandées pour la taille des clés de certificat varient selon les différentes organisations à travers le temps. Dans un souci de sécurité, la valeur minimale par défaut pour key_size sera augmentée avec le temps.

Si vous souhaitez que vos certificats conservent toujours la même key_size lorsqu'ils sont renouvelés, définissez cette variable sur la valeur souhaitée.

key_usage

Les valeurs valides pour key_usage sont :

digitalSignature
nonRepudiation
keyEncipherment
dataEncipherment
keyAgreement
keyCertSign
cRLSign
encipherOnly
decipherOnly

Les valeurs par défaut pour key_usage sont :

digitalSignature
keyEncipherment

extended_key_usage

Tout oid valide peut être utilisé pour définir un ou plusieurs extended_key_usage. De plus, il existe également une liste d'alias connus qui seront reconnus par le rôle :

id-kp-serverAuth
id-kp-clientAuth
id-kp-codeSigning
id-kp-emailProtection
id-kp-timeStamping
id-kp-OCSPSigning
id-kp-ipsecEndSystem
id-kp-ipsecTunnel
id-kp-ipsecUser

Si extended_key_usage n'est pas défini, le rôle par défaut à :

id-kp-serverAuth
id-kp-clientAuth

run hooks

Parfois, vous devez exécuter une commande juste avant qu'un certificat ne soit renouvellé et une autre juste après. Pour ce faire, utilisez run_before et run_after.

La valeur fournie à run_before et run_after sera encapsulée et stockée dans des fichiers de script shell qui seront ensuite exécutés par le fournisseur.

CAs et Fournisseurs

CA	Fournisseurs	Description de la CA	Exigences
auto-signé	certmonger*	Émet des certificats auto-signés à partir d'une CA locale.
ipa	certmonger*	Émet des certificats en utilisant la CA FreeIPA.	L'hôte doit être inscrit sur un serveur FreeIPA.

* Fournisseur par défaut.

CA représente les certificats CA qui seront utilisés pour émettre et signer le certificat demandé. Le fournisseur représente la méthode utilisée pour envoyer la demande de certificat à la CA et ensuite récupérer le certificat signé.

Si un utilisateur choisit la CA auto-signé, avec certmonger comme fournisseur, et décide ensuite de changer le fournisseur en openssl, les certificats CA utilisés dans les deux cas doivent être les mêmes. Veuillez noter que openssl n'est pas encore un fournisseur supporté et n'est mentionné ici qu'à titre d'exemple.

Certmonger et SELinux

Si SELinux est appliqué, le service certmonger ne peut écrire ou modifier des fichiers que dans les répertoires où le contexte cert_t est présent.

De plus, si les scripts exécutés par les paramètres run_before et run_after ont besoin d'écrire ou de modifier des fichiers, ces scripts doivent également avoir le contexte cert_t présent avant l'exécution du rôle.

Vous pouvez utiliser le rôle système selinux pour gérer les contextes SELinux.

Pour plus d'informations sur les exigences de certmonger et SELinux, voir certmonger_selinux(8) man pages.

Exemples

Émettre un certificat auto-signé

Émettre un certificat pour *.exemple.com et le placer dans le répertoire standard de la distribution.

---
- hosts: serveurweb

  vars:
    certificate_requests:
      - name: moncertificat
        dns: *.exemple.com
        ca: auto-signé

  roles:
    - linux-system-roles.certificate

Vous pouvez trouver les répertoires pour chaque distribution aux emplacements suivants :

Debian/Ubuntu :
- Certificats : /etc/ssl/localcerts/certs/
- Clés : /etc/ssl/localcerts/private/
RHEL/CentOS/Fedora :
- Certificats : /etc/pki/tls/certs/
- Clés : /etc/pki/tls/private/

Choisir où placer les certificats

Émettre un certificat et une clé et les placer à l'emplacement spécifié. L'exemple ci-dessous crée un fichier de certificat dans /autre/chemin/moncertificat.crt et un fichier de clé dans /autre/chemin/moncertificat.key.

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: /autre/chemin/moncertificat
        dns: *.exemple.com
        ca: auto-signé

  roles:
    - linux-system-roles.certificate

Émettre des certificats avec plusieurs DNS, IP et Email

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns:
          - www.exemple.com
          - sous1.exemple.com
          - sous2.exemple.com
          - sous3.exemple.com
        ip:
          - 192.0.2.12
          - 198.51.100.65
          - 2001:db8::2:1
        email:
          - [email protected]
          - [email protected]
        ca: auto-signé

  roles:
    - linux-system-roles.certificate

Définir des options de sujet communes

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        common_name: www.exemple.com
        ca: auto-signé
        country: FR
        state: Île-de-France
        locality: Paris
        organization: Red Hat
        organizational_unit: plateforme
        email: [email protected]
  roles:
    - linux-system-roles.certificate

Définir la taille de la clé du certificat

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        ca: auto-signé
        key_size: 4096
  roles:
    - linux-system-roles.certificate

Définir l'« Utilisation des clés » et l'« Utilisation des clés étendues » (EKU)

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        ca: auto-signé
        key_usage:
          - digitalSignature
          - nonRepudiation
          - keyEncipherment
        extended_key_usage:
          - id-kp-clientAuth
          - id-kp-serverAuth
  roles:
    - linux-system-roles.certificate

Ne pas attendre l'émission du certificat

L'émission du certificat peut prendre plusieurs minutes selon la CA. C'est pourquoi il est également possible de demander le certificat sans attendre effectivement son émission.

Cette configuration affecte tous les certificats : si certificate_wait est défini sur non, le rôle n'attend aucun certificat à émettre.

---
- hosts: serveurweb
  vars:
    certificate_wait: false
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        ca: auto-signé
  roles:
    - linux-system-roles.certificate

Définir un principal

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        ca: auto-signé
        principal: HTTP/[email protected]

  roles:
    - linux-system-roles.certificate

Choisir de ne pas renouveler automatiquement un certificat

Par défaut, les certificats générés par le rôle sont configurés pour un renouvellement automatique. Pour désactiver ce comportement, définissez auto_renew: non.

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        ca: auto-signé
        auto_renew: non

  roles:
    - linux-system-roles.certificate

Utiliser FreeIPA pour émettre un certificat

Si votre hôte est inscrit sur un serveur FreeIPA, vous avez également la possibilité d'utiliser sa CA pour émettre votre certificat. Pour ce faire, définissez ca: ipa.

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        principal: HTTP/[email protected]
        ca: ipa

  roles:
    - linux-system-roles.certificate

Exécuter une commande avant ou après qu'un certificat soit émis

Parfois, vous devez exécuter une commande juste avant l'émission d'un certificat et une autre juste après. Pour ce faire, utilisez run_before et run_after.

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        ca: auto-signé
        run_before: systemctl stop serveurweb.service
        run_after: systemctl start serveurweb.service

  roles:
    - linux-system-roles.certificate

Définir le propriétaire et le groupe du certificat

Si vous utilisez un certificat pour un service, par exemple httpd, vous devez définir le propriétaire et le groupe qui posséderont le certificat. Dans l'exemple suivant, le propriétaire et le groupe sont tous deux définis sur httpd.

---
- hosts: serveurweb
  vars:
    certificate_requests:
      - name: moncertificat
        dns: www.exemple.com
        ca: auto-signé
        owner: httpd
        group: httpd

  roles:
    - linux-system-roles.certificate