Configurer un modèle de certificat Secure Socket Layer (SSL) pour serveur web

Ci-dessous, des instructions pour la configuration d'un modèle de serveur web avec les paramètres recommandés.

Cette étape nécessite des droits d'administrateur d'entreprise ou des droits délégués correspondants pour la création et la modification de modèles de certificats.

Configuration du modèle de certificat

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

La configuration du modèle de certificat s'effectue via la console de gestion des modèles de certificats (certtmpl.msc).

Le modèle de certificat standard "Web Server" est utilisé comme point de départ et une copie en est faite.

Fiche "Compatibilité

Nous avons l'intention Fournisseur de stockage clé (KSP) de l'entreprise. Pour cela, il est nécessaire de définir les paramètres de compatibilité pour l'autorité de certification et le destinataire du certificat sur "Windows Vista" ou "Windows Server 2008".

Fiche "Général

Un nom évocateur est utilisé dans la fiche "Général". La validité du certificat ne doit pas être supérieure à deux ans.

Apple impose désormaisque la durée de validité des certificats de serveur web ne dépasse pas deux ans (825 jours).

Chrome et Safari, la validité des certificats a même été réduite à un an. (398 jours), mais les autorités de certification internes sont explicitement exclues de cette restriction.

La "Renewal Period" n'a pas d'importance, car aucun renouvellement automatique n'est possible pour cette forme de présentation de certificat.

Fiche "Request Handling" (gestion des demandes)

Dans l'onglet "Request Handling", le Purpose doit être adapté à l'algorithme de clé à utiliser. Le contexte est que, selon le type de clé, différentes exigences sont posées à l'extension "Key Usage" du certificat (voir RFC 5246 et RFC 4492).

Algorithme clé	Valeur
RSA	Signature et cryptage
ECDSA	Signature
ECDH	Signature et cryptage

Fiche "Cryptographie

Dans l'onglet "Cryptography", il faut maintenant sélectionner la catégorie "Key Storage Provider" et l'algorithme de clé correspondant.

Il convient de choisir comme fournisseur le Microsoft Software Key Storage Provider, à moins que l'on n'ait l'intention de stocker les clés, par exemple, avec un Module de plate-forme de confiance (TPM) protéger.

Si un Fournisseur de services cryptographiques (CSP) doit être utilisé, le "Fournisseur de cryptographie Microsoft RSA SChannel"doit être utilisé. Celle-ci ne supporte que AT_KEYEXCHANGE, c'est pourquoi le Purpose doit être réglé sur "Signature and Encryption" dans l'onglet "Request Handling". En principe, la préférence devrait être donnée, dans la mesure du possible, à un fournisseur de stockage de clés.

Le choix du fournisseur n'a de conséquences que pour les demandes de certificat qui lisent le modèle de certificat lors de la demande (donc les demandes de certificat manuelles ou automatiques par auto-enrollment).

Fiche "Nom du sujet

Dans l'onglet "Subject Name", on veillera à ce que l'option "Supply in the request" soit sélectionnée (paramètre par défaut). Cela permet au demandeur de déterminer l'identité dans le certificat. Cela est nécessaire, car les sites web utilisent souvent un alias qui ne peut pas être représenté comme une identité Kerberos. L'identité du demandeur et celle du site web sont donc différentes.

Comme le réglage précédent comporte un risque de sécurité (le demandeur pourrait demander des certificats pour n'importe quel nom de sujet), l'option "CA certificae manager approval" doit impérativement être activée dans l'onglet "Issuance Requirements". Elle a pour effet que la demande de certificat ne soit pas directement émise, mais qu'elle atterrisse à la place dans le dossier "Pending Requests", où un gestionnaire de certificats peut les vérifier.

Si l'on décoche la case "CA certificate manager approval", un avertissement correspondant apparaît également.

Fiche "Sécurité

Dans l'onglet "Sécurité", le droit "Enroll" peut maintenant être accordé à la personne ou au groupe d'utilisateurs souhaité.

Étant donné que le modèle de certificat est configuré de manière à ce que les demandes de certificat entrantes atterrissent dans le dossier "Pending Requests" et qu'elles doivent d'abord être vérifiées et validées par un gestionnaire de certificats, l'attribution du droit "Enroll" comme dans cet exemple ne présente aucun risque de sécurité.

Autre durcissement de sécurité

Une limitation du contenu du certificat pouvant être demandé (par exemple, quels noms de domaine peuvent être demandés) et la garantie que l'algorithme de clé correct est utilisé peuvent être obtenues à l'aide du Module TameMyCerts Policy pour l'autorité de certification être garanti.

Demander un certificat de serveur web

La procédure de demande est décrite dans l'article "Demande manuelle d'un certificat de serveur web" décrit.

Liens complémentaires :

Sources externes

Enforce 398-day validity for certificates issued on-or-after 2020-09-01 (Projet Chromium)
A propos des limites à venir sur les certificats de confiance (Apple)
Exigences pour les certificats de confiance dans iOS 13 et macOS 10.15 (Apple)
Réduction de la durée de vie des certificats TLS à 398 jours (Mozilla)
Limitation des certificats TLS à 398 jours de validité après le 31 août 2020 (Mozilla)