URL: https://linuxfr.org/news/reparlons-de-let-s-encrypt
Title: Reparlons de Let’s Encrypt
Authors: gouttegd
 Davy Defaud, bubar🦥, ZeroHeure, Benoît Sibaud, Xavier Teyssier et Nÿco
Date: 2016年02月23日T12:31:06+01:00
License: CC By-SA
Tags: letsencrypt, tls, x509, framasoft et firefox
Score: 82
Let’s Encrypt est une autorité de certification fournissant gratuitement des certificats de type [X.509](https://fr.wikipedia.org/wiki/X.509) pour [TLS](https://fr.wikipedia.org/wiki/Transport_Layer_Security "Transport Layer Security"). Dans le dernier [journal](https://linuxfr.org/users/richarddern/journaux/pourquoi-je-suis-passe-a-let-s-encrypt) où il était question de [Let’s Encrypt](https://letsencrypt.org/), 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](https://letsencrypt.org/) délivrant des certificats par l’intermédiaire du [protocole ACME](https://datatracker.ietf.org/wg/acme/documents/) («_ Automatic Certificate Management Environment _»), tandis que « Letsencrypt » (en un seul mot) désignera le [client ACME officiel](https://github.com/letsencrypt/letsencrypt)._
----
[Journal à l’origine de la dépêche](http://linuxfr.org/users/gouttegd/journaux/reparlons-de-let-s-encrypt)
----
## 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 : 1 _obtenir_ un certificat pour le(s) domaine(s) souhaité(s), et 2 _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](https://community.letsencrypt.org/t/quick-start-guide/1631) (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](https://community.letsencrypt.org/t/drupals-defualt-htaccess-file-breaks-webroot-authentication/3014)) 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.
_[What could possibly](https://community.letsencrypt.org/t/letsencrypt-messed-up-apache2-multidomain-config/11097) [go wrong](https://community.letsencrypt.org/t/all-services-are-down-after-running-letsencrypt/9852)?_> Au passage, le [_disclaimer_](https://github.com/letsencrypt/letsencrypt) 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](https://community.letsencrypt.org/t/list-of-client-implementations/2103). 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.](http://www.la-rache.com/) — 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.](http://www.la-rache.com/), bien sûr, faut pas déconner quand même) [le greffon letsencrypt-ssh](https://git.framasoft.org/gouttegd/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 :
 
```sh
$ 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.com
```
Avec 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](https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status)) 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](http://tools.ietf.org/html/rfc7469). 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](http://tools.ietf.org/html/rfc6698). 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](http://www.postfix.org/TLS_README.html)).> 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](http://tools.ietf.org/html/rfc7469#appendix-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](http://tools.ietf.org/html/rfc7469#section-4.3) _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](http://tools.ietf.org/html/rfc6960). 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](http://tools.ietf.org/html/rfc6066#section-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](http://httpd.apache.org/docs/2.4/mod/mod_ssl.html) 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_](https://certificate-transparency.org/) ([RFC 6962](http://tools.ietf.org/html/rfc6962)). 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](http://tools.ietf.org/html/rfc6962#section-3.3.1), 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_](http://httpd.apache.org/docs/trunk/mod/mod_ssl_ct.html)) ;
* 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_](https://github.com/grahamedgecombe/ct-submit), par exemple), en espérant que l’opérateur du journal accepte de vous redonner le jeton correspondant (la [RFC 6962](http://tools.ietf.org/html/rfc6962#section-3) 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](http://www.netcraft.com/internet-data-mining/ssl-survey/)), 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 ?
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/reparlons-de-let-s-encrypt.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/reparlons-de-let-s-encrypt.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>