Gestion des certificats dans IdM

Procédure

1. Sous l'onglet Identity, sélectionnez le sous-onglet Users, Hosts ou Services.

2. Cliquez sur le nom de l'utilisateur, de l'hôte ou du service pour ouvrir sa page de configuration.

   Figure 2.1. Liste des hôtes

   
3. Cliquez sur Actions → Nouveau certificat.
4. Facultatif : Sélectionnez l'autorité de certification émettrice et l'ID de profil.
5. Suivez les instructions d'utilisation de l'utilitaire de ligne de commande (CLI) certutil à l'écran.
6. Cliquez sur Issue.

Procédure

1. Créez un répertoire temporaire pour la base de données des certificats :

   # mkdir ~/certdb/

2. Créez une nouvelle base de données temporaire de certificats, par exemple :

   # certutil -N -d ~/certdb/

3. Créez la CSR et redirigez la sortie vers un fichier. Par exemple, pour créer une CSR pour un certificat de 4096 bits et définir l'objet à CN=server.example.com,O=EXAMPLE.COM:

   # certutil -R -d ~/certdb/ -a -g 4096 -s \N-CN=server.example.com,O=EXAMPLE.COM\N- server.example.com > certificate_request.csr

4. Soumettre le fichier de demande de certificat à l'autorité de certification fonctionnant sur le serveur IdM. Indiquer le principal Kerberos à associer au certificat nouvellement émis :

   # ipa cert-request certificate_request.csr --principal=host/server.example.com

   La commande ipa cert-request dans IdM utilise les valeurs par défaut suivantes :

   • Le profil de certificat caIPAserviceCert

     Pour sélectionner un profil personnalisé, utilisez l'option --profile-id.

   • L'autorité de certification racine de l'IdM intégrée, ipa

     Pour sélectionner un sous-CA, utilisez l'option --ca.

Procédure

1. Créez un ou plusieurs alias pour votre principal Kerberos test/server.example.com. Par exemple, test1/server.example.com et test2/server.example.com.

2. Dans le CSR, ajoutez un subjectAltName pour dnsName (server.example.com) et otherName (test2/server.example.com). Pour ce faire, configurez le fichier openssl.conf pour qu'il contienne la ligne suivante spécifiant l'UPN otherName et subjectAltName :

   otherName=1.3.6.1.4.1.311.20.2.3;UTF8:test2/server.example.com@EXAMPLE.COM
   DNS.1 = server.example.com

3. Créez une demande de certificat à l'aide de openssl:

   openssl req -new -newkey rsa :2048 -keyout test2service.key -sha256 -nodes -out certificate_request.csr -config openssl.conf

4. Soumettre le fichier de demande de certificat à l'autorité de certification fonctionnant sur le serveur IdM. Indiquer le principal Kerberos à associer au certificat nouvellement émis :

   # ipa cert-request certificate_request.csr --principal=host/server.example.com

   La commande ipa cert-request dans IdM utilise les valeurs par défaut suivantes :

   • Le profil de certificat caIPAserviceCert

     Pour sélectionner un profil personnalisé, utilisez l'option --profile-id.

   • L'autorité de certification racine de l'IdM intégrée, ipa

     Pour sélectionner un sous-CA, utilisez l'option --ca.

Procédure

1. Ouvrez l'onglet Identity et sélectionnez le sous-onglet Users, Hosts ou Services.
2. Cliquez sur le nom de l'utilisateur, de l'hôte ou du service pour ouvrir sa page de configuration.

3. Cliquez sur Ajouter à côté de l'entrée Certificates.

   Figure 3.1. Ajouter un certificat à un compte d'utilisateur

   
4. Collez le certificat au format Base64 ou PEM dans le champ de texte, puis cliquez sur Ajouter.
5. Cliquez sur Sauvegarder pour enregistrer les modifications.

Procédure

1. Ouvrez l'onglet Identity et sélectionnez le sous-onglet Users, Hosts ou Services.
2. Cliquez sur le nom de l'utilisateur, de l'hôte ou du service pour ouvrir sa page de configuration.
3. Cliquez sur les Actions en regard du certificat à supprimer, puis sélectionnez Supprimer.
4. Cliquez sur Sauvegarder pour enregistrer les modifications.

Procédure

1. Créer un profil personnalisé en copiant un profil par défaut existant :

   $ ipa certprofile-show --out smime.cfg caIPAserviceCert
   ------------------------------------------------
   Profile configuration stored in file 'smime.cfg'
   ------------------------------------------------
     Profile ID: caIPAserviceCert
     Profile description: Standard profile for network services
     Store issued certificates: TRUE

2. Ouvrez le fichier de configuration du profil nouvellement créé dans un éditeur de texte.

   $ vi  smime.cfg

3. Remplacez Profile ID par un nom qui reflète l'utilisation du profil, par exemple smime.

   Note

   Lorsque vous importez un profil nouvellement créé, le champ profileId, s'il est présent, doit correspondre à l'identifiant spécifié dans la ligne de commande.

4. Mettez à jour la configuration de l'extension Extended Key Usage. La configuration par défaut de l'extension Extended Key Usage concerne l'authentification du serveur et du client TLS. Par exemple, pour S/MIME, l'Extended Key Usage doit être configuré pour la protection du courrier électronique :

   policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.4

5. Importer le nouveau profil :

   $ ipa certprofile-import smime --file smime.cfg \
     --desc "S/MIME certificates" --store TRUE
   
   ------------------------
   Imported profile "smime"
   ------------------------
     Profile ID: smime
     Profile description: S/MIME certificates
     Store issued certificates: TRUE

Procédure

1. Créez un nouveau groupe pour les utilisateurs du profil de certificat :

   $ ipa group-add smime_users_group
   ---------------------------------
   Added group "smime users group"
   ---------------------------------
     Group name: smime_users_group
     GID: 75400001

2. Créez un nouvel utilisateur à ajouter au groupe smime_user_group:

   $ ipa user-add smime_user
   First name: smime
   Last name: user
   ----------------------
   Added user "smime_user"
   ----------------------
     User login: smime_user
     First name: smime
     Last name: user
     Full name: smime user
     Display name: smime user
     Initials: TU
     Home directory: /home/smime_user
     GECOS: smime user
     Login shell: /bin/sh
     Principal name: smime_user@IDM.EXAMPLE.COM
     Principal alias: smime_user@IDM.EXAMPLE.COM
     Email address: smime_user@idm.example.com
     UID: 1505000004
     GID: 1505000004
     Password: False
     Member of groups: ipausers
     Kerberos keys available: False

3. Ajouter le smime_user au groupe smime_users_group:

   $ ipa group-add-member smime_users_group --users=smime_user
     Group name: smime_users_group
     GID: 1505000003
     Member users: smime_user
   -------------------------
   Number of members added 1
   -------------------------

4. Créez l'ACL CA pour permettre aux utilisateurs du groupe d'accéder au profil de certificat :

   $ ipa caacl-add smime_acl
   ------------------------
   Added CA ACL "smime_acl"
   ------------------------
     ACL name: smime_acl
     Enabled: TRUE

5. Ajoutez le groupe d'utilisateurs à la CAL :

   $ ipa caacl-add-user smime_acl --group smime_users_group
     ACL name: smime_acl
     Enabled: TRUE
     User Groups: smime_users_group
   -------------------------
   Number of members added 1
   -------------------------

6. Ajoutez le profil de certificat à la liste de contrôle de l'autorité de certification :

   $ ipa caacl-add-profile smime_acl --certprofile smime
     ACL name: smime_acl
     Enabled: TRUE
     Profiles: smime
     User Groups: smime_users_group
   -------------------------
   Number of members added 1
   -------------------------

Procédure

1. Générer une demande de certificat pour l'utilisateur. Par exemple, en utilisant OpenSSL :

   $ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=smime_user'

2. Demander un nouveau certificat pour l'utilisateur à l'autorité de certification IdM :

   $ ipa cert-request cert.csr --principal=smime_user --profile-id=smime

   L'option --ca sub-CA_name peut être ajoutée à la commande pour demander le certificat à une autorité de certification secondaire plutôt qu'à l'autorité de certification racine.

Procédure

1. Déterminez l'identifiant du profil de certificat que vous modifiez. Pour afficher tous les modèles de certificats actuellement stockés dans l'IdM :

   # ipa certprofile-find
   
   ------------------
   4 profiles matched
   ------------------
     Profile ID: caIPAserviceCert
     Profile description: Standard profile for network services
     Store issued certificates: TRUE
   
     Profile ID: IECUserRoles
     ...
   
     Profile ID: smime
     Profile description: S/MIME certificates
     Store issued certificates: TRUE
   --------------------------
   Number of entries returned
   --------------------------

2. Modifiez la description du profil de certificat. Par exemple, si vous avez créé un modèle de certificat personnalisé pour les certificats S/MIME en utilisant un modèle existant, modifiez la description en fonction de la nouvelle utilisation :

   # ipa certprofile-mod smime --desc "New certificate profile description"
   ------------------------------------
   Modified Certificate Profile "smime"
   ------------------------------------
       Profile ID: smime
       Profile description: New certificate profile description
       Store issued certificates: TRUE

3. Ouvrez votre fichier de profil de certificat client dans un éditeur de texte et modifiez-le en fonction de vos besoins :

   # vi smime.cfg

   Pour plus de détails sur les options qui peuvent être configurées dans le fichier de configuration du profil de certificat, voir Paramètres de configuration du profil de certificat.

4. Mettre à jour le fichier de configuration du profil de certificat existant :

   # ipa certprofile-mod _profile_ID_ --file=smime.cfg

Procédure

1. Dans le menu Authentication, cliquez sur Certificates > Certificates.

2. Cliquez sur le numéro de série du certificat pour ouvrir la page d'information sur le certificat.

   Figure 6.1. Liste des certificats

   
3. Dans la page d'information sur le certificat, recherchez les informations sur Expires On.

1. Obtenir les fichiers contenant les certificats de l'autorité de certification au format PEM.
2. Exécutez le script intégré ipa-advise.
3. Recharger la configuration du système.

Procédure

1. Créez un répertoire dans lequel vous effectuerez la configuration :

   [root@server]# mkdir ~/SmartCard/

2. Naviguez jusqu'au répertoire :

   [root@server]# cd ~/SmartCard/

3. Obtenez les certificats d'autorité de certification pertinents stockés dans des fichiers au format PEM. Si votre certificat d'autorité de certification est stocké dans un fichier d'un format différent, tel que DER, convertissez-le au format PEM. Le certificat de l'autorité de certification IdM est au format PEM et se trouve dans le fichier /etc/ipa/ca.crt.

   Convertit un fichier DER en fichier PEM :

   # openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM

4. Pour plus de commodité, copiez les certificats dans le répertoire dans lequel vous souhaitez effectuer la configuration :

   [root@server SmartCard]# cp /tmp/rootca.pem ~/SmartCard/
   [root@server SmartCard]# cp /tmp/subca.pem ~/SmartCard/
   [root@server SmartCard]# cp /tmp/issuingca.pem ~/SmartCard/

5. En option, si vous utilisez des certificats d'autorités de certification externes, utilisez l'utilitaire openssl x509 pour visualiser le contenu des fichiers au format PEM et vérifier que les valeurs Issuer et Subject sont correctes :

   [root@server SmartCard]# openssl x509 -noout -text -in rootca.pem | more

6. Générer un script de configuration avec l'utilitaire intégré ipa-advise, en utilisant les privilèges de l'administrateur :

   [root@server SmartCard]# kinit admin
   [root@server SmartCard]# ipa-advise config-server-for-smart-card-auth > config-server-for-smart-card-auth.sh

   Le script config-server-for-smart-card-auth.sh effectue les actions suivantes :

   • Il configure le serveur HTTP Apache de l'IdM.
   • Il active la cryptographie à clé publique pour l'authentification initiale dans Kerberos (PKINIT) sur le centre de distribution de clés (KDC).
   • Il configure l'interface Web IdM pour qu'elle accepte les demandes d'autorisation de carte à puce.

7. Exécutez le script en ajoutant les fichiers PEM contenant les certificats de l'autorité de certification racine et de l'autorité de certification secondaire en tant qu'arguments :

   [root@server SmartCard]# chmod +x config-server-for-smart-card-auth.sh
   [root@server SmartCard]# ./config-server-for-smart-card-auth.sh rootca.pem subca.pem issuingca.pem
   Ticket cache:KEYRING:persistent:0:0
   Default principal: admin@IDM.EXAMPLE.COM
   [...]
   Systemwide CA database updated.
   The ipa-certupdate command was successful

   Note

   Assurez-vous que vous ajoutez le certificat de l'autorité de certification racine en tant qu'argument avant tout certificat d'autorité de certification secondaire et que les certificats de l'autorité de certification ou de l'autorité de certification secondaire n'ont pas expiré.

8. En option, si l'autorité de certification qui a émis le certificat utilisateur ne fournit pas de répondeur OCSP (Online Certificate Status Protocol), il peut être nécessaire de désactiver la vérification OCSP pour l'authentification à l'IdM Web UI :

   1. Définissez le paramètre SSLOCSPEnable à off dans le fichier /etc/httpd/conf.d/ssl.conf:

      SSLOCSPEnable off

   2. Redémarrez le démon Apache (httpd) pour que les modifications prennent effet immédiatement :

      [root@server SmartCard]# systemctl restart httpd

   Avertissement

   Ne désactivez pas le contrôle OCSP si vous n'utilisez que des certificats d'utilisateur émis par l'autorité de certification IdM. Les répondeurs OCSP font partie de l'IdM.

   Pour savoir comment maintenir la vérification OCSP activée, tout en empêchant un certificat d'utilisateur d'être rejeté par le serveur IdM s'il ne contient pas les informations relatives à l'emplacement où l'autorité de certification qui a délivré le certificat d'utilisateur écoute les demandes de service OCSP, voir la directive SSLOCSPDefaultResponder dans les options de configuration de Apache mod_ssl.

Procédure

1. Si vos certificats d'autorité de certification sont stockés dans des fichiers d'un format différent, tel que DER, convertissez-les au format PEM:

   # openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM

   Le certificat de l'autorité de certification IdM est au format PEM et se trouve dans le fichier /etc/ipa/ca.crt.

2. En option, utilisez l'utilitaire openssl x509 pour visualiser le contenu des fichiers au format PEM et vérifier que les valeurs Issuer et Subject sont correctes :

   # openssl x509 -noout -text -in root-ca.pem | more

3. Naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

   $ cd ~/MyPlaybooks/

4. Créez un sous-répertoire dédié aux certificats d'autorité de certification :

   $ mkdir SmartCard/

5. Pour plus de commodité, copiez tous les certificats requis dans le répertoire ~/MyPlaybooks/SmartCard/:

   # cp /tmp/root-ca.pem ~/MyPlaybooks/SmartCard/
   # cp /tmp/intermediate-ca.pem ~/MyPlaybooks/SmartCard/
   # cp /etc/ipa/ca.crt ~/MyPlaybooks/SmartCard/ipa-ca.crt

6. Dans votre fichier d'inventaire Ansible, spécifiez ce qui suit :

   • Les serveurs IdM que vous souhaitez configurer pour l'authentification par carte à puce.
   • Le mot de passe de l'administrateur de l'IdM.

   • Les chemins d'accès aux certificats des autorités de certification dans l'ordre suivant :

     • Le fichier du certificat de l'autorité de certification racine
     • Les fichiers des certificats de l'autorité de certification intermédiaire
     • Le fichier du certificat de l'autorité de certification IdM

   Le fichier peut se présenter comme suit :

   [ipaserver]
   ipaserver.idm.example.com
   
   [ipareplicas]
   ipareplica1.idm.example.com
   ipareplica2.idm.example.com
   
   [ipacluster:children]
   ipaserver
   ipareplicas
   
   [ipacluster:vars]
   ipaadmin_password=SomeADMINpassword
   ipasmartcard_server_ca_certs=/home/<user_name>/MyPlaybooks/SmartCard/root-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/intermediate-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/ipa-ca.crt

7. Créez un playbook install-smartcard-server.yml avec le contenu suivant :

   ---
   - name: Playbook to set up smart card authentication for an IdM server
     hosts: ipaserver
     become: true
   
     roles:
     - role: ipasmartcard_server
       state: present

8. Enregistrer le fichier.

9. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

   $ ansible-playbook --vault-password-file=password_file -v -i inventory install-smartcard-server.yml

   Le rôle ipasmartcard_server Ansible effectue les actions suivantes :

   • Il configure le serveur HTTP Apache de l'IdM.
   • Il active la cryptographie à clé publique pour l'authentification initiale dans Kerberos (PKINIT) sur le centre de distribution de clés (KDC).
   • Il configure l'interface Web IdM pour qu'elle accepte les demandes d'autorisation de carte à puce.

10. En option, si l'autorité de certification qui a émis le certificat utilisateur ne fournit pas de répondeur OCSP (Online Certificate Status Protocol), il peut être nécessaire de désactiver la vérification OCSP pour l'authentification à l'IdM Web UI :

    1. Se connecter au serveur IdM en tant que root:

       ssh root@ipaserver.idm.example.com

    2. Définissez le paramètre SSLOCSPEnable à off dans le fichier /etc/httpd/conf.d/ssl.conf:

       SSLOCSPEnable off

    3. Redémarrez le démon Apache (httpd) pour que les modifications prennent effet immédiatement :

       # systemctl restart httpd

    Avertissement

    Ne désactivez pas le contrôle OCSP si vous n'utilisez que des certificats d'utilisateur émis par l'autorité de certification IdM. Les répondeurs OCSP font partie de l'IdM.

    Pour savoir comment maintenir la vérification OCSP activée, tout en empêchant un certificat d'utilisateur d'être rejeté par le serveur IdM s'il ne contient pas les informations relatives à l'emplacement où l'autorité de certification qui a délivré le certificat d'utilisateur écoute les demandes de service OCSP, voir la directive SSLOCSPDefaultResponder dans les options de configuration de Apache mod_ssl.

Procédure

1. Sur un serveur IdM, générez un script de configuration avec ipa-advise en utilisant les privilèges de l'administrateur :

   [root@server SmartCard]# kinit admin
   [root@server SmartCard]# ipa-advise config-client-for-smart-card-auth > config-client-for-smart-card-auth.sh

   Le script config-client-for-smart-card-auth.sh effectue les actions suivantes :

   • Il configure le démon de la carte à puce.
   • Il définit la réserve de confiance du système.
   • Il configure le System Security Services Daemon (SSSD) pour permettre aux utilisateurs de s'authentifier soit avec leur nom d'utilisateur et leur mot de passe, soit avec leur carte à puce. Pour plus de détails sur les options du profil SSSD pour l'authentification par carte à puce, voir Options d'authentification par carte à puce dans RHEL.

2. A partir du serveur IdM, copiez le script dans un répertoire de votre choix sur la machine du client IdM :

   [root@server SmartCard]# scp config-client-for-smart-card-auth.sh root@client.idm.example.com:/root/SmartCard/
   Password:
   config-client-for-smart-card-auth.sh        100%   2419       3.5MB/s   00:00

3. À partir du serveur IdM, copiez les fichiers de certificats d'autorité de certification au format PEM, pour plus de commodité, dans le même répertoire de la machine du client IdM que celui utilisé à l'étape précédente :

   [root@server SmartCard]# scp {rootca.pem,subca.pem,issuingca.pem} root@client.idm.example.com:/root/SmartCard/
   Password:
   rootca.pem                          100%   1237     9.6KB/s   00:00
   subca.pem                           100%   2514    19.6KB/s   00:00
   issuingca.pem                       100%   2514    19.6KB/s   00:00

4. Sur l'ordinateur client, exécutez le script en ajoutant les fichiers PEM contenant les certificats d'autorité de certification en tant qu'arguments :

   [root@client SmartCard]# kinit admin
   [root@client SmartCard]# chmod +x config-client-for-smart-card-auth.sh
   [root@client SmartCard]# ./config-client-for-smart-card-auth.sh rootca.pem subca.pem issuingca.pem
   Ticket cache:KEYRING:persistent:0:0
   Default principal: admin@IDM.EXAMPLE.COM
   [...]
   Systemwide CA database updated.
   The ipa-certupdate command was successful

   Note

   Assurez-vous que vous ajoutez le certificat de l'autorité de certification racine en tant qu'argument avant tout certificat d'autorité de certification secondaire et que les certificats de l'autorité de certification ou de l'autorité de certification secondaire n'ont pas expiré.

Procédure

1. Si vos certificats d'autorité de certification sont stockés dans des fichiers d'un format différent, tel que DER, convertissez-les au format PEM:

   # openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM

   Le certificat de l'autorité de certification IdM est au format PEM et se trouve dans le fichier /etc/ipa/ca.crt.

2. En option, utilisez l'utilitaire openssl x509 pour visualiser le contenu des fichiers au format PEM et vérifier que les valeurs Issuer et Subject sont correctes :

   # openssl x509 -noout -text -in root-ca.pem | more

3. Sur votre nœud de contrôle Ansible, naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

   $ cd ~/MyPlaybooks/

4. Créez un sous-répertoire dédié aux certificats d'autorité de certification :

   $ mkdir SmartCard/

5. Pour plus de commodité, copiez tous les certificats requis dans le répertoire ~/MyPlaybooks/SmartCard/, par exemple :

   # cp /tmp/root-ca.pem ~/MyPlaybooks/SmartCard/
   # cp /tmp/intermediate-ca.pem ~/MyPlaybooks/SmartCard/
   # cp /etc/ipa/ca.crt ~/MyPlaybooks/SmartCard/ipa-ca.crt

6. Dans votre fichier d'inventaire Ansible, spécifiez ce qui suit :

   • Les clients IdM que vous souhaitez configurer pour l'authentification par carte à puce.
   • Le mot de passe de l'administrateur de l'IdM.

   • Les chemins d'accès aux certificats des autorités de certification dans l'ordre suivant :

     • Le fichier du certificat de l'autorité de certification racine
     • Les fichiers des certificats de l'autorité de certification intermédiaire
     • Le fichier du certificat de l'autorité de certification IdM

   Le fichier peut se présenter comme suit :

   [ipaclients]
   ipaclient1.example.com
   ipaclient2.example.com
   
   [ipaclients:vars]
   ipaadmin_password=SomeADMINpassword
   ipasmartcard_client_ca_certs=/home/<user_name>/MyPlaybooks/SmartCard/root-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/intermediate-ca.pem,/home/<user_name>/MyPlaybooks/SmartCard/ipa-ca.crt

7. Créez un playbook install-smartcard-clients.yml avec le contenu suivant :

   ---
   - name: Playbook to set up smart card authentication for an IdM client
     hosts: ipaclients
     become: true
   
     roles:
     - role: ipasmartcard_client
       state: present

8. Enregistrer le fichier.

9. Exécutez le playbook Ansible. Spécifiez le playbook et les fichiers d'inventaire :

   $ ansible-playbook --vault-password-file=password_file -v -i inventory install-smartcard-clients.yml

   Le rôle ipasmartcard_client Ansible effectue les actions suivantes :

   • Il configure le démon de la carte à puce.
   • Il définit la réserve de confiance du système.
   • Il configure le System Security Services Daemon (SSSD) pour permettre aux utilisateurs de s'authentifier soit avec leur nom d'utilisateur et leur mot de passe, soit avec leur carte à puce. Pour plus de détails sur les options de profil SSSD pour l'authentification par carte à puce, voir Options d'authentification par carte à puce dans RHEL.

Procédure

1. Connectez-vous à l'interface Web IdM en tant qu'administrateur si vous souhaitez ajouter un certificat à un autre utilisateur. Pour ajouter un certificat à votre propre profil, vous n'avez pas besoin des informations d'identification de l'administrateur.
2. Naviguez vers Users → Active users → sc_user.
3. Recherchez l'option Certificate et cliquez sur Add.

4. Sur le site Command-Line Interface, affichez le certificat au format PEM à l'aide de l'utilitaire cat ou d'un éditeur de texte :

   [user@client SmartCard]$ cat testuser.crt

5. Copiez et collez le certificat de l'interface de gestion dans la fenêtre qui s'est ouverte dans l'interface Web.

6. Cliquez sur Add.

   Figure 7.1. Ajout d'un nouveau certificat dans l'interface Web IdM

   

Procédure

1. Connectez-vous au CLI IdM en tant qu'administrateur si vous souhaitez ajouter un certificat à un autre utilisateur :

   [user@client SmartCard]$ kinit admin

   Pour ajouter un certificat à votre propre profil, vous n'avez pas besoin des informations d'identification de l'administrateur :

   [user@client SmartCard]$ kinit sc_user

2. Créez une variable d'environnement contenant le certificat dont l'en-tête et le pied de page ont été supprimés et concaténés en une seule ligne, ce qui correspond au format attendu par la commande ipa user-add-cert:

   [user@client SmartCard]$ export CERT=`openssl x509 -outform der -in testuser.crt | base64 -w0 -`

   Notez que le certificat dans le fichier testuser.crt doit être au format PEM.

3. Ajoutez le certificat au profil de l'utilisateur sc_user à l'aide de la commande ipa user-add-cert:

   [user@client SmartCard]$ ipa user-add-cert sc_user --certificate=$CERT

Procédure

1. Installez les paquets opensc et gnutls-utils:

   # dnf -y install opensc gnutls-utils

2. Démarrez le service pcscd.

   # systemctl start pcscd

Procédure

1. Effacez votre carte à puce et authentifiez-vous avec votre code PIN :

   $ pkcs15-init --erase-card --use-default-transport-keys
   Using reader with a card: Reader name
   PIN [Security Officer PIN] required.
   Please enter PIN [Security Officer PIN]:

   La carte a été effacée.

2. Initialisez votre carte à puce, définissez votre code PIN et PUK d'utilisateur, ainsi que le code PIN et PUK de votre responsable de la sécurité :

   $ pkcs15-init --create-pkcs15 --use-default-transport-keys \
       --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123
   Using reader with a card: Reader name

   L'outil pcks15-init crée un nouvel emplacement sur la carte à puce.

3. Définir l'étiquette et l'ID d'authentification pour l'emplacement :

   $ pkcs15-init --store-pin --label testuser \
       --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478
   Using reader with a card: Reader name

   L'étiquette est définie sur une valeur lisible par l'homme, dans ce cas, testuser. L'adresse auth-id doit être composée de deux valeurs hexadécimales ; dans ce cas, elle est fixée à 01.

4. Stockez et étiquetez la clé privée dans le nouvel emplacement de la carte à puce :

   $ pkcs15-init --store-private-key testuser.key --label testuser_key \
       --auth-id 01 --id 01 --pin 963214
   Using reader with a card: Reader name

   Note

   La valeur que vous indiquez pour --id doit être la même lorsque vous stockez votre clé privée et votre certificat à l'étape suivante. Il est recommandé de spécifier votre propre valeur pour --id, sinon l'outil calculera une valeur plus complexe.

5. Stockez et étiquetez le certificat dans le nouvel emplacement de la carte à puce :

   $ pkcs15-init --store-certificate testuser.crt --label testuser_crt \
       --auth-id 01 --id 01 --format pem --pin 963214
   Using reader with a card: Reader name

6. (Facultatif) Stockez et étiquetez la clé publique dans le nouvel emplacement de la carte à puce :

   $ pkcs15-init --store-public-key testuserpublic.key
       --label testuserpublic_key --auth-id 01 --id 01 --pin 963214
   Using reader with a card: Reader name

   Note

   Si la clé publique correspond à une clé privée ou à un certificat, indiquez le même ID que celui de la clé privée ou du certificat.

7. (Facultatif) Certaines cartes à puce exigent que vous finalisiez la carte en verrouillant les paramètres :

   $ pkcs15-init -F

   À ce stade, votre carte à puce comprend le certificat, la clé privée et la clé publique dans l'emplacement nouvellement créé. Vous avez également créé votre code PIN et PUK d'utilisateur ainsi que le code PIN et PUK de l'agent de sécurité.

Procédure

1. Ouvrez l'interface Web IdM dans le navigateur.

2. Cliquez sur Log In Using Certificate.

   

3. Si la boîte de dialogue Password Required s'ouvre, ajoutez le code PIN pour déverrouiller la carte à puce et cliquez sur le bouton OK.

   La boîte de dialogue User Identification Request s'ouvre.

   Si la carte à puce contient plus d'un certificat, sélectionnez le certificat que vous souhaitez utiliser pour l'authentification dans la liste déroulante située sous Choose a certificate to present as identification.

4. Cliquez sur le bouton OK.

Procédure

1. Insérez la carte à puce dans le lecteur.
2. Saisissez le code PIN de la carte à puce.
3. Cliquez sur Sign In.

Procédure

1. Connectez-vous à partir de the IdM server et copiez le certificat racine de adcs-winserver-ca.cer sur le serveur IdM :

   root@idmserver ~]# sftp Administrator@winserver.ad.example.com
   Administrator@winserver.ad.example.com's password:
   Connected to Administrator@winserver.ad.example.com.
   sftp> cd <Path to certificates>
   sftp> ls
   adcs-winserver-ca.cer    aduser1.pfx
   sftp>
   sftp> get adcs-winserver-ca.cer
   Fetching <Path to certificates>/adcs-winserver-ca.cer to adcs-winserver-ca.cer
   <Path to certificates>/adcs-winserver-ca.cer                 100%  1254    15KB/s 00:00
   sftp quit

2. Connectez-vous à partir de the IdM client et copiez le certificat d'utilisateur de aduser1.pfx sur le client :

   [root@client1 ~]# sftp Administrator@winserver.ad.example.com
   Administrator@winserver.ad.example.com's password:
   Connected to Administrator@winserver.ad.example.com.
   sftp> cd /<Path to certificates>
   sftp> get aduser1.pfx
   Fetching <Path to certificates>/aduser1.pfx to aduser1.pfx
   <Path to certificates>/aduser1.pfx                 100%  1254    15KB/s 00:00
   sftp quit

Procédure

1. Sur le serveur IdM, utilisez le script ipa-advise pour configurer un client :

   [root@idmserver ~]# ipa-advise config-client-for-smart-card-auth > sc_client.sh

2. Sur le serveur IdM, utilisez le script ipa-advise pour configurer un serveur :

   [root@idmserver ~]# ipa-advise config-server-for-smart-card-auth > sc_server.sh

3. Sur le serveur IdM, exécuter le script :

   [root@idmserver ~]# sh -x sc_server.sh adcs-winserver-ca.cer

   • Il configure le serveur HTTP Apache de l'IdM.
   • Il active la cryptographie à clé publique pour l'authentification initiale dans Kerberos (PKINIT) sur le centre de distribution de clés (KDC).
   • Il configure l'interface Web IdM pour qu'elle accepte les demandes d'autorisation de carte à puce.

4. Copiez le script sc_client.sh sur le système client :

   [root@idmserver ~]# scp sc_client.sh root@client1.idm.example.com:/root
   Password:
   sc_client.sh                  100%  2857   1.6MB/s   00:00

5. Copiez le certificat Windows sur le système client :

   [root@idmserver ~]# scp adcs-winserver-ca.cer root@client1.idm.example.com:/root
   Password:
   adcs-winserver-ca.cer                 100%  1254   952.0KB/s   00:00

6. Sur le système client, exécutez le script client :

   [root@idmclient1 ~]# sh -x sc_client.sh adcs-winserver-ca.cer

Procédure

1. Sur le client IdM, dans le format PEM :

   [root@idmclient1 ~]# openssl pkcs12 -in aduser1.pfx -out aduser1_cert_only.pem -clcerts -nodes
   Enter Import Password:

2. Extraire la clé dans un fichier séparé :

   [root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -nocerts -out adduser1.pem > aduser1.key

3. Extraire le certificat public dans un fichier séparé :

   [root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -clcerts -nokeys -out aduser1_cert_only.pem > aduser1.crt

Procédure

1. Installez les paquets opensc et gnutls-utils:

   # dnf -y install opensc gnutls-utils

2. Démarrez le service pcscd.

   # systemctl start pcscd

Procédure

1. Effacez votre carte à puce et authentifiez-vous avec votre code PIN :

   $ pkcs15-init --erase-card --use-default-transport-keys
   Using reader with a card: Reader name
   PIN [Security Officer PIN] required.
   Please enter PIN [Security Officer PIN]:

   La carte a été effacée.

2. Initialisez votre carte à puce, définissez votre code PIN et PUK d'utilisateur, ainsi que le code PIN et PUK de votre responsable de la sécurité :

   $ pkcs15-init --create-pkcs15 --use-default-transport-keys \
       --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123
   Using reader with a card: Reader name

   L'outil pcks15-init crée un nouvel emplacement sur la carte à puce.

3. Définir l'étiquette et l'ID d'authentification pour l'emplacement :

   $ pkcs15-init --store-pin --label testuser \
       --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478
   Using reader with a card: Reader name

   L'étiquette est définie sur une valeur lisible par l'homme, dans ce cas, testuser. L'adresse auth-id doit être composée de deux valeurs hexadécimales ; dans ce cas, elle est fixée à 01.

4. Stockez et étiquetez la clé privée dans le nouvel emplacement de la carte à puce :

   $ pkcs15-init --store-private-key testuser.key --label testuser_key \
       --auth-id 01 --id 01 --pin 963214
   Using reader with a card: Reader name

   Note

   La valeur que vous indiquez pour --id doit être la même lorsque vous stockez votre clé privée et votre certificat à l'étape suivante. Il est recommandé de spécifier votre propre valeur pour --id, sinon l'outil calculera une valeur plus complexe.

5. Stockez et étiquetez le certificat dans le nouvel emplacement de la carte à puce :

   $ pkcs15-init --store-certificate testuser.crt --label testuser_crt \
       --auth-id 01 --id 01 --format pem --pin 963214
   Using reader with a card: Reader name

6. (Facultatif) Stockez et étiquetez la clé publique dans le nouvel emplacement de la carte à puce :

   $ pkcs15-init --store-public-key testuserpublic.key
       --label testuserpublic_key --auth-id 01 --id 01 --pin 963214
   Using reader with a card: Reader name

   Note

   Si la clé publique correspond à une clé privée ou à un certificat, indiquez le même ID que celui de la clé privée ou du certificat.

7. (Facultatif) Certaines cartes à puce exigent que vous finalisiez la carte en verrouillant les paramètres :

   $ pkcs15-init -F

   À ce stade, votre carte à puce comprend le certificat, la clé privée et la clé publique dans l'emplacement nouvellement créé. Vous avez également créé votre code PIN et PUK d'utilisateur ainsi que le code PIN et PUK de l'agent de sécurité.

Procédure

1. Ouvrez le fichier sssd.conf:

   [root@idmclient1 ~]# vim /etc/sssd/sssd.conf

2. Modifier la valeur de p11_child_timeout:

   [pam]
   p11_child_timeout = 60

3. Modifier la valeur de krb5_auth_timeout:

   [domain/IDM.EXAMPLE.COM]
   krb5_auth_timeout = 60

4. Sauvegarder les paramètres.

1. Sur un serveur de gestion des identités, obtenez les privilèges d'administrateur et créez un script shell pour configurer le serveur.

   1. Exécutez la commande ipa-advise config-server-for-smart-card-auth et enregistrez son résultat dans un fichier, par exemple server_certificate_script.sh:

      # kinit admin
      # ipa-advise config-server-for-smart-card-auth > server_certificate_script.sh

   2. Ajoutez des autorisations d'exécution au fichier à l'aide de l'utilitaire chmod:

      # chmod x server_certificate_script.sh

2. Sur tous les serveurs du domaine Identity Management, exécutez le script server_certificate_script.sh

   1. avec le chemin du certificat de l'autorité de certification IdM, /etc/ipa/ca.crt, comme entrée si l'autorité de certification IdM est la seule autorité de certification qui a émis les certificats des utilisateurs pour lesquels vous voulez activer l'authentification par certificat :

      # ./server_certificate_script.sh /etc/ipa/ca.crt

   2. avec en entrée les chemins d'accès aux certificats d'autorité de certification concernés si différentes autorités de certification externes ont signé les certificats des utilisateurs pour lesquels vous souhaitez activer l'authentification par certificat :

      # ./server_certificate_script.sh /tmp/ca1.pem /tmp/ca2.pem

Procédure

1. Si vous le souhaitez, créez un nouveau répertoire, par exemple ~/certdb/, et faites-en une base de données de certificats temporaire. Si on vous le demande, créez un mot de passe pour la base de données des certificats NSS afin de crypter les clés du certificat qui sera généré lors d'une étape ultérieure :

   # mkdir ~/certdb/
   # certutil -N -d ~/certdb/
   Enter a password which will be used to encrypt your keys.
   The password should be at least 8 characters long,
   and should contain at least one non-alphabetic character.
   
   Enter new password:
   Re-enter password:

2. Créez la demande de signature de certificat (CSR) et redirigez la sortie vers un fichier. Par exemple, pour créer une CSR avec le nom certificate_request.csr pour un certificat bit 4096 pour l'utilisateur idm_user dans le domaine IDM.EXAMPLE.COM, en définissant le surnom des clés privées du certificat à idm_user pour faciliter la recherche, et en définissant le sujet à CN=idm_user,O=IDM.EXAMPLE.COM:

   # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr

3. À l'invite, saisissez le même mot de passe que celui que vous avez saisi lorsque vous avez utilisé certutil pour créer la base de données temporaire. Continuez ensuite à taper randlomly jusqu'à ce qu'on vous dise d'arrêter :

   Enter Password or Pin for "NSS Certificate DB":
   
   A random seed must be generated that will be used in the
   creation of your key.  One of the easiest ways to create a
   random seed is to use the timing of keystrokes on a keyboard.
   
   To begin, type keys on the keyboard until this progress meter
   is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
   
   
   Continue typing until the progress meter is full:

4. Soumettez le fichier de demande de certificat au serveur. Indiquez le principal Kerberos à associer au certificat nouvellement émis, le fichier de sortie dans lequel stocker le certificat et, éventuellement, le profil du certificat. Par exemple, pour obtenir un certificat du profil IECUserRoles, un profil avec l'extension des rôles d'utilisateur ajoutés, pour le principal idm_user@IDM.EXAMPLE.COM, et l'enregistrer dans le fichier ~/idm_user.pem:

   # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --certificate-out=~/idm_user.pem

5. Ajoutez le certificat à la base de données NSS. Utilisez l'option -n pour définir le même surnom que celui que vous avez utilisé lors de la création de la CSR, afin que le certificat corresponde à la clé privée dans la base de données NSS. L'option -t définit le niveau de confiance. Pour plus de détails, voir la page de manuel certutil(1). L'option -i spécifie le fichier de certificat d'entrée. Par exemple, pour ajouter à la base de données NSS un certificat avec le pseudonyme idm_user qui est stocké dans le fichier ~/idm_user.pem de la base de données ~/certdb/:

   # certutil -A -d ~/certdb/ -n idm_user -t "P,," -i ~/idm_user.pem

6. Vérifiez que la clé dans la base de données NSS n'indique pas (orphan) comme surnom. Par exemple, pour vérifier que le certificat stocké dans la base de données ~/certdb/ n'est pas orphelin :

   # certutil -K -d ~/certdb/
   < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user

7. Utilisez la commande pk12util pour exporter le certificat de la base de données NSS au format PKCS12. Par exemple, pour exporter le certificat avec le pseudonyme idm_user de la base de données NSS /root/certdb vers le fichier ~/idm_user.p12:

   # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
   Enter Password or Pin for "NSS Certificate DB":
   Enter password for PKCS12 file:
   Re-enter password:
   pk12util: PKCS12 EXPORT SUCCESSFUL

8. Transférez le certificat vers l'hôte sur lequel vous souhaitez activer l'authentification par certificat pour idm_user:

   # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/

9. Sur l'hôte vers lequel le certificat a été transféré, rendez le répertoire dans lequel le fichier .pkcs12 est stocké inaccessible au groupe "other" pour des raisons de sécurité :

   # chmod o-rwx /home/idm_user/

10. Pour des raisons de sécurité, supprimez la base de données NSS temporaire et le fichier .pkcs12 du serveur :

    # rm ~/certdb/
    # rm ~/idm_user.p12

Procédure

1. Ouvrez Firefox, puis naviguez vers Preferences → Privacy & Security.

   Figure 10.1. Section Vie privée et sécurité dans les préférences

   

2. Cliquez sur Afficher les certificats.

   Figure 10.2. Voir les certificats en protection de la vie privée et en sécurité

   
3. Dans l'onglet Your Certificates, cliquez sur Importer. Localisez et ouvrez le certificat de l'utilisateur au format PKCS12, puis cliquez sur OK et OK.

4. Assurez-vous que l'autorité de certification de la gestion d'identité est reconnue par Firefox comme une autorité de confiance :

   1. Enregistrer localement le certificat de l'autorité de certification IdM :

      • Naviguez vers l'interface web IdM en écrivant le nom de votre serveur IdM dans la barre d'adresse de Firefox. Cliquez sur Advanced sur la page d'avertissement de connexion non sécurisée.

        Figure 10.3. Connexion non sécurisée

        

      • Add Exception. Cliquez sur View.

        Figure 10.4. Afficher les détails d'un certificat

        

      • Dans l'onglet Details, mettez en évidence les champs Certificate Authority.

        Figure 10.5. Exportation du certificat de l'autorité de certification

        
      • Cliquez sur Exporter. Enregistrez le certificat d'autorité de certification, par exemple dans le fichier CertificateAuthority.crt, puis cliquez sur Fermer et sur Annuler.

   2. Importer le certificat de l'autorité de certification IdM dans Firefox en tant que certificat d'autorité de certification de confiance :

      • Ouvrez Firefox, allez dans Préférences et cliquez sur Confidentialité & Sécurité.

        Figure 10.6. Section Vie privée et sécurité dans les préférences

        

      • Cliquez sur Afficher les certificats.

        Figure 10.7. Voir les certificats en protection de la vie privée et en sécurité

        
      • Dans l'onglet Authorities, cliquez sur Importer. Localisez et ouvrez le certificat CA que vous avez enregistré à l'étape précédente dans le fichier CertificateAuthority.crt. Faites confiance au certificat pour identifier les sites web, puis cliquez sur OK et OK.
5. Passez à la section Authentification à l'interface Web de gestion des identités avec un certificat en tant qu'utilisateur de gestion des identités.

Procédure

1. Dans le navigateur, accédez à l'interface utilisateur Web de gestion des identités à l'adresse suivante : https://server.idm.example.com/ipa/ui.

2. Cliquez sur Connexion à l'aide d'un certificat.

   login Utiliser un certificat dans l'interface web de gestion des identités

   
3. Le certificat de l'utilisateur doit déjà être sélectionné. Décochez la case Se souvenir de cette décision, puis cliquez sur OK.

Procédure

1. Obtenir les informations d'identification de l'administrateur IdM :

   ~]$ kinit admin
   Password for admin@IDM.EXAMPLE.COM:

2. Optionnellement, pour savoir quels serveurs IdM dans le déploiement ont le rôle d'autorité de certification nécessaire pour être éligibles à devenir le nouveau serveur de renouvellement de l'autorité de certification :

   ~]$ ipa server-role-find --role 'CA server'
   ----------------------
   2 server roles matched
   ----------------------
     Server name: server.idm.example.com
     Role name: CA server
     Role status: enabled
   
     Server name: replica.idm.example.com
     Role name: CA server
     Role status: enabled
   ----------------------------
   Number of entries returned 2
   ----------------------------

   Il y a deux serveurs d'autorité de certification dans le déploiement.

3. En option, pour savoir quel serveur CA est le serveur de renouvellement CA actuel, entrez :

   ~]$ ipa config-show | grep 'CA renewal'
     IPA CA renewal master: server.idm.example.com

   Le serveur de renouvellement actuel est server.idm.example.com.

4. Pour modifier la configuration du serveur de renouvellement, utilisez l'utilitaire ipa config-mod avec l'option --ca-renewal-master-server:

   ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com | grep 'CA renewal'
     IPA CA renewal master: replica.idm.example.com

   Important

   Vous pouvez également passer à un nouveau serveur de renouvellement de l'autorité de certification en utilisant :

   • la commande ipa-cacert-manage --renew. Cette commande renouvelle le certificat de l'autorité de certification and et fait du serveur de l'autorité de certification sur lequel vous exécutez la commande le nouveau serveur de renouvellement de l'autorité de certification.

   • la commande ipa-cert-fix. Cette commande rétablit le déploiement lorsque des certificats expirés sont à l'origine d'échecs. Elle fait également du serveur d'autorité de certification sur lequel vous exécutez la commande le nouveau serveur de renouvellement de l'autorité de certification.

     Pour plus de détails, voir Renouvellement des certificats système expirés lorsque l'IdM est hors ligne.

Procédure

1. Sur le serveur de renouvellement de l'autorité de certification IdM, renouveler le certificat de l'autorité de certification en tant que certificat auto-signé :

   # ipa-cacert-manage renew --self-signed
   Renewing CA certificate, please wait
   CA certificate successfully renewed
   The ipa-cacert-manage command was successful

2. SSH à tous les autres serveurs et clients IdM en tant que root. Par exemple :

   # ssh root@idmclient01.idm.example.com

3. Sur le client IdM, mettre à jour les bases de données locales de certificats IdM avec les certificats du serveur :

   [idmclient01 ~]# ipa-certupdate
   Systemwide CA database updated.
   Systemwide CA database updated.
   The ipa-certupdate command was successful

4. Optionnellement, pour vérifier si la mise à jour a réussi et si le nouveau certificat d'autorité de certification a été ajouté au fichier /etc/ipa/ca.crt:

   [idmclient01 ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
   [...]
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number: 39 (0x27)
           Signature Algorithm: sha256WithRSAEncryption
           Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
           Validity
               Not Before: Jul  1 16:32:45 2019 GMT
               Not After : Jul  1 16:32:45 2039 GMT
           Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
   [...]

   La sortie montre que la mise à jour a réussi puisque le nouveau certificat d'autorité de certification est listé avec les anciens certificats d'autorité de certification.

1. Créer une RSC à soumettre à l'autorité de certification externe :

   • Si l'autorité de certification externe est un CS AD, utilisez l'option --external-ca-type=ms-cs. Si vous souhaitez un modèle différent du modèle par défaut subCA, indiquez-le à l'aide de l'option --external-ca-profile:

     ~]# ipa-cacert-manage renew --external-ca --external-ca-type=ms-cs [--external-ca-profile=PROFILE]
     Exporting CA certificate signing request, please wait
     The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
     ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
     The ipa-cacert-manage command was successful

   • Si l'autorité de certification externe n'est pas une autorité de certification AD :

     ~]# ipa-cacert-manage renew --external-ca
     Exporting CA certificate signing request, please wait
     The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
     ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
     The ipa-cacert-manage command was successful

     La sortie montre qu'un CSR a été créé et qu'il est stocké dans le fichier /var/lib/ipa/ca.csr.

2. Soumettre le CSR situé dans /var/lib/ipa/ca.csr à l'autorité de certification externe. La procédure diffère selon le service utilisé comme autorité de certification externe.

3. Récupérer le certificat émis et la chaîne de certificats de l'autorité de certification émettrice dans un blob codé en base 64, qui est :

   • un fichier PEM si l'autorité de certification externe n'est pas une autorité de certification AD.

   • un certificat Base_64 si l'autorité de certification externe est un CS AD.

     La procédure diffère d'un service de certification à l'autre. En général, un lien de téléchargement sur une page web ou dans l'e-mail de notification permet à l'administrateur de télécharger tous les certificats requis.

     Si l'autorité de certification externe est un CS AD et que vous avez soumis la RSC avec un modèle connu via la fenêtre de gestion de l'autorité de certification de Microsoft Windows, le CS AD émet immédiatement le certificat et la boîte de dialogue Enregistrer le certificat apparaît dans l'interface web du CS AD, demandant où enregistrer le certificat émis.

4. Exécutez à nouveau la commande ipa-cacert-manage renew, en ajoutant tous les fichiers de certificats d'autorité de certification nécessaires pour fournir une chaîne de certificats complète. Spécifiez autant de fichiers que nécessaire, en utilisant plusieurs fois l'option --external-cert-file:

   ~]# ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate_1 --external-cert-file=/path/to/external_ca_certificate_2

5. Sur tous les serveurs et clients IdM, mettre à jour les bases de données locales de certificats IdM avec les certificats du serveur :

   [client ~]$ ipa-certupdate
   Systemwide CA database updated.
   Systemwide CA database updated.
   The ipa-certupdate command was successful

6. Optionnellement, pour vérifier si la mise à jour a réussi et si le nouveau certificat d'autorité de certification a été ajouté au fichier /etc/ipa/ca.crt:

   [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
   [...]
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number: 39 (0x27)
           Signature Algorithm: sha256WithRSAEncryption
           Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
           Validity
               Not Before: Jul  1 16:32:45 2019 GMT
               Not After : Jul  1 16:32:45 2039 GMT
           Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
   [...]

   La sortie montre que la mise à jour a réussi puisque le nouveau certificat d'autorité de certification est listé avec les anciens certificats d'autorité de certification.

Procédure

1. Lancez l'outil ipa-cert-fix pour analyser le système et dresser la liste des certificats expirés qui doivent être renouvelés :

   # ipa-cert-fix
   ...
   The following certificates will be renewed:
   
   Dogtag sslserver certificate:
     Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
     Serial:  13
     Expires: 2019-05-12 05:55:47
   ...
   Enter "yes" to proceed:

2. Saisissez yes pour lancer la procédure de renouvellement :

   Enter "yes" to proceed: yes
   Proceeding.
   Renewed Dogtag sslserver certificate:
     Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
     Serial:  268369925
     Expires: 2021-08-14 02:19:33
   ...
   
   Becoming renewal master.
   The ipa-cert-fix command was successful

   Il peut s'écouler jusqu'à une minute avant que ipa-cert-fix ne renouvelle tous les certificats expirés.

3. Si vous le souhaitez, vérifiez que tous les services sont en cours d'exécution :

   # ipactl status
   Directory Service: RUNNING
   krb5kdc Service: RUNNING
   kadmin Service: RUNNING
   httpd Service: RUNNING
   ipa-custodia Service: RUNNING
   pki-tomcatd Service: RUNNING
   ipa-otpd Service: RUNNING
   ipa: INFO: The ipactl command was successful

Procédure

1. Redémarrer IdM avec le paramètre --force:

   # ipactl restart --force

   Avec le paramètre --force, l'utilitaire ipactl ignore les échecs de démarrage des services individuels. Par exemple, si le serveur est également une autorité de certification dont les certificats ont expiré, le service pki-tomcat ne démarre pas. Ce phénomène est attendu et ignoré en raison de l'utilisation du paramètre --force.

2. Après le redémarrage, vérifiez que le service certmonger a renouvelé les certificats (l'état des certificats indique MONITORING) :

   # getcert list | egrep '^Request|status:|subject:'
   Request ID '20190522120745':
           status: MONITORING
           subject: CN=IPA RA,O=EXAMPLE.COM 201905222205
   Request ID '20190522120834':
           status: MONITORING
           subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205
   ...

   Il peut s'écouler un certain temps avant que certmonger ne renouvelle les certificats partagés sur la réplique.

3. Si le serveur est également une autorité de certification, la commande précédente indique CA_UNREACHABLE pour le certificat utilisé par le service pki-tomcat:

   Request ID '20190522120835':
           status: CA_UNREACHABLE
           subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
   ...

4. Pour renouveler ce certificat, utilisez l'utilitaire ipa-cert-fix:

   # ipa-cert-fix
   Dogtag sslserver certificate:
     Subject: CN=ca2.example.com,O=EXAMPLE.COM
     Serial:  3
     Expires: 2019-05-11 12:07:11
   
   Enter "yes" to proceed: yes
   Proceeding.
   Renewed Dogtag sslserver certificate:
     Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
     Serial:  15
     Expires: 2019-08-14 04:25:05
   
   The ipa-cert-fix command was successful

Procédure

1. Vérifiez si votre serveur génère la CRL :

   [root@server ~]# ipa-crlgen-manage status
   CRL generation: enabled
   Last CRL update: 2019-10-31 12:00:00
   Last CRL Number: 6
   The ipa-crlgen-manage command was successful

2. Arrêter la génération de la CRL sur le serveur :

   [root@server ~]# ipa-crlgen-manage disable
   Stopping pki-tomcatd
   Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
   Starting pki-tomcatd
   Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
   Restarting httpd
   CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
   The ipa-crlgen-manage command was successful

3. Vérifier si le serveur a cessé de générer des CRL :

   [root@server ~]# ipa-crlgen-manage status

Procédure

1. Commencez à générer la CRL :

   [root@replica1 ~]# ipa-crlgen-manage enable
   Stopping pki-tomcatd
   Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
   Starting pki-tomcatd
   Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
   Restarting httpd
   Forcing CRL update
   CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
   The ipa-crlgen-manage command was successful

2. Vérifier si la CRL est générée :

   [root@replica1 ~]# ipa-crlgen-manage status
   CRL generation: enabled
   Last CRL update: 2019-10-31 12:10:00
   Last CRL Number: 7
   The ipa-crlgen-manage command was successful

Procédure

1. Sur le client my_company.idm.example.com IdM sur lequel le service HTTP est exécuté, demandez un certificat pour le service correspondant au principal HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM et spécifiez que

   • Le certificat doit être stocké dans le fichier local /etc/pki/tls/certs/httpd.pem
   • La clé privée doit être stockée dans le fichier local /etc/pki/tls/private/httpd.key

   • Qu'une demande d'extension pour SubjectAltName soit ajoutée à la demande de signature avec le nom DNS de my_company.idm.example.com:

     # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -C "systemctl restart httpd"
     New signing request "20190604065735" added.

     Dans la commande ci-dessus :

     • La commande ipa-getcert request spécifie que le certificat doit être obtenu auprès de l'autorité de certification IdM. La commande ipa-getcert request est un raccourci pour getcert request -c IPA.
     • L'option -g spécifie la taille de la clé à générer s'il n'y en a pas déjà une.
     • L'option -D spécifie la valeur DNS SubjectAltName à ajouter à la demande.
     • L'option -C demande à certmonger de redémarrer le service httpd après avoir obtenu le certificat.
     • Pour spécifier que le certificat doit être émis avec un profil particulier, utilisez l'option -T.
     • Pour demander à l'autorité de certification spécifiée un certificat utilisant l'émetteur nommé, utilisez l'option -X ISSUER.

2. Optionnellement, pour vérifier le statut de votre demande :

   # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
   Number of certificates and requests being tracked: 3.
   Request ID '20190604065735':
       status: MONITORING
       stuck: no
       key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
       certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
       CA: IPA
   [...]

   La sortie montre que la demande est à l'état MONITORING, ce qui signifie qu'un certificat a été obtenu. Les emplacements de la paire de clés et du certificat sont ceux demandés.

1. Sur le serveur IdM, vous créez un certificat pour un système qui n'existe pas encore.
2. Vous créez le nouveau système.
3. Vous inscrivez le nouveau système en tant que client IdM.
4. Vous importez le certificat et la clé du serveur IdM sur le client IdM.
5. Vous commencez à suivre le certificat à l'aide de certmonger pour vous assurer qu'il est renouvelé lorsqu'il arrive à expiration.

Procédure

1. Obtenir le code PIN pour les certificats de l'autorité de certification du sous-système :

   # grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf

2. Ajouter le suivi aux certificats CA du sous-système, en remplaçant [internal PIN] dans les commandes ci-dessous par le PIN obtenu à l'étape précédente :

   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"' -T caCACert
   
   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"' -T caSignedLogCert
   
   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"' -T caOCSPCert
   
   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"' -T caSubsystemCert
   
   # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -T caServerCert

3. Ajouter le suivi des certificats IdM restants, les certificats HTTP, LDAP, IPA renewal agent et PKINIT:

   # getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/idm.example.com-443-RSA -c IPA -C /usr/libexec/ipa/certmonger/restart_httpd -T caIPAserviceCert
   
   # getcert start-tracking -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM -n "Server-Cert" -c IPA -p /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt -C '/usr/libexec/ipa/certmonger/restart_dirsrv "IDM-EXAMPLE-COM"' -T caIPAserviceCert
   
   # getcert start-tracking -f /var/lib/ipa/ra-agent.pem -k /var/lib/ipa/ra-agent.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_ra_cert -T caSubsystemCert
   
   # getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -k /var/kerberos/krb5kdc/kdc.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_kdc_cert -T KDCs_PKINIT_Certs

4. Redémarrer certmonger:

   # systemctl restart certmonger

5. Attendez une minute après le démarrage de certmonger, puis vérifiez l'état des nouveaux certificats :

   # getcert list

Procédure

1. Activer l'ACME dans l'ensemble du déploiement IdM :

   # ipa-acme-manage enable
   The ipa-acme-manage command was successful

2. Configurer ACME pour qu'il supprime automatiquement les certificats expirés de l'autorité de certification :

   # ipa-acme-manage pruning --enable --cron "0 0 1 * *"

   Note

   Les certificats expirés sont supprimés après leur période de conservation. Par défaut, cette période est de 30 jours après l'expiration.

Procédure

1. Désactiver ACME dans l'ensemble du déploiement IdM :

   # ipa-acme-manage disable
   The ipa-acme-manage command was successful

2. (Facultatif) Désactiver la suppression automatique des certificats expirés :

   ipa-acme-manage pruning --disable

Procédure

1. Optional: Créer un fichier d'inventaire, par exemple inventory.file:

   $ *touch inventory.file* (toucher le fichier d'inventaire)

2. Ouvrez votre fichier d'inventaire et définissez les hôtes sur lesquels vous souhaitez demander le certificat, par exemple :

   [webserver]
   server.idm.example.com

3. Créez un fichier playbook, par exemple request-certificate.yml:

   • Définissez hosts pour inclure les hôtes sur lesquels vous souhaitez demander le certificat, par exemple webserver.

   • Définissez la variable certificate_requests de manière à ce qu'elle contienne les éléments suivants :

     • Attribuez au paramètre name le nom souhaité pour le certificat, par exemple mycert.
     • Le paramètre dns correspond au domaine à inclure dans le certificat, par exemple *.example.com.
     • Réglez le paramètre ca sur self-sign.

   • Définir le rôle de rhel-system-roles.certificate sous roles.

     Il s'agit du fichier du playbook pour cet exemple :

     ---
     - hosts: webserver
     
       vars:
         certificate_requests:
           - name: mycert
             dns: "*.example.com"
             ca: self-sign
     
       roles:
         - rhel-system-roles.certificate

4. Enregistrer le fichier.

5. Exécutez le manuel de jeu :

   *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file

Procédure

1. Optional: Créer un fichier d'inventaire, par exemple inventory.file:

   $ *touch inventory.file* (toucher le fichier d'inventaire)

2. Ouvrez votre fichier d'inventaire et définissez les hôtes sur lesquels vous souhaitez demander le certificat, par exemple :

   [webserver]
   server.idm.example.com

3. Créez un fichier playbook, par exemple request-certificate.yml:

   • Définissez hosts pour inclure les hôtes sur lesquels vous souhaitez demander le certificat, par exemple webserver.

   • Définissez la variable certificate_requests de manière à ce qu'elle contienne les éléments suivants :

     • Attribuez au paramètre name le nom souhaité pour le certificat, par exemple mycert.
     • Le paramètre dns correspond au domaine à inclure dans le certificat, par exemple www.example.com.
     • Le paramètre principal indique le principal Kerberos, par exemple HTTP/www.example.com@EXAMPLE.COM.
     • Réglez le paramètre ca sur ipa.

   • Définir le rôle de rhel-system-roles.certificate sous roles.

     Il s'agit du fichier du playbook pour cet exemple :

     ---
     - hosts: webserver
       vars:
         certificate_requests:
           - name: mycert
             dns: www.example.com
             principal: HTTP/www.example.com@EXAMPLE.COM
             ca: ipa
     
       roles:
         - rhel-system-roles.certificate

4. Enregistrer le fichier.

5. Exécutez le manuel de jeu :

   *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file

Procédure

1. Optional: Créer un fichier d'inventaire, par exemple inventory.file:

   $ *touch inventory.file* (toucher le fichier d'inventaire)

2. Ouvrez votre fichier d'inventaire et définissez les hôtes sur lesquels vous souhaitez demander le certificat, par exemple :

   [webserver]
   server.idm.example.com

3. Créez un fichier playbook, par exemple request-certificate.yml:

   • Définissez hosts pour inclure les hôtes sur lesquels vous souhaitez demander le certificat, par exemple webserver.

   • Définissez la variable certificate_requests de manière à ce qu'elle contienne les éléments suivants :

     • Attribuez au paramètre name le nom souhaité pour le certificat, par exemple mycert.
     • Le paramètre dns correspond au domaine à inclure dans le certificat, par exemple www.example.com.
     • Définissez le paramètre ca en fonction de l'autorité de certification que vous souhaitez utiliser pour émettre le certificat, par exemple self-sign.
     • Attribuez au paramètre run_before la valeur de la commande que vous souhaitez exécuter avant l'émission ou le renouvellement de ce certificat, par exemple systemctl stop httpd.service.
     • Attribuez au paramètre run_after la commande que vous souhaitez exécuter après l'émission ou le renouvellement de ce certificat, par exemple systemctl start httpd.service.

   • Définir le rôle de rhel-system-roles.certificate sous roles.

     Il s'agit du fichier du playbook pour cet exemple :

     ---
     - hosts: webserver
       vars:
         certificate_requests:
           - name: mycert
             dns: www.example.com
             ca: self-sign
             run_before: systemctl stop httpd.service
             run_after: systemctl start httpd.service
     
       roles:
         - rhel-system-roles.certificate

4. Enregistrer le fichier.

5. Exécutez le manuel de jeu :

   *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file

Procédure

1. Dans le menu Authentication, cliquez sur Certificates > Certificates.

   Figure 20.2. certificat de sous-CA dans la liste des certificats

   
2. Cliquez sur le numéro de série du certificat sous-CA pour ouvrir la page d'information sur le certificat.
3. Dans la page d'information sur le certificat, cliquez sur Actions > Download.

4. Dans le CLI, déplacez le certificat sub-CA dans le répertoire /etc/pki/tls/private/:

   # mv path/to/the/downloaded/certificate /etc/pki/tls/private/sub-ca.crt

Procédure

1. Sur le client my_company.idm.example.com IdM sur lequel le service HTTP est exécuté, demandez un certificat pour le service correspondant au principal HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM et spécifiez que

   • Le certificat doit être stocké dans le fichier local /etc/pki/tls/certs/httpd.pem
   • La clé privée doit être stockée dans le fichier local /etc/pki/tls/private/httpd.key
   • La sous-CA webserver-ca doit être l'autorité de certification émettrice

   • Qu'une demande d'extension pour SubjectAltName soit ajoutée à la demande de signature avec le nom DNS de my_company.idm.example.com:

     # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -X webserver-ca -C "systemctl restart httpd"
     New signing request "20190604065735" added.

     Dans la commande ci-dessus :

     • La commande ipa-getcert request spécifie que le certificat doit être obtenu auprès de l'autorité de certification IdM. La commande ipa-getcert request est un raccourci pour getcert request -c IPA.
     • L'option -g spécifie la taille de la clé à générer s'il n'y en a pas déjà une.
     • L'option -D spécifie la valeur DNS SubjectAltName à ajouter à la demande.
     • L'option -X précise que l'émetteur du certificat doit être webserver-ca et non ipa.
     • L'option -C demande à certmonger de redémarrer le service httpd après avoir obtenu le certificat.
     • Pour spécifier que le certificat doit être émis avec un profil particulier, utilisez l'option -T.

2. Optionnellement, pour vérifier le statut de votre demande :

   # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
   Number of certificates and requests being tracked: 3.
   Request ID '20190604065735':
       status: MONITORING
       stuck: no
       key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
       certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
       CA: IPA
       issuer: CN=WEBSERVER,O=IDM.EXAMPLE.COM
   
   [...]

   La sortie montre que la demande est à l'état MONITORING, ce qui signifie qu'un certificat a été obtenu. Les emplacements de la paire de clés et du certificat sont ceux demandés.

Procédure

1. Installez le paquetage httpd:

   # dnf install httpd

2. Si vous utilisez firewalld, ouvrez le port TCP 80 dans le pare-feu local :

   # firewall-cmd --permanent --add-port=80/tcp
   # firewall-cmd --reload

3. Activez et démarrez le service httpd:

   # systemctl enable --now httpd

4. Facultatif : Ajoutez des fichiers HTML au répertoire /var/www/html/.

   Note

   Lors de l'ajout de contenu à /var/www/html/, les fichiers et les répertoires doivent être lisibles par l'utilisateur sous lequel httpd s'exécute par défaut. Le propriétaire du contenu peut être soit l'utilisateur root et le groupe d'utilisateurs root, soit un autre utilisateur ou groupe au choix de l'administrateur. Si le propriétaire du contenu est l'utilisateur root et le groupe d'utilisateurs root, les fichiers doivent pouvoir être lus par d'autres utilisateurs. Le contexte SELinux pour tous les fichiers et répertoires doit être httpd_sys_content_t, qui est appliqué par défaut à tout le contenu du répertoire /var/www.

Procédure

1. Installez le paquetage mod_ssl:

   # dnf install mod_ssl

2. Modifiez le fichier /etc/httpd/conf.d/ssl.conf et ajoutez les paramètres suivants à la directive <VirtualHost _default_:443>:

   1. Définir le nom du serveur :

      ServerName my_company.idm.example.com

      Important

      Le nom du serveur doit correspondre à l'entrée définie dans le champ Common Name du certificat.

   2. Facultatif : Si le certificat contient des noms d'hôtes supplémentaires dans le champ Subject Alt Names (SAN), vous pouvez configurer mod_ssl pour qu'il fournisse également un cryptage TLS pour ces noms d'hôtes. Pour ce faire, ajoutez le paramètre ServerAliases avec les noms correspondants :

      ServerAlias www.my_company.idm.example.com server.my_company.idm.example.com

   3. Définissez les chemins d'accès à la clé privée, au certificat du serveur et au certificat de l'autorité de certification :

      SSLCertificateKeyFile "/etc/pki/tls/private/httpd.key"
      SSLCertificateFile "/etc/pki/tls/certs/httpd.pem"
      SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"

3. Pour des raisons de sécurité, configurez l'accès au fichier de la clé privée uniquement pour l'utilisateur root:

   # chown root:root /etc/pki/tls/private/httpd.key
   # chmod 600 //etc/pki/tls/private/httpd.key

   Avertissement

   Si des utilisateurs non autorisés ont eu accès à la clé privée, révoquez le certificat, créez une nouvelle clé privée et demandez un nouveau certificat. Sinon, la connexion TLS n'est plus sécurisée.

4. Si vous utilisez firewalld, ouvrez le port 443 dans le pare-feu local :

   # firewall-cmd --permanent --add-port=443/tcp
   # firewall-cmd --reload

5. Redémarrez le service httpd:

   # systemctl restart httpd

   Note

   Si vous avez protégé le fichier de clé privée par un mot de passe, vous devez saisir ce mot de passe à chaque démarrage du service httpd.

   • Utilisez un navigateur et connectez-vous à https://my_company.idm.example.com.

Procédure

1. Modifiez le fichier /etc/httpd/conf/httpd.conf et ajoutez le paramètre suivant à la directive <VirtualHost> pour laquelle vous souhaitez définir la version du protocole TLS. Par exemple, pour activer uniquement le protocole TLSv1.3:

   SSLProtocol -All TLSv1.3

2. Redémarrez le service httpd:

   # systemctl restart httpd

Verification steps

1. Utilisez la commande suivante pour vérifier que le serveur prend en charge TLSv1.3:

   # openssl s_client -connect example.com:443 -tls1_3

2. Utilisez la commande suivante pour vérifier que le serveur ne prend pas en charge TLSv1.2:

   # openssl s_client -connect example.com:443 -tls1_2

   Si le serveur ne prend pas en charge le protocole, la commande renvoie une erreur :

   140111600609088:error:1409442E:Routines SSL:ssl3_read_bytes:version du protocole d'alerte tlsv1:ssl/record/rec_layer_s3.c:1543:alerte SSL numéro 70

3. Facultatif : Répétez la commande pour d'autres versions du protocole TLS.

Procédure

1. Modifiez le fichier /etc/httpd/conf/httpd.conf et ajoutez le paramètre SSLCipherSuite à la directive <VirtualHost> pour laquelle vous souhaitez définir les algorithmes TLS :

   SSLCipherSuite "EECDH AESGCM:EDH AESGCM:AES256 EECDH:AES256 EDH:!SHA1:!SHA256"

   Cet exemple n'active que les algorithmes de chiffrement EECDH AESGCM, EDH AESGCM, AES256 EECDH et AES256 EDH et désactive tous les algorithmes de chiffrement qui utilisent les codes d'authentification des messages (MAC) SHA1 et SHA256.

2. Redémarrez le service httpd:

   # systemctl restart httpd

Verification steps

1. Pour afficher la liste des algorithmes de chiffrement pris en charge par le serveur HTTP Apache :

   1. Installez le paquetage nmap:

      # dnf install nmap

   2. Utilisez l'utilitaire nmap pour afficher les algorithmes de chiffrement pris en charge :

      # nmap --script ssl-enum-ciphers -p 443 example.com
      ...
      PORT    STATE SERVICE
      443/tcp open  https
      | ssl-enum-ciphers:
      |   TLSv1.2:
      |     ciphers:
      |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
      |       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
      |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
      ...

Procédure

1. Modifiez le fichier /etc/httpd/conf/httpd.conf et ajoutez les paramètres suivants à la directive <VirtualHost> pour laquelle vous souhaitez configurer l'authentification du client :

   <Directory "/var/www/html/Example/">
     SSLVerifyClient require
   </Directory>

   Le paramètre SSLVerifyClient require définit que le serveur doit valider avec succès le certificat du client avant que ce dernier puisse accéder au contenu du répertoire /var/www/html/Example/.

2. Redémarrez le service httpd:

   # systemctl restart httpd

Verification steps

1. Utilisez l'utilitaire curl pour accéder à l'URL https://my_company.idm.example.com/Example/ sans authentification du client :

   $ curl https://my_company.idm.example.com/Example/
   curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 **alert certificate required**, errno 0

   L'erreur indique que le serveur web my_company.idm.example.com nécessite une authentification par certificat client.

2. Transmettez la clé privée et le certificat du client, ainsi que le certificat de l'autorité de certification à curl pour accéder à la même URL avec l'authentification du client :

   $ curl --cacert ca.crt --key client.key --cert client.crt https://my_company.idm.example.com/Example/

   Si la demande aboutit, curl affiche le fichier index.html stocké dans le répertoire /var/www/html/Example/.

Procédure

1. Si vous le souhaitez, créez un nouveau répertoire, par exemple ~/certdb/, et faites-en une base de données de certificats temporaire. Si on vous le demande, créez un mot de passe pour la base de données des certificats NSS afin de crypter les clés du certificat qui sera généré lors d'une étape ultérieure :

   # mkdir ~/certdb/
   # certutil -N -d ~/certdb/
   Enter a password which will be used to encrypt your keys.
   The password should be at least 8 characters long,
   and should contain at least one non-alphabetic character.
   
   Enter new password:
   Re-enter password:

2. Créez la demande de signature de certificat (CSR) et redirigez la sortie vers un fichier. Par exemple, pour créer une CSR avec le nom certificate_request.csr pour un certificat bit 4096 pour l'utilisateur idm_user dans le domaine IDM.EXAMPLE.COM, en définissant le surnom des clés privées du certificat à idm_user pour faciliter la recherche, et en définissant le sujet à CN=idm_user,O=IDM.EXAMPLE.COM:

   # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr

3. À l'invite, saisissez le même mot de passe que celui que vous avez saisi lorsque vous avez utilisé certutil pour créer la base de données temporaire. Continuez ensuite à taper randlomly jusqu'à ce qu'on vous dise d'arrêter :

   Enter Password or Pin for "NSS Certificate DB":
   
   A random seed must be generated that will be used in the
   creation of your key.  One of the easiest ways to create a
   random seed is to use the timing of keystrokes on a keyboard.
   
   To begin, type keys on the keyboard until this progress meter
   is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
   
   
   Continue typing until the progress meter is full:

4. Soumettez le fichier de demande de certificat au serveur. Indiquez le principal Kerberos à associer au certificat nouvellement émis, le fichier de sortie pour stocker le certificat et, éventuellement, le profil de certificat. Indiquez la sous-CA IdM à laquelle vous souhaitez délivrer le certificat. Par exemple, pour obtenir un certificat du profil IECUserRoles, un profil avec l'extension des rôles d'utilisateur ajoutés, pour le principal idm_user@IDM.EXAMPLE.COM à partir de webclient-ca, et enregistrer le certificat dans le fichier ~/idm_user.pem:

   # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --ca=webclient-ca --certificate-out=~/idm_user.pem

5. Ajoutez le certificat à la base de données NSS. Utilisez l'option -n pour définir le même surnom que celui que vous avez utilisé lors de la création de la CSR, afin que le certificat corresponde à la clé privée dans la base de données NSS. L'option -t définit le niveau de confiance. Pour plus de détails, voir la page de manuel certutil(1). L'option -i spécifie le fichier de certificat d'entrée. Par exemple, pour ajouter à la base de données NSS un certificat avec le pseudonyme idm_user qui est stocké dans le fichier ~/idm_user.pem de la base de données ~/certdb/:

   # certutil -A -d ~/certdb/ -n idm_user -t "P,," -i ~/idm_user.pem

6. Vérifiez que la clé dans la base de données NSS n'indique pas (orphan) comme surnom. Par exemple, pour vérifier que le certificat stocké dans la base de données ~/certdb/ n'est pas orphelin :

   # certutil -K -d ~/certdb/
   < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user

7. Utilisez la commande pk12util pour exporter le certificat de la base de données NSS au format PKCS12. Par exemple, pour exporter le certificat avec le pseudonyme idm_user de la base de données NSS /root/certdb vers le fichier ~/idm_user.p12:

   # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
   Enter Password or Pin for "NSS Certificate DB":
   Enter password for PKCS12 file:
   Re-enter password:
   pk12util: PKCS12 EXPORT SUCCESSFUL

8. Transférez le certificat vers l'hôte sur lequel vous souhaitez activer l'authentification par certificat pour idm_user:

   # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/

9. Sur l'hôte vers lequel le certificat a été transféré, rendez le répertoire dans lequel le fichier .pkcs12 est stocké inaccessible au groupe "other" pour des raisons de sécurité :

   # chmod o-rwx /home/idm_user/

10. Pour des raisons de sécurité, supprimez la base de données NSS temporaire et le fichier .pkcs12 du serveur :

    # rm ~/certdb/
    # rm ~/idm_user.p12

Procédure

1. Ouvrez Firefox, puis naviguez vers Preferences → Privacy & Security.

   Figure 20.8. Section Vie privée et sécurité dans les préférences

   

2. Cliquez sur Afficher les certificats.

   Figure 20.9. Voir les certificats en protection de la vie privée et en sécurité

   
3. Dans l'onglet Your Certificates, cliquez sur Importer. Localisez et ouvrez le certificat de l'utilisateur au format PKCS12, puis cliquez sur OK et OK.

4. Pour vous assurer que votre sous-CA IdM est reconnu par Firefox comme une autorité de confiance, importez le certificat du sous-CA IdM que vous avez sauvegardé dans Télécharger le certificat du sous-CA à partir de l'interface Web de l'IdM comme un certificat d'autorité de confiance :

   1. Ouvrez Firefox, allez dans Préférences et cliquez sur Confidentialité & Sécurité.

      Figure 20.10. Section Vie privée et sécurité dans les préférences

      

   2. Cliquez sur Afficher les certificats.

      Figure 20.11. Voir les certificats en protection de la vie privée et en sécurité

      
   3. Dans l'onglet Authorities, cliquez sur Importer. Localisez et ouvrez le certificat sub-CA. Faites confiance au certificat pour identifier les sites web, puis cliquez sur OK et OK.

Procédure

1. En option, pour afficher toutes les ACL de votre environnement IdM, entrez la commande ipa caacl-find:

   $ ipa caacl-find
   -----------------
   3 CA ACLs matched
   -----------------
     ACL name: hosts_services_caIPAserviceCert
     Enabled: TRUE
   
     ACL name: TLS_web_server_authentication
     Enabled: TRUE
   
     ACL name: TLS_web_client_authentication
     Enabled: TRUE

2. En option, pour afficher les détails d'une CA ACL, entrez la commande ipa caacl-show et indiquez le nom de la CA ACL :

   $ ipa caacl-show TLS_web_server_authentication
     ACL name: TLS_web_server_authentication
     Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
     Enabled: TRUE
     CAs: webserver-ca
     Profiles: caIPAserviceCert
     Services: HTTP/rhel8server.idm.example.com@IDM.EXAMPLE.COM

3. Pour désactiver une CA ACL, entrez la commande ipa caacl-disable et indiquez le nom de la CA ACL.

   • Pour désactiver l'ACL TLS_web_server_authentication CA, entrez :

     $ ipa caacl-disable TLS_web_server_authentication
     -------------------------------------------------
     Disabled CA ACL "TLS_web_server_authentication"
     -------------------------------------------------

   • Pour désactiver l'ACL TLS_web_client_authentication CA, entrez :

     $ ipa caacl-disable TLS_web_client_authentication
     -------------------------------------------------
     Disabled CA ACL "TLS_web_client_authentication"
     -------------------------------------------------

   La seule CA ACL activée actuellement est la CA ACL hosts_services_caIPAserviceCert.

   Important

   Soyez extrêmement prudent lorsque vous désactivez l'ACL hosts_services_caIPAserviceCert. La désactivation de hosts_services_caIPAserviceCert, sans une autre ACL CA accordant aux serveurs IdM l'utilisation de l'AC ipa avec le profil caIPAserviceCert signifie que le renouvellement des certificats IdM HTTP et LDAP échouera. Les certificats expirés des serveurs IdM HTTP et LDAP finiront par provoquer une défaillance du système IdM.