La durée de vie maximale des certificats TLS publics sera progressivement réduite à 200 jours en 2026, puis à 47 jours en 2029, rendant le renouvellement manuel intenable. Cette décision, adoptée par le CA/Browser Forum, impose un calendrier strict sans dérogation, avec une validation de domaine (DCV) réutilisable seulement 10 jours à partir de 2029. Les autorités de certification, co-sponsors de cette mesure, privilégient désormais des modèles économiques basés sur des souscriptions et des plateformes de gestion automatisée.
Le renouvellement manuel, autrefois annuel, devient ingérable avec des échéances semestrielles dès 2026, trimestrielles en 2027, puis toutes les six semaines en 2029. Les infrastructures automatisées, comme ACM sur AWS ou ACME, deviennent indispensables pour éviter les interruptions de service. Un exemple concret illustre cette contrainte : un certificat wildcard hérité, géré manuellement, a nécessité une intervention urgente en raison de sa durée de vie désormais limitée.
Cette transition, motivée par des impératifs de sécurité (réduction des fenêtres d’exploitation des clés compromises), s’aligne aussi avec les intérêts commerciaux des autorités de certification. Leur modèle évolue vers des abonnements et des solutions de gestion centralisée, rendant les processus manuels obsolètes et coûteux.
Cet article explique comment utiliser mitmproxy pour intercepter et analyser les flux HTTP(s) de manière simple et efficace. L'outil, installé via une archive, permet de se placer en "Man In The Middle" pour écouter le trafic entre votre code et le monde extérieur. L'interface web mitmweb facilite l'analyse des requêtes et réponses. Le tutoriel couvre l'installation, l'exécution, et l'utilisation de mitmproxy pour le HTTP et le HTTPS, en abordant les problèmes de certificats SSL et les solutions possibles.
L'article aborde l'utilisation des courbes elliptiques pour les certificats SSL, offrant une alternative robuste et légère aux clés RSA traditionnelles. Il explique comment générer un certificat auto-signé avec OpenSSL en utilisant des courbes elliptiques, en détaillant les étapes pour lister les courbes disponibles, créer une clé et un certificat. L'auteur partage également une méthode pour vérifier la correspondance entre une clé et un certificat, cruciale pour l'administration système. Enfin, il mentionne l'utilisation d'acme.sh pour générer des certificats avec Let's Encrypt, soulignant la simplicité et l'efficacité des courbes elliptiques dans la cryptographie moderne.
L'article explore l'utilisation de SPIFFE (Secure Production Identity Framework for Everyone) et du mTLS (mutual Transport Layer Security) avec cert-manager dans un environnement Kubernetes. SPIFFE est un standard open-source qui utilise des certificats X.509 pour sécuriser les échanges entre les workloads dans des architectures microservices, contrairement à Kerberos qui est plus adapté aux architectures monolithiques. L'article détaille l'installation et la configuration de cert-manager, un contrôleur Kubernetes pour la gestion des certificats, en désactivant l'approbation automatique des certificats pour une gestion plus sécurisée. Il explique également l'utilisation de trust-manager pour propager les certificats de confiance et du CSI Driver SPIFFE pour monter automatiquement les certificats SPIFFE dans les pods Kubernetes. Enfin, l'article présente une application simple utilisant SPIFFE pour communiquer en mTLS, soulignant l'importance de recharger régulièrement les certificats pour éviter les problèmes d'expiration.
Le guide explique comment créer un certificat TLS auto-signé et l'installer sur un serveur nginx ainsi que sur des systèmes clients. Il commence par discuter des objectifs de TLS, qui incluent l'authentification et le chiffrement pour assurer la confidentialité et l'intégrité des données. Le processus de création d'un certificat racine est détaillé, incluant la génération d'une clé privée et la création du certificat avec OpenSSL. Le certificat racine est ensuite ajouté à la liste des certificats de confiance sur les systèmes clients, ce qui permet de l'utiliser pour signer d'autres certificats. Enfin, le guide montre comment créer un certificat final pour un serveur web, le configurer dans nginx, et mettre en place une méthode automatique pour mettre à jour les certificats.
Dans cet article, on voit :
- Les formats de certificats
- Manipulation des certificats avec OpenSSL
- Visualiser le contenu d’un certificat
- Convertir entre différents formats
- Extraire des éléments d’un fichier PKCS#12
- Créer et gérer des clés privées
- Vérifier une clé privée et un certificat
- Vérifier la chaîne de certificats
- Générer une demande de signature de certificat (CSR)
- Créer un certificat auto-signé
- Examiner une demande de signature de certificat (CSR)
- Vérifier et tester un site web TLS
- Bonnes pratiques pour la gestion des certificats
Un article expliquant le fonctionnement des certificats TLS
Un journal qui explique bien à quoi servait / sert OCSP et pourquoi Let's Encrypt arrête ce service
Présentation d'un outil écrit par l'auteur
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Vous tentez de vous connecter à un serveur auquel vous vous connectez sans problème d'habitude... et vous tombez sur l'erreur
The authenticity of host 'mon_super_serveur' can't be established.
RSA key fingerprint is SHA256:le_fingerprint.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Généralement, vous choisissez yes sans réfléchir. Il s'agit d'une pratique TOFU ("Trust On First Use") et ce n'est pas terrible d'un point de vue sécurité.
L'auteur montre comment utiliser plutôt des certificats SSH, qui permettent de n'avoir plus de TOFU.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre (via https://hebdoo.fr/hebdoo-de-la-semaine )
Tout est dans le titre