KernelHost Tools SSL Checker

SSL-certifikatkontroll

Ange en domän (eller host:port) och se direkt vem som utfärdade certifikatet, när det går ut, om det täcker ditt värdnamn och hur certifikatkedjan är uppbyggd. Frankfurt-nod, gratis, ingen registrering.

Kontrollera en domän
Snabbtest: kernelhost.com cloudflare.com github.com:443 expired.badssl.com

Vad kontrollerar testet?

KernelHost SSL Checker hämtar servercertifikatet via TLS-handskakning från vår Frankfurt-nod och visar de viktigaste fälten, utan tredjepartsanrop. Följande kontrolleras och visas:

  • Utfärdat för och av: Common Name (Subject CN), den fullständiga Subject DN och Issuer (vilken CA som signerat certifikatet).
  • Giltighetsperiod: Start- och slutdatum i UTC plus återstående dagar. Färgkodat: grönt (>30 dagar), orange (7 till 30 dagar), rött (under 7 dagar eller redan utgånget).
  • Subject Alternative Names (SANs): Komplett lista över värdnamn som certifikatet täcker, inklusive wildcard-poster.
  • Värdnamnsmatchning: Verifierar att den angivna domänen verkligen täcks av Common Name eller en SAN-wildcard (RFC 6125).
  • Nyckel och signatur: Algoritm för publik nyckel (RSA, ECDSA), nyckelstorlek i bitar eller kurvnamn, samt signaturalgoritm.
  • Fingerprints och serienummer: SHA-256 och SHA-1 fingerprint av det DER-kodade certifikatet plus det hexadecimala serienumret.
  • Hela kedjan: Alla certifikat som servern levererade under handskakningen, med subject, issuer och roll (leaf, mellan, rot).

Vanliga SSL-fel och vad de betyder

Webbläsare visar ofta kryptiska fel som NET::ERR_CERT_DATE_INVALID eller SSL_ERROR_BAD_CERT_DOMAIN. Här är de vanligaste orsakerna och hur du åtgärdar dem:

  • Certifikat utgånget: notAfter-datumet ligger i det förflutna. Webbläsare blockerar sidan helt. Lösning: förnya certifikatet. Med Let's Encrypt sker detta automatiskt var 60:e dag via certbot eller acme.sh.
  • Värdnamn matchar inte: Värdnamnet finns varken i Common Name eller någon SAN. Lösning: vid återutfärdande, lägg till alla domäner och underdomäner du behöver som SAN.
  • Självsignerat eller okänd CA: Issuer är ingen betrodd rot-CA. Webbläsare visar NET::ERR_CERT_AUTHORITY_INVALID. Lösning: hämta ett certifikat från en erkänd CA som Let's Encrypt, ZeroSSL, Sectigo eller DigiCert.
  • Ofullständig kedja: Servern skickar bara leaf-certifikatet utan mellancertifikat. Mobila webbläsare och äldre enheter misslyckas. Lösning: konfigurera hela kedjan (fullchain.pem) i din webbserver.
  • Svag nyckel eller svag signatur: RSA under 2048 bit eller SHA-1-signaturer accepteras inte längre. Lösning: återutfärda med RSA 2048+ eller ECDSA P-256.
  • Mixed content och HSTS-fälla: Om du tidigare skickat en giltig HSTS-header och certifikatet sedan går ut kan besökare inte klicka förbi varningen. Omedelbar åtgärd: förnya certifikatet, i nödfall sänk HSTS max-age.

Let's Encrypt vs. kommersiella certifikat

Let's Encrypt är en gratis, automatiserad CA driven av ISRG. Certifikaten är tekniskt identiska med kommersiella DV-certifikat och betros av alla moderna webbläsare.

När är ett betalt certifikat motiverat? Egentligen bara i specialfall:

  • Extended Validation (EV): Förr med grön adressfält, idag knappt synligt. Lönt för banker eller handelsplattformar bara när lagen kräver det.
  • Wildcard utan DNS-utmaning: Let's Encrypt stöder wildcards bara via DNS-01-utmaning. Utan API-åtkomst till DNS är ZeroSSL Premium eller Sectigo alternativ.
  • Garanti och försäkring: Kommersiella CAs erbjuder försäkringsbelopp vid felaktig utfärdande. I praktiken sällan relevant, men vissa compliance-ramverk kräver det.

KernelHost Webhosting och cPanel inkluderar gratis Let's Encrypt-integration som standard. Certifikat förnyas var 60:e dag via AutoSSL utan att du gör något. Wildcard-certifikat via DNS-utmaning är också möjliga så snart domänen ligger på KernelHost DNS.

TLS 1.2 vs. TLS 1.3

TLS 1.2 har varit standard sedan 2008, TLS 1.3 publicerades som RFC 8446 år 2018 och är brett utrullat sedan 2020. Äldre versioner (SSL 3.0, TLS 1.0, TLS 1.1) är osäkra och bör vara avstängda i serverkonfigurationen.

Vad TLS 1.3 gör bättre:

  • Snabbare handskakning: 1-RTT istället för 2-RTT, plus valfri 0-RTT vid återupptagande. Märkbart snabbare på TLS-tunga sidor.
  • Renare cipheruppsättning: Endast 5 tillåtna AEAD-cipher suites. Inget mer RSA-nyckelutbyte, alltid forward secrecy.
  • Krypterad handskakning: Servercertifikatet skickas krypterat. Med ESNI/ECH är även SNI privat.
  • Bakåtkompatibel: Servrar kan erbjuda TLS 1.2 och 1.3 parallellt. Webbläsare förhandlar automatiskt fram den högsta gemensamma versionen.

Vad innebär ett utgånget certifikat?

Ett utgånget SSL-certifikat innebär konkret att webbläsare visar en helskärmsvarning och blockerar sajten. Besökare kan i de flesta fall inte klicka förbi, särskilt inte med en aktiv HSTS-header.

Konsekvenser för operatören:

  • Rankingförlust hos Google (HTTPS är en rankingfaktor och förtroenderelaterade signaler vägs in).
  • E-postservrar (MX/SMTP med STARTTLS) avvisar inkommande anslutningar, post studsar eller levereras med fördröjning.
  • API-klienter och mobilappar med certificate pinning slutar fungera och kan behöva en app-uppdatering.

HSTS, CAA och OCSP stapling

Ett giltigt certifikat är bara början. Tre extra mekanismer lyfter TLS-säkerheten till best practice-nivå:

  • HSTS (HTTP Strict Transport Security): Header som tvingar webbläsare att bara använda HTTPS framöver. Rekommenderat: max-age=63072000; includeSubDomains; preload (två år, alla underdomäner, preload-lista). Var försiktig vid aktivering, en felkonfiguration går inte att rulla tillbaka medan max-age löper.
  • CAA (Certification Authority Authorization): DNS-post som anger vilka CAs som får utfärda certifikat för din domän. Exempel: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' förhindrar felaktig utfärdande av andra CAs.
  • OCSP stapling: Webbservern levererar själv CA:s revokeringsstatussvar istället för att varje webbläsare frågar CA separat. Snabbare för besökare och skonsammare mot CA-infrastruktur. Apache: SSLUseStapling On, nginx: ssl_stapling on.

Integritet

KernelHost SSL Checker körs helt på vår Frankfurt-nod utan tredjepartsanrop:

  • Ingen vidarebefordran av din indata till externa API:er (inget SSL Labs, Hardenize eller Cryptomon).
  • Ingen lagring av den kontrollerade domänen utöver standardloggning av förfrågningar (webbserver-logg, 14 dagars retention).
  • Anti-SSRF-filter blockerar förfrågningar till privata IP-intervall, loopback och länklokala adresser.
  • Per-IP rate limit mot missbruk. Valfri hCaptcha vid skickande.

FAQ om SSL-certifikat

Stöder du även icke-standardportar?

Ja. Ange som host:port, t.ex. mail.example.com:993 för IMAPS eller vpn.example.com:8443. Standardport är 443.

Varför visar testet ett utgånget certifikat när min webbläsare inte varnar?

Mest troligt levererar din webbserver ett annat certifikat per SNI än det testet ser. Verifiera att du testar rätt underdomän och att servern implementerar SNI korrekt.

Varför misslyckas testet på min interna domän?

Checkern körs i Frankfurt och kan bara kontrollera publikt nåbara värdar. Privata IP:er (10.x, 192.168.x, 172.16-31.x), loopback och länklokala blockeras avsiktligt (SSRF-skydd).

Hur ofta bör jag kontrollera?

Med automatiserad förnyelse (Let's Encrypt + cronjob) räcker en kontroll efter setup plus uptime-övervakning. Utan automatisering minst var 30:e dag manuellt.

Kan jag kontrollera underdomäner och e-postservrar?

Ja, valfritt värdnamn stöds. För e-postservrar: smtp.example.com:25 eller imap.example.com:993. Testet gör en ren TLS-handskakning med korrekt SNI.

Vad betyder en 'self-signed certificate'-notis?

Servern signerade sitt eget certifikat istället för att använda en betrodd CA. Webbläsare accepterar inte detta om användaren inte manuellt lägger till certifikatet i sin trust store. För produktion, använd alltid en riktig CA.

Vilka nyckelstorlekar rekommenderar KernelHost?

RSA 2048 bit som minimum, RSA 3072 eller 4096 bit för långlivade certifikat, eller ECDSA P-256 när prestanda är viktigt (betydligt mindre signaturer, snabbare handskakning). RSA 1024 eller mindre har varit förbjudet i åratal och avvisas av webbläsare.

Vad är skillnaden mellan DV, OV och EV?

DV (Domain Validation) bekräftar bara att den sökande kontrollerar domänen (standard hos Let's Encrypt). OV (Organization Validation) verifierar dessutom företaget (handelsregisterutdrag). EV (Extended Validation) är striktast, med fysisk adressverifiering. Sedan 2019 visar webbläsare ingen visuell skillnad, så DV räcker i 99% av fallen.

Alla KernelHost-produkter

Behöver du mer än bara verktyg? Kolla in vårt kommersiella hostingutbud.