Les signatures de votre domaine sont-elles en bonne santé ?
Saisissez un domaine et notre serveur inspecte sa configuration TLS comme le ferait un client strict : la chaîne de certificats et ses algorithmes de signature, les versions du protocole, les durées de vie et la préparation aux évolutions à venir. Le tout est condensé en une note de A+ à F, avec un badge à placer dans un README.
Cette vérification s’exécute depuis notre serveur : le nom de domaine que vous saisissez est envoyé à ecdsa.com, et nous nous connectons au port 443 de ce domaine. Rien d’autre n’est collecté.
Ce qui est vérifié
Algorithmes de signature
Quel algorithme signe le certificat et quelle clé celui-ci certifie (courbe ECDSA, taille de la clé RSA, Ed25519 ou un ML-DSA post-quantique), et si une fonction de hachage cassée (SHA-1, MD5) est encore utilisée.
Chaîne de certificats
La chaîne exactement telle que le serveur la présente : chaque lien émetteur → sujet concorde-t-il, manque-t-il un certificat intermédiaire, le certificat feuille est-il auto-signé ?
Versions du protocole
Si le handshake atteint TLS 1.3 et, grâce à un handshake distinct et volontairement à l’ancienne, si les versions obsolètes TLS 1.0/1.1 sont encore acceptées.
Durées de vie et rotation
L’expiration, les jours restants et la durée de vie comparée aux limites du CA/Browser Forum, qui ne cessent de se réduire (200 jours à partir de mars 2026, 47 d’ici 2029). Les durées de vie courtes sont saluées : elles signalent une rotation automatisée.
Comment lire les notes
- A+TLS 1.3, une clé moderne, un certificat de courte durée, rien à corriger
- Aconfiguration saine, avec tout au plus des remarques cosmétiques
- Bfonctionne bien, un ou deux points méritent d’être nettoyés
- Cplusieurs pénalités réelles : planifiez les corrections
- Ddes problèmes sérieux s’accumulent
- Fau moins un défaut éliminatoire : certificat expiré ou signé avec SHA-1, RSA de moins de 2048 bits, ou TLS 1.0 accepté
La notation est déterministe : la même configuration obtient toujours la même lettre. Les résultats sont mis en cache pendant une heure ; chaque page de rapport comporte un bouton « Relancer la vérification » qui contourne le cache.
À propos du scanner
Les rapports, les badges et l’API proviennent tous d’un même scanner, qui s’exécute sur les serveurs d’ecdsa.com. Ses requêtes HTTP portent le User-Agent ecdsa.com-scanner avec un lien vers cette section ; un handshake TLS n’a aucun champ pour un tel nom, les handshakes n’en portent donc aucun.
Il ne contacte que des adresses publiques d’Internet. Chaque adresse vers laquelle un nom se résout est d’abord comparée aux registres IANA des adresses à usage spécial, et un nom qui pointe, même en partie, vers un espace privé, de bouclage (loopback), lien-local ou réservé à un autre titre est refusé. La connexion se fait ensuite vers l’adresse vérifiée, jamais vers le résultat d’une seconde résolution.
Quel que soit le nombre de demandes, un domaine est analysé au plus 6 fois en 10 minutes, et le scanner dans son ensemble effectue au plus 300 analyses par minute. Les résultats sont mis en cache pendant une heure.
Vous voulez examiner un certificat vous-même ? Le décodeur de certificats décode n’importe quel PEM ou DER en local dans votre navigateur. Pour comprendre pourquoi les algorithmes sont notés ainsi, commencez par ECDSA face à RSA.