Le service, qui permet de disposer de certificats de chiffrement gratuits pour favoriser l'extension de l'accès sécurisé aux sites (HTTPS), vient de passer une grande étape.
En effet, le protocole ACME, au cœur de son fonctionnement, passe en v2, Plusieurs améliorations sont présentes, dont le support des certificats wildcard, valables pour une infinité de sous-domaines pour un domaine donné.
De quoi faciliter la vie de certains éditeurs de sites et favoriser un peu plus l'utilisation de Let's Encrypt.
Commentaires (26)
#1
le support des certificats wildcard
ça va pleurer chez les autorités payantes de certification. revendez vos actions…
#2
Let’s encrypt est vraiment une super initiative !
" />
Selon les dernières stats de mozilla, pas loin des 3⁄4 des pages chargées sont maintenant en protocole chiffré
#3
#4
Et même… Pour les TPE, les particuliers, les gens qui savent pas trop, ceux qu’on pas trop les moyens… c’est super. La règle c’est le site certifié maintenant, et puis ça permet réinjecter un peu plus de confiance sur le net.
C’est tout bon.
#5
#6
Quand je vois les navigateurs mettre de plus en plus le HTTP de côté et considérer HTTPS comme la norme, je me dis, heureusement que Let’s Encrypt existe… autrement beaucoup de sites seraient menacés (même si le fait que Let’s Encrypt existe est sûrement la raison pour laquelle les navigateurs ont tout accéléré depuis 2 ans ^^)
" />
Autrement, bien entendu c’est une excellente nouvelle, c’était selon moi la seule chose qui manquait à Let’s Encrypt. Pour le coup on peut vraiment les remercier car sans eux le web ne serait pas le même
Pour autant, je ne pense pas non plus que cela sonne le glas des autorités payantes, il faut toujours passer par elles pour obtenir un certificat plus “sûr” (du type : nom de la société affiché dans la barre d’URL), car cela requiert une vérification un peu plus poussée qu’un simple challenge avec l’API ACME. C’est donc toujours utile pour les entreprises (qui ont sûrement aussi besoin d’un support commercial à côté)
#7
#8
Je n’ai jamais compris pourquoi la partie chiffrement devait être avec à la partie “confiance”.
À part pour racketter en masse…
Let’s Encrypt a fait beaucoup de bien pour le web depuis son apparition, heureusement qu’on a ce genre d’initiative.
Le wildcard était vraiment LE gros manque de la plateforme, gérer les sous domaines de manière automatisée c’était vraiment compliqué !
#9
C’est exactement la question que je me posais : le certificat SSL est facilement accessible (et c’est tant mieux), donc également pour les concepteurs de sites malveillants.
Y-a-t-il un mécanisme qui permet de s’en prémunir ? Du genre révoquer les certificats des sites considérés comme frauduleux ?
#10
“révoquer les certificats des sites considérés comme frauduleux ?”
Surtout pas. La seule chose qu’un certificat HTTPS est censée garantir (hors validation étendue), c’est que ta connexion est bien chiffrée sans man-in-the-middle entre le client et le serveur correspondant au nom de domaine. Les autorités de certification n’ont pas vocation à faire la police, d’autant plus que, avec les initiatives de Google et dans une moindre mesure de Mozilla, le certificat HTTPS va bientôt devenir indispensable pour mettre un site en ligne.
#11
#12
Je suis un peu novice sur l’usage de Letsencrypt.
Si j’ai bien suivi il faut un client sur le serveur qui va faire la validation du certificat avec le serveur de Letsencrypt, genre un Certbot sur Gnu/linux (Debian 8⁄9 dans mon cas).
Comment ça se passe pour un wildcard ? on peut généré le certificat sur un serveur, puis le récupérer et l’installer sur un autre ou faut forcément passer par un client compatible ?
J’ai par ex le cas là d’un serveur web debian/apache et d’un serveur exchange 2016 / sur win 2012 R2, actuellement j’ai un certificat pour chaque sous-domaine (dont celui pour exchange qui nous coûte une blinde à chaque fois).
Si je peux générer un certificat wildcard depuis l’un des serveur et l’appliquer à tous les autres ce serait un sacré progrès :)
#13
Le but d’un certificat SSL de base c’est uniquement de permettre une connexion sécurisé. Ce n’est pas parce qu’il y a un petit cadenas vert que le site est de confiance.
Pour ça il y a les certificats EV (que ne propose pas LE, et sur lesquels les autorités de certif vont pouvoir continuer à se faire du beurre). EV pour Extended Validation, l’autorité est censée avoir vérifié pas mal de choses avant de délivrer ce genre de certificats. Avec ce type de certifs généralement ton navigateur t’affiche le nom de la boite détenant le certificat, dans un cadre vert à côté du cadenas TLS.
#14
Partager un même certificat sur différents serveurs est une TRÈS mauvaise pratique… La clé privée fuite, ce sont tous tes serveurs qui sont compromis.
#15
Wildward….
" />
#16
#17
Pas forcément. Tu as aussi le cas ou sur le même serveur tu héberge app1.xxx.com et app2.xxx.com et app3.xxx.com etc… et dans ce cas tu as besoin de demander à LE des certifs pour app1 app2 et app3. Sauf que le jour ou tu installes app4.xxx.com sur ce même serveur, comme tu n’as pas de wildcard, ton sous domaine n’est soit pas sécurisé soit tu dois refaire une nouvelle demande à LE.
La avec la wildcard au moins dès que tu installes ou vire un sous-domaine, ton certif reste bon.
#18
#19
#20
Un exemple rapide (il y en a probablement d’autres).
Si un jour tu veux déplacer app1.xxx.com sur un autre serveur, une mise à jour DNS + transfert/copie du certificat SSL et c’est fait.
Si tu es xxx.com/appX, toutes tes apps ont le même point d’entrée : xxx.com. Tu es donc dépendant de ce DNS. Si il tombe, tout tes services qui sont derrières tombent en même temps.
#21
#22
C’est pas vraiment une question de DNS qui tombe. Tu peux faire de la redondance entre DNS sur un unique NDD (donc sécurité même avec toto.com/app1…), ou tu peux mettre 45 sous-domaines sur le même DNS sans redondance (donc tout tombe si le DNS tombe).
C’est une souplesse si jamais on envisage plus tard de répartir les apps sur différents serveurs (et encore, avec du reverse proxy, on peut le faire même avec le modèle toto.com/app), et c’est un aspect cosmétique (j’ai l’impression que la plupart des boites préfèrent communiquer sur app.entreprise.com que sur entreprise.com/app).
#23
Ah nan c’est sûr, mais c’est pas le but du chiffrage des échanges. Ça permettra au moins pour les sites certifiés et honnêtes de ne pas être vus comme des “pirates” chinois par madame Michu parce que son navigateur lui affiche un gros message rouge “Attention, connexion dangereuse”.
L’effet pervers c’est, effectivement, que la vigilance baisse sur les sites certifiés.
#24
Oui mais non, dans une entreprise tu peux avoir bu.company.com, bu2.company.com, etc.
Perso sur mon NAS, j’ai séparé ainsi les différentes fonctions (transfert de fichiers, videos, etc.)
#25
Ne pas oublier que du SSL/TLS ça s’intercepte et que pour le voir (quand c’est bien fait) ça réclame d’être super vigilant.
db
#26
Quand c’est gratuit c’est toi le produit faut pas l’oublier.
" />
Il ont inventé Let’s encrypt pour pouvoir savoir ce qu’il transite sur ton site, si jamais il estime que tu fais partis d’extrémistes
Enfin bref, la news date quand même un peu personne verra mon message