Alors que Let's Encrypt peut être utilisé par tous afin de générer des certificats SSL/TLS, des hébergeurs vont commencer à proposer une intégration directement aux sein de leurs offres dès les premiers jours de 2016.
Le projet Let's Encrypt est désormais en bêta publique. L'occasion pour les premiers utilisateurs de sauter le pas, mais aussi pour les premiers partenaires de faire preuve de leurs intentions de manière plus ouverte.
Let's Encrypt : automatisation et gratuité des certificats
Pour rappel, Let's Encrypt vise à simplifier la création et l'installation d'un certificat SSL/TLS gratuit sur un serveur, pour une durée de trois mois (renouvelable). De quoi permettre à chacun de proposer des connexions sécurisées, afin de chiffrer les contenus échangés, de s'assurer de l'identité du serveur et d'éviter que le contenu ne soit altéré.
Cela passe par la mise en place d'une nouvelle autorité de certification (Boulder, développé en Go), mais aussi d'un protocole spécifique en voie de standardisation (ACME) et un client open source (pouvant être remplacé). La vérification de l'identité est assez basique et l'ensemble du processus est automatisé. Une sorte de croisement entre StartSSL (pour l'aspect gratuit) et SSLMate qui avait introduit une automatisation assez intéressante du processus d'achat et d'acquisition des certificats SSL.
Néanmoins Let's Encrypt va tout de même un peu plus loin et se propose de s'occuper de la mise en place du certificat au sein de la configuration de votre serveur (Apache, ou Nginx de manière expérimentale).
Conférence SSL/TLS de Benjamin Sonntag -Il était une fois internet (Licence CC BY-SA 3.0)
Des hébergeurs vont sauter le pas d'ici quelques jours
De quoi séduire de nombreux acteurs qui voudraient chercher à simplifier la mise en place de certificats SSL/TLS pour leurs clients. Mais les premiers à sortir du bois pourraient bien être les hébergeurs.
En effet, dans le cadre de la rédaction d'un article sur Let's Encrypt, nous avons pu apprendre qu'au moins trois acteurs allaient sauter le pas dès les premiers jours de 2016 : Gandi, Infomaniak et OVH. Un l'a déjà fait depuis le début du mois : Planet-Work (c'est actuellement en phase de test, ce qui explique l'absence de mise en avant sur le site).
Gandi nous a ainsi confirmé ce matin travailler actuellement à « une intégration facilitée de Let’s Encrypt » pour ses clients. Une annonce devrait ainsi intervenir dès le mois de janvier sur les modalités exactes. Pour rappel, Gandi propose déjà à ses clients qui achètent un domaine de disposer d'un certificat SSL sans surcoût la première année (12 euros HT par an ensuite).
Infomaniak est de son côté un sponsor officiel de Let's Encrypt. La société avait d'ailleurs annoncé dès octobre dernier quelle allait proposer à ses clients de bénéficier gratuitement d’un certificat SSL délivré par la nouvelle autorité. L'intérêt est là aussi dans la procédure simplifiée puisque tout se passe à travers la console principale « par un simple clic ». De quoi remplacer la procédure actuelle permettant simplement d'obtenir un certificat auto-signé.
Annoncée pour décembre, cette fonctionnalité devrait finalement être mise en place sous peu selon nos informations. Il nous a ainsi été confirmé que le lancement était imminent et que les derniers détails sont en train d'être mis en place, notamment au niveau de la documentation.
OVH, enfin, a indiqué il y a quelques jours à travers un communiqué de presse être désormais un sponsor officiel de Let's Encrypt. Mais il n'était pour autant pas question d'une intégration à l'offre de l'hébergeur, qui propose actuellement des certificats pour un peu moins de 50 euros HT sur son site.
Mais là encore, nous avons pu avoir la confirmation que des certificats seraient intégrés aux offres d'hébergement web dès le courant du mois de janvier. Les modalités exactes restent à découvrir, mais tout devrait aller très vite.
Let's Encrypt obtient des résultats, mais va encore devoir évoluer
Si l'initiative Let's Encrypt n'est ainsi pas la première à vouloir proposer des certificats SSL/TLS gratuits ou de manière bien plus automatisée que la moyenne, sa capacité à fédérer un grand nombre d'acteurs et sa conception basée sur des standards et un client open source semblent donc réussir là où d'autres avaient échoué auparavant (notamment CACert).
Elle arrive ainsi à fédérer les hébergeurs sur la mise en place de certificats gratuits et automatisée, alors que rares étaient les acteurs qui osaient aller dans ce sens jusqu'à maintenant. De quoi faire des certificats de base la norme pour l'hébergement, chacun étant libre ensuite de monter en gamme, et d'aller jusqu'aux certificats à validation étendue (et leur fameuse barre verte).
Cela devrait contenter les acteurs qui poussent à une utilisation massive de HTTPS, Google en tête, mais ils sont de plus en plus nombreux. Reste maintenant à ce que d'autres suivent le chemin, comme les éditeurs de solutions d'auto-hébergement ou les fabricants de NAS par exemple. Il faudra aussi que Let's Encrypt continue son évolution et sorte de sa phase de bêta, notamment pour renforcer ses paramètres par défaut qui peuvent être critiqués, mais aussi afin de supporter un nombre croissant de plateformes.
Commentaires (72)
#1
le seul petit bémol de la beta: ce n’est pas full auto: le programme (sous linux) demande encore quelques validation manuelles afin de générer le/les certificats.
d’ailleurs, pour ceux qui voudrait automatiser un peu le bouzin quand même, la commande linux pour vérifier si un certificat est toujours valide (à un jour près):
openssl x509 -checkend 86400 -noout -in certificat.pem
le checkend est en secondes
#2
Tu entends quoi par “full auto” ? Le fait qu’il faille remplir 2⁄3 champs dans des champs (mail, domaine, etc.) ? Après, l’intérêt c’est surtout de voir d’autres clients émerger, je pense que c’est là dessus que se basent les hébergeurs.
https://community.letsencrypt.org/t/list-of-client-implementations/2103
#3
le fait qu’il demande de dire si oui ou non, tu veux remplacer le certificat,
qu’il en profite pour te rappeler les règles (pas plus de 5 domaines / 7 jours) et éventuellement te prévenir si ton certificat est toujours valide.
en gros tu peux pas faire un script dans un cron (enfin, si on pourrait mais c’est un peu crade) si le système attend un “yes” de ta part à un moment donné.
#4
#5
Si si tu peux lancer une commande complète pour que ce soit tout automatique (il ne restera plus qu’à relancer les serveurs utilisant le certificat).
Par contre il manque toujours l’auth via DNS qui pourrait être bien plus sympa que par http.
#6
quel est l’intérêt a ce que tous les sites ou presque soit en HTTPS?
#7
Le même que de porter des vêtements dans la rue " />
#8
De quoi permettre à chacun de proposer des connexions sécurisées, afin de chiffrer les contenus échangés, de s’assurer de l’identité du serveur et d’éviter que le contenu ne soit altéré.
Cool. Je pourrais enfin me connecter à “nextimpact.com” sans avoir ce popup ennuyeux. Le cadenas me garantira une totale sécurité. " />
#9
Faudrait qu’on pense à officialiser un “Point à quoi ça sert” sur les papiers HTTPS (un peu comme le #RTFN pour Read The Fucking News)
#10
Comme avec le responsive, c’est grâce (ou à cause c’est selon) de Google qui pousse via son algorithme de privilégier tel ou tel site, sinon le HTTPS aurait mis quelques années de plus pour émerger majoritairement sur les sites. D’ailleurs quand la mesure de privilégier le responsive à été mis en place, en quelques mois, de nombreux sites y sont passés, alors que c’était hors de question avant …
#11
Même si Google mérite d’être cité dans ce cas là, c’est surtout grâce à Snowden que la mise en place de HTTPS est de plus en plus présent ;-)
#12
Oui et non, pour une adoption massive, ça ne change rien. Le ranking Google va pousser la grosse majorité des éditeurs à bouger rapidement sous peine de se perdre leur positionnement (et donc inciter les régies, les agences et les clients à se bouger un peu le cul, ce qui n’est pas vraiment gagné " />)
#13
#14
Disons que Bootstrap a facilité la mise en place pour certains et que Google a motivé les sites à sauter le pas. Comme dit plus haut, à partir du moment où certains entendent “respectez cette règle ou vous aller vous casser la gueule dans les SERPs”, des trucs qui pouvaient prendre des années ne prennent plus que quelques jours/semaines ;)
#15
#16
#17
#18
#19
avec le client officiel? moi j’ai toujours une demande de confirmation…
avec un client alternatif, ça sera peut-être plus automatisable…
#20
Google a poussé à la version mobile disponible, avec outil de vérification et tout le toutim habituel. Après le responsive c’était la politique “recommandée” historiquement par Google dans ses docs, mais pas forcée :)
#21
#22
#23
#24
Il est tout à fait possible de faire un Full auto.
Il suffit de suivre le RTFM…
Je le fais actuellement sur deux serveurs avec deux configs différentes. l’une via l’installeur apache l’autre en manuel.
Voici un exemple pour apache :
./letsencrypt-auto –apache -d exemple.com–rsa-key-size 4096 –redirect –hsts –duplicate
Cette commande te renouvelle automatiquement ton certificat sans clic à faire.
Ensuite tu peux mettre cette commande en crontab ou autre afin de l’exécuter tous les mois ou 90 jours
Pour mon serveur en manual j’ai du crée un script en bash tout bête disant :
1- Stop le service XAMPP
2 - Lance la commande letsencrypt
3- Déplace les certificats letsencrypt dans le répertoire de XAMPP
4 - Relance le service XAMPP
Pour l’instant c’est la beta, je pense que le client complet sera beaucoup plus simple à configurer pour aller plus loin, et complétement compatible ngix
#25
avec la méthode en standalone, il me semble que j’ai un avertissement. j’essaierai avec un nouveau domaine ou bien dans 60 jours quand les anciens certifs seront expirés.
l’avertissement actuel que j’ai porte sur le fait que le certificat est toujours valide
#26
L’embétant avec le HTTPS (avec les navigateurs modernes), c’est que si ton site utilise un autre site qui ne soit pas en HTTPS, ce dernier contenu ne sera pas affiché dans le navigateur.
Particulièrement chiant lorsque ta régie publicitaire n’est qu’en HTTP … " />
#27
Du coup faut que les régies se bougent (mais bon elles sont plus à un n’importe quoi près) ou que les éditeurs sortent un peu de leur léthargie
#28
Moi il me manque toujours les wildcards pour utiliser let’s encrypt…
J’aime bien tester tout et n’importe quoi et mettre une redirection https://nouveau-truc.chez-moi.tld et avec les certifs let’s encrypt, pas possible le wildcard… rédhibitoire pour moi.
Maintenant, je reconnais que ça va pas gêner tout le monde l’absence de wildcard, et l’initiative des certifs gratuits, c’est bien!
#29
Donc ils vont proposer dès janvier un truc qui concerne la sécurtié mais est encore officiellement en béta ?
#30
J’ai du mal à comprendre ces deux phrases, elles me paraissent opposées :
“OVH […] Mais il n’était pour autant pas question d’une intégration à l’offre de l’hébergeur”
“des certificats seraient intégrés aux offres d’hébergement web dès le courant du mois de janvier”
Alors on doit attendre des certificats gratuits sur les offres d’hébergement OVH ou pas ?
Sinon, je viens de découvrir infomaniak grâce à l’article. Quelqu’un a des retour sur cet hébergeur ?
#31
#32
J’ai eu un avertissement en manuel disant que j’avais redemandé trop de certificats en si peu de temps (je voulais bien vérifier que mon script fonctionnait)
Et j’ai eu une fois un avertissement disant que j’avais déjà un certificat en cours, j’avais relancé ./letsencrypt-auto tout de suite après sans faire exprès.
#33
#34
#35
#36
Il n’y a pas de wildcard à proprement parlé mais tu peut très bien avoir un certificat pour chacun de tes sous-domaines. C’est ce que j’ai fait et ça marche très bien.
Quand tu crées ton certificat, letsencrypt te demande le domaine à certifier, tu indiques simplement ton sous-domaine complet : nouveau-truc.chez-moi.tld et c’est tout.
#37
#38
Oui, j’ai bien vu, mais j’ai juste pas envie de faire la procédure pour 20⁄30 sous domaines en fonction de mes tests/envies du moment… Un certificat pour *.chez-moi.tld et ma conf est fixée (juste à déclarer les nouvelles redirections dans mon HA proxy).Avec leur système, tu te retrouves avec un certificat à chaque fois que tu veux “jouer” avec un nouveau sous domaine… avec son renouvellement à faire (séparément donc) sous 90j… ça risque de vite devenir ingérable!Sans compter qu’il y a une limite du nombre de certif demandable par période (5 par semaine)https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769
#39
#40
#41
L’idee c’est d’automatiser le renouvellement. Du coup tu as pas a tes taper a la main le renouvellement de tes domaine. Ca se fait automatiquement.
#42
Il me semble qu’il est possible d’obtenir un certificat multi-domaines (en utilisant l’option “-d” plusieurs fois). Ce qui permet de ne soumettre qu’une requête de certification.
#43
Hello,
C’est bien compliqué pour moi tout ça…
j’ai même pas de site internet " />
Par contre est-ce que vous savez si on pourra avoir “simplement” un certificat pour certifier ses emails? (un peu comme ceux que fournissaient Cacert gratuitement…)?
Merci d’avance de vos réponses.
Bonnes fêtes de fin d’année à tous.
#44
Tu veux dire en signant avec une clé GPG ?
Il existe déjà des mécanismes comme DKIM (signatures des principaux en-têtes avec une clé RSA et publication de la clé publique dans le DNS pour que le serveur qui reçoit le mail puisse vérifier), bin ça n’a pas trop fait chier les spammeurs " />
#45
Let’s Encrypt c’est aussi une grosse couche d’automatisation de l’installation. Pour ça, c’est un peu “inutile” pour les emails.
Après comme dit dans le papier, il existe déjà des solutions pour avoir du SSL gratuit qui peuvent être utilisées pour obtenir un certificat exploitable dans un client email :) Mais sur le fond, ce serait intéressant de les voir proposer des certificats pour autre chose que de l’hébergement via leur CA " />
#46
DKIM ça permet surtout de certifier le domaine, pas l’expéditeur en particulier. Mais oui c’est déjà une bonne chose. Après, le souci est toujours le même : quand la techno existe, encore faut-il l’utiliser…
#47
Le from: est nécessairement signé. Si le domaine qui envoie le mail fait correctement les choses et que le serveur qui reçoit à un anti-spam efficace derrière pour balancer les mails mal signé, ça marche.
Google, Microsoft ou Yahoo le réclame pour le mail entrant
Pour le mail sortant Google et Yahoo signent, MS… non (une vieille tradition " />)
Ensuite les fournisseurs de mails français (FAI notamment), je sais que Free ne signe pas le sortant, les autres je sais pas.
Bon ensuite, c’est en général fait avec les pieds. Quand je vois le mail de mon taff (qui repose sur les service Google) qui possède des machins mal signés ce qui force la personne qui reçoit le mail à whitelister le domaine… " />
#48
J’en reviens au mail, DANE pour SMTP a été normalisé il y a peu de temps. Si la techno prend (j’ai un doute malheureusement), elle permettra de pouvoir facilement utiliser des certifs auto-signé, en laissant la vérif se faire au niveau via les enregistrement DNS signés avec DNSSEC (la faible adoption de cette dernière techno étant le plus gros frein " />)
EDIT : bon je suis un peu HS là :) :fatigue:
#49
Conclusion, change de régie.
#50
Pour les wildcards, je comprends un peu pourquoi ils sont récalcitrants.
Imaginez par exemple que quelqu’un fasse un certificat pour *.ovh.net. Et hop avec un seul certificat on englobe tous les VPS ovh !
#51
En tant que mini patron d’une petite boite d’hébergement anglophone, je suis aussi sur le qui vive pour implémenter leur solution. Le SSL gratuit c’est bien.
Excellent article @David_L, complet et très bonnes connaissances sur le sujet, ça change des conneries qu’on peut lire à gauche ou à droite et des ccl erronées.
#52
c’est surtout que leur méthode de vérification se fait par sous-domaine. donc ils peuvent pas vérifier un *.truc.com puisque ça voudrait dire de vérifier une infinité de sous-domaines. en l’état actuel du fonctionnement de leur outils, ce n’est donc pas possible.
et je ne pense pas que ça leur pose un problème.
ni au client, il suffit de générer un certificat en quelque clics/touches de clavier pour un nouveau sous-domaine à la volée, ça va pas chercher loin. on lance la commande letsencrypt pour le nouveau sous-domaine et hop c’est bon.
#53
#54
+1
#55
Je ne suis pas un pro mais j’ai réussi à faire accepter par Google un mail venant de son domaine alors qu’il transitait par le SMTP d’Orange.
Gmail a bien affiché un avertissement, mais j’aurais cru que le courriel passerait directement dans les SPAM.
#56
#57
Google et Yahoo réclame surtout SPF mais pas DKIM en entrant…
Maintenant ajouter DKIM n’est pas du luxe " />
#58
Ah il me semblait. Enfin bon MS le veut donc bon.
D’ailleurs, la prochaine étape serait de réclamer DMARC
#59
 http://labriqueinter.net/
#60
#61
Infomaniak l’a inclus dans ces offres depuis cette après midi 16h00 :-) SSL Ready
#62
#63
#64
#65
Je n’ai pas encore déployé DMARC chez moi, mais il y a fort à parier qu’un gros fournisseur de mail le réclame tôt ou tard (au hasard Google), que ce soit vraiment utile ou pas (d’ailleurs SPF et DKIM ne me semble pas, dans les faits, vraiment utiles pour lutter contre le spam. Bon ceci dit, c’est rigolo à déployer " />)
#66
SPF et DKIM ne sont pas la pour lutter contre les spam mais contre le phising en limitant les possibilités d’usurpations de domaines.
#67
" />
J’ai tendance à ne plus faire la différence entre les deux, le deuxième étant une sous catégorie du premier ;)
#68
Le fishing ce n’est pas que les mails " />
J’ai déjà eut une pub LCL chez Yahoo, qui ramenait directement sur une page de login “fishing” LCL " />" />" />
#69
Oui, il faudrait aussi faire le ménage dans les pratiques automatisées de la pub… ;) Mais bon, le mail reste encore un canal assez important pour ce genre de pratiques.
#70
C’est sur que les mails sont bien moins chez que de payer à Yahoo de l’affichage de pub " />
#71
Tu te compliques la vie pour rien.
Prends Adsense.
Et si ton site n’est vraiment pas fréquenté, oublies la pub.
#72
Quand j’essaie de créer un certificat pour mon vps xxxx.ovh.net ça me dit que le nombre de certificats pour le domaine ovh.net a été dépassé. Trop tard pour moi…