Une autorité de certification peut être en ligne, en santé, répondre sur le réseau, réussir toutes les vérifications que vous avez mises en place, et être complètement incapable d'émettre un certificat. Non pas parce que quelque chose est brisé sur l'AC, mais parce que ce dont elle a besoin se trouve ailleurs.

Ce n'est pas une panne exotique. C'est la conséquence prévisible d'une décision d'architecture qui est bonne et que vous ne devriez pas renverser. Il vaut mieux la comprendre avant qu'elle se présente à trois heures du matin.

Où se trouve réellement la clé

Une AC signe les certificats avec une clé privée. Dans tout environnement construit selon une norme raisonnable, cette clé ne réside pas sur l'AC. Elle réside dans un module matériel de sécurité, un HSM, un appareil dont la raison d'être est que la clé ne le quitte jamais.

Cette dernière partie n'est pas une figure de style. L'AC ne va pas chercher la clé pour signer localement. Elle en est incapable. Elle prépare les données à signer, les transmet au HSM par le réseau, le HSM effectue l'opération de signature à l'interne, et la signature revient. Chaque émission, chaque LCR, chaque réponse OCSP signée par l'AC elle-même constitue un aller-retour réseau vers un appareil distinct.

L'image qui convient est celle d'un notaire à qui il est interdit de garder son propre sceau. Le sceau se trouve dans une chambre forte à l'autre bout de la ville et la loi lui interdit de le transporter. Chaque document qu'il authentifie part par messager vers la chambre forte, s'y fait estampiller, et revient par messager. Il est à son bureau. Il est éveillé. Il est disponible. Quand la route vers la chambre forte est emportée, il ne peut plus rien authentifier, peu importe la force avec laquelle vous frappez à sa porte.

Ce que cela signifie pour la disponibilité

La disponibilité de votre service d'émission n'est pas la disponibilité de votre AC. C'est l'intersection de plusieurs éléments :

  • l'hôte de l'AC et le rôle des services de certificats
  • le HSM lui-même, et l'état de sa session authentifiée avec le client installé sur l'AC
  • chaque segment réseau, règle de pare-feu, route et répartiteur de charge entre les deux
  • le logiciel client du fournisseur, sur l'AC, qui dialogue avec l'appareil

La plupart des dispositifs de surveillance PKI surveillent le premier élément et s'arrêtent là. C'est précisément pourquoi cette panne surprend. Le service roule. Le rôle répond. Rien n'est au rouge dans le tableau de bord. Ce qui a lâché, c'est une dépendance que personne n'a dessinée sur le schéma, et le symptôme apparaît ailleurs, généralement sous forme de billets au centre de services au sujet de l'inscription.

Dans un environnement Active Directory Certificate Services en particulier, l'AC rejoint le HSM par l'entremise d'un fournisseur de stockage de clés, un KSP enregistré auprès de CNG, qui dialogue à son tour avec la bibliothèque cliente du fournisseur, habituellement au moyen de PKCS #11. Il s'agit d'un détail d'implémentation propre à Microsoft, appliqué à un modèle qui, lui, n'a rien de propre à Microsoft. Le diagnostic qui révèle la vérité le plus rapidement est certutil -verifykeys, qui force l'AC à exercer sa clé de signature de bout en bout plutôt que de simplement confirmer l'existence d'un objet certificat. Une AC qui réussit une vérification de service et qui échoue à -verifykeys vient de vous dire exactement où se situe le problème.

La panne avec laquelle vous pouvez vivre

Une panne qui interrompt l'émission est désagréable, et elle se rétablit généralement d'elle-même.

L'inscription automatique réessaie. Les demandes soumises par les voies normales échouent puis sont resoumises, ou demeurent en attente. Les services dont les certificats ont encore des semaines de validité ne se soucient pas d'avoir été privés de renouvellement pendant une fenêtre de quatre heures au milieu de la nuit. Quand le chemin revient, l'arriéré s'écoule, habituellement sans que personne intervienne.

Si votre exposition se limite à une émission différée, vous avez un problème de surveillance et un problème de communication, pas une crise de disponibilité.

La panne avec laquelle vous ne pouvez pas vivre

Signer une liste de révocation de certificats fait appel à la même clé, par le même chemin, et se heurte à la même dépendance. C'est là que se trouve le vrai risque, et c'est la partie qu'on oublie.

Deux facteurs rendent la publication de la LCR plus dangereuse que l'émission.

D'abord, elle est planifiée plutôt que déclenchée par la demande. Si la tâche de publication se déclenche pendant la fenêtre de panne, elle échoue, consigne un événement que la plupart des gens ne surveillent pas, et attend le prochain intervalle prévu. Elle ne réessaie pas avec l'insistance d'un client en cours d'inscription. Un échec qui tombe dans la mauvaise fenêtre peut passer inaperçu jusqu'à ce que quelqu'un exécute certutil -CRL à la main.

Ensuite, les conséquences sont à l'échelle du parc plutôt que locales. Un poste qui n'arrive pas à s'inscrire, c'est un poste incommodé. Une LCR dont la date NextUpdate est dépassée, c'est un échec de validation pour chaque partie utilisatrice qui vérifie la révocation et qui est configurée en mode strict. Ce n'est plus un certificat en retard. C'est l'authentification et le TLS qui cassent sur des systèmes qui fonctionnaient parfaitement et qui ne demandaient rien à personne.

Le chiffre qui compte n'est donc pas votre période de validité de LCR. C'est votre chevauchement, soit l'écart entre le moment où une nouvelle LCR est publiée et le moment où la précédente expire. Ce chevauchement constitue votre budget de panne. Si vous publiez la LCR d'une AC émettrice tous les trois jours avec une validité de sept jours, vous disposez d'environ quatre jours de coussin, et vous pouvez absorber un cycle de publication manqué sans que personne s'en aperçoive. Si vous publiez aux sept jours avec une validité de sept jours, vous n'avez aucun coussin, et un seul échec de tâche devient un compte à rebours.

Dimensionnez le chevauchement en fonction de la pire panne que vous êtes prêt à encaisser, puis ajoutez une marge, parce que la panne n'aura pas la politesse de survenir au début de la fenêtre.

Les LCR différentielles méritent le même calcul et le reçoivent rarement. Et si les certificats de signature de votre répondeur OCSP sont émis par l'AC avec une validité courte et un renouvellement automatique, une configuration courante et par ailleurs sensée, notez que leur chemin de renouvellement passe par la dépendance que vous venez justement de perdre.

Ce qu'il faut surveiller à la place

La leçon à tirer d'un incident de cette forme n'est pas que l'architecture est mauvaise. C'est que l'environnement était instrumenté pour observer la mauvaise couche. Les correctifs concrets, dans l'ordre où je les mettrais en place :

Une sonde d'émission synthétique. À intervalle régulier, demandez un certificat à partir d'un modèle à faible incidence dédié à cet usage, validez le résultat, et déclenchez une alerte en cas d'échec. C'est la seule vérification qui exerce la chaîne complète, de l'AC au KSP, à la bibliothèque cliente, au réseau, au HSM, et retour. Tout le reste relève de la déduction.

La santé directe de la dépendance. Surveillez la connectivité et l'état de session du client HSM depuis l'hôte de l'AC, et non seulement la page d'état de l'appareil. L'appareil peut être en parfaite santé tout en étant injoignable depuis la seule machine qui en a besoin.

La latence de signature comme indicateur avancé. Le temps d'aller-retour des opérations de signature se dégrade avant de céder. Un chemin qui a discrètement basculé vers une route plus longue se manifeste en latence plusieurs jours avant de se manifester en panne.

La fraîcheur de la LCR vue de l'extérieur. Récupérez la LCR depuis un point de distribution publié, par le même chemin réseau qu'emprunterait une partie utilisatrice, et alertez sur le temps restant avant NextUpdate plutôt que sur la réussite de la tâche. La réussite de la tâche vous dit que l'AC croit que ça a fonctionné. La validité restante vous dit si vos utilisateurs sont sur le point de passer une mauvaise journée.

Ce qu'il ne faut pas faire

La mauvaise réaction à cet incident consiste à conclure que la dépendance réseau est le problème et à ramener les clés de signature dans le logiciel. Ce n'est pas le problème. Les clés dans un HSM, c'est la bonne réponse, et l'aller-retour réseau en est le prix. Les modules validés FIPS 140 aux niveaux d'assurance supérieurs ne se contentent pas de résister à l'altération : ils y répondent activement, en effaçant le matériel de clé lors d'une ouverture du boîtier, d'une température ou d'une tension hors plage, ou d'un déplacement non autorisé. C'est la différence entre une serrure qui vous montre qu'elle a été crochetée et un coffre qui détruit son contenu au passage. C'est précisément pour cela que le notaire ne peut pas glisser le sceau dans sa poche. Le sceau ne survivrait pas au trajet.

Si la dépendance doit véritablement raccourcir, les options honnêtes sont architecturales et non cryptographiques. Des membres de grappe locaux à chaque site d'AC. Des HSM placés dans le même domaine de défaillance que les AC qu'ils desservent. Des chemins redondants qui ne partagent pas un mode de défaillance commun. Chacune de ces options comporte un coût réel en garde des clés, en complexité de cérémonie et en charge opérationnelle, et chacune est une décision à prendre délibérément plutôt qu'en réaction, à la fin d'une longue nuit.

L'ancrage normatif

Le principe voulant qu'une clé privée n'existe jamais en clair à l'extérieur d'une frontière protégée est plus ancien que n'importe quel produit qui l'implémente aujourd'hui. La norme FIPS 140-3 définit les exigences de sécurité et les niveaux d'assurance du module cryptographique lui-même. La publication NIST SP 800-57 encadre les pratiques de gestion des clés autour de ce module. La RFC 5280 définit la structure de la LCR et la sémantique du champ NextUpdate sur laquelle repose tout le calcul présenté plus haut. PKCS #11 est l'interface que l'hôte de l'AC emprunte généralement pour rejoindre le module.

Aucun de ces documents ne vous dira qu'un incident WAN dans une portion sans rapport de votre réseau peut se présenter comme une panne de PKI. Cette partie-là, c'est à vous de la dessiner sur le schéma.