Le renouvellement de l’autorité de certification, l’autorité racine d’une PKI, doit vraiment devenir une opération standard.
J’avais en tête que la règle de base est simple : à 80 % de sa validité, un certificat doit être renouvelé.
L’autorité de certification est facilement assimilable à un certificat, au sens clés cryptographiques j’entends, pour avoir une image simple en tête.
Lorsque vous renouvelez votre autorité de certification (AC0 admettons), l’opération de renouvellement n’invalide pas instantanément les 20 % restants de sa durée de validité.
Deux autorités (AC0 et AC1) sont donc valides et cohabitent durant une courte durée une fois le renouvellement effectif.
Heureusement que le mécanisme de renouvellement est ainsi, que la cohabitation existe donc, autrement vous devriez mobiliser la terre entière à chaque renouvellement de l’autorité racine de certification.
Ce mécanisme de renouvellement est transparent dans un environnement Active Directory, puisque les informations relatives à A1 se propagent naturellement / automatiquement, c’est pour vulgariser mon exemple.
Généralement dans le cadre d’une automatisation, le protocole ACME est mis en œuvre.
Dans la mesure où les infrastructures sont hétérogènes, il ne faut pas omettre de partager cette nouvelle autorité racine (AC1) aux composants qui consomment des services sécurisés à travers les certificats (à l’instar des équipements réseaux (niveau 3), les WAF (niveau 7) et autres, qui réalisent par exemple des requêtes Active Directory en LDAP over TLS.
Heureusement que le mécanisme de renouvellement est ainsi insiste-je, car si les certificats émis par la nouvelle autorité de certification (A1) n’étaient pas naturellement compris par la chaine de certification A0, alors le WAF – pour reprendre cet exemple – ne serait pas en mesure de détecter ma CRL (ma DeltaCRL pour corser l’image) faute de signature cohérente.
Second exemple, lorsque l’AC1 est générée, les autorités intermédiaires relatives à l’AC0 – en fin de vie pour rappel – ne sont pas invalidées instantanément non plus ; sans quoi à chaque fois qu’une autorité publique renouvelle son AC, la terre entière s’arrête de tourner.
Remarquez, ce serait une vraie dinguerie … 🙂
Je prends un dernier exemple simple dans ma narration, mais nous pouvons translater la démarche vers une autorité racine hors ligne (la bonne pratique pour rappel). Je renouvelle mon AC hors ligne, l’autorité intermédiaire en ligne ne meut pas instantanément, i.e. révoquée ou expirée.
Souvent cette opération technique de renouvellement est simple, mais coince car nous manquons de visibilité. Un assessment clair côté applicatif et/ou réseau manque la plupart du temps.
Comme la visibilité est de mise, la technique ne fait pas tout mais reste tout de même importante, il est grand temps de s’outiller convenablement.
Peu importe la solution technique de la PKI, car la PKI répond à un standard d’implémentation PKCS #11. So, CLM your mind.
C’est un vrai sujet car certains acteurs tendent à réduire à quelques mois la durée de vie des certificats (13 mois, 3 mois … jusqu’où irons-nous ?).
Un dashboard clair permet d’être confortable dans la phase de renouvellement de son AC. Les questions habituelles (quand, comment, y a-t-il un oubli, à qui diffuser la Root CA et cætera) se poseront de moins en moins. Ce sera donc moins chronophage.
La technique est rarement le blocage dans ce type d’opération, mais elle a le dos large n’est-ce pas ?