Vérificateur de certificat SSL

Saisissez un domaine (ou host:port) et voyez instantanément qui a émis le certificat, quand il expire, s'il couvre votre hostname et comment la chaîne est construite. Nœud à Francfort, gratuit, sans inscription.

Vérifier un domaine

Que vérifie ce test ?

Le KernelHost SSL Checker récupère le certificat serveur via un handshake TLS depuis notre nœud de Francfort et affiche les champs essentiels, sans appel à des tiers. Voici ce qui est vérifié et affiché :

Émis pour et par : Common Name (Subject CN), le Subject DN complet et l'Issuer (la CA qui a signé le certificat).
Période de validité : Date de début et de fin en UTC plus les jours restants. Code couleur : vert (>30 jours), orange (7 à 30 jours), rouge (moins de 7 jours ou déjà expiré).
Subject Alternative Names (SANs) : Liste complète des hostnames couverts par le certificat, y compris les entrées wildcard.
Correspondance hostname : Vérifie que le domaine saisi est bien couvert par le Common Name ou un SAN wildcard (RFC 6125).
Clé et signature : Algorithme de clé publique (RSA, ECDSA), taille de clé en bits ou nom de courbe et algorithme de signature.
Fingerprints et numéro de série : Fingerprint SHA-256 et SHA-1 du certificat encodé DER plus le numéro de série en hexadécimal.
Chaîne complète : Tous les certificats livrés par le serveur pendant le handshake, avec subject, issuer et rôle (leaf, intermediate, root).

Erreurs SSL fréquentes et leur signification

Les navigateurs affichent souvent des erreurs cryptiques comme NET::ERR_CERT_DATE_INVALID ou SSL_ERROR_BAD_CERT_DOMAIN. Voici les causes les plus fréquentes et comment les corriger :

Certificat expiré : La date notAfter est dépassée. Les navigateurs bloquent entièrement la page. Solution : renouveler le certificat. Avec Let's Encrypt cela arrive automatiquement tous les 60 jours via certbot ou acme.sh.
Hostname incorrect : Le hostname n'est ni dans le Common Name ni dans aucun SAN. Solution : lors de la réémission, ajouter chaque domaine et sous-domaine voulu en SAN.
Auto-signé ou CA inconnue : L'Issuer n'est pas une racine de confiance. Les navigateurs affichent NET::ERR_CERT_AUTHORITY_INVALID. Solution : prendre un certificat auprès d'une CA reconnue comme Let's Encrypt, ZeroSSL, Sectigo ou DigiCert.
Chaîne incomplète : Le serveur n'envoie que le certificat leaf sans les intermédiaires. Les navigateurs mobiles et anciens appareils échouent. Solution : configurer la full chain (fullchain.pem) sur votre serveur web.
Clé ou signature faible : RSA inférieur à 2048 bits ou signatures SHA-1 ne sont plus acceptés. Solution : réémettre avec RSA 2048+ ou ECDSA P-256.
Mixed content et piège HSTS : Si vous avez envoyé un en-tête HSTS valide et que le certificat expire ensuite, les visiteurs ne peuvent plus contourner l'avertissement. Action immédiate : renouveler le certificat ; en urgence réduire le HSTS max-age.

Let's Encrypt vs. certificats commerciaux

Let's Encrypt est une CA gratuite et automatisée gérée par l'ISRG. Les certificats sont techniquement identiques aux certificats DV commerciaux et reconnus par tous les navigateurs modernes.

Quand un certificat payant a-t-il du sens ? Vraiment seulement dans des cas particuliers :

Extended Validation (EV) : Affichait jadis une barre verte, aujourd'hui à peine visible. Pertinent uniquement pour banques ou plateformes de trading lorsque la loi l'exige.
Wildcard sans DNS challenge : Let's Encrypt ne supporte les wildcards que via le challenge DNS-01. Sans accès API au DNS, ZeroSSL Premium ou Sectigo sont des alternatives.
Garantie et assurance : Les CA commerciales offrent des montants d'assurance en cas de mis-issuance. Rarement pertinent en pratique, mais certains cadres de compliance l'exigent.

KernelHost Webhosting et cPanel intègrent Let's Encrypt gratuitement et de façon automatique. Les certificats sont renouvelés tous les 60 jours via AutoSSL sans aucune action de votre part. Les certificats wildcard via DNS challenge sont également possibles dès lors que le domaine est hébergé sur le DNS KernelHost.

TLS 1.2 vs. TLS 1.3

TLS 1.2 est le standard depuis 2008, TLS 1.3 a été publié en RFC 8446 en 2018 et est largement déployé depuis 2020. Les versions plus anciennes (SSL 3.0, TLS 1.0, TLS 1.1) ne sont pas sûres et doivent être désactivées dans la configuration serveur.

Ce que TLS 1.3 fait mieux :

Handshake plus rapide : 1-RTT au lieu de 2-RTT, plus 0-RTT optionnel pour la reprise. Sensiblement plus rapide sur les pages riches en TLS.
Jeu de chiffrements épuré : Seulement 5 cipher suites AEAD autorisées. Plus d'échange de clés RSA ; toujours forward secrecy.
Handshake chiffré : Le certificat serveur est lui-même transmis chiffré. Avec ESNI/ECH, même le SNI reste privé.
Rétrocompatible : Les serveurs peuvent proposer TLS 1.2 et 1.3 en parallèle. Les navigateurs négocient automatiquement la version commune la plus haute.

Que signifie un certificat expiré ?

Un certificat SSL expiré veut concrètement dire : les navigateurs affichent un avertissement plein écran et bloquent le site. Les visiteurs ne peuvent dans la plupart des cas pas passer outre, surtout avec un en-tête HSTS actif.

Conséquences pour l'opérateur :

Perte de classement dans Google (HTTPS est un facteur de ranking et les signaux de confiance sont évalués).
Les serveurs mail (MX/SMTP avec STARTTLS) refusent les connexions entrantes ; le mail bounce ou est livré en retard.
Les clients API et apps mobiles avec certificate pinning cassent et peuvent nécessiter une mise à jour.

HSTS, CAA et OCSP stapling

Un certificat valide n'est qu'un début. Trois mécanismes supplémentaires hissent la sécurité TLS au niveau best practice :

HSTS (HTTP Strict Transport Security) : En-tête qui force les navigateurs à n'utiliser que HTTPS désormais. Recommandé : max-age=63072000; includeSubDomains; preload (deux ans, tous les sous-domaines, liste preload). Attention à l'activation : une mauvaise configuration n'est pas réversible tant que max-age n'est pas écoulé.
CAA (Certification Authority Authorization) : Enregistrement DNS qui définit quelles CAs ont le droit d'émettre des certificats pour votre domaine. Exemple : 'kernelhost.com. CAA 0 issue "letsencrypt.org"' empêche la mis-issuance par d'autres CAs.
OCSP stapling : Le serveur web livre lui-même la réponse de statut de révocation de la CA, au lieu que chaque navigateur interroge la CA séparément. Plus rapide pour les visiteurs et économe pour l'infrastructure CA. Apache : SSLUseStapling On, nginx : ssl_stapling on.

Confidentialité

Le KernelHost SSL Checker fonctionne entièrement dans notre nœud de Francfort sans appel tiers :

Pas de transfert de votre saisie vers des API externes (pas de SSL Labs, pas de Hardenize, pas de Cryptomon).
Pas de stockage du domaine vérifié au-delà du logging standard des requêtes (log de serveur web, conservation 14 jours).
Filtre anti-SSRF qui bloque les requêtes vers les plages IP privées, loopback et link-local.
Rate-limit par IP contre les abus. hCaptcha optionnel à l'envoi.

FAQ sur les certificats SSL

Supportez-vous aussi les ports non standards ?

Oui. Saisissez sous forme host:port, p. ex. mail.example.com:993 pour IMAPS ou vpn.example.com:8443. Le port par défaut est 443.

Pourquoi le test affiche-t-il un certificat expiré alors que mon navigateur ne signale rien ?

Très probablement, votre serveur web présente un autre certificat par SNI que celui que voit le test. Vérifiez que vous testez le bon sous-domaine et que le serveur implémente proprement le SNI.

Pourquoi le test échoue-t-il sur mon domaine interne ?

Le checker tourne à Francfort et ne peut tester que des hôtes joignables publiquement. Les IP privées (10.x, 192.168.x, 172.16-31.x), loopback et link-local sont bloquées intentionnellement (protection SSRF).

À quelle fréquence vérifier ?

Avec un renouvellement automatique (Let's Encrypt + cronjob) un check après installation et un monitoring uptime suffisent. Sans automatisation, manuellement tous les 30 jours minimum.

Puis-je vérifier des sous-domaines et des serveurs mail ?

Oui, n'importe quel hostname est supporté. Pour les serveurs mail : smtp.example.com:25 ou imap.example.com:993. Le test fait un handshake TLS propre avec le bon SNI.

Que signifie l'avis 'self-signed certificate' ?

Le serveur a signé son propre certificat au lieu d'utiliser une CA de confiance. Les navigateurs ne l'acceptent pas, sauf si l'utilisateur ajoute manuellement le certificat à son trust store. En production, utilisez toujours une vraie CA.

Quelles tailles de clé recommande KernelHost ?

RSA 2048 bits au minimum, RSA 3072 ou 4096 bits pour des certificats à longue durée, ou ECDSA P-256 quand la performance compte (signatures sensiblement plus petites, handshake plus rapide). RSA 1024 ou inférieur est interdit depuis des années et rejeté par les navigateurs.

Quelle est la différence entre DV, OV et EV ?

DV (Domain Validation) ne confirme que le contrôle du domaine par le demandeur (par défaut chez Let's Encrypt). OV (Organization Validation) vérifie en plus l'entreprise (extrait registre du commerce). EV (Extended Validation) est la plus stricte avec vérification d'adresse physique. Depuis 2019 les navigateurs ne montrent plus de différence visuelle, donc DV suffit dans 99 % des cas.

Tous les produits KernelHost

Besoin de plus que des outils ? Découvrez notre offre d'hébergement commercial.

KVM-Rootserver à partir de 4,99 €/mois Dedicated-Server à partir de 69,99 €/mois Minecraft-Server à partir de 4,00 €/mois Webhosting à partir de 3,99 €/mois Private VPN-Server IP dédiée Protection DDoS 3,2 Tbps Arbor