Let’s Encrypt est une autorité de certification fournissant gratuitement des certificats de type X.509 pour TLS. Dans le dernier journal où il était question de Let’s Encrypt, des commentateurs ont demandé des retours d’expérience :
On est sur LinuxFr.org, moi je t’aurais surtout demandé « Comment ? ». J’ai l’intention de m’y mettre aussi, mais je n’ai pas encore franchi le pas et j’aimerais avoir des retours d’expérience.
En effet, y a largement matière à s’étendre sur l’utilisation de Let’s Encrypt. Cette dépêche est donc un ensemble pas forcément cohérent de réflexions sur des points divers et variés (sans aucune prétention à l’exhaustivité), agrémentées d’un peu de « retours d’expérience » et de conseils (qui valent ce qu’ils valent).
Convention : « Let’s Encrypt » (en deux mots) désignera l’autorité de certification délivrant des certificats par l’intermédiaire du protocole ACME (« Automatic Certificate Management Environment »), tandis que « Letsencrypt » (en un seul mot) désignera le client ACME officiel.
Sommaire
Principe de fonctionnement de Letsencrypt
La facilité d’utilisation promise par Let’s Encrypt repose en réalité principalement sur le client Letsencrypt et sur l’automatisation qu’il propose.
Letsencrypt s’occupe (ou peut s’occuper) de deux tâches distinctes : ① obtenir un certificat pour le(s) domaine(s) souhaité(s), et ② installer le certificat obtenu.
Pour obtenir un certificat, Letsencrypt :
- génère une paire de clefs et une demande de signature de certificat (Certificate Signing Request, CSR) ;
- envoie la demande à un serveur ACME ;
- répond aux défis d’authentification (challenges) posés par le serveur, permettant au demandeur de prouver qu’il contrôle le(s) domaine(s) demandé(s) ;
- reçoit le certificat signé en retour.
Une fois le certificat obtenu, le client installe le certificat proprement dit, la clef privée correspondante et les certificats intermédiaires là où le serveur Web pourra les trouver, enfin il configure et relance ledit serveur s’il sait le faire (si le serveur en question est Apache HTTP ou nginx, pour l’instant).
Letsencrypt garde aussi une trace des certificats obtenus. Lancé à intervalle régulier, il répétera automatiquement la procédure s’il détecte qu’un certificat est sur le point d’expirer.
En définitive, le but est clairement que l’administrateur puisse mettre en place TLS en une seule commande, avant d’oublier jusqu’à l’existence même de Let’s Encrypt.
Le mode « staging »
Si vous voulez tester Letsencrypt, que ce soit parce que vous n’êtes pas encore sûr de vouloir l’utiliser, parce que vous voulez vérifier s’il fonctionne dans votre configuration (une très bonne idée, parce qu’une des limites de l’automatisation est qu’il suffit parfois de peu de choses pour la faire capoter), ou que vous voulez bidouiller le client, pensez à l’option --staging.
Avec cette option, le client passe par toutes les étapes mentionnées ci‐dessus, mais le certificat obtenu est signé par une pseudo-autorité de confiance (« happy hacker fake CA ») réservée aux tests.
Le principal intérêt est de pouvoir vous livrer à autant de tests dont vous avez besoin, sans vous heurter aux limitations fixées par Let’s Encrypt (notamment, la limite de cinq certificats par semaine pour un domaine donné).
Une fois que votre décision est prise, que vous savez que le client fonctionne comme vous l’attendez, ou que vous êtes satisfait de votre bidouillage, retirez simplement l’option --staging pour demander un certificat auprès de la véritable autorité Let’s Encrypt.
L’authentification HTTP-01
Le protocole ACME propose plusieurs types de défis pour vérifier la légitimité du client sur un domaine. Le plus important pour l’instant est le défi HTTP-01.
Si Alice demande un certificat pour example.com, le défi HTTP-01 consistera pour elle à rendre accessible sur la machine example.com, par HTTP sur le port 80, un fichier .well-known/acme-challenge/token, où token est une valeur aléatoire générée pour l’occasion par le serveur ACME. Le fichier devra contenir le même token, suivi d’un condensat de la clef associée au compte ACME d’Alice.
Le client Letsencrypt se charge normalement tout seul de répondre à ce défi, soit en plaçant le fichier demandé à la racine d’un serveur Web qui, par ailleurs, est déjà en service sur la machine, soit en se plaçant lui‐même en écoute sur le port 80.
Si vous avez déjà un serveur Web opérationnel, vous choisirez probablement la première méthode (la seconde vous oblige à couper temporairement le serveur pré‐existant).
Dans ce cas, assurez‐vous que la configuration actuelle du serveur autorise l’accès à .well-known. Plusieurs applications Web viennent avec un fichier .htaccess qui par défaut restreint l’accès à ce dossier, comme par exemple Drupal (cas rapporté ici) ou Owncloud (testé par votre serviteur).
Avec Owncloud 8.x, la ligne responsable dans le .htaccess est la suivante :
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* [R=404,L]
Elle interdit l’accès, entre autres, à tout fichier ou dossier dont le nom commence par un point. Insérez avant cette ligne une règle autorisant spécifiquement l’accès au dossier des défis ACME :
RewriteRule ^\.well-known/acme-challenge/ - [L]
Je mentionne ce cas pour illustrer ce que j’ai appelé plus haut les limites de l’automatisation : Letsencrypt tente de tout faire tout seul, mais ses développeurs ne peuvent pas tout prévoir et il y a aura toujours des cas où l’administrateur devra aller voir lui‐même ce qui se passe.
Utiliser Letsencrypt ailleurs que sur le serveur de production
Le client Letsencrypt est conçu pour être exécuté directement sur le serveur sur lequel le certificat demandé sera utilisé. Cela au nom de la facilité d’utilisation et de l’automatisation : c’est ce qui permet au client à la fois de répondre aux défis d’authentification, et de configurer le serveur pour utiliser le certificat obtenu.
Le problème que j’ai avec ça, c’est que cela implique donc d’exécuter, sur un serveur de production, un gros morceau de code qui :
- est clairement estampillé BETA SOFTWARE ;
- nécessite les privilèges du super‐utilisateur ;
- manipule directement des clefs cryptographiques ;
- joue avec les paquets installés sur le système ;
- tripatouille les fichiers de configuration des logiciels serveurs.
Au passage, le disclaimer sur l’état du client (« should be tested thoroughly in staging environments before use on production systems »), même s’il est de bon sens, me semble assez décalé par rapport à la cible de Let’s Encrypt. Combien d’administrateurs en herbe ont un serveur de pré‐production ?
Pour ma part, il est simplement hors de question que j’utilise ce client dans ces conditions. Question de principe.
Pour les râleurs utilisateurs dans mon genre, il y a plusieurs solutions.
La première est d’utiliser un autre client que le client officiel Letsencrypt. Ce n’est pas le choix qui manque. Le nom de certains d’entre eux, ou leur façon d’insister sur leur caractère simple, minimaliste (SimpLE, ACME Tiny (~200 lines), a relatively simple bash-script, simplest shell script, a tiny script (~400 lines), lightweight manual-workflow, no magical webserver auto-configuration, etc.) ou le fait qu’ils ne requièrent pas de privilèges (No Sudo Client, obviously runs without root access), me fait dire que je ne suis pas seul à trouver le client officiel un peu bloated.
La seconde est d’utiliser quand même le client officiel (spontanément, j’ai quand même un peu plus confiance dans ce client que dans un script de 200 lignes que je soupçonne d’avoir été pondu à la R. A. C. H. E. — je connais bien ce genre de scripts, pour en écrire moi‐même régulièrement…), mais avec la commande certonly, qui se contente d’obtenir un certificat sans chercher à l’installer, et l’option --manual, qui laisse l’administrateur répondre aux défis d’authentification lui‐même. La combinaison des deux permet d’utiliser le client sur une machine distincte du serveur où le certificat sera utilisé.
Rajoutez encore les options --config-dir, --work-dir et --logs-dir pour changer les dossiers de travail de Letsencrypt (qui par défaut veut absolument écrire dans /etc/letsencrypt, /var/lib/letsencrypt et /var/log/letsencrypt), et le client n’a plus besoin de privilèges particuliers.
Le problème évident avec cette solution, c’est son caractère manuel. « Répondre soi‐même aux défis d’authentification » (c’est‐à‐dire, aller déposer manuellement sur le serveur le bon fichier dans .well-known/acme-challenge, avec la valeur du jeton affiché par le client) est fastidieux et error‐prone, surtout si vous demandez un certificat pour plus de deux ou trois domaines). Et la perspective de devoir recommencer tous les trois mois est peu engageante au possible.
Reste la troisième solution, qui est celle que j’ai choisie : adapter le comportement du client officiel pour avoir les avantages de l’authentification manuelle (pas besoin de lancer le client sur le serveur) tout en permettant une certaine automatisation. Letsencrypt a le bon goût d’être modulaire (les méthodes d’authentification sont implémentées sous la forme de greffons), donc on peut faire ça « proprement » dans un greffon séparé sans aller bidouiller honteusement le code du client comme un sagouin.
J’ai donc commis (à la R. A. C. H. E., bien sûr, faut pas déconner quand même) le greffon letsencrypt-ssh, qui permet de répondre aux défis d’authentification en exécutant un script à travers une connexion SSH.
En définitive, j’invoque Letsencrypt (sur mon poste de travail, pas sur mon serveur) à peu près comme suit :
$ letsencrypt \
certonly \
--config ~/.config/letsencrypt/letsencrypt.conf \
--csr cert.csr \
--cert-path cert.pem \
--chain-path chain.pem \
--fullchain-path cert+chain.pem \
--authenticator letsencrypt-ssh:ssh \
--letsencrypt-ssh:ssh-server root@myserver.example.com \
--domains example.com,www.example.com,nimportequoi.example.comAvec le contenu suivant dans ~/.config/letsencrypt/letsencrypt.conf :
config-dir = /home/alice/.config/letsencrypt
work-dir = /home/alice/.local/share/letsencrypt
logs-dir = /home/alice/.local/share/letsencrypt
email = alice@example.com
non-interactive
agree-tos
cert.csr est la demande de signature de certificat (Certificate Signing Request), générée « classiquement » avec openssl req (voir plus bas pourquoi je fournis moi-même la CSR au lieu de laisser Letsencrypt la générer lui-même — en gros, c’est pour pouvoir gérer les clefs privées à ma guise).
Si la demande est accordée, le résultat est le certificat proprement dit dans 0000_cert.pem, le certificat intermédiaire dans 0000_chain.pem, et la concaténation des deux (directement utilisable avec la plupart des logiciels serveurs) dans 0000_cert+chain.pem (le préfixe nnnn est automatiquement ajouté par Letsencrypt ; il est incrémenté si besoin est pour éviter d’écraser un fichier pré‐existant).
Letsencrypt et l’épinglage des clefs
L’épinglage (pinning) des clefs désigne un ensemble de méthodes par lesquelles un site peut désigner à ses visiteurs les clefs publiques ou les certificats qu’il utilise.
Il y a principalement trois méthodes d’épinglage, qui diffèrent par l’endroit où l’on plante l’épingle.
- Directement dans le code du navigateur. Cette méthode est née quand les développeurs de Chrome ont épinglé les clefs des sites de Google dans leur navigateur, puis s’est peu à peu étendue à la fois à d’autres navigateurs (Firefox à partir de la version 32) et à une poignée d’autres « sites sensibles » sélectionnés manuellement.
Je ne m’étendrai pas davantage sur cette méthode, qui par définition est du seul ressort des éditeurs de navigateurs. Si votre site est suffisamment « gros » ou « sensible » pour être éligible à ce type d’épinglage, vous n’avez pas besoin de ce journal pour savoir ce que vous avez à faire…
Dans les en‐têtes HTTP. C’est le HTTP Public Key Pinning (HPKP), normalisé dans le RFC 7469. C’est la forme la plus répandue d’épinglage aujourd’hui, pour deux raisons : c’est la plus facile à déployer pour l’administrateur du site Web et elle est pleinement prise en charge par Chrome et Firefox. Elle a pour inconvénient de ne pas pouvoir protéger l’utilisateur lors de sa première visite sur le site.
Dans le DNS. C’est le DNS-based Authentication of Named Entities (DANE), normalisé dans le RFC 6698. Cette méthode a le double avantage, par rapport à la précédente, de n’être pas limitée au protocole HTTP et d’être efficace dès la première connexion. Elle a le double inconvénient d’être plus délicate à déployer côté serveur — parce qu’il faut déployer DNSSEC au préalable (si DNSSEC est déjà en place, rajouter DANE par dessus est trivial) — et pas du tout prise en charge nativement côté client (en tout cas par les navigateurs, donc pour HTTP — la situation est plus engageante dans le monde du courrier électronique, avec notamment une pleine prise en charge par Postfix).
DANE permet aussi d’épingler les certificats plutôt que les clefs publiques. Je ne m’attarderai pas ici sur cette possibilité.
Quelle que soit la méthode (notez qu’elles sont combinables, vous pouvez épingler dans les en‐têtes HTTP et dans le DNS), l’épinglage nécessite au préalable de réfléchir à trois questions :
- quelle(s) clef(s) épingler ?
- pour combien de temps ?
- comment gère‐t‐on le changement de clef ?
Quelle(s) clef(s) épingler ?
Vous pouvez épingler la clef de n’importe lequel des certificats constituant votre chaîne de certification, depuis le propre certificat du serveur jusqu’au certificat racine de l’autorité de certification.
Dans le cas de Let’s Encrypt, la chaîne de certification est à trois maillons :
- votre certificat ;
- le certificat intermédiaire
Let’s Encrypt Authority X1; - le certificat racine
DST Root CA X3.
Épingler la clef du certificat racine est à mon avis toujours une mauvaise idée (que ce soit avec Let’s Encrypt ou n’importe quelle autre autorité de certification) : d’une part vous donnez trop de pouvoir à l’AC, d’autre part et surtout, ce n’est pas vous qui décidez à quelle racine votre chaîne de certification va être rattachée. Par le jeu des signatures croisées entre autorités de certification, une même chaîne peut être rattachée à plusieurs racines, et c’est le navigateur qui décide seul comment reconstruire la chaîne globale.
Épingler la clef du certificat intermédiaire n’est pas une mauvaise solution, à condition d’être conscient de deux écueils. D’une part, il est toujours possible que ce certificat intermédiaire change à l’avenir, ce qui casserait votre épingle (un tel changement serait probablement annoncé à l’avance par Let’s Encrypt, mais encore faut‐il se tenir au courant — et il y a aussi le risque d’un changement à l’improviste, en cas de compromission). D’autre part, cela pose un problème épineux lors du choix de la clef de secours (voir plus loin).
Reste l’épinglage de la clef de votre certificat, qui est (vous m’avez vu venir) à mon sens la meilleure solution. C’est à la fois plus sûr (vous vous protégez contre d’éventuelles malversations de toutes les AC, y compris Let’s Encrypt, alors que l’épinglage d’une clef parente vous protège « seulement » contre les AC autres que Let’s Encrypt), et ça vous donne plus de flexibilité quand il s’agit de remplacer la clef — puisque vous décidez à quel moment vous changez de clef, et donc à quel moment vous devez mettre à jour votre épingle.
Malheureusement, cette dernière solution est celle qui ne fonctionne pas out‐of‐the‐box avec Letsencrypt. Par défaut, en effet, le client génère automatiquement une nouvelle clef à chaque renouvellement du certificat, ne vous laissant pas la mainmise nécessaire à la bonne gestion des épingles.
Pas d’obstacle insurmontable, mais il faut renoncer à ce comportement par défaut et prendre en charge vous‐même la gestion des clefs de vos certificats et fournir à Letsencrypt, via l’option --csr, une CSR pré‐générée par vos soins — cela désactive de fait la génération automatique d’une nouvelle clef.
La durée de l’épinglage
Le choix de la durée de l’épinglage (paramètre max-age dans un en‐tête Public-Key-Pins) est dictée par deux considérations :
- une durée trop courte risque de faire perdre le bénéfice de l’épinglage aux visiteurs occasionnels (par exemple, un épinglage de trois jours ne servirait à rien pour quelqu’un qui visite votre site en moyenne une fois par semaine) ;
- une durée trop longue augmente la période d’indisponibilité de votre site si jamais les clefs épinglées venaient à ne plus correspondre aux clefs réellement utilisées pour quelque raison que ce soit (typiquement, une erreur de votre part…).
La RFC 7469, annexe B suggère de commencer par une durée de l’ordre de quelques minutes à quelques heures, puis d’augmenter progressivement cette durée. En gardant à l’esprit que les navigateurs peuvent imposer une borne supérieure, laissée à leur discrétion (mais la RFC suggère environ 60 jours, §4.1).
Pour ma part, j’ai opté pour un alignement avec la durée de validité des certificats délivrés par Let’s Encrypt, soit 90 jours. Mais ce n’est aucunement nécessaire. Souvenez‐vous qu’on épingle ici des clefs (qui sont valables aussi longtemps que vous le décidez) et non des certificats.
Dans le cas de l’épinglage dans le DNS, il n’y a pas d’équivalent explicite au paramètre max-age, mais la période de validité de la signature de l’enregistrement TLSA en tient lieu.
Épinglage et changement de clefs
Quelle que soit la clef épinglée, anticiper son changement est crucial. Si une clef épinglée change subitement sans que l’épingle n’ait été mise à jour à l’avance, les visiteurs ne pourront plus se connecter au site tant que l’ancienne épingle n’aura pas expirée.
Comme il n’est pour autant pas possible de changer une épingle tant que la clef correspondante est toujours utilisée, la seule solution viable est d’épingler en permanence au moins deux clefs : une clef en cours d’utilisation, et la clef qui la remplacera dans le futur.
Ce double épinglage est d’ailleurs formellement obligatoire dans le cas de l’épinglage dans les en‐têtes HTTP : la RFC 7469 interdit aux navigateurs de tenir compte d’un en‐tête Public-Key-Pins qui ne comporterait pas (au moins) une « épingle de secours » (backup pin), c’est‐à‐dire l’épingle d’une clef absente de la chaîne de certification actuelle (§4.3).
Si vous avez choisi d’épingler la clef d’un certificat intermédiaire ou du certificat racine, vous devez maintenant vous demander : quelle clef de secours allez‐vous épingler ? La recommandation dans ce cas de figure est d’épingler une clef équivalente d’une autre autorité de certification — l’autorité vers laquelle vous avez prévu de vous retourner en cas de problème avec Let’s Encrypt.
Si au contraire vous avez choisi d’épingler la clef de votre propre certificat, il vous suffit de générer initialement non pas une mais deux clefs : une que vous utiliserez pour générer la CSR et obtenir un certificat de Let’s Encrypt (et qui se retrouvera donc sur votre serveur) et une dont vous prendrez juste l’empreinte avant de la mettre bien à l’abri (ailleurs que sur votre serveur).
Comme déjà vu plus haut, cela implique de renoncer à la génération automatique des clefs qui est le comportement par défaut de Letsencrypt.
Lorsque vous déciderez qu’il est temps de changer de clef, il vous faudra alors :
- générer une nouvelle CSR à partir de la clef de secours (qui devient la clef « active ») ;
- renouveller le certificat en utilisant la CSR fraîchement générée ;
- générer une nouvelle clef de secours ;
- mettre à jour les épingles pour y ajouter la nouvelle clef de secours (et supprimer l’ancienne clef).
Notez que dès l’instant où vous gérez les clefs vous‐mêmes au lieu de laisser Letsencrypt le faire, rien ne vous oblige à procéder à ce changement à chaque renouvellement du certificat. Vous seul décidez de la fréquence de rotation des clefs (hors le cas où une compromission de votre clef actuelle vous oblige à activer prématurément la clef de secours) : ce peut être à chaque renouvellement (donc tous les trois mois environs), mais aussi un renouvellement sur deux, un renouvellement sur cinq…
Let’s Encrypt et OCSP
Une des principales craintes de l’équipe de Let’s Encrypt sur la viabilité du projet concerne la charge des serveurs OCSP. Délivrer un certificat est un acte unique qui ne coûte pas grand’chose, mais pour chaque certificat délivré, Let’s Encrypt doit être prêt à répondre à quiconque demande si le certificat est toujours valide ou bien s’il a été révoqué, et ce pour la durée de vie du certificat.
C’est l’une des raisons derrière, à la fois, la décision de limiter la validité des certificats à 90 jours (passés ces 90 jours, un client n’a plus besoin de solliciter le serveur OCSP, la date d’expiration suffit à dire que le certificat n’est plus valable), et la décision de limiter le nombre de demandes de certificats à cinq par domaine et par semaine.
Vous pouvez contribuer à alléger la charge pesant sur Let’s Encrypt en configurant votre serveur pour fournir lui‐même les réponses OCSP à vos clients. C’est l’épinglage OCSP (OCSP stapling, RFC 6066 §8).
Le principe est que c’est votre serveur, et non vos clients, qui ira périodiquement s’enquérir auprès du serveur OCSP de Let’s Encrypt (dont l’adresse est mentionnée dans le certificat) de l’état du certificat. À la connexion d’un client, si celui‐ci prend en charge les épingles OCSP (c’est le cas à ma connaissance de tous les navigateurs courants), le serveur lui enverra la réponse OCSP en même temps que le certificat, dispensant ainsi le client d’aller contacter lui‐même le serveur OCSP de l’autorité de certification (réduisant par là non seulement la charge dudit serveur, mais aussi une fuite d’informations sur les sites visités par le client).
À l’heure actuelle, même si vous laissez Letsencrypt configurer automatiquement votre serveur, il n’active pas l’épinglage OCSP. Vous devez donc le faire vous‐même si votre serveur le prend en charge.
Avec Apache 2.4 :
SSLUseStapling on
SSLStaplingCache shmcb:/var/lib/httpd/ssl_stapling(512000)
Reportez‐vous à la documentation du module SSL pour le détail des options SSLStapling*.
Let’s Encrypt et Certificate Transparency
Let’s Encrypt soumet automatiquement les certificats générés à plusieurs opérateurs de journaux Certificate Transparency (RFC 6962). Toutefois, les jetons CT correspondants ne sont pas inclus dans le certificat délivré, et ne sont apparemment pas inclus non plus dans les réponses OCSP.
Cela veut dire que si vous voulez fournir les jetons CT à vos visiteurs, il ne vous reste que la méthode de l’extension TLS, ce qui peut poser deux problèmes :
- votre serveur Web doit prendre en charge l’extension en question, ce qui est le cas de peu de serveurs aujourd’hui, du moins dans leurs versions stables (pour Apache HTTP, il faut la version de développement et le module ssl-ct) ;
- il vous faut récupérer les jetons auprès des opérateurs de journaux, et il ne semble pas y avoir de moyen direct de faire ça — le plus simple est a priori de carrément re‐soumettre vous‐même le certificat (avec ct-submit, par exemple), en espérant que l’opérateur du journal accepte de vous redonner le jeton correspondant (la RFC 6962 autorise ce comportement mais ne l’impose pas, l’opérateur pourrait simplement rejeter votre soumission au motif que le certificat a déjà été ajouté au journal).
Gardez toutefois à l’esprit qu’aucun navigateur n’exige de jetons CT pour valider un certificat. Seul Chrome exige de tels jetons, seulement pour les certificats « à validation étendue » (Extended Validation, EV), et seulement pour afficher la « barre verte » associée à ce type de certificats (sans jetons CT, le certificat est toujours accepté, mais pas comme un certificat EV). Les certificats délivrés par Let’s Encrypt étant Domain-Validated, les jetons CT n’apportent rien de plus.
Au passage, je ne suis pas sûr que les opérateurs de journaux CT voient d’un très bon œil le fait que Let’s Encrypt leur soumettent ses certificats. Les serveurs de journaux ont été dimensionnés pour enregistrer des certificats EV dont le nombre est relativement faible (moins de 5 % de tous les certificats), pas des certificats DV générés par millions et qui plus est renouvelés tous les trois mois…
Let’s Encrypt, initié par l’EFF, Mozilla & L’Université du Michigan, sous le chapeau de l’« Internet Security Research Group » est un projet aujourd’hui rejoint et soutenu par de plus en plus de particuliers (Alex Povli, par exemple), de groupes (IdenTrust et la Fondation Linux, par exemple) et de sociétés (Cisco, Free, OVH, par exemple) permet à tout à chacun à égalité de mettre en œuvre du chiffrement certifié des communications, tout en facilitant grandement la maintenance et la gestion. Let’s Encrypt met aussi un coup de pied dans la juteuse fourmilière des autorités de certifications, en proposant ce niveau de service et cette simplicité d'usage, gratuitement. Allons nous tous passer par let’s encrypt ? Et, à la fin, il ne peut en rester qu’un ?
Aller plus loin
- Journal à l’origine de la dépêche (382 clics)
# Let's encrypt chez OVH ?
Posté par ardechelibre . Évalué à 3.
Le 22 décembre 2015, OVH annonçait son engagement auprès de Let’s Encrypt pour la fourniture gratuite de certificats SSL.
Aujourd'hui le 24 février, toujours aucune nouvelle…
Je comprend qu'ils ne soient pas pressés, car ils vendent 59,99 € le certificat SSL
[^] # Re: Let's encrypt chez OVH ?
Posté par lGuillaume (site web personnel) . Évalué à 10.
Dans un Tweet du 14 février 2016 (https://twitter.com/olesovhcom/status/698985877712797697), Octave Klaba donne quelques informations :
[^] # Re: Let's encrypt chez OVH ?
Posté par ardechelibre . Évalué à 9.
Et aujourd'hui réponse d'@ovh_fr :
# Automatisation mon amour
Posté par Benjamin (site web personnel) . Évalué à 10.
Utilisateur de LetsEncrypt de la première heure, j'ai adoré à quel point ils ont centré ce système sur l'automatisation. Et si le client officiel reste un peu faible sur ces aspects d'industrialisation (dépendances importantes, pas super scriptable, gestion bizarre des renouvellements…) c'est une belle voie pour que tout le monde puisse passer à HTTPS.
Un peu de pub maintenant ;) mais tout est libre, donc pas de regret :D
Pour ceux qui aiment le papier, j'ai écrit un article assez similaire dans le prochain MiscMag Hors série http://www.miscmag.com/ à paraître en mars donc.
Il existe aussi de nombreux clients alternatifs, comme cette classe en pur PHP (à laquelle j'ai participé), avec tests unitaires & injection de dépendance, client ACME permettant de se passer du client python (typiquement on va l'utiliser pour un panel web comme AlternC) ici : https://github.com/octopuce/acmephpc
Enfin pour ceux qui ne veulent pas se prendre la tête, un 10 liner en shell me permet de renouveler sans me prendre la tête les certifs au bout de 60 jours, ajoutez-y un service reload de ce qu'il faut (genre nginx ou apache ou postfix …) et pouf, vous êtes bon pour du TLS partout ! https://github.com/octopuce/octopuce-goodies/blob/master/letsencrypt-renew/letsencrypt-auto-renew.sh
bref, tout ça pour dire : letsencrypt c'est bon mangez en, c'est toujours mieux que l'industrie du vent qu'on nous vendait depuis des années, et cela invite tout le monde à utiliser en masse SSL/TLS !
! Let's encrypt all the things !
[^] # Re: Automatisation mon amour
Posté par Aurélien Jarno (site web personnel) . Évalué à 7.
En pratique le problème du redémarrage du serveur web (et les droits au script pour le faire) est un faux problème. La plupart du temps il y a un service de rotation des logs qui le fait régulièrement. Il faut donc juste être sûr de renouveler le certificat suffisamment à l'avance.
# Let's Encrypt chez moi
Posté par meumeul . Évalué à 9.
m'a permis de passer mes sites perso en https, sans trop faire peur aux gens à cause de l'exception de sécurité !
Webmaster du dimanche, l'installation est plutôt simple, la doc concise et assez efficace.
Côté client, il est super lent (je le fais tourner sur un raspberry pi qui se tape déjà node.js…), mais passé la demni journée de mise en place, on ne l'appelle pas souvent..
# Le client simp_le
Posté par Julien Wajsberg . Évalué à 10.
De mon côté, j'ai implémenté Let's Encrypt en utilisant le client simp_le. J'ai confiance dans ce client alternatif tout simplement parce que son auteur est aussi l'auteur du client officiel…
Merci pour l'article complet, y compris sur les sujets comme HPKP qui sont moins bien traités habituellement.
[^] # Re: Le client simp_le
Posté par _alex . Évalué à 2.
Merci pour le lien, pour le coup c'est vraiment simple sans tout un tas de dépendances et ça fonctionne sur une debian wheezy alors que le client officiel ne fonctionne pas.
# freebox & let's encrypt
Posté par Phil3556 . Évalué à 5.
Bonjour,
n'est ce pas de la production : un déploiement sur les freebox ?
cf http://www.universfreebox.com/article/33405/Free-supporte-le-projet-Let-s-Encrypt
et
http://www.nextinpact.com/news/98328-freebox-os-3-3-prise-en-charge-lets-encrypt-et-corrections-bugs.htm
[^] # Re: freebox & let's encrypt
Posté par Arthur Accroc . Évalué à 1.
Ce serait bien s’ils le proposaient aussi pour les pages web des utilisateurs…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# limitations
Posté par RD . Évalué à -6.
Le fait de devoir laisser la clef privée Let's Encrypt sur le serveur (ce qui peut être contourné)
+ la limitation des certificats à 90 jours
+ la limitation des challenges ACME aux ports 80 et 443
sont des points noirs qui paraissent être des limitations arbitraires plutôt idéologiques que techniques.
J'aurais vraiment préféré que Mozilla et l'EFF mettent leur (notre ?) pognon dans une vrai root CA alternative (CACert).
[^] # Re: limitations
Posté par Zenitram (site web personnel) . Évalué à 2.
Hein?
C'est voulu et la raison expliquée.
Ca gène en quoi?
Ha ha ha.
(Désolé, mais là c'est énorme comme blague)
[^] # Re: limitations
Posté par gouttegd . Évalué à 6.
Ce n’est pas clair, mais je pense qu’il parle de la clef privée de ton compte ACME.
Cette clef est générée automatiquement par le client à la première invocation, et stockée sous
CONFIGDIR/accounts/. Elle est utilisée ensuite lors des échanges entre le serveur ACME et le client (ce dernier signe la demande de certificat avec sa clef privée avant de l’envoyer au serveur ACME).Cette clef ne sert qu’à obtenir le certificat et n’a, en principe, rien à faire sur le serveur (ne pas confondre avec la clef privée du certificat, qui bien sûr doit être à disposition du logiciel serveur).
Si cette clef est sur le serveur, c’est parce que le client Letsencrypt lui-même est supposé fonctionner sur le serveur, au nom de l’automatisation.
[^] # Re: limitations
Posté par Kerro . Évalué à 4.
En étant plus précis :
La clef privée est accessible à la machine qui renouvelle le certificat.
Donc si on veut faire simple, on met le programme de renouvellement sur le serveur, donc la clef privée aussi.
Mais on devrait en principe renouveller depuis une machine sécurisée, qui transmet ensuite la clef publique au serveur. Ça coûte un scp puis un ssh (ou via un POST HTTP mais il faut coder le truc).
[^] # Re: limitations
Posté par claudex . Évalué à 4.
Il faut aussi rediriger les requête
.well-known/acme-challengevers la machine hébergeant la clef (ou qu'elle puisse écrire un fichier sur l'autre serveur ou…)« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: limitations
Posté par ɹǝıʌıʃO . Évalué à 3.
Comme je le disais sur le journal à l’origine de la dépêche, ça marche très bien en montant le webroot du serveur web sur le serveur qui exécute letsencrypt par sshfs. L’intérêt de sshfs est de ne pas avoir à mettre en place sur le serveur web autre chose que ce qu’il faut pour ssh. Montage, exécution de letsencrypt, copie du certificat, démontage, et c’est réglé.
[^] # Re: limitations
Posté par claudex . Évalué à 3.
C'est ce que je disais dans mon message
Cela augmente un peu la charge de travail quand même (gestion des clefs pour qu'il puisse monter son sshfs, vérifier qu'il ne puisse pas lire/écrire n'importe où, sans doute configurer un Alias côté serveur…)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: limitations
Posté par gouttegd . Évalué à 10.
Il y a au moins deux raisons techniques à cela :
La liste des défis n’est pas définitive. Par exemple, le défi DNS (« prouve-moi que tu contrôles ce domaine en publiant cette valeur dans la zone correspondante »), que beaucoup d’utilisateurs réclamaient depuis le début, est disponible depuis fin janvier (du côté de Let’s Encrypt, pas encore dans le client officiel).
# Let's Encrypt
Posté par microlinux (site web personnel) . Évalué à 8.
J'utilise Let's Encrypt depuis que c'est passé en beta publique en décembre dernier. Tous mes serveurs tournent sous Slackware, ce qui fait que j'utilise le client "standalone". À noter que ce client "standalone" ne tripatouille pas les fichiers config des serveurs. Tous les fichiers résultant des opérations de génération de certificat se trouvent en-dessous de l'arborescence /etc/letsencrypt. Après, suffit d'éditer les fichiers à la main.
Ça marche à peu près correctement, avec quelques petits hoquets de temps en temps. Suffisamment bien en tout cas pour gérer quelques hébergements HTTPS. Perso, j'en suis très content. Plus la peine de sauter à travers des cerceaux en feu avec StartSSL.
Dyslexics have more fnu.
# Des coquilles
Posté par Astaoth . Évalué à 4. Dernière modification le 25 février 2016 à 20:41.
Permets moi d'en douter :
* "--certonly" n'est pas une option valide, c'est d'ailleurs une commande, donc sans le "--"
* "--csr" n'est pas une option valide chez moi
Vu l'absence de man, l'absence de contenu avec le paramètre "--help" et l'absence de précision dans la doc officiel sur https://letsencrypt.readthedocs.org/en/latest/using.html , comment est-ce qu'on trouve les options disponibles ?
Emacs le fait depuis 30 ans.
[^] # Re: Des coquilles
Posté par gouttegd . Évalué à 8.
Exact, c’est une commande et non une option, autant pour moi. Si un modérateur pouvait modifier la section correspondante pour enlever les deux tirets devant…
Elle existe pourtant bel et bien, mais elle ne fonctionne qu’avec la commande
certonly.[^] # Re: Des coquilles
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
[^] # Re: Des coquilles
Posté par microlinux (site web personnel) . Évalué à 3.
J'ai pas mal expérimenté, et voici les scripts que j'utilise.
http://www.microlinux.fr/microlinux/template/letsencrypt/
Dyslexics have more fnu.
# Debian Jessie / backport
Posté par mazarini . Évalué à 3.
Let's Encrypt est dispo sur Jessie dans le dépôt backport.
Si le paquet du greffon apache (python-letsencrypt-apache) est installé, un simple "letsencrypt --apache" permet le paramétrage et la création du certificat.
L'ajout d'un cron pour le renouvellement et ca doit rouler.
[^] # Re: Debian Jessie / backport
Posté par Marc Quinton . Évalué à 2. Dernière modification le 29 février 2016 à 13:41.
ha zut …
[^] # Re: Debian Jessie / backport
Posté par mazarini . Évalué à 1. Dernière modification le 29 février 2016 à 14:17.
apt-get -t jessie-backports install python-letsencrypt-apache
(installer également letsencrypt s'il ne viens pas par dépendance)
A priori, le "pinning" par défaut ne permet que les maj et les installations, pas les installations par dépendance.
[^] # Re: Debian Jessie / backport
Posté par freem . Évalué à 3.
Exact, pour éviter de backporter tout le système par accident, seuls les paquets backport installés volontairement et explicitement sont installés et où mis à jour (à noter que ça n'a rien à voir avec le marquage manuel/automatique).
C'est pour ça qu'avoir un paquet installé en stable n'est pas mis à jour vers sa version backportée automatiquement, malgré que la version soit plus récente.
M'enfin, le système de priorités et de pinning de Debian est pas simple a comprendre, perso a un moment je jouais avec mais maintenant j'évite autant que possible: trop de prise de tête pour pas grand chose, c'est limite plus simple de faire les paquets soi-même à partir du paquet source (sauf que du coup les MàJ auto on les a plus, bien sûr, d'où le "limite")…
# Est ce une solution Certification pour objets connecté avec interface web et adresse IP paramétrable
Posté par trancheX . Évalué à 3.
Je pose ma question à 3 sous ici, car je ne suis pas un expert en certification TLS et j'ai bon espoir que les personnes venant lire cette news en soient (des experts ou au moins des personnes ayant mis en place du https, ce qui n'est pas mon cas).
Si je vends un objet connecté disposant d'une interface web de configuration, qu'il est possible pour l'utilisateur de changer l'adresse IP et pourquoi pas de le placer derrière un DNS.
De ce que je comprends pour ne pas avoir dans le navigateur le message de connexion https non vérifiée qui fait fuir les utilisateurs, il faut obtenir un certificat auprès d'un organisme reconnu et utilisé par les navigateur web.
Le hic c'est que le certificat délivré par l'organisme est associé à un DNS unique, hors mon objet connecté est paramétrable.
Y a t'il une solution existante pour avoir du https transparent pour l'utilisateur (pas de message de certificat inconnu) pour ce cas d’utilisation ? J'ai l'impression que non, mais à tout hasard mieux poser cette question d'abord.
J'ai l'impression que la seule solution serait de laisser la possibilité à l'utilisateur d'uploader des certificat sur le dispositif.
Du coup vu que let's encrypt à l'air automatisable c'est peut être un bon candidat pour intégration direct dans mon dispositif (arrêtez moi si je me trompe) ce qui serait peut être encore plus simple pour l'utilisateur.
Question subsidiaire : peut on faire un certificat pour une adresse IP (voire adresse IP locale) et non un DNS ?
Question subsidiaire2 : si quelqu'un sait comment ceci est géré sur les switch configurable avec interface web (genre les CISCO d'entreprise ou autre truc bien sérieux/chère) ?
Merci d’avance, désolé pour la question un peu décousue et juste un tout petit peu en lien avec let’s encrypt
[^] # Re: Est ce une solution Certification pour objets connectés
Posté par gouttegd . Évalué à 7.
À part obtenir, de la part d’une CA reconnue, un certificat intermédiaire autorisé à signer des certificats finaux sans limitation, je ne vois pas.
Seulement si le dispositif en question est accessible depuis l’Internet (pour qu’il puisse répondre aux défis d’authentification posés par le serveur ACME).
Pas avec Let’s Encrypt. Et en théorie, pour une adresse IP locale (je suppose que tu veux dire par là une adresse privée au sens du RFC 1918), ce n’est possible avec aucune autorité de certification : les consignes du CA/Browser Forum leur interdisent d’émettre des certificats pour des adresses privées (mais il y a déjà eu des CA qui ne se sont pas privées de le faire…).
Aucune idée. Si je devais deviner, je serais enclin à dire que c’est géré comme suit : « on s’en fout, c’est prévu pour être utilisé sur le réseau local donc pas d’HTTPS et puis ça ira. » Mais je suis (sûrement) mauvaise langue, aucune entreprise n’oserait se moquer de ses clients comme ça…
[^] # Re: Est ce une solution Certification pour objets connectés
Posté par trancheX . Évalué à 1.
Merci pour la réponse détaillée, c'est très instructif.
Ça serait la solution la plus simple.
Si je comprend bien c'est justement comme cela que fonctionne let's encrypt : les certificats issus de let's encrypt sont signés par identTrust qui est reconnu par les navigateurs; ce qui permet que let's encrypt même tout jeune soit lui aussi reconnu par les navigateurs. J'ai bon ?
Mais j'imagine que d'obtenir ce type de certificat est hors de prix ?
…
Pour la suite je fais des précisions/réflexions issue de mes recherches faites depuis (mais vous pouvez me corriger si je fais fausse route) :
Après quelque recherches j'ai trouvé quelqu'un qui a posé exactement la même question que moi sur stackoverflow et la réponse qui y est faite est qu'une adresse IP peut être utilisé à la place d'un hostname (RFC 2818). Mais effectivement il ne précise pas le type d'IP et les "Private Address Space" font sûrement exception.
Je suis certain que je vais avoir des clients qui vont utiliser des IP du coup pour les IP publiques ça devrait être bon, mais pas les privées.
Donc, pour mon dispositif l'idéal serait que le client puisse :
1. Installer ses certificats sur le dispositif (que le dispositif utilisera pour signer son certificats https). En fait j'ai découvert depuis que les switchs hp et cisco font comme ça.
2. Pour rendre l'utilisation du SSL plus simple pour l'utilisateur je pense implémenter un client let's encrypt (ça marche à la condition que mon dispositif soit mis en place de sorte qu'il soit accessible depuis internet)
Le point 2 ça serait vraiment la "classe à Dallas", et du coup j'ai regardé le principe de fonctionnement de let's encrypt à l'air plutôt simple. Mais par contre les clients let's encrypt ont l'air assez complexe… parce qu'ils automatisent tout et font la config de apache/nginx.
Et la limite du port 80 pour l’authentification HTTP-01 risque d'être gênante : je vois pas mal de nos clients utiliser des ports complètement exotique pour faire une redirection publique sur leur dispositif, du coup pas de let's encrypt pour eux.
Je pensais pouvoir faire du https simplement depuis que ARM avait rendu libre PolarSSL, mais je découvre que la certification est peut être un problème plus ardu a bien intégrer.
[^] # Re: Est ce une solution Certification pour objets connectés
Posté par gouttegd . Évalué à 3. Dernière modification le 07 mars 2016 à 18:53.
Oui.
Il n’y a généralement pas de prix affiché. Et pour cause, les CA ne sont pas supposées délivrer ce genre de certificats intermédiaire à la légère. Ça doit se négocier au cas par cas, ce n’est pas le genre de certificats que tu commandes en passant par un simple formulaire web.
Pour paraphraser je ne sais plus qui : « si tu dois demander le prix, c’est que tu ne peux pas te le payer ».
Il faut distinguer plusieurs choses :
En l’espèce, un certificat X.509 peut parfaitement être associé à n’importe quelle adresse IP (privée ou non). Mais le CA/Browser Forum interdit aux CA d’émettre des certificats associés à des adresses privées, et Let’s Encrypt va plus loin en décidant de n’émettre que des certificats associés à des noms de machine.
[^] # Re: Est ce une solution Certification pour objets connectés
Posté par trancheX . Évalué à 0.
OK, merci pour la précision sur les IP, j’étais passé à côté de tout ça.
Du coup laisser à mes clients la possibilité de mettre en place leurs certificats et être capable de convenir aux power-user tout comme aux clients ayant moins de connaissance réseau va être un défit plus subtile que simplement mettre en place SSL dans le dispositif…
[^] # Re: Est ce une solution Certification pour objets connecté avec …
Posté par Frédéric Blanc . Évalué à 3.
Le plus souvent : un certificat auto-signé qui aura été, dans le meilleur des cas, auto-généré par le périphérique (comme son couple clef privée/publique), et dans le pire, généré (de même que les clefs) en usine et partagé par toute une (la) gamme de produit du constructeur.
Dans l'idéal, le périphérique devrait accepter de se voir installer le(s) certificat(s) racine(s) de votre propre autorité de certification, que vous utiliseriez pour signer un certificat correspondant au couple clef privée/publique auto-généré par le périphérique. Ce même certificat racine serait utilisé pour vérifier les certificats clients installés sur les navigateurs se connectant à l'interface d'administration. Mais je ne crois pas que beaucoup de constructeur fasse comme cela…
[^] # Le titre est trop long
Posté par claudex . Évalué à 6.
C'est tout à fait possible dans la plupart de ce genre de switch. Par exemple pour un Cisco Nexus 7000 (premier trouvé) http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_nx-os-cfg/sec_pki.html
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le titre est trop long
Posté par trancheX . Évalué à 1.
Merci, ça peut être intéressant de regarder comment ils ont fait pour faire pareil … par contre les prix du nexus 7000 ouch !! Je pensais pas que ça existait des équipements réseau à ce prix.
Sinon les HP procurve ont de l'https activable aussi
[^] # Re: Le titre est trop long
Posté par claudex . Évalué à 3.
Ah ben, c'est toi qui a demandé un truc bien cher
(mais c'est loin d'être ce qu'ont trouve le plus cher en équipement réseau)
Comme je l'ai dis, j'ai pris la première doc trouvée mais la plupart des fabricants le permette. Si tu veux du moins cher, il y a Mikrotik avec sa gamme CRS qui permet aussi de configurer son certificat.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le titre est trop long
Posté par trancheX . Évalué à 0.
Juste une question subsidiaire sur Mikrotik que je te remercie de me faire découvrir :
As tu des retours d'expérience sur cette marque, en utilisant des switchs POE : est ce fiable ?
On a eu quelques problèmes avec pas mal de marques, souvent pas cher, ce qui exclu Cisco et Hp : ports POE tombant en panne, alim qui lâche étaient des problèmes arrivant rarement (mais trop souvent).
[^] # Re: Le titre est trop long
Posté par claudex . Évalué à 4.
Personnellement, je n'ai pas de switch POE, mais ceux que j'ai entendu en avoir ne sont pas encore plain de problèmes similaires.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.