Certbot: Besoin de la prise en charge des certificats Wildcard | Conflit d'intérêts avec les CA?

@HLFH , nous avons verrouillé #66 parce que nous étions inutilement conscients de la demande de certificats génériques. Malgré le verrouillage du problème, je peux vous assurer que nous n'avons pas oublié la demande pour cette fonctionnalité.

Ce référentiel est destiné au client Let's Encrypt qui suit le protocole ACME qui n'autorise pas les certificats génériques. Étant donné que l'ajout de cette fonctionnalité est en dehors de la portée du client, je ferme ce problème. N'hésitez pas à contacter le groupe de travail de l'IETF pour l'ACME. Vous pouvez trouver plus d'informations sur leur page github .

Quelqu'un pourrait-il expliquer ce que signifie la section 6.6 de l'ACME dans ce contexte :

C'est à la politique locale du serveur de décider quels noms sont
acceptable dans un certificat, compte tenu des autorisations que le serveur
s'associe à la clé de compte du client. Un serveur PEUT envisager un
client autorisé pour un domaine wildcard s'il est autorisé pour le
nom de domaine sous-jacent (sans le label "*").

Le PR 14, même non fusionné, l'exprime encore plus clairement.

À ma connaissance, cela permettrait à LE d'autoriser un client pour un domaine (tel que : example.com) et d'émettre des certificats génériques (tels que : *.example.com) par la suite du point de vue de la spécification ACME.

Il me semble que le manque de prise en charge des caractères génériques était lié à la politique locale du serveur. Si tel est le cas, veuillez indiquer clairement que la politique de LE est (actuellement) opposée à la délivrance d'une certification générique et arrêtez de blâmer le groupe de travail ACME. :)

Si je me trompe merci d'avance pour les éclaircissements. :)

@bmw Des idées à ce sujet? Peut-être pousser une mise à jour vers #66 ou même la déverrouiller pour que les gens sachent ce qui se passe ? Je fais également un ping à @jmhodges et @bdaehlie qui ont respectivement verrouillé et fermé le #66.

J'ai juste regardé la spécification moi-même pour voir s'il y avait eu un mouvement sur les caractères génériques, et j'ai vu exactement la même chose mentionnée par @MichaelHierweck (bien que ce soit maintenant dans la section 6.5 de la dernière version).

Surtout si l'on considère que ce projet n'est plus seulement letsencrypt , mais maintenant certbot le protocole devrait être entièrement pris en charge et non limité par un seul fournisseur qui ne respecte pas les spécifications. La politique d'émission est difficile, la mise en œuvre de la spécification l'est moins. Je suppose que certbot afficherait simplement une sorte de message d'erreur si quelqu'un essayait d'obtenir un caractère générique émis parletsencrypt.

À titre personnel, j'espère que soutenir cela dans le client et rejeter la faute _proprement_ sur le côté serveur/ca LE les poussera à autoriser les caractères génériques, car cela faciliterait considérablement certains projets sur lesquels je travaille.

Personnellement, je pense que #66 a été résolu correctement en pointant les gens vers https://community.letsencrypt.org. Quant à les mettre à jour, je pense qu'il n'y a rien à dire. La phrase

Un serveur PEUT considérer un client autorisé pour un domaine générique s'il est autorisé pour le nom de domaine sous-jacent (sans l'étiquette "*").

n'est pas nouveau et remonte àletsencrypt/acme-spec#166. J'avais tort quand j'ai dit que ce n'était pas autorisé dans la spécification ACME.

Cela dit, j'ai créé #3233 pour suivre le problème de permettre aux utilisateurs de demander des certificats génériques dans le client.