Installation de l’autorité secondaire n°2 pour les certificats des machines

I. Présentation

Ce chapitre évoque l'installation et la configuration de la seconde autorité intermédiaire, destinée à délivrer les certificats aux machines, autant les serveurs que les postes de travail.

La seconde autorité intermédiaire est nommée S-SUBCA2. Le serveur est intégré au domaine Active Directory. Particularité toutefois, il s'agit d'un Windows Server en mode Core, sans interface graphique donc !

Le mode Core de Windows est intéressant pour plusieurs raisons :

• Il réduit la surface d’attaque,
• Il consomme moins de ressources,
• Les correctifs sont moins nombreux

L’objectif est ici de vous montrer les étapes d'installation et de configuration en ligne de commandes à l'aide de PowerShell et d'autres outils. Pour des clients particulièrement sensibles à la sécurité, il m’est arrivé de déployer toutes les autorités basées sur un Windows Server en mode Core. L’exploitation est néanmoins plus complexe.

Remarque : vous remarquerez qu’il y a des similitudes entre la configuration de cette seconde autorité secondaire et celle déjà configurée précédemment.

II. Déploiement

A. Installation du rôle AD CS avec PowerShell

La première étape consiste à ajouter le rôle d’autorité de certification sur la machine

Add-WindowsFeature Adcs-Cert-Authority

B. Stratégie AD CS

Pour rappel, un fichier nommé « CAPolicy.inf » peut être créé, via bloc-notes, sous « C:\Windows » afin de fixer certains paramètres avant même le premier démarrage du service comme :

• Empêcher la publication des modèles de certificats par défaut,
• Définir la longueur de clé privée de l'autorité lors de son renouvellement,
• Fixer la durée de validité de la CRL.

Nous allons créer ce fichier à partir de la ligne de commande :

notepad C:\Windows\CAPolicy.inf

Pour une autorité intermédiaire, j'ai l'habitude d'utiliser le fichier suivant :

[Version]
Signature="$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=3072
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0
CRLPeriod=weeks
CRLPeriodUnits=2

C. Configuration initiale

Créons tout d'abord un dossier pour accueillir les fichiers de certificats :

mkdir C:\certificats

Ensuite, nous pouvons exécuter la commande PowerShell qui procèdera à la configuration initiale de l'autorité :

$params = @{
  CAType = "EnterpriseSubordinateCA"
  CryptoProviderName = "RSA#Microsoft Software Key Storage Provider"
  KeyLength = "2048"
  HashAlgorithmName = "SHA256"
  ValidityPeriod = "Years"
  ValidityPeriodUnits = "5"
  DatabaseDirectory = "C:\Windows\system32\Certlog"
  LogDirectory = "C:\Windows\system32\Certlog"
  OutputCertRequestFile = "C:\Certificats\s-subca2.csr"
  CACommonName = "ContosoSubCA2"
  CADistinguishedNameSuffix = "CN=ContosoSubCA2,O=Contoso,OU=IT,L=Ivry-sur-Seine,S=Val-de-Marne,C=FR"
}

Install-AdcsCertificationAuthority @params

Quelques secondes plus tard, vous obtiendrez un message de réussite avec des avertissements. En effet, pour finaliser la configuration, il faut soumettre la demande de certificat auprès de l'autorité racine, puis récupérer la réponse et installer le certificat obtenu sur l'autorité secondaire.

D. Finalisation

Une fois le fichier de demande copié sur l'autorité racine, il est possible de demander le certificat. Depuis la console de gestion de l'autorité, opérez un clic-droit sur le nom de l'autorité, et à la rubrique "Toutes les tâches" vous trouverez l'option "Soumettre une nouvelle demande…"

Vous pourrez alors sélectionner le fichier de demande.

Aucun message ne s'affiche. Rendez-vous à la rubrique "Demandes en attente", où vous verrez apparaître la demande envoyée. En faisant un clic-droit dessus, vous pourrez accéder à "Toutes les tâches" -> "Délivrer".

Cette fois, c'est depuis la rubrique « Certificats délivrés » que l'on retrouvera notre tout nouveau certificat et il nous faut l'exporter afin de l'installer sur l'autorité secondaire. Opérez un double-clic sur l'entrée du certificat dans la liste de la vue "Certificats délivrés", puis dans l'onglet "Détails", cliquez sur le bouton "Copier dans un fichier". Le fichier généré devra être copié sur le serveur d'autorité intermédiaire.

De retour sur l'autorité intermédiaire, il nous reste à installer le certificat d'autorité provenant de l'autorité racine.

Bien que le certificat de l'autorité racine soit publié dans l'Active Directory, son installation dans le magasin local, n'est pas immédiate. Aussi, je vous recommande de lancer la commande suivante pour l'installer tout de suite :

gpupdate /force

À présent, nous pouvons sereinement installer le certificat d'autorité. Les commandes PowerShell sont :

certutil -installCert .\ContosoSubCA2.cer
Start-Service CertSvc

En lançant la console de gestion d'autorité depuis une autre machine, par exemple « S-SUBCA1 » et en ciblant le serveur « S-SUBCA2 », vous obtiendrez un affichage de ce type, confirmant que l'autorité est opérationnelle :

III. Tâches post-installation

A. Durée de validité

Par défaut, les certificats émis par l'autorité sont valables 2 ans. Cette durée peut convenir, toutefois sur certaines plateformes où le changement de certificats est pénible, une durée plus longue sera profitable. Raisonnablement, il est possible de l'étendre à 3 ans.

Depuis une invite de commandes PowerShell, exécuter :

Certutil -setreg CA\ValidityPeriodUnits 3
Certutil -setreg CA\ValidityPeriod "Years"
Restart-Service certsvc

Comme pour l'autorité racine et la première autorité intermédiaire, ces commandes vont venir ajuster des paramètres dans le Registre de Windows.

B. CRL : Delta

La liste de révocation de certificats (CRL) est valable 2 semaines comme nous l'avons paramétré précédemment. Elle sera utilisée pour vérifier la révocation des certificats émis par cette autorité.

Par défaut, une liste de révocation delta est générée chaque jour en plus de la liste complète. Sauf à avoir un usage intensif d'émission/révocation de certificats, la liste de révocation delta n'est pas utile et elle peut être désactivée via les commandes :

Certutil -setreg CA\CRLDeltaPeriodUnits 0
Restart-Service certsvc

C. CRL : Emplacements

La CRL est publiée à la fois dans l'Active Directory, puisqu'il s'agit d'une autorité de type « Enterprise », et en local sous « C:\Windows\System32\Certsrv ».

Il nous faut ajouter le serveur « S-SERVICESCA » comme emplacement au travers de son alias pour la publication et par son nom pour l'inclusion (voir explications dans le module sur l'installation de l'autorité secondaire 1).

Si vous êtes plus à l'aise en mode graphique, vous pouvez appeler la console MMC de gestion de l'autorité depuis un autre serveur afin d'ajouter les emplacements. Ici, nous allons procéder à cet ajout en lignes de commandes.

Il est possible de s'en sortir avec une commande de ce type :

certutil -setreg CA\CRLPublicationURLs

Ou encore d'utiliser le module PowerShell AD CS, assez pauvre en fonctionnalité.

Toutefois, nous allons nous tourner vers un module PowerShell gratuit fourni par « PKI Solutions », à savoir « PSPKI » que je souhaite introduire auprès de vous ici.

Son installation s'effectue via la commande suivante :

Install-Module -Name PSPKI

Charger ensuite le module via :

Import-Module PSPKI

Pour voir la liste des points de distribution configurés, lancez une commande de ce type :

$serveurPKI="S-SUBCA2.contoso.ad"
Get-CertificationAuthority -ComputerName $serveurPKI | Get-CRLDistributionPoint | select -ExpandProperty uri

Nous pouvons voir l'URI paramétrée, et savoir au travers d'un booléen les cases cochées (visibles dans la console graphique de gestion de l'autorité).

Pour commencer, nous allons inscrire l'URL en mode HTTP de téléchargement de la CRL.

La première valeur dans l'URL correspond aux cases à cocher, selon la nomenclature suivante :

• 1 – Publish CRLs to this location.
• 2 – Include in all issued certificates.
• 4 – Include in CRLs. Clients use this to find delta CRL locations.
• 8 – Include in the CDP extension of CRLs.
• 64 – Publish delta CRLs to this location. Specifies where to publish in AD DS when publishing to LDAP URLs.
• 128 – Include in the IDP extension of issued CRLs.

Puisque nous voulons inclure le chemin de CRL dans l'extension CDP, la valeur sera 8, il nous faut également l'inclure dans tous les certificats émis, soit 2. Il convient de faire l'addition : 8+2=10.

Ensuite, il nous faut constituer l'URI au format relatif, selon les variables suivantes :

• %1 – the CA's computer DNS name.
• %2 – the CA's computer NetBIOS name.
• %3 – CA's logical name.
• %6 – the LDAP path of the forest's configuration naming context for the forest.
• %7 – CA's 'sanitized' name. This is the same as CA name but with encoded special characters, such: \/:\*?"<>|.
• %8 – the CRL's renewal extension.
• %9 – indicates whether Delta CRLs are supported by this CA.
• %10 – indicates that the object is CDP object in AD CS.

Cela nous amène à lancer les commandes suivantes :

$newURI="10:http://pki.contoso.com/CRLDist/%3%8.crl"
$serveurPKI="S-SUBCA2.contoso.ad"
Get-CertificationAuthority -ComputerName $serveurPKI | Get-CRLDistributionPoint | Add-CrlDistributionPoint -URI $newuri | Set-CrlDistributionPoint -RestartCA

À présent, si on veut que le fichier .crl soit automatiquement copié vers l'emplacement que l'on vient d'ajouter, « pki.contoso.com » alias « S-SERVICESCA », il nous faut ajouter un chemin UNC, selon la même logique :

$newURI="1:\\S-SERVICESCA\CRLdist\%3%8.crl"
$serveurPKI="S-SUBCA2.contoso.ad"
Get-CertificationAuthority -ComputerName $serveurPKI | Get-CRLDistributionPoint | Add-CrlDistributionPoint -URI $newuri | Set-CrlDistributionPoint -RestartCA

Sur le partage « CRLDist » de « S-SERVICESCA », il faut ajouter l'autorisation pour le serveur « S-SUBCA2 » d'écrire.

Dernière étape : forcer la publication d'une nouvelle CRL.

certutil -CRL

Vous pourrez vérifier que le partage contient bien le fichier de CRL.

D. AIA : Emplacement

L'emplacement AIA (Authority Information Access) contient le certificat de l'autorité. Ce certificat est publié dans l'Active Directory, aussi, il est automatiquement installé sur les serveurs ou postes clients intégrés au domaine.

Pour d'autres plateformes, il peut être intéressant de référencer l'emplacement où il peut être téléchargé.

Toujours au travers du module PSPKI, nous allons intégrer l'emplacement dans la configuration de l'autorité. Toutefois, la copie du fichier doit se faire manuellement.

Depuis le serveur « S-SUBCA2 » :

$serveurPKI="S-SUBCA2.contoso.ad"
$newURI="2:http://pki.contoso.com/%1_%3%4.crt"
Get-CertificationAuthority -ComputerName $serveurPKI | Get-AIA | Add-AuthorityInformationAccess -URI $newURI| Set-AuthorityInformationAccess -RestartCA

Il ne nous reste plus qu'à copier le fichier de certificat sur le serveur « S-SERVICESCA ».

copy C:\Windows\system32\CertSrv\CertEnroll\S-SUBCA2.contoso.ad_ContosoSubCA2.crt '\\S-SERVICESCA\c$\inetpub\wwwroot\'

IV. Conclusion

Cette seconde autorité est prête à remplir sa mission ! Il nous faut à présent configurer le serveur S-SERVICESCA pour finaliser la plateforme AD CS. Rendez-vous au prochain chapitre.