Sujet : tls
-
Surveiller l'expiration des certificats TLS sur chaque point d'accès, pas seulement sur le site web principal
Un certificat expiré est une panne dont l'heure est exactement prévisible : sonder depuis l'extérieur la date notAfter de chaque certificat réellement présenté (web, API, messagerie, interfaces internes, répartiteurs de charge), alerter assez tôt pour permettre un renouvellement manuel, et vérifier les certificats intermédiaires comme le certificat final.
-
La poignée de main TLS 1.3, en résumé
TLS 1.3 négocie les clés en un seul aller-retour : le ClientHello porte déjà un partage de clé, le ServerHello répond avec le sien, et tout ce qui suit, y compris le certificat, est chiffré. La reprise de session utilise des clés prépartagées issues des tickets de session ; les données précoces 0-RTT sont optionnelles et rejouables.
-
Vérifier depuis la ligne de commande, avec openssl, une chaîne de certificats TLS servie et son expiration
openssl s_client avec -servername et -showcerts affiche les certificats qu'un serveur envoie réellement, ce que le manuel décrit comme n'étant pas une chaîne vérifiée ; openssl x509 lit le sujet, l'émetteur, les SAN et la date notAfter de chacun, et openssl verify -untrusted reconstruit la chaîne face à un magasin de confiance. Vérifier chaque nom d'hôte, ainsi que l'IPv4 et l'IPv6 séparément.
-
Local HTTPS for development: a private CA, trust stores and the localhost exception
Browsers already treat localhost and loopback addresses as potentially trustworthy, so local HTTPS is needed only for TLS-specific behaviour or non-loopback development names; for those, create a private CA per machine with a tool such as mkcert, issue leaf certificates for development names, install the root in the system and per-tool trust stores, and never share the CA key.
Lisible par machine : JSON