La beta publique de Let’s Encrypt est ouverte

Une première fois annoncée pour novembre, la beta publique de l’autorité de certification gratuite Let’s Encrypt ouvre enfin les vannes de son système aujourd’hui sans nécessité de requérir une invitation.
Durant la phase précédente de tests, plus de 26000 certificats SSL ont été émis.
Les certificats sont valides dans la plupart des navigateurs grâce à la cross-signature de IdenTrust.

Du coup j'ai testé avec https://github.com/kuba/simp_le évoqué dans les commentaires sur HN sur un sous-domaine hébergé sur un nginx, ça marche très bien, c'est un jeu d'enfant, j'ai juste mis une petite heure à mettre ça en place, me reste juste à rajouter la commande dans une crontab et roule ma poule ! J'ai eu un A sur le test de Qualys (je chercherai comment obtenir le A+).

Par ailleurs j'ai vu hier Caddy, un serveur web (comme Apache ou nginx par exemple) écrit en Go, qui propose tenez-vous bien, le HTTPS par défaut via Let's Encrypt : https://caddyserver.com/blog/caddy-0_8-released (via /r/golang).

Ah merci du retour d'expérience, j'ai simp_le sur mon serveur mais pas pris le temps de m'y coller encore. Est-ce que tu n'as utilisé que les informations du README de simp_le, ou as-tu trouvé un post de blog plus didactique ?

La doc est succinte en effet, j’ai suivi ce tuto qui est dans la page “Links” du wiki du projet sur github : http://blog.heckel.xyz/2015/12/04/lets-encrypt-5-min-guide-to-set-up-cronjob-based-certificate-renewal/

Grosse annonce longtemps attendue hier : l'émission de certificats SSL/TLS wildcard est prévue pour janvier 2018 (lobste.rs). Assez surpris que ça se fasse, je trouve ça un peu dangereux (rien ne prouve que tous les serveurs en *.example.org sont sous mon contrôle).

Petite mise à jour vis-à-vis du déploiement sur mes serveurs : dans les messages précédents je parlais de simp_le, mais le renouvellement automatique des certificats n'était pas ou plus fonctionnel et le programme n'était plus mis à jour quand je l'utilisais encore. Je suis passé sur le client officiel Certbot qui lui marche très bien. J'ai même réfléchi à Caddy, mais je n'avais pas vraiment envie de refaire toute la configuration à la place du couple nginx+certbot actuel.

Le but des certificats n'est pas de dire c'est le contenu est "propre", mais que le domaine sur lequel t'es appartient bien à celui qui le dit. Ca apporte la vérification de l'identité par qui ça passe, pas la "qualité" du contenu

Les wildcarts sont pour moi indispensables pour tout site un minimum conséquent, qui a aussi plusieurs sous domaines.

Manque plus que les certificats EV (validation étendue), et ça sera du bon gros et "vrai" certificat complet.

A titre d'exemple, on s'est déjà fait refuser un certificat EV, car le nom commercial et la raison socaile de l'entreprise n'était pas le même, obligé de faire le certificat sous la raison sociale

De mémoire, Let's Encrypt faisait que les certificats DV (du domaine, ça prouve que la personne qui le monde a la main sur le domaine), mais pas de OV (pas de vérification de l’existence réelle de l'organisme), ni de EV (vérification de l'organisme, mais aussi de l'identité de la personne derrière)

Super leur site !

Quand on cherche "let's encrypt + debian" sur un moteur de recherche, ça donne une méthode d’installation différente à chaque lien. Je ne sais pas combien d'outils permettent de gérer les certificats LE aujourd'hui...

Seul l'adresse example.org est testée avant l'émission du certificat ? Les sous-domaine ne sont pas contacté par LE pour vérification ?

On ne sait pas encore, mais vu que c'est un wildcard il parait impossible de vérifier a priori l'infinité des sous-domaines possibles sous example.org.
Néanmoins, ma crainte n'est pas forcément justifiée : actuellement lors de la vérification d'un domaine, on se repose sur le DNS, soit pour faire pointer un domaine vers une IP qu'on contrôle avec un serveur web, soit en modifiant ou ajoutant une entrée TXT. Dans les deux cas on doit bien contrôler le DNS autoritaire du domaine example.org, donc il est de sa responsabilité de faire pointer les sous-domaines de example.org vers des serveurs qu'on contrôle. Perdre le contrôle du DNS de example.org est tout aussi grave avec ou sans wildcard vis-à-vis de la création de certificats SSL/TLS sur des serveurs qui ne sont pas sous notre contrôle.
Par contre ça donne la possibilité d'avoir du SSL/TLS sans avertissement de sécurité par le navigateur sur un serveur qui n'est accessible que sur un réseau local, avec un DNS local autoritaire sur un sous-domaine inclus dans le wilcard ce qui est impossible actuellement où il faut que le DNS au moins soit accessible sur Internet par les serveurs de Let's Encrypt.

Un wildcard valide le domaine et tous les sous domaines qui en dépendent, sans devoir valider chaque sous domaine. Le domaine ayant la gestion de ces sous domaines.

Dans les procédures les plus “légères” et permissives, tu dois montrer que tu peux gérer le domaine qui fait autorité (typiquement, rajouter une entrée dans la zone DNS, qui n’a aucun effet pour les visiteurs, via le champs TXT).

Les procédures plus contraignantes, ça implique en plus que le whois soit visible et EXACTEMENT pareil que les données du certificats demandé, un KBIS pour les entreprises, un appel téléphonique sur le numéro du whois, photocopie de la pièce d’identité / justificatif de domicile du particulier indiqué en responsable, ect… (tu vas trouver ce genre de chose sur les certificats VE)

Merci, je pensais qu'il fallait renseigner tous les sous-domaines que l'on voulait couvrir par le certificat au moment de sa demande d'émission.

C’est justement bien l’intérêt de ce type de certificat. On peut aujourd’hui (avec Let’s Encrypt notamment) spécifier d’autres domaines pour lesquels peut s’appliquer le certificat avec l’extension SAN. Ça permet de contourner un peu les limitations de Let’s Encrypt, mais c’est contraignant et pas applicable à tous les usages :

If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week. A certificate with multiple names is often called a SAN certificate, or sometimes a UCC certificate.

Je n’avais pas fait attention mais dans le lien d’annonce, il est bien fait mention que les certificats wildcard seront validés via DNS uniquement, au moins au départ.

We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.

Les SAN / UCC sont différents des wildcards, ça permet notamment d’avoir un seul certificats pour des domaines différents (genre monsite.fr, monsite.com et également un domaine tiers qui sert pour un webservice par exemple superapplication.com) Ce sont des certificats multi-domaines, alors qu’un wildcard est un certificat générique au domaine (donc couvre aussi les sous domaines)

En général, les SAN / UCC sont très limités en quantité de domaines différents (contrairement au wildcard / sous domaine), et faut repayer un peu plus à chaque ajout au final. Bon après, la limite, c’est souvent autour des 10 pour les très très bas prix, et régulièrement 100 domaines ailleurs…