Résumé

  • draft-ietf-acme-profiles-02 permet à un serveur ACME d’annoncer ses profils locaux et d’associer le profil choisi à une commande. Le texte demeure un Internet-Draft Standards Track, pas une RFC ni un catalogue mondial.
  • Le nom reçu dans la commande atteste une sélection de politique. L’éligibilité du compte, la maîtrise des identifiants, la conformité du DER, l’installation et la décision du client restent des preuves distinctes.
  • Une chaîne exploitable conserve la Directory et la documentation vues lors du choix, puis contrôle le certificat effectivement signé et celui réellement servi.

Le renouvellement est marqué « réussi ». La commande contient profile: "tlsserver". La requête ACME était signée et le serveur a renvoyé le même nom. Pourtant, un nœud sert encore l’ancien certificat, le nouveau DER contient un EKU inattendu et certains clients refusent la chaîne.

Le profil n’a pas menti ; on lui a demandé de prouver trop de choses. Il relate un choix sur le plan de contrôle. Il ne constate ni le contenu final du certificat, ni sa propagation, ni la politique locale de chaque partie utilisatrice.

Daté du 28 août 2026, draft-ietf-acme-profiles-02 est un document de travail de l’ACME Working Group. Il répond à une lacune concrète de la RFC 8555 : les CA proposent plusieurs familles de certificats, alors que le client ne dispose pas d’un emplacement normalisé pour les découvrir et les choisir. La note d’implémentation cite deux serveurs et sept clients ; Let’s Encrypt documente un déploiement. Ce sont des indices sérieux de code en fonctionnement, non une RFC définitive ni une mesure exhaustive de l’adoption.

Un sélecteur dans l’espace de noms du serveur

Le serveur qui autorise la sélection publie meta.profiles dans sa ressource Directory. Chaque nom court pointe vers une explication lisible par un humain. Le client place éventuellement ce nom dans profile lors de newOrder, et la commande acceptée le reprend.

La portée est locale. Rien n’impose que classic, tlsserver ou shortlived possède la même sémantique chez deux CA. L’URL descriptive n’est pas un schéma obligatoire énumérant chaque extension X.509. Elle peut même être une URI de données. Le nom est donc une clé vers la politique d’un serveur, pas un certificat portable de signification.

Cette modestie est une qualité architecturale. Le client peut exprimer son intention sans encoder un produit dans le CSR. Le serveur peut exposer ses options sans API de commande parallèle. La sélection survit jusqu’à la finalisation. Il n’est pas nécessaire qu’une autorité centrale régisse les gammes, les prix ou les règles internes de toutes les CA.

Il faut en revanche préserver le contexte : URL de Directory, empreinte de la réponse, heure, pair TLS, contenu exact de la documentation et conditions particulières du compte. Archiver seulement le mot tlsserver revient à conserver une clé en supprimant le dictionnaire qui lui donnait son sens.

La décision de politique quitte le CSR, pas la clé publique

Avec la RFC 8555, la commande porte les identifiants et une préférence de validité ; le CSR arrive à la finalisation. Ce CSR peut demander de nombreux champs. Copier aveuglément ses extensions vers le certificat accroît les risques de conformité et d’analyse ASN.1.

L’extension Profiles déplace la sélection vers la commande. Le projet indique que, pour cette décision, le contenu du CSR au-delà des Subject Alternative Names et de la Subject Public Key devient sans pertinence. La CA fabrique le certificat selon sa politique au lieu de traiter le CSR comme un bon à tirer.

La formulation doit rester précise. La clé publique demeure essentielle ; les SAN se rattachent aux identifiants autorisés. La CA doit toujours construire et signer correctement, choisir une chaîne, satisfaire sa politique de certification et les exigences applicables, et produire les éléments de transparence nécessaires.

Le progrès est une réduction de surface, pas une magie. Le protocole commun normalise le minimum. La réalité se lit dans les octets que la CA a finalement signés.

Qui a choisi : le client ou le serveur ?

Lorsque le client envoie explicitement un profil, le message ACME signé montre que la clé du compte a autorisé cette charge utile. Le serveur conserve le pouvoir de vérifier la combinaison.

Quand le client ne précise rien, le projet recommande au serveur qui annonce des profils d’en choisir un et de l’associer à la commande. Cette valeur témoigne alors d’un défaut serveur, pas d’un choix actif du souscripteur.

Un journal utile conserve l’origine de la sélection, la version du client, la source de configuration, le compte, la requête, la réponse Order, la version de politique serveur et l’autorité qui pouvait modifier chaque configuration. On distingue ainsi une migration volontaire d’un changement de défaut appliqué à des clients inchangés.

Cette différence est visible dans les calendriers Let’s Encrypt. Des profils optionnels permettent de tester un EKU plus étroit ou une durée plus courte avant que classic ne change. Les deux trajectoires peuvent être légitimes, mais elles ne distribuent pas la décision de la même manière.

L’éligibilité du compte ne prouve pas le contrôle du nom

Le serveur doit rejeter un profil incompatible avec le reste de la requête. Le texte évoque un type d’identifiant inadéquat et un compte absent de l’allowlist requise. Le type d’erreur proposé est invalidProfile.

Cette vérification n’est pas l’autorisation ACME de l’identifiant. Un compte peut avoir accès à un profil privé sans avoir démontré le contrôle d’un domaine. Un compte ayant réussi DNS-01 ou HTTP-01 peut ne pas être autorisé à obtenir un profil restreint.

Trois pièces sont nécessaires : la raison pour laquelle le compte est éligible ; la validation de chaque identifiant ; la raison pour laquelle la politique d’émission accepte l’ensemble. External Account Binding, contrat, paiement, approbation d’incident ou allowlist concernent la première. Les traces de challenge concernent la deuxième. Le dossier CA et le certificat concernent la troisième.

L’interface peut présenter une seule transaction. L’autorité reste distribuée entre plusieurs décisions. La signature du compte n’est ni un titre sur tous les identifiants, ni un droit général à toutes les propriétés de certificat.

L’exception non annoncée doit nommer son autorité

Le serveur devrait refuser un profil absent de la Directory, mais peut l’accepter dans des circonstances exceptionnelles. Le projet cite un accord privé conclu hors protocole et le remplacement massif d’un certificat émis sous un profil désormais retiré.

Cette soupape évite que la publication publique soit l’unique source d’autorité en situation d’entreprise ou d’urgence. Par conséquent, l’absence d’un nom dans la Directory ne prouve pas son invalidité.

Une acceptation non annoncée exige un dossier plus riche : contrat ou incident, comptes concernés, période, contraintes, approbateur, objectif de remplacement, mécanisme de retrait et preuve que le chemin n’était pas ouvert à tous. Privé ne signifie pas abusif. Sans provenance signifie impossible à auditer.

Le retrait suit deux horloges

Un profil peut disparaître de la Directory alors que des commandes antérieures restent vivantes. Si la CA refuse désormais d’émettre à la finalisation, le serveur doit retourner invalidProfile. Le projet recommande d’éviter ce cas en laissant expirer les commandes avant l’arrêt.

L’horloge de publication indique ce qu’un nouveau client découvre. L’horloge de commande part de newOrder, traverse les autorisations et se termine à l’expiration ou à l’émission. Une migration doit enregistrer les dates d’annonce, le dernier Order accepté, l’expiration maximale, la dernière émission, les renouvellements restants et les exceptions.

Sans ce tableau, un client reçoit tardivement une erreur et la confond avec une panne réseau, un CSR défectueux ou une validation ratée.

Le cas le plus délicat est une sémantique modifiée sous un nom stable. Durée, EKU, réutilisation des autorisations ou chaîne peuvent évoluer. Il faut geler la définition vue par chaque Order et contrôler chaque certificat renouvelé.

Le DER est l’objet de conformité

La commande acceptée est l’engagement de politique du serveur. Le certificat est le résultat vérifiable.

Le contrôle doit comparer le DER à un prédicat versionné : SAN exacts, types d’identifiants, algorithme et paramètres de clé, Key Usage, Extended Key Usage, Basic Constraints, Certificate Policies, criticité, période de validité, issuer, algorithme de signature, chaîne, numéro de série, encodage, éléments CT et champs interdits.

Il faut aussi relier le certificat à l’Order, aux autorisations et à la clé du CSR. Sinon, on démontre qu’un certificat quelconque respecte une politique, pas qu’il provient de la transaction examinée.

Une documentation en prose aide l’opérateur à choisir, mais se prête mal à l’automatisation. Une CA pourrait publier un manifeste de conformité interprétable par machine. C’est une proposition d’exploitation de cet article, non une obligation du projet. Elle rendrait la promesse locale testable sans créer un registre central des produits.

Le test doit être répété à chaque renouvellement. Le même nom ne garantit ni la même version, ni la même durée, ni la même chaîne. Une automatisation qui vérifie seulement la réponse ACME contrôle la commande et omet le credential.

CT et CAA ne ferment pas les autres preuves

Certificate Transparency peut montrer qu’un certificat ou un précertificat a été journalisé. Elle ne prouve pas la sélection du profil, sa conformité, ni le déploiement.

CAA peut limiter les émetteurs autorisés et porter ses propres paramètres de compte ou de validation. Il ne sélectionne pas le profil ACME et ne décrit pas les champs du résultat.

Ces contrôles ont de la valeur parce qu’ils sont indépendants. La construction de chaîne l’est aussi : la CA propose un chemin, le client peut en construire un autre selon son magasin local. Une intention de profil ne commande pas la confiance du client.

L’émission ne déploie rien

Après la signature, le certificat et la clé privée doivent atteindre la bonne cible. Répartiteurs, régions, secrets, sidecars et processus anciens créent des déploiements partiels. Le job de renouvellement peut être vert pendant qu’une partie du trafic voit l’ancien credential.

Associez l’empreinte DER et celle de la clé à chaque cible. Observez de l’extérieur ce qui est réellement servi. Vérifiez SNI, identité de service, chaîne, activation et disparition du précédent certificat. Testez enfin des clients représentatifs.

La séquence complète est : découvrir -> préserver -> choisir -> qualifier -> autoriser les identifiants -> lier l’Order -> finaliser -> inspecter -> déployer -> observer -> renouveler.

Chaque étape peut réussir tandis que la suivante échoue. Il faut donc une suite de reçus liés, pas un voyant global.

Un déploiement réel montre la valeur du calendrier

Let’s Encrypt définit un profil comme un ensemble de caractéristiques de validation et de certificat final. La majorité des souscripteurs peut accepter le choix automatique ; certains peuvent sélectionner explicitement.

Pour le changement d’EKU, tlsserver a permis d’exclure plus tôt Client Authentication, avant la modification de classic, tandis qu’un tlsclient temporaire ménageait une transition. Pour les durées, des profils de 45 et de six jours précèdent les changements du défaut.

Ce cas prouve que le mécanisme peut séparer adopteurs précoces, bascule générale et compatibilité bornée. Il prouve aussi qu’un nom sans date est incomplet. Durée, EKU, fenêtre de réutilisation et disponibilité changent selon des calendriers différents.

Il ne prouve pas que tous les abonnés ont réussi leur migration ni que chaque client listé gère chaque choix. Il documente l’usage du sélecteur par une CA.

Un reçu de profil plutôt qu’un badge

Le reçu doit relier Directory et documentation, origine du choix, compte et autorité de configuration, identifiants, clé, règle d’éligibilité, autorisations ACME, Order et expiration, CSR, DER, série, issuer, chaîne, CT, résultat de conformité, cibles d’installation, observation externe, tests clients, renouvellement, exception et rollback.

« L’Order a renvoyé le nom » est une observation. « Le DER correspond à la version X » est un test. « Le service a présenté ce DER » est une autre observation. « Le résultat métier est obtenu » vient encore après.

Le protocole reste minimal. Les acteurs conservent localement les preuves dont ils ont besoin. C’est plus robuste que de demander au nom de profil de gouverner tous les usages ultérieurs.