tag:linuxfr.org,2005:/tags/letsencrypt/publicLinuxFr.org : les contenus étiquetés avec « letsencrypt »2023-10-21T12:00:33+02:00/favicon.pngtag:linuxfr.org,2005:Bookmark/73742023-10-20T16:46:26+02:002023-10-20T16:46:26+02:00Interception de traffic sur les serveurs jabber.ru xmpp.ru<a href="http://notes.valdikss.org.ru/jabber.ru-mitm/">http://notes.valdikss.org.ru/jabber.ru-mitm/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/133694/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/pulkomandy/liens/interception-de-traffic-sur-les-serveurs-jabber-ru-xmpp-ru#comments">ouvrir dans le navigateur</a>
</p>
pulkomandyhttps://linuxfr.org/nodes/133694/comments.atomtag:linuxfr.org,2005:Diary/403612022-09-03T20:39:00+02:002022-09-03T20:39:00+02:00Peter Eckersley bronsonisé Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Un chic type vient de nous quitter, voici un extrait, traduit de sa <a href="https://pde.is/about/">web-bio</a> </p>
<blockquote>
<p>Peter a également cofondé ou [co]-créé de nombreux projets ayant un impact sur la vie privée et la cybersécurité, notamment Let's Encrypt, Certbot, Privacy Badger, HTTPS Everywhere, Panopticlick ; pendant la pandémie de COVID-19, il a réuni le groupe stop-covid.tech, conseillant de nombreux groupes travaillant sur la recherche de contacts numériques préservant la vie privée et la notification d'exposition, et contribuant à plusieurs plans stratégiques pour l'atténuation du COVID.</p>
</blockquote>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7064652e69732f696d672f7064652d62696f2e6a7067/pde-bio.jpg" alt="Titre de l'image" title="Source : https://pde.is/img/pde-bio.jpg"></p>
<p>Tristement, omc</p>
<div><a href="https://linuxfr.org/users/omc/journaux/peter-eckersley-bronsonise.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/128651/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/omc/journaux/peter-eckersley-bronsonise#comments">ouvrir dans le navigateur</a>
</p>
omchttps://linuxfr.org/nodes/128651/comments.atomtag:linuxfr.org,2005:Post/430442022-07-29T08:08:38+02:002022-07-29T08:09:17+02:00pb avec letsencrypt et docker<p>bonjour</p>
<p>je me remet a nextcloud avec un petit lenovo (amd64) à la place d'un RPI, j'aimerais l'utiliser avec docker pour simplifier les choses. la je bloque depuis quelques temps.</p>
<p>du coup j'arrive très bien à lancer un container avec nextcloud, un autre avec mariadb, je pense avoir compris les montages local pour garder des fichier hors du container.</p>
<p>du coup je me dis qu'avec un certificat letsencrypt ce serais parfait, il y pleiiin de tuto pour le faire complétement avec docker. aucun ne fonctionne :( pour le moment.</p>
<p><a href="https://blog.ssdnodes.com/blog/installing-nextcloud-docker/">https://blog.ssdnodes.com/blog/installing-nextcloud-docker/</a> (je copie et colle le fameux fichier yml après avoir essayer l'ensemble de sa procédure par étape)</p>
<p>nextcloud+mariadb+letsencrypt+nginx pour le proxy</p>
<p>la stratégie est d'utiliser nginx comme proxy et le certificat pour nginx</p>
<p>a force d'essayer, je pense que je dois configurer au petit oignon nginx + letsencrypt pour le mode proxy avec un montage local pour les fichier de configuration ce qu'il n'y a pas (trop) dans le tuto. lorsque je fini l'installation, la configuration etc … en HTPPS j'ai un erreur 503, et en http ca fonctionne :) mais il n'y a pas de certificat, forcement.</p>
<p><strong>MA QUESTION :</strong> est ce quelqu'un parmis vous à réussi ce genre de configuration avec docker ?<br>
que des container: nextcloud+mariadb+letsencrypt+nginx.</p>
<p>si je sais que c'est possible je creuserais de mon coté un peu plus, sinon je me passerais du https, j'ai un peu besoin de mon nextcloud même si je n'ai aucune urgence.</p>
<p>soyons fou, avoir carrément le fichier yml fonctionnel + les fichier de config deporter/monter localement, mais c'est un poil trop facile à mon gout :)</p>
<div><a href="https://linuxfr.org/forums/programmationautre/posts/pb-avec-letsencrypt-et-docker.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/128393/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/programmationautre/posts/pb-avec-letsencrypt-et-docker#comments">ouvrir dans le navigateur</a>
</p>
ChocolatineFlyinghttps://linuxfr.org/nodes/128393/comments.atomtag:linuxfr.org,2005:Bookmark/33922021-07-26T15:50:48+02:002021-07-26T15:50:48+02:00acme.sh will change default CA to ZeroSSL on August-1st 2021<a href="https://community.letsencrypt.org/t/the-acme-sh-will-change-default-ca-to-zerossl-on-august-1st-2021/144052">https://community.letsencrypt.org/t/the-acme-sh-will-change-default-ca-to-zerossl-on-august-1st-2021/144052</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/124974/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/anonyme/liens/acme-sh-will-change-default-ca-to-zerossl-on-august-1st-2021#comments">ouvrir dans le navigateur</a>
</p>
Anonymehttps://linuxfr.org/nodes/124974/comments.atomtag:linuxfr.org,2005:Bookmark/32162021-06-16T17:19:53+02:002021-06-16T17:19:53+02:00 Let's Encrypt: certificate lifetimes 90 days plus one second<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1715455">https://bugzilla.mozilla.org/show_bug.cgi?id=1715455</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/124616/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/anonyme/liens/let-s-encrypt-certificate-lifetimes-90-days-plus-one-second#comments">ouvrir dans le navigateur</a>
</p>
Anonymehttps://linuxfr.org/nodes/124616/comments.atomtag:linuxfr.org,2005:Diary/396332021-03-04T23:01:13+01:002021-03-04T23:01:13+01:00Auto-hébergement sous OpenBSDLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Bon, tu as lu le titre, tu te doutes que je ne suis pas là pour te parler de mes <a href="https://i.ibb.co/TrYZGd6/2021-03-04-20-59-39.jpg">protèges préservatifs</a> cousus maison. Je te réserve ça pour un prochain journal.</p>
<p>Aujourd'hui, je vais te résumer mon installation d'<a href="https://www.openbsd.org/">OpenBSD</a> sur un netbook pour faire tourner mon blog et une instance FreshRSS.</p>
<h3 id="toc-fluff">Fluff</h3>
<p>Cela fait un moment que <a href="https://dataswamp.org/%7Esolene/index.html">Solène</a>, développeuse OpenBSD me parle de ce système. Je n'y ai jamais trop prêté attention. Voyez-vous, elle et moi n'avons pas la même définition de la simplicité. Elle code en lisp et perl sous emacs avec un stacking vm, alors que je suis plutôt du genre arch/kde/vscode/python/rust. Je n'ai jamais compris comment elles faisait pour aimer ses trucs et réciproquement¹. Alors quand ses principaux arguments étaient « ça marche pas », « c'est lent », et « les programmes crashent à cause des protections mémoires :D », je pense que vous comprendrez aisément mon manque d’intérêt. Pis là, comme l'envie de m'auto-héberger commence à poindre, j'ai décidé de lui donner une chance.</p>
<p>Le serveur ? Un netbook de récupération qui prenait la poussière et que j'ai décidé de sacrifier pour la cause.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f692e6962622e636f2f736a68355336662f696d6167652d323032312d30332d30342d32302d34352d30332e6a7067/image-2021-03-04-20-45-03.jpg" alt="Un netbook affichant le prompt OpenBSD" title="Source : https://i.ibb.co/sjh5S6f/image-2021-03-04-20-45-03.jpg"></p>
<h3 id="toc-installation">Installation</h3>
<p>Pour l'installation, <a href="https://www.openbsd.org/faq/faq4.html">Read The Fine Documentation</a>. </p>
<p>Mais en résumé, télécharger l'image, l'écrire sur une clé usb, l'insérer dans le netbook et booter. </p>
<p>Il est temps d'attaquer les choses sérieuses. "fr-dvorak" (bépo), enter, "harvest.slaanesh.org", enter, "killruana", enter, reboot. Yup, aussi simple que ça. Au premier boot, le système va automatiquement chercher les dernières mises du système et télécharger les firmware du processeur et du module Wi-Fi.</p>
<p>La <a href="https://www.openbsd.org/faq/faq6.html#Wireless">connexion au Wi-Fi</a> se fait avec un simple fichier de configuration et fonctionne sans aucun soucis.</p>
<pre><code>$ cat /etc/hostname.ral0
nwid MY-SSID wpakey MY-TOP-SECRET-PASSWORD
dhcp
</code></pre>
<p>Installation des paquets nécessaires</p>
<pre><code>$ doas pkg_add php php-curl php-pdb_pgsql php-fpm postgresql-server
</code></pre>
<p>Génération des certificats Let's Encrypt avec le <a href="https://man.openbsd.org/acme-client">client ACME</a> intégré au système</p>
<pre><code>$ doas cp /etc/examples/httpd.conf /etc/httpd.conf
$ doas rcctl start httpd
$ doas cp /etc/examples/acme-client.conf /etc/acme-client.conf
$ doas vi /etc/acme-client.conf
$ cat /etc/acme-client.conf
<snip>
domain slaanesh.org {
alternative names { www.slaanesh.org rss.slaanesh.org }
domain key "/etc/ssl/private/slaanesh.org.key"
domain full chain certificate "/etc/ssl/slaanesh.org.fullchain.pem"
sign with letsencrypt
}
$ acme-client slaanesh.org
</code></pre>
<p>Configuration du serveur web intégré au système :</p>
<pre><code>$ doas nvim /etc/httpd.conf
$ cat /etc/httpd.conf
# $OpenBSD: httpd.conf,v 1.20 2018/06/13 15:08:24 reyk Exp $
server "slaanesh.org" {
alias "beta.slaanesh.org"
alias "www.slaanesh.org"
listen on * port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI"
}
}
server "slaanesh.org" {
alias "www.slaanesh.org"
listen on * tls port 443
tls {
certificate "/etc/ssl/slaanesh.org.fullchain.pem"
key "/etc/ssl/private/slaanesh.org.key"
}
root "/htdocs/blog"
}
server "rss.slaanesh.org" {
listen on * tls port 443
tls {
certificate "/etc/ssl/slaanesh.org.fullchain.pem"
key "/etc/ssl/private/slaanesh.org.key"
}
root "/htdocs/freshrss/p"
directory index "index.html"
location "*.php*" {
fastcgi socket "/run/php-fpm.sock"
}
location "/i/*" {
directory index "index.php"
}
}
$ rcctl restart httpd
</code></pre>
<p>Configuration de postgresql et de php classique, création de la base de données et de l'utilisateur pour freshrss, chargement des modules php nécessaires, …</p>
<p>Lancement des services php-fpm et postgresql :</p>
<pre><code># rcctl php74_fpm postgresql
</code></pre>
<p>L'installation de FreshRSS est laissé en exercise au lecteur. Mais en résumé, récupérer les sources, les mettre dans /var/www/htdocs/freshrss, et accéder à votre instance.</p>
<h3 id="toc-conclusion">Conclusion</h3>
<p>Ça m'a pris moins de trois heures pour avoir mon <a href="https://slaanesh.org">blog</a> et mon [instance](<a href="https://rss.slaanesh.org/i/">https://rss.slaanesh.org/i/</a> freshrss en partant de zéro. Il n'y pas eu de mauvaises surprises. Tout fonctionne simplement et directement. La documentation est claire (si jamais vous trouvez ce que vous cherchez. Ça manque d'un wiki tout ça). C'est simple d'utilisation. Ça juste marche. Je recommande et je regrette de ne pas avoir découvert plus tôt.</p>
<p>1: c'était à l'époque hein, les goûts et avis ont depuis évolués.</p>
<div><a href="https://linuxfr.org/users/killruana/journaux/auto-hebergement-sous-openbsd.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/123479/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/killruana/journaux/auto-hebergement-sous-openbsd#comments">ouvrir dans le navigateur</a>
</p>
jtremesayhttps://linuxfr.org/nodes/123479/comments.atomtag:linuxfr.org,2005:Diary/395202020-12-23T22:42:12+01:002020-12-23T22:42:12+01:00Android < 7.1 va refuser les connections TLS certifiées par Let's EncryptLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Hello,</p>
<p>En novembre dernier, Let's Encrypt a <a href="https://letsencrypt.org/2020/11/06/own-two-feet.html">annoncé</a> que ~ 33,4% utilisateurs d'Android (ceux dont la version Android est plus vieille que la 7.1.1) ne pourront plus se connecter aux sites webs et ressources Internet certifiées par leurs certificats.</p>
<p>En effet, ils ont noté à juste titre que le certificat racine <code>DST Root X3</code> d'<em>IdenTrust</em> va expirer en septembre 2021.</p>
<p>Or, c'est ce certificat racine qui est utilisé pour signer le certificat intermédiaire <code>Let's Encrypt Authority X3</code> de Let's Encrypt et permettre d'avoir la chaîne complètement validée sur les anciens systèmes d'exploitations.</p>
<p>En effet, ces anciens systèmes ne reçoivent plus de mises à jour et ils n'ont pas intégré le nouveau certificat racine <code>ISRG Root X1</code> de Let's Encrypt. La chaîne de confiance ne pourra donc théoriquement plus être confirmée après septembre 2021.</p>
<p>Vous noterez que Let's Encrypt proposait 3 solutions à ce problème pour les propriétaires de sites web:<br>
1. Faire installer Firefox aux utilisateurs d'anciennes versions d'Android<br>
2. Basculer en HTTP sans TLS<br>
3. Ne plus utiliser Let's Encrypt pour créer ses certificats, mais un des CA disponible dans ces cersions</p>
<p>Malheureusement, Firefox ne résoudrait le problème que pour le web et uniquement pour Android version 5.0 ou supérieur.</p>
<p>Le 21 décembre dernier, Let's Encrypt <a href="https://letsencrypt.org/2020/12/21/extending-android-compatibility.html">remercie</a> l'innovation de sa communauté et la confiance d'<em>IdenTrust</em>. En effet, ils ont trouvé ensemble un moyen de conserver encore 3 ans la sécurité pour les utilisateurs d'Android < 7.1.1.</p>
<p>La communauté a remarqué qu'Android fait confiance inconditionnellement aux certificats racines installés sur le système (1). Donc, même si le certificat racine <code>DST Root X3</code> d'<em>IdenTrust</em> ne devrait plus être valide à partir de septembre 2021, Android continue de lui faire confiance.</p>
<p><em>IdenTrust</em> a accepté de cross-signer le certificat racine <code>ISRG Root X1</code> de Let's Encrypt pour une durée de 3 ans. Oui, cette fois, c'est bien le certificat racine de Let's Encrypt qui est directement cross-signé et non pas le certificat intermédiaire.</p>
<p>Cette solution permet à Let's Encrypt de passer à leur nouvelle chaîne de certificat tout en restant compatible avec les anciennes versions d'Android, comme montré dans leur schéma:</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f6c657473656e63727970742e6f72672f696d616765732f323032302e31322e32312d616e64726f69642d636f6d7061742d636572742d636861696e2e706e67/2020.12.21-android-compat-cert-chain.png" alt="Transition de chaîne de certificat" title="Source : https://letsencrypt.org/images/2020.12.21-android-compat-cert-chain.png"></p>
<p>Comme vous pouvez le voir sur ce schéma, la nouvelle chaîne livrée par défaut aux clients de Let's Encrypt va contenir 4 certificats. D'un côté, ça va ralentir un peu l'initialisation de la connexion TLS, mais d'un autre, ça donne 3 ans de compatibilité Android en plus.</p>
<p>Le client pourra demander expressément d'utiliser la nouvelle chaîne avec uniquement 3 certificats, mais il perdra alors la compatibilité avec les anciennes versions d'Android. Dans ce cas, le client Let's Encrypt doit permettre de trouver les chaînes alternatives. C'est déjà le cas pour certbot et j'ai décidé de ne pas l'implémenter pour <a href="https://projects.adorsaz.ch/adrien/acme-dns-tiny/-/issues/13">acme-dns-tiny</a>.</p>
<p>Bref, les utilisateurs d'Android ont eu chaud, mais ils ont plus de répit 😅</p>
<hr>
<p>1: J'ai appris dans cet article, que le standard précise que pour valider les <em>trust anchors</em> (certificats racines de confiances du système), le client TLS (le système d'exploitation, le navigateur…) peut choisir ou non de suivre les indications des différents champs présents. Android a décidé de ne pas utiliser le champ <em>notAfter</em> dans leur implémentation et ça aide bien Let's Encrypt pour cette fois. Il se peut que d'autres systèmes fassent de même.</p>
<div><a href="https://linuxfr.org/users/trim/journaux/android-7-1-va-refuser-les-connections-tls-certifiees-par-let-s-encrypt.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/122718/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/trim/journaux/android-7-1-va-refuser-les-connections-tls-certifiees-par-let-s-encrypt#comments">ouvrir dans le navigateur</a>
</p>
Adrien Dorsazhttps://linuxfr.org/nodes/122718/comments.atomtag:linuxfr.org,2005:Bookmark/22742020-11-17T20:19:23+01:002020-11-17T20:19:23+01:00Mozilla Punts Servo Web Engine Development To The Linux Foundation - phoronix<a href="https://www.phoronix.com/scan.php?page=news_item&px=Linux-Foundation-Servo">https://www.phoronix.com/scan.php?page=news_item&px=Linux-Foundation-Servo</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/122262/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/liens/mozilla-punts-servo-web-engine-development-to-the-linux-foundation-phoronix#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/122262/comments.atomtag:linuxfr.org,2005:Diary/392002020-06-15T21:51:33+02:002020-06-15T21:51:33+02:00Publication d'acme-dns-tiny et du RFC 8555Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Hello,</p>
<p>Ce weekend, j'ai pris le temps de sortir une nouvelle version de mon projet <a href="https://acme-dns-tiny.adorsaz.ch">acme-dns-tiny</a> dont je vous avais <a href="//linuxfr.org/users/trim/journaux/creer-des-certificats-avec-acme-let-s-encrypt-et-des-verifications-dns">parlé il y a presque 4 ans déjà</a>.</p>
<p>Cette version 2.2 est une sortie mineure, mais elle a été l'occasion de mettre à jour le site du projet, de publier quelques correctifs mineurs déjà publiés dans la branche <code>master</code> et d'intégrer des correctifs du projet original <a href="https://github.com/diafygi/acme-tiny">ACME tiny</a>.</p>
<p>Ce qui m'a motivé à reprendre le développement du projet, c'était que j'ai récemment appris à utiliser de manière plus avancée l'intégration continue de Gitlab.</p>
<p>Maintenant, dès que je fais une Merge Request, des images Docker pour Debian Jessie, Stretch et Buster sont fraîchement préparées et elles sont utilisées pour exécuter les tests du projet.</p>
<p>C'est assez cool d'avoir les images Docker toujours à jour, parce que, avant, je devais le faire manuellement. C'était clairement un frein pour reprendre le développement du projet (il fallait que je me replonge dans les commandes Docker, que je me rappelle pourquoi j'avais fait comme ça les builds…).</p>
<p>Grâce à l'intégration continue de Gitlab, j'ai aussi ajouté des contrôles sur le style du code pour suivre au mieux les directives de la <a href="https://www.python.org/dev/peps/pep-0008/">PEP 8</a>. Ces directives me semblent avoir du sens et elles me permettent d'unifier le style du code des 3 scripts proposés par le projet.</p>
<p>Vous noterez que dans le script <code>acme-dns-tiny.py</code>, j'ai choisi de désactiver les règles de <code>pylint</code> au sujet du nombre d'instructions et du nombre de variables utilisées dans un bloc.</p>
<p>Comme l'idée du script est de pouvoir être lu par un maximum de personnes, j'ai préféré garder un grand bloc d'instruction pour qu'il puisse être lu de haut en bas sans avoir besoin de rechercher des fonctions éparpillées au début du code. En effet, le but est que les administrateurs systèmes puissent aussi auditer le code pour être sûr que les clés privées ne soient pas divulguées.</p>
<p>Finalement, quitte à sortir une nouvelle version pour ces améliorations mineures, j'ai également profité de vérifier si le projet est compatible avec la version définitive du standard <em>Automatic Certificate Management Environment</em> (ACME) définie dans la <a href="https://tools.ietf.org/html/rfc8555"><em>RFC 8555</em></a>.</p>
<p>En effet, la version précédente d'acme-dns-tiny a été publiée pour être compatible avec le 16<sup>ème</sup> brouillon du standard.</p>
<p>Heureusement, le texte de la <em>RFC</em> n'a pas beaucoup changé depuis ce brouillon et le code d'acme-dns-tiny n'avait quasiment pas besoin d'être adapté.</p>
<p>À propos de cette <em>RFC 8555</em>, elle a été publiée en mars 2019 et je n'ai pas vu de nouvelle sur LinuxFr après une rapide recherche.</p>
<p>Ce standard est au cœur du projet <a href="https://letsencrypt.org/">Let's Encrypt</a> et il permet de fournir des certificats X.509 à moindre coût.</p>
<p>Ces certificats sont très utiles pour sécuriser le transfert des données entre client et serveur et pour s'assurer que le serveur appartient bien au propriétaire du nom de domaine. Ils sont typiquement utilisés pour le web avec le protocole HTTPS, mais également tous les protocoles qui permettent d'utiliser TLS, comme SMTP, IMAP, XMPP, LDAP, les connexions aux bases de données MariaDb, Postgresql…</p>
<p>Pour vérifier que la personne qui demande un certificat possède bien un nom de domaine, l'autorité de certification devait jusqu'à la publication de ce standard définir lui même le moyen utilisé.</p>
<p>Pour les certificats gratuits ou bon marché, souvent, l'identité était déjà vérifiée de manière automatique par l'autorité de certification.</p>
<p>Cependant, elle demandait au propriétaire du nom de domaine des actions manuelles comme: cliquer sur un lien unique publié dans un mail adressé, par exemple, à <code>hostmaster@example.com</code>, ou de créer une ressource DNS unique le temps de la vérification de l'identité, ou encore d'installer un fichier unique sur un site web à une adresse précise…</p>
<p>L'avantage du RFC 8555, c'est qu'il définisse clairement différent moyens sécurisés de vérifier que le demandeur de certificat possède bien un nom de domaine (soit en installant un fichier sur un serveur web, soit en installant une ressource DNS).</p>
<p>En plus d'être sécurisés, ces vérifications sont non seulement automatisable pour les autorités de certifications, mais aussi pour les demandeurs de certificat.</p>
<p>Dorénavant, il n'y a plus besoin d'intervention humaine pour demander et recevoir des certificats X.509 et c'est pour ça que je disais plus haut que ce RFC permet de les fournir à moindre coût.</p>
<p>Non seulement, Let's Encrypt a développé le standard <em>ACME</em> dans le RFC8555, mais en plus, le projet fournit une implémentation logicielle libre nommée <a href="https://github.com/letsencrypt/boulder">boulder</a> pour le serveur de l'autorité de confiance.</p>
<p>Côté client pour les demandeurs de certificats, Let's Encrypt avait débuté le développement de <a href="https://github.com/certbot/certbot">certbot</a>, puis le projet a laissé le maintient du client à l'Electronic Frontier Foundation (EFF). Let's Encrypt tient à jour une <a href="https://letsencrypt.org/docs/client-options/">liste</a> de tous les clients disponibles (dont, <code>acme-dns-tiny</code> de votre serviteur 😊)</p>
<p>Comme le standard et boulder ont évolué en même temps, boulder connaît quelques <a href="https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md">divergences</a> par rapport au RFC. Heureusement, aujourd'hui la liste des divergences est courte :)</p>
<div><a href="https://linuxfr.org/users/trim/journaux/publication-d-acme-dns-tiny-et-du-rfc-8555.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/120794/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/trim/journaux/publication-d-acme-dns-tiny-et-du-rfc-8555#comments">ouvrir dans le navigateur</a>
</p>
Adrien Dorsazhttps://linuxfr.org/nodes/120794/comments.atomtag:linuxfr.org,2005:Bookmark/12062020-03-03T19:17:27+01:002020-03-03T19:17:27+01:00Certains certificats Let's Encrypt seront révoqués le 4 mars. Pensez à mettre à jour!<a href="https://community.letsencrypt.org/t/revoking-certain-certificates-on-march-4/114864">https://community.letsencrypt.org/t/revoking-certain-certificates-on-march-4/114864</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/119550/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/ted/liens/certains-certificats-let-s-encrypt-seront-revoques-le-4-mars-pensez-a-mettre-a-jour#comments">ouvrir dans le navigateur</a>
</p>
tedhttps://linuxfr.org/nodes/119550/comments.atomtag:linuxfr.org,2005:Bookmark/11992020-02-29T01:09:00+01:002020-02-29T01:09:00+01:00UN milliard de certificats Let's Encrypt<a href="https://letsencrypt.org/2020/02/27/one-billion-certs.html">https://letsencrypt.org/2020/02/27/one-billion-certs.html</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/119524/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/andrianarivony/liens/un-milliard-de-certificats-let-s-encrypt#comments">ouvrir dans le navigateur</a>
</p>
ZeroHeurehttps://linuxfr.org/nodes/119524/comments.atomtag:linuxfr.org,2005:Post/408362020-02-11T21:34:02+01:002020-02-11T21:34:02+01:00DynDNS, Oracle, nsupdate et le support inexistant<p>Hello,</p>
<p>Pour un besoin particulier, j'ai besoin de pouvoir obtenir un certificat Let's Encrypt sur <strong>un sous-domaine d'un sous-domaine</strong> géré par <a href="https://dyn.com">DynDNS</a> (désormais Dyn.com, et propriété de ce cher Oracle, mais je m'égare) en passant par la validation "TXT record" au lieu de la traditionnelle HTTP.</p>
<p>Je pensais qu'avec un service de ce genre, point de salut, mais j'ai quand même regardé et lu tout ce que j'ai pu.</p>
<p>Et je suis tombé sur la mise à jour via <code>nsupdate</code> et l'authentification TSIG. Il se trouve justement que Dyn.com <a href="https://dyn.com/updater/tsig/">propose justement cette méthode</a>, il n'y a qu'à créer sa paire de clés depuis son compte. On est ensuite théoriquement capable d'agir sur les sous-domaines d'un sous-domaine associé à son compte Dyn (ex : <code>bar.foo.dyndns.org</code> quand on a réservé <code>foo.dyndns.org</code>).</p>
<p>Malheureusement, impossible d'arriver à faire fonctionner le bouzin, je me prends constamment un statut de réponse <code>NOTZONE</code>, qui semblerait indiquer (si j'ai bien tout compris, ce qui n'est pas garanti) que je n'ai pas les droits sur la zone en question. Ce qui est normalement faux bien sûr puisque le domaine est bien assigné à mon compte.</p>
<p>La <a href="https://dyn.com/updater/tsig/">doc</a> précise bien qu'il est nécessaire de préciser la zone cible en préambule de la requête via <code>nsupdate</code>, ce que je fais.</p>
<p>J'ai tenté de contacter le support mais il est bien évidemment aux abonnés absents, et aucune réponse non plus sur Twitter. Je m'en remets donc à vos coquilles, en espérant qu'elles soient bien pleines :)</p>
<p>Voilà les deux tests les plus significatifs effectués jusqu'ici avec les réponses associées :</p>
<p><strong>Ajout TXT record</strong></p>
<pre><code>$ nsupdate -d <<EOF
server update.dyndns.com
zone foo.dyndns.com
key <clé publique> <clé privée>
update add test.foo.dyndns.com 60 TXT some-test-value
send
quit
EOF
Sending update to 162.88.175.16#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 55612
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;foo.dyndns.com. IN SOA
;; UPDATE SECTION:
test.foo.dyndns.com. 60 IN TXT "some-test-value"
;; TSIG PSEUDOSECTION:
<clé publique>. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1581452809 300 16 sWHiDqX5WguiYEJtheae/A== 55612 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOTZONE, id: 55612
;; flags: qr aa; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;foo.dyndns.com. IN SOA
;; TSIG PSEUDOSECTION:
<clé publique>. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1581452809 300 16 oRuORNj9O2JvTq97mv6prg== 55612 NOERROR 0
</code></pre>
<p><strong>Ajout A record</strong></p>
<pre><code>$ nsupdate -d <<EOF
server update.dyndns.com
zone foo.dyndns.com
key <clé publique> <clé privée>
update add test.foo.dyndns.com 60 A 8.8.8.8
send
quit
EOF
Sending update to 162.88.175.16#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44371
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;foo.dyndns.com. IN SOA
;; UPDATE SECTION:
test.foo.dyndns.com. 60 IN A 8.8.8.8
;; TSIG PSEUDOSECTION:
<clé publique>. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1581452946 300 16 3q7VdZRneaEbvTfNqbQpjw== 44371 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOTZONE, id: 44371
;; flags: qr aa; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;foo.dyndns.com. IN SOA
;; TSIG PSEUDOSECTION:
<clé publique>. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1581452946 300 16 RGy6ScHhEu/76Y2UiCRvxA== 44371 NOERROR 0
</code></pre>
<p>Un petit coup de pouce d'un pro du DNS ? (et éventuellement d'un habitué de Dyn.com ça aiderait je suppose)</p>
<p>Merci d'avance</p>
<div><a href="https://linuxfr.org/forums/general-general/posts/dyndns-oracle-nsupdate-et-le-support-inexistant.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/119390/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/general-general/posts/dyndns-oracle-nsupdate-et-le-support-inexistant#comments">ouvrir dans le navigateur</a>
</p>
Nanawelhttps://linuxfr.org/nodes/119390/comments.atomtag:linuxfr.org,2005:Post/404722019-09-17T07:54:59+02:002019-09-17T07:54:59+02:00activation ssl en local<h2 id="toc-activation-ssl-en-local">activation ssl en local</h2>
<p>Bonjour,<br>
J’ai installé Debian en local, et mise en place la solution <strong>lamp</strong> plus <strong>phpMyAdmin</strong> pour gérer mes sites web.<br>
Enfin, j'ai installé <strong>LetSenCrypt</strong> pour crypter mes données entre mon serveur et celle des clients pour une meilleurs sécurités et protections sensibles de mes utilisateurs.<br>
Mais seulement voilà, lorsque je tente d'activer le certificat <strong>ssl</strong> de mes noms de domaine, mes sites sont par la suite inaccessibles que ce soit en http qu’en https.</p>
<p>Alors j'ai tenté de le faire chez mon hébergeur, j'ai fait la même chose que j'ai fait en local, l'installation de lamp et de phpMyAdmin et là, j'arrive à avoir le certificat <strong>ssl</strong> qui fonctionne bien, mes noms de domaines passent bien ssl et je peux donc y accéder à mes sites via https.</p>
<p>Ma question est, pour qu'elle raison mes activations en <strong>ssl</strong> de mes noms de domaine fonctionne t'ils <strong>chez l'hébergeur "ovh"</strong> et non pas en local chez moi.</p>
<div><a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/activation-ssl-en-local.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/118134/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/activation-ssl-en-local#comments">ouvrir dans le navigateur</a>
</p>
gerardhttps://linuxfr.org/nodes/118134/comments.atomtag:linuxfr.org,2005:Diary/385602019-06-15T17:09:50+02:002019-06-15T21:01:50+02:00EASYLAN - Mise en place simplifiée et personnalisable d'un intranet sécurisé avec DockerLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Bonjour, passé un temps à devoir réaliser les mêmes choses lors de déploiement d'application conteneurisées, à savoir configurer un proxy HTTPS, générer des certificats SSL (CA local ou passant par Let's Encrypt), je me suis lancé dans la réalisation d'un projet, EasyLAN, dans le but de simplifier tout ça.</p>
<p>Globalement, cette solution vise à déployer une application conteneurisée rapidement sans avoir à gérer différents aspects récurent, voir rébarbatif, comme la mise en place d'un proxy HTTP, un certificat SSL ou encore un serveur DNS, sur un petit serveur résidentiel, d'une TPE/PME, d'une petite équipe projet, etc.</p>
<p>Extrait de la documentation :</p>
<p>Schéma d'un exemple de déploiement :<br>
<img src="//img.linuxfr.org/img/68747470733a2f2f6769746c61622e636f6d2f6d6265647379732f656173796c616e2f7261772f6d61737465722f646f632f696d672f70726f6a6563745f6172636869746563747572652e706e67/project_architecture.png" alt="Organisation du projet" title="Source : https://gitlab.com/mbedsys/easylan/raw/master/doc/img/project_architecture.png"></p>
<p>Liste des services fournis :</p>
<ul>
<li>Génération automatisée de certificat SSL avec une PKI et un CA auto-signé et local ou à partir de Let's Encrypt</li>
<li>Génération automatisée d'un proxy HTTPS pour l'ensemble des services</li>
<li>Génération automatisée d'un serveur DNS avec une zone DNS pour les services locaux</li>
</ul>
<p>Cette solution est conçue principalement pour les cas suivants :</p>
<ul>
<li>Déploiement d'application web dans un réseau privé pour une des raisons comme :
<ul>
<li>vous n'avez pas la possibilité de vous procurer un certificat valide fourni par un CA reconnu</li>
<li>vous n'avez pas la possibilité de vous procurer un nom de domaine public</li>
</ul>
</li>
<li>Pour un environnement de test ou développement, pour tester une application sans avoir à gérer la partie proxy/SSL/DNS</li>
</ul>
<p><a href="https://gitlab.com/mbedsys/easylan">Page du projet (avec la documentation complète)</a></p>
<p>Le projet est à son tout début, dites-moi ce que vous en pensez…</p>
<div><a href="https://linuxfr.org/users/emericv/journaux/easylan-mise-en-place-simplifiee-et-personnalisable-d-un-intranet-securise-avec-docker.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/117474/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/emericv/journaux/easylan-mise-en-place-simplifiee-et-personnalisable-d-un-intranet-securise-avec-docker#comments">ouvrir dans le navigateur</a>
</p>
Emerichttps://linuxfr.org/nodes/117474/comments.atomtag:linuxfr.org,2005:News/386402018-06-05T09:37:09+02:002018-06-05T12:44:30+02:00Post‐mortem de l’incident du 3 juin 2018Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Beaucoup d’entre‐vous s’en sont rendus compte, le certificat X.509 utilisé par <em>LinuxFr.org</em> a expiré ce 3 juin 2018. Retour sur cet incident et sur le renouvellement de ce certificat dans la seconde partie de cette dépêche.</p></div><ul><li>lien nᵒ 1 : <a title="https://linuxfr.org/news/quoi-de-neuf-cote-linuxfr-org" hreflang="fr" href="https://linuxfr.org/redirect/102169">LinuxFr.org : Quoi de neuf côté LinuxFr.org, relatant le changement de certificat en 2015</a></li><li>lien nᵒ 2 : <a title="https://linuxfr.org/users/krunch/journaux/dlfp-hacke" hreflang="fr" href="https://linuxfr.org/redirect/102170">Journal LinuxFr.org hacké</a></li><li>lien nᵒ 3 : <a title="https://www.gandi.net/fr/security" hreflang="fr" href="https://linuxfr.org/redirect/102174">Les certificats SSL chez Gandi</a></li><li>lien nᵒ 4 : <a title="https://letsencrypt.org/" hreflang="fr" href="https://linuxfr.org/redirect/102175">Let’s Encrypt</a></li><li>lien nᵒ 5 : <a title="https://fr.wikipedia.org/wiki/X.509" hreflang="fr" href="https://linuxfr.org/redirect/102180">Wikipédia : X.509</a></li></ul><div><h2 id="historique-des-certificats-x509-sur-linuxfrorg">Historique des certificats X.509 sur LinuxFr.org</h2>
<p>Jusqu’en 2015, <em>LinuxFr.org</em> était accessible en HTTPS grâce à un certificat X.509 provenant de l’autorité de certification communautaire <a href="http://www.cacert.org/">CAcert</a>. Malgré un fonctionnement communautaire et quelque peu décentralisé plaisant beaucoup à notre équipe, la <a href="https://fr.wikipedia.org/wiki/CAcert.org#Inclusion">non‐inclusion</a> de cette autorité de certification dans les navigateurs les plus utilisés devenait un frein à l’accès grand public à <em>LinuxFr.org</em>.</p>
<p>En 2015, le bureau d’enregistrement de noms de domaines (<em>registrar</em>) <a href="https://www.gandi.net/fr">Gandi</a> a fourni gracieusement à <em>LinuxFr.org</em> un certificat X.509 valable pour tout le domaine <em>linuxfr.org</em> (ce que l’on appelle un <em>wildcard</em>, c.‐à‐d. un certificat dont le sujet est <code>*.linuxfr.org</code>) pour une durée de trois ans. Cette dépêche est d’ailleurs l’occasion de les remercier chaleureusement pour cela.</p>
<p>Trois ans plus tard, nous sommes en 2018. Se pose alors la question de renouveler le certificat.</p>
<h2 id="chronologie-de-lincident">Chronologie de l’incident</h2>
<p>La date d’expiration du certificat offert par Gandi est le 3 juin 2018 à 1 h 59. Le 24 mai, Benoît poste un rappel sur la tribune de modération. Personne n’étant disponible, le certificat expire le 3 juin. Les premières alertes sont données par courriel, en direction de la liste des modérateurs, à partir de 9 h 11. D’autres personnes signalent aussi le problème sur Twitter dans la foulée. Les premiers administrateurs au courant n’ayant pas forcément la possibilité de se connecter immédiatement sur les serveurs pour résoudre la situation, il faudra attendre 10 h avant que quelqu’un puisse le faire.</p>
<p>Deux des administrateurs entrevoient les possibilités :</p>
<ul>
<li>commander un nouveau certificat chez Gandi ;</li>
<li>utiliser l’autorité de certification gratuite et automatisée Let’s Encrypt.</li>
</ul><p>Après quelques tergiversations, d’envois de demandes de signature de certificats (<a href="https://fr.wikipedia.org/wiki/Demande_de_signature_de_certificat" title="Certificate signing request">CSR</a>) pas forcément bien ficelées, c’est vers Let’s Encrypt que les administrateurs se tournent. Du fait de dépendances légères et de connaissances sur ce logiciel, c’est le client <a href="https://dehydrated.io/">dehydrated</a> qui est utilisé, d’abord sur le serveur <em>alpha</em> (préproduction) puis sur le serveur <em>prod</em> (qui porte bien son nom). Le certificat est généré sur la production à 11 h 28, la fin de l’incident peut donc être déclarée vers 11 h 35. À ce moment‐là, décision est prise de ne pas activer le renouvellement automatique, afin de décider de la pérennisation de Let’s Encrypt une fois tous les administrateurs disponibles.</p>
<p>Le certificat sur <em>prod</em> sera de nouveau généré en début de soirée (20 h 39) pour ajouter une entrée <a href="https://www.ssl.com/faqs/common-name/">CN</a> (celle de <em>prod</em> lui‐même).</p>
<p>À noter que la priorité étant donnée au service HTTPS, les services de messagerie SMTP ne sont pas modifiés à ce moment‐là. Les courriels continuant d’arriver, cela n’est pas considéré comme prioritaire. Le sujet est néanmoins abordé sur le canal IRC des administrateurs du site et des actions auront lieu sur le sujet.</p>
<h2 id="leçons-et-actions-futures">Leçons et actions futures</h2>
<p>Suite à cet incident, on peut retenir :</p>
<ul>
<li>que la communauté autour de <em>LinuxFr.org</em> fait un sacré travail de signalement des incidents :) ;</li>
<li>qu’il est important d’avoir plusieurs personnes dans l’équipe qui peuvent intervenir ;</li>
<li>qu’il ne faut pas oublier de vérifier les dates d’expiration de certains services critiques (certificats X.509, noms de domaines…).</li>
</ul><p>Les actions actuellement envisagées :</p>
<ul>
<li>un passage permanent à Let’s Encrypt, sur chaque serveur en ayant besoin ;</li>
<li>pourquoi pas l’installation d’un serveur de supervision pour alerter l’équipe de ce genre de problème (et d’autres ?).</li>
</ul></div><div><a href="https://linuxfr.org/news/post-mortem-de-l-incident-du-3-juin-2018.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/114632/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/post-mortem-de-l-incident-du-3-juin-2018#comments">ouvrir dans le navigateur</a>
</p>
Nils RatusznikDavy DefaudZeroHeureFlorent Zarahttps://linuxfr.org/nodes/114632/comments.atom