Résumé

  • Le 9 novembre 2015, Let’s Encrypt a annoncé une limite de 90 jours et conseillé le renouvellement au 60e jour : réduire la durée d’exposition après une clé volée ou une émission erronée, et faire de l’automatisation un élément central du HTTPS.
  • Trois jours plus tard, l’annonce de la bêta publique comptait plus de 11 000 certificats émis pendant la bêta limitée, tout en reconnaissant que l’expérience du client devait encore fonctionner sur de nombreuses plateformes.

Analyse

Une date d’expiration peut rester discrète dans un fichier et devenir très bruyante sur un site. Le champ notAfter appartient au certificat signé. La RFC 5280 définit une période de validité comprise entre notBefore et notAfter, dates incluses. Quand la seconde est passée, il faut mettre en service un nouveau certificat.

Le 9 novembre 2015, Josh Aas, directeur exécutif de l’Internet Security Research Group, a expliqué pourquoi Let’s Encrypt plafonnait ses certificats à 90 jours. Il attribuait deux fonctions à cette même limite. Une clé privée volée ou un certificat émis à tort conserverait moins longtemps sa validité. Et les renouvellements rapprochés pousseraient les exploitants vers l’automatisation, indispensable à un HTTPS facile à généraliser.

La recommandation de renouveler au bout de 60 jours donne au choix sa forme concrète. Let’s Encrypt ne demandait pas d’attendre la dernière journée. Il restait environ un mois avant la limite, intervalle qu’un administrateur pouvait encore utiliser pour intervenir manuellement. Aas précisait que le service était jeune et que l’automatisation était nouvelle pour beaucoup d’abonnés. Le compromis devait donc être assez court pour rendre le logiciel utile, mais assez long pour laisser une reprise humaine.

Le calendrier montre l’état du projet. Le 12 novembre, Aas indiquait que la bêta limitée avait commencé le 12 septembre et dépassé 11 000 certificats. La bêta publique était prévue pour le 3 décembre. Le même avis présentait l’automatisation comme un pilier de la stratégie et signalait encore du travail sur l’expérience du client, à travers des plateformes très différentes. Les émissions progressaient; le renouvellement fiable partout restait à construire.

L’argument de Let’s Encrypt tenait en une phrase de gestion. On ne pouvait pas demander aux administrateurs de renouveler chaque certificat à la main à l’échelle de tout le Web. Si l’émission et le renouvellement étaient automatiques, une durée plus courte ne compliquerait pas le travail de la personne qui exploite le site. La réduction du risque et la cadence de renouvellement formaient donc une seule décision.

La voie manuelle restait ouverte, mais le modèle visé plaçait le logiciel au centre. Le délai permettait de repérer un renouvellement raté et d’agir avant l’expiration. Le fonctionnement courant, lui, dépendait du client, de sa planification, de sa compatibilité avec la plateforme et de l’installation effective du nouveau certificat. Soixante jours donnaient une échéance; l’automatisation devait permettre de la tenir à grande échelle.

Le total de la bêta mesure les certificats émis au 12 novembre, pas les renouvellements réussis ou manqués. Une série datée de réussite des renouvellements permettrait d’évaluer la marge de secours; les deux annonces ne la publient pas.

Sources