Connexion
Let's Encrypt is continuing a push toward tighter security by reducing free SSL/TLS certificate lifetimes from 90 days to 64 days, starting February 10, 2027. For administrators already implementing modern ACME clients that support ARI (ACME Renewal Information), the change should be seamless. For those still relying on hardcoded renewal schedules or manual processes, February will be the deadline to update before certificates start expiring unexpectedly.
Starting on October 14, Let's Encrypt will begin testing the 64-day certificates, and interested users can opt in to test their setups before production goes live.
Prior to Let's Encrypt's launch in early 2016, certificates were often issued for as long as one to three years. The service started with 90-day certificates to force renewal automation that didn't previously exist. Shorter certificate validity periods limited vulnerabilities from private key thefts and encouraged accelerated HTTPS adoption across the web.
Je ne sais pas si vous en avez déjà entendu parler, mais DNSforge est un résolveur DNS allemand qui a une particularité plutôt cool : il refuse de résoudre les noms de domaine qui sont liés à la publicité, au pistage et au malware. Cela veut dire que la pub n'est pas bloquée dans votre navigateur, elle n'arrive tout simplement jamais à lui.
En arrivant sur la home de DNSforge, vous pouvez voir quatre portes d'entrée, selon ce que vous voulez laisser passer. En mode normal, c'est le DNS par défaut, avec blocage des pubs, blocage des trackers et blocage des malwares. Cela représente environ 1,4 million de noms de domaine.
De son côté, le mode Hard vise les mêmes catégories, mais avec des listes de blocage bien plus agressives, ce qui couvre environ 2,8 millions de noms de domaine et surtout, aucune exception n'est tolérée. Et cela même si cela nécessite de péter des bouts de Facebook.
Clean, quant à lui, c'est une version identique au mode normal qui bloque en plus le contenu adulte et les jeux d'argent, ainsi que le mode SafeSearch forcé sur les moteurs de recherche et sur YouTube. C'est pour ça qu'il couvre 8 millions de noms de domaine. Mais ça ne veut pas forcément dire que ça protège mieux que le mode Hard.
Quant au mode Blank, c'est un DNS qui n'est pas filtrant, il laisse tout passer.
Pour ces listes de blocage, DNS Forge se repose sur des listes tierces rafraîchies chaque nuit, notamment celles de hagezi ou d'oisd. Mais en cas de faux positif, rassurez-vous, vous pouvez toujours signaler ça sur le forum.
Après, comme tout ce qui est gratuit, il y a un petit plafond : DNSForge accepte 100 requêtes par tranche de 10 secondes. Et si vous dépassez ce chiffre, c'est que vous bombardez trop le résolveur, et votre adresse IP sera bannie durant 900 secondes. Voilà, ça représente un quart d'heure durant lequel vous n'avez plus accès à aucun site web. Mais bon, si ça vous arrive, il suffit de rebasculer sur un autre DNS et vous êtes tranquille.
Après 100 requêtes par tranche de 10 secondes, moi je trouve ça plutôt large pour un utilisateur seul, mais c'est vrai que si vous avez toute votre maison qui sort derrière une seule IP, que ce soit vos ordinateurs, vos téléviseurs, vos applications, vos robots, etc., on peut y être très, très vite...
Reste la question qui compte quand on confie son DNS à un inconnu : peut-on faire confiance à DNSForge ? Est-ce qu'ils conservent nos requêtes ? Eh bien, leur site dit que non : "keine Aufzeichnung von Zugriffen". À voir maintenant si c'est vrai et pour cela, il n'y a qu'une réquisition judiciaire qui saura nous le dire un jour.
Je note quand même qu'en mai 2026, un utilisateur a réclamé un rapport de transparence sur le forum et la réponse qu'il a obtenue, raconte que la police et le BKA (Office fédéral de la police criminelle) ont envoyé quelques demandes, et que DNSforge n'a rien pu leur remettre, faute d'adresses IP et de logs.
Et surtout, DNSForge indique qu'aucune requête n'est censurée... Je pense par exemple à quand les ayants droit commencent à s'exciter un petit peu trop. Maintenant, si la zone grise vous gêne, allez voir DNS4EU , le résolveur public européen. Là, c'est clean, garanti sans logs et respectueux du droit européen.
Pour tester ce DNS allemand sponsorisé par les dons, vous collez dnsforge.de dans le DNS privé d'Android, ou son adresse DoH dans Firefox, Chrome ou Edge . Sur iOS par contre, il faudra installer un profil de configuration, ce qui est un peu plus contraignant. Sinon, vous pouvez opter pour les bonnes vieilles adresses IPv6 ou IPv4 mais là, tout passera en clair.
Et si ça coince, vous remettez vos anciens DNS et on n'en parle plus.
Source : dnsforge.de
Si vous êtes développeur en Iran, à Cuba ou en Corée du Nord, vous venez officiellement de perdre l'accès à Let's Encrypt !
En effet, la version 1.7 du Subscriber Agreement publiée par l'ISRG (Internet Security Research Group), l'organisation derrière le service, est malheureusement entrée en vigueur le 4 juin dernier. Et sur les 8 pages du document, il n'y a qu'un seul ajout, mais il pèse trèèès lourd : section 3.1, un nouveau bullet point oblige maintenant chaque utilisateur à garantir qu'il "n'est pas localisé, organisé sous les lois de, ou résident dans un pays cible de sanctions américaines complètes".
En pratique, la liste OFAC des juridictions sous sanctions globales actuelles couvre Cuba, l'Iran, la Corée du Nord, et les zones occupées de Crimée, Donetsk et Lougansk (la Syrie en a été retirée fin 2025 ce qui montre bien à quel point ce périmètre peut évoluer rapidement).
Et le couperet ne tombe pas que sur des États-paria abstraits puisque ONG d'aide humanitaire, journalistes, universités, et tout le monde qui travaille ou vit dans ces zones perd le service. Du coup, pour récupérer un certificat HTTPS gratuit, vous devez maintenant signer une clause d'embargo. Plusieurs utilisateurs rapportent également que des certificats de sites russes auraient déjà été révoqués au cours des derniers mois, sans préavis officiel de l'ISRG...
Le piège, c'est la section 2.2 du contrat, intacte depuis longtemps mais qui prend un sens tout neuf : l'agrément reste en vigueur tant que vous possédez un seul certificat valide. Cela veut dire qu'une violation potentielle sur UN certificat peut donc, en théorie, déclencher une révocation en cascade de TOUS les autres, un peu comme un crédit immobilier où une mensualité ratée rendrait tout le contrat caduque...
Je vous laisse imaginer la tronche d'un hébergeur qui gère mille sites le jour où ça tombe et qui crée des certificats Let's Encrypt pour ses clients... La section 4.2 énumère onze motifs de révocation activables "à la seule discrétion" de l'ISRG, dont la violation de l'agrément et un joli fourre-tout "d'autres motifs raisonnables et légaux".
Notez que l'ISRG est domiciliée à San Jose, en Californie et que tous les CA américains (DigiCert, Sectigo, GlobalSign US) sont déjà soumis aux mêmes obligations OFAC depuis toujours, donc c'est pas vraiment non plus une surprise... Mais ça tombe toujours mal ce genre de conneries.
Maintenant, côté alternatives, si vous voulez sortir de la juridiction US, y'a pas grand chose... Je me souviens de ZeroSSL qui ressemblait à une option européenne mais qui a été racheté début 2024 par HID Global (filiale du suédois Assa Abloy, basée au Texas... donc aux Etats-Unis), donc soumis aux mêmes obligations OFAC à terme. Après vous avez peut-être des services à me recommander ? Sinon il faudra passer par des certificats payants.
Bref, le HTTPS gratuit a toujours eu un drapeau, mais on faisait juste semblant de l'oublier...
Faire s'afficher un site en HTTPS sur une machine qui tournait déjà sous Mac OS 9, le système d'exploitation d'Apple antérieur à Mac OS X, relevait jusqu'ici de l'impossible, et c'est pourtant ce qu'a réussi un développeur connu sous le pseudonyme mplsllc avec un projet baptisé MacSurf.
MacSurf est un portage de NetSurf, un navigateur web léger et open-source déjà connu sur d'autres plateformes anciennes, adapté cette fois aux vieux Mac équipés d'un processeur PowerPC, l'architecture qu'Apple a employée pendant des années avant de basculer vers les puces Intel au milieu des années 2000.
Ces premiers PowerPC occupent une position un peu ingrate dans l'histoire d'Apple, puisqu'ils sont trop anciens pour faire tourner Mac OS X comme leurs successeurs en G3, ce qui les avait jusqu'ici condamnés à un web figé sur les standards du début des années 2000, sans accès raisonnable aux sites d'aujourd'hui.
C'est précisément ce que MacSurf fait sauter, en gérant le CSS3, le JavaScript ES5 et les images PNG avec transparence, soit de quoi afficher convenablement des pages pensées pour des navigateurs récents, le tout démontré sur un iMac G3, ce fameux ordinateur tout-en-un au boîtier de plastique coloré translucide.
La partie la plus spectaculaire concerne la sécurité, puisque la version 1.3 a apporté la toute première implémentation native de TLS 1.3 jamais réalisée sur Mac OS 9, TLS étant le protocole de chiffrement qui se cache derrière le petit cadenas des connexions HTTPS et qui empêche quiconque d'intercepter ce que vous échangez avec un site.
Dans le détail, cette implémentation s'appuie sur la bibliothèque cryptographique BearSSL et sur la poignée de main définie par la norme RFC 8446, avec des algorithmes modernes comme ChaCha20-Poly1305 et AES-128-GCM, alors que la mouture 1.3.1 a ajouté plusieurs courbes elliptiques récentes, dont X25519 et les classiques P-256 et P-384.
Tout cela a été développé avec les outils d'époque de la plateforme, à savoir l'environnement CodeWarrior, l'API Carbon, le moteur graphique QuickDraw et la pile réseau Open Transport, sans la moindre émulation, puisqu'il s'agit d'un vrai logiciel natif compilé directement pour ces machines.
Il ne faut évidemment pas s'attendre à un équivalent de Chrome, et mplsllc prévient lui-même que les sites exigeant les tout derniers standards risquent de coincer sur sa création, qui reste un navigateur fonctionnel plus qu'une bête de course.
Pour ceux qui voudraient essayer, le code source ainsi que des binaires prêts à installer sont disponibles sur GitHub , et le projet dispose même de son propre site.
Faire entrer le web chiffré d'aujourd'hui dans une machine de vingt-cinq ans, alors que l'industrie laisse mourir des systèmes plus récents, c'est une bidouille qui force le respect.
Source : Hackaday
Monter un serveur HTTPS local pour bosser sur du Next.js ou du Vite, ça reste étrangement chiant. Faut mkcert pour générer les certifs, faut éditer le /etc/hosts à la mimine, installer caddy ou nginx en reverse proxy par-dessus... bref, vous voyez le diiiiliiiire ! Heureusement, Kamran Ahmed , le mec derrière roadmap.sh, vient de balancer Slim , un binaire Go standalone qui fait tout ça d'un coup.
Et tant qu'à faire, il rajoute aussi des tunnels publics à la ngrok au cas où vous voudriez présenter votre travail de dev payé au lance pierre, à un client pressé.
L'idée c'est donc de taper : slim start myapp --port 3000 et hop, votre app tourne OKLM en local sur le port 3000 et devient accessible via https://myapp.test avec un certif totalement valide reconnu à 100% par votre navigateur.
Ça permet d'esquiver tout config manuelle, puisque le binaire crée une autorité de certification locale (CA) dès le premier lancement, signe ensuite les certifs par domaine, et met à jour /etc/hosts tout seul, sans oublier de rediriger les ports 80/443 sur 10080/10443 sans même avoir besoin de root.
Et cette CA est ajoutée au trousseau du système, donc votre Chrome, Safari ou Firefox (ze best !!) la considèrent immédiatement comme légitime, sans alerte de sécurité. Du tout-en-un comme je l'aime quoi !
L'install se fait en une ligne (pensez à regarder comme d'hab le contenu du fichier .sh avant de le lancer, je ne le répéterais jamais assez) :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 
curl -sL https://slim.sh/install.sh | sh
Ensuite, pour les domaines, vous avez le choix entre .test (par défaut), .loc ou .dev. Notez que Kamran a explicitement banni le .local parce que ce TLD est réservé à mDNS et que ça fout en l'air toute la résolution DNS sur macOS et Linux. Ouf !
Le routing par chemin est aussi de la partie. Si vous bossez sur une app Next.js qui tourne sur le port 3000 et une API séparée sur le 8080, vous pouvez tout router en 1 seule commande :
slim start myapp --port 3000 --route /api=8080 --route /ws=9000
Tout tape alors sur https://myapp.test, et c'est slim qui fait le découpage. Et si vous avez plusieurs services à orchestrer, un fichier .slim.yaml à la racine du projet permet de tout déclarer d'un coup et de lancer le bouzin avec slim up.
WebSocket et HMR sont également gérés nativement, donc ça marche direct avec Vite et Next.
Maintenant, l'autre moitié de l'outil c'est slim share --port 3000 --subdomain demo qui vous délivre une URL publique sur slim.show pour exposer votre localhost sur le net. Vous pouvez ainsi ajouter un mot de passe, un TTL d'expiration, voir les logs en direct... bref, c'est du ngrok-like classique mais déjà inclus dans le même binaire ce qui évite d'aller vous créer un compte séparé. Suffit de lancer un slim login pour activer le partage public.
Alors Slim c'est cool mais y'a pas de support Windows officiel pour l'instant... ce sera donc macOS ou Linux uniquement.
Et si vous êtes sur des stacks où vous avez déjà investi dans Tunnelto pour son dashboard d'introspection HTTP ou dans Tunnl.gg pour son approche zéro-client, slim n'apportera pas forcément de quoi migrer. Mais si vous galérez à empiler mkcert + caddy + ngrok à chaque nouveau projet, c'est pil poil ce qu'il vous faut.
Le code est sur GitHub et un grand merci à Philobois pour le partage !
