What does this test check?
The KernelHost SSL Checker fetches the server certificate via TLS handshake from our Frankfurt node and shows you the most important fields, with no third-party calls. The following is checked and displayed:
- Issued for and by: Common Name (Subject CN), the full Subject DN, and the Issuer (which CA signed the certificate).
- Validity period: Start and end date in UTC plus the remaining days. Color-coded: green (>30 days), orange (7 to 30 days), red (under 7 days or already expired).
- Subject Alternative Names (SANs): Full list of hostnames that the certificate covers, including wildcard entries.
- Hostname match: Verifies that the entered domain is actually covered by the Common Name or a SAN wildcard (RFC 6125).
- Key and signature: Public-key algorithm (RSA, ECDSA), key size in bits or curve name, and the signature algorithm.
- Fingerprints and serial: SHA-256 and SHA-1 fingerprint of the DER-encoded certificate plus the hexadecimal serial number.
- Full chain: All certificates the server delivered during the handshake, with subject, issuer, and role (leaf, intermediate, root).
Common SSL errors and what they mean
Browsers often show cryptic errors like NET::ERR_CERT_DATE_INVALID or SSL_ERROR_BAD_CERT_DOMAIN. Here are the most frequent root causes and how to fix them:
- Certificate expired: The notAfter date is in the past. Browsers block the page entirely. Fix: renew the certificate. With Let's Encrypt this happens automatically every 60 days via certbot or acme.sh.
- Hostname mismatch: The hostname is in neither the Common Name nor any SAN. Fix: when re-issuing, add every domain and subdomain you need as a SAN.
- Self-signed or unknown CA: Issuer is not a trusted root CA. Browsers show NET::ERR_CERT_AUTHORITY_INVALID. Fix: get a certificate from a recognized CA like Let's Encrypt, ZeroSSL, Sectigo, or DigiCert.
- Incomplete chain: Server only ships the leaf certificate without intermediates. Mobile browsers and older devices fail. Fix: configure the full chain (fullchain.pem) in your web server.
- Weak key or weak signature: RSA below 2048 bit or SHA-1 signatures are no longer accepted. Fix: re-issue with RSA 2048+ or ECDSA P-256.
- Mixed content and HSTS pitfall: If you previously sent a valid HSTS header and the cert then expires, visitors cannot click through the warning. Immediate action: renew the cert; in emergencies reduce the HSTS max-age.
Let's Encrypt vs. commercial certificates
Let's Encrypt is a free, automated CA run by ISRG. The certificates are technically identical to commercial DV certificates and are trusted by all modern browsers.
When does a paid certificate make sense? Really only in special cases:
- Extended Validation (EV): Used to show a green address bar; today it's barely visible. Only worthwhile for banks or trading platforms when legally required.
- Wildcard without DNS challenge: Let's Encrypt only supports wildcards via DNS-01 challenge. If you have no API access to DNS, ZeroSSL Premium or Sectigo are alternatives.
- Warranty and insurance: Commercial CAs offer insurance amounts in case of mis-issuance. In practice rarely relevant, but some compliance frameworks demand it.
KernelHost Webhosting and cPanel include free Let's Encrypt integration out of the box. Certificates are renewed every 60 days via AutoSSL without you doing anything. Wildcard certificates via DNS challenge are also possible once the domain is hosted on KernelHost DNS.
TLS 1.2 vs. TLS 1.3
TLS 1.2 has been the standard since 2008, TLS 1.3 was published as RFC 8446 in 2018 and has been widely deployed since 2020. Older versions (SSL 3.0, TLS 1.0, TLS 1.1) are insecure and should be disabled in your server config.
What TLS 1.3 does better:
- Faster handshake: 1-RTT instead of 2-RTT, plus optional 0-RTT for resumption. Noticeably faster on TLS-heavy pages.
- Cleaner cipher set: Only 5 allowed AEAD cipher suites. No more RSA key exchange; always forward secrecy.
- Encrypted handshake: Server certificate itself is transmitted encrypted. With ESNI/ECH, even the SNI is private.
- Backwards-compatible: Servers can offer TLS 1.2 and 1.3 in parallel. Browsers automatically negotiate the highest common version.
What does an expired certificate mean?
An expired SSL certificate concretely means: browsers show a full-screen warning and block the site. Visitors cannot click through in most cases, especially when an active HSTS header is present.
Consequences for the operator:
- Ranking loss in Google (HTTPS is a ranking factor and trust-related signals are evaluated).
- Mail servers (MX/SMTP with STARTTLS) refuse incoming connections; mail bounces or is delivered with delay.
- API clients and mobile apps with certificate pinning break and may need an app update.
HSTS, CAA, and OCSP stapling
A valid certificate is only the start. Three extra mechanisms lift TLS security to best-practice level:
- HSTS (HTTP Strict Transport Security): Header that forces browsers to use HTTPS only from now on. Recommended: max-age=63072000; includeSubDomains; preload (two years, all subdomains, preload list). Be careful when enabling: a misconfiguration is not reversible while max-age still runs.
- CAA (Certification Authority Authorization): DNS record that defines which CAs may issue certificates for your domain. Example: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' prevents mis-issuance by other CAs.
- OCSP stapling: Web server delivers the CA's revocation status response itself instead of every browser asking the CA separately. Faster for visitors and easier on CA infrastructure. Apache: SSLUseStapling On, nginx: ssl_stapling on.
Privacy
The KernelHost SSL Checker runs entirely in our Frankfurt node with no third-party calls:
- No forwarding of your input to external APIs (no SSL Labs, no Hardenize, no Cryptomon).
- No storage of the checked domain beyond standard request logging (web-server log, 14-day retention).
- Anti-SSRF filter blocks requests to private IP ranges, loopback, and link-local addresses.
- Per-IP rate limit against abuse. Optional hCaptcha on submit.