Publication automatique des listes de certificats révoqués après la révocation d'un certificat

J'entends souvent dire que les opérateurs d'infrastructures de clés publiques (PKI) souhaitent qu'une nouvelle liste de certificats révoqués soit publiée sans délai.

Je voudrais maintenant exposer quelques réflexions sur les raisons pour lesquelles cette approche n'est pas optimale et proposer une solution plus élégante.

Au fond, quel problème voulons-nous résoudre ?

La véritable intention qui sous-tend la publication immédiate de la liste noire est de permettre une „ révocation en temps réel “, c'est-à-dire que la révocation prenne effet immédiatement, ou du moins aussi rapidement que possible.

Dans ce cas, « effectif » signifie que Parties de confiance détecter immédiatement la suspension des certificats et, par conséquent, ne plus accepter les certificats révoqués.

Les limites du sens

Avant d'évoquer des solutions, nous devrions prendre conscience que notre approche est vouée à l'échec dès le départ.

Les informations relatives aux certificats révoqués ne sont pas mises à jour en temps réel : clients (Windows) enregistrer les CRL entre et ne récupèrent donc pas de nouvelles listes de révocation à chaque vérification de certificat. Dans le pire des cas, les clients ne récupèrent une nouvelle liste de révocation que lorsque la liste mise en cache a expiré. L'utilisation de la Le rôle de l'OCSP (Online Responder) n'y changera rien.

Et même si nous disposons d'une infrastructure de statut de révocation extrêmement robuste, nous sommes confrontés au problème que toutes les parties de confiance ne vérifier si les certificats sont bloqués.

Nous pouvons donc en conclure que nous ne pouvons pas garantir que les clients utiliseront effectivement les listes de révocation de certificats nouvellement émises, ce qui signifie par conséquent que nous ne tirerons aucun avantage notable d'une émission plus fréquente (sauf dans des cas exceptionnels).

La solution la plus évidente serait de déclencher directement la création d'une liste de certificats révoqués à chaque révocation de certificat.

Certains créent par exemple pour cela une tâche planifiée sur la plateforme de certification, qui permet de Événement d'ID 25 provenant de la source « Microsoft-Windows-CertificationAuthority » ou le Événement n° 4870 provenant de la source « Microsoft-Windows-Security-Auditing » l'intercepte, puis déclenche la publication d'une liste noire.

Il semblerait également qu'il y ait déjà eu des demandes de fonctionnalités concernant des produits de gestion du cycle de vie des certificats (CLM) que je connais, visant à envoyer des commandes correspondantes à l'autorité de certification.

Cette approche présente toutefois plusieurs inconvénients majeurs :

La création d'une liste de certificats révoqués mobilise beaucoup de ressources, en particulier lorsque de nombreux certificats ont été révoqués ou doivent l'être. La création d'une liste de certificats révoqués peut prendre plusieurs minutes et mobiliser d'autant d'espace de stockage et de ressources système. En règle générale, on peut estimer qu'il faut compter 1 Mo pour 20 000 certificats révoqués.

Chaque liste de révocation de certificats émise et encore valide est stockée dans la base de données de l'autorité de certification. Si nous générons trop souvent des listes de révocation de certificats (et que, dans le pire des cas, celles-ci sont particulièrement volumineuses), notre base de données d'autorité de certification grossit considérablement. J'ai d'ailleurs déjà été confronté à un cas extrême dans la pratique : j'ai vu une autorité de certification dont la base de données contenait plus de 65 Go (!) de listes de révocation de certificats valides. Cette situation était due à la révocation massive de certificats via un script. Chaque révocation a déclenché la création d’une nouvelle CRL, ce qui a entraîné une réaction en chaîne.

De plus, le principe de la séparation des rôles est enfreint lorsqu'un système CLM a le droit d'ordonner à l'autorité de certification de publier des listes de certificats révoqués.

Ce que nous voulons réellement et ce qui est réaliste

Maintenant que nous avons pris conscience que la publication d'une liste de certificats révoqués à chaque révocation de certificat n'est pas une très bonne idée, nous pourrions en conclure qu'une publication régulière par l'autorité de certification pourrait constituer une solution plus judicieuse. Et c’est d’ailleurs exactement ce que fait déjà l’autorité de certification dans sa configuration par défaut.

Mais peut-être que cet intervalle nous semble trop long et que nous souhaiterions déclencher une publication avant cela.

Nous pourrions, par exemple, publier une nouvelle liste noire à intervalles réguliers, sans intervention d'un administrateur de l'autorité de certification, et uniquement si des certificats ont été révoqués depuis la dernière publication, sans pour autant générer de charge inutile pour l'autorité de certification.

Notre approche pourrait se présenter comme suit :

Nous commençons par déterminer la date à laquelle la dernière liste de certificats révoqués a été publiée (en analysant la date « NotBefore » de la liste actuelle).
Nous vérifions ensuite si des certificats ont été révoqués depuis lors (en consultant le journal des événements Windows pour la période comprise entre „ maintenant “ et la date de publication de la dernière CRL)
Si tel est le cas, nous publierons une nouvelle liste de certificats révoqués. Sinon, nous ne le ferons pas.

Pour cela, nous utilisons le Événement d'ID 25 provenant de la source Microsoft-Windows-CertificationAuthority.

Sinon, on pourrait aussi faire comme ça Événement n° 4870 provenant de la source « Microsoft-Windows-Security-Auditing », le mais qui doit d'abord être activée), car cela nous permet de concevoir une requête efficace.

Nous pourrions également obtenir ces informations via la base de données des organismes de certification, mais cette méthode est nettement moins efficace et deviendra de plus en plus lente à mesure que le nombre de certificats augmentera.

Voici un exemple de script PowerShell :

#requires -RunAsAdministrator

[cmdletbinding()]
param()

$RegistryRoot = "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration"

If (-not (Test-Path -Path $RegistryRoot)) {
    Write-Error -Message "No CA found!" -ErrorAction Stop
}

# Query the CA registry for the relevant information
$CaName = (Get-ItemPropertyValue -Path $RegistryRoot -Name "Active")
$CaServerName = (Get-ItemPropertyValue -Path "$RegistryRoot\$CaName" -Name 'CAServerName')
$ClockSkewMinutes = (Get-ItemPropertyValue -Path "$RegistryRoot\$CaName" -Name 'ClockSkewMinutes')

# Parse the current CRL for it's creation time
$CRLFile = "$env:SystemRoot\System32\CertSrv\CertEnroll\$CaName.crl"
$CRL = New-Object -ComObject X509Enrollment.CX509CertificateRevocationList
$CRL.InitializeDecode([System.Convert]::ToBase64String((Get-Content -Path $CRLFile -Encoding Byte)), 1)
$ThisUpdateUtc = [DateTime]::SpecifyKind($CRL.ThisUpdate, [DateTimeKind]::Utc)

# Query the audit log for any revocations that happened since the last $Events = Get-WinEvent -FilterHashtable @{
    Logname='Application'
    ProviderName='Microsoft-Windows-CertificationAuthority'
    Id='25'
    StartTime=($ThisUpdateUtc.AddMinutes($ClockSkewMinutes).ToLocalTime())
} -ErrorAction SilentlyContinue

# Only publish a new CRL if there were any revocations since the last CRL publication
If ($Events) {
    Write-Host "Publishing CRL"
    $CertAdmin = New-Object -ComObject CertificateAuthority.Admin
    $CertAdmin.PublishCRL("$CaServerName\$CaName", 0)
}

Nous exécutons ce script à intervalles réguliers via une tâche planifiée sur l'autorité de certification, par exemple une fois par heure.

Si un certificat est bloqué entre-temps, notre script le détecte et publie une nouvelle liste de certificats bloqués lors de sa prochaine exécution.

Pièges à éviter

Dans les autorités de certification traitant un volume important de données, le journal des événements se remplit plus rapidement et atteint donc plus tôt sa taille maximale, ce qui entraînera la suppression des événements les plus anciens. Pour que le script fonctionne de manière fiable, il faut donc définir une taille maximale suffisante pour le journal des événements de l'autorité de certification.

Mot de la fin

À mon avis, on accorde trop d'importance au mécanisme de révocation des certificats.

En tant qu'opérateur d'infrastructure à clé publique (PKI), nous n'avons aucun moyen de vérifier si les parties de confiance vérifient effectivement le statut de révocation.
En tant qu'opérateur d'infrastructure à clé publique (PKI), nous n'avons aucun contrôle sur le fait que les parties de confiance demandent une nouvelle liste de révocation de certificats ou une nouvelle réponse OCSP tant qu'une liste de révocation de certificats antérieure est encore valide.
En tant qu'opérateur d'infrastructure à clé publique (PKI), nous n'avons aucun moyen de nous assurer que l'information indiquant que des certificats doivent être révoqués nous parvienne effectivement.

Je m'en tiens ici à Peter Gutmann: Les CRL ne fonctionnent pas.

À mon avis, la solution la plus sûre consiste à ne pas se fier à l'infrastructure de gestion des statuts de blocage et à utiliser plutôt des certificats dont la durée de validité est la plus courte possible, ce qui implique des recertifications fréquentes.