KernelHost Tools SSL Checker

Verificare certificat SSL

Introduceți un domeniu (sau host:port) și vedeți instantaneu cine a emis certificatul, când expiră, dacă acoperă hostname-ul dvs. și cum este construit lanțul de certificate. Nod Frankfurt, gratuit, fără înregistrare.

Verificați un domeniu
Test rapid: kernelhost.com cloudflare.com github.com:443 expired.badssl.com

Ce verifică acest test?

KernelHost SSL Checker preia certificatul serverului prin TLS handshake din nodul nostru de la Frankfurt și vă arată cele mai importante câmpuri, fără apeluri către terți. Următoarele sunt verificate și afișate:

  • Emis pentru și de: Common Name (Subject CN), Subject DN complet, și Issuer (ce CA a semnat certificatul).
  • Perioadă de validitate: Data de început și de final în UTC plus zilele rămase. Cod culori: verde (>30 zile), portocaliu (7 până la 30 zile), roșu (sub 7 zile sau deja expirat).
  • Subject Alternative Names (SANs): Lista completă a hostname-urilor pe care le acoperă certificatul, inclusiv intrări wildcard.
  • Potrivire hostname: Verifică dacă domeniul introdus este efectiv acoperit de Common Name sau de o wildcard SAN (RFC 6125).
  • Cheie și semnătură: Algoritm cheie publică (RSA, ECDSA), dimensiune cheie în biți sau nume curbă, și algoritm de semnătură.
  • Fingerprints și serial: Fingerprint SHA-256 și SHA-1 al certificatului codat DER, plus numărul serial hexazecimal.
  • Lanț complet: Toate certificatele pe care serverul le-a livrat în timpul handshake-ului, cu subject, issuer și rol (leaf, intermediate, root).

Erori SSL frecvente și ce înseamnă

Browserele afișează adesea erori criptice ca NET::ERR_CERT_DATE_INVALID sau SSL_ERROR_BAD_CERT_DOMAIN. Iată cele mai frecvente cauze și cum le rezolvați:

  • Certificat expirat: Data notAfter este în trecut. Browserele blochează pagina complet. Soluție: reînnoiți certificatul. Cu Let's Encrypt asta se întâmplă automat la fiecare 60 zile prin certbot sau acme.sh.
  • Hostname mismatch: Hostname-ul nu apare nici în Common Name nici într-un SAN. Soluție: la reemitere, adăugați fiecare domeniu și subdomeniu de care aveți nevoie ca SAN.
  • Self-signed sau CA necunoscută: Issuer-ul nu este o root CA de încredere. Browserele afișează NET::ERR_CERT_AUTHORITY_INVALID. Soluție: obțineți un certificat de la o CA recunoscută ca Let's Encrypt, ZeroSSL, Sectigo sau DigiCert.
  • Lanț incomplet: Serverul livrează doar certificatul leaf fără intermediates. Browserele mobile și dispozitivele mai vechi eșuează. Soluție: configurați lanțul complet (fullchain.pem) în serverul web.
  • Cheie slabă sau semnătură slabă: RSA sub 2048 bit sau semnături SHA-1 nu mai sunt acceptate. Soluție: reemiteți cu RSA 2048+ sau ECDSA P-256.
  • Mixed content și capcana HSTS: Dacă ați trimis anterior un header HSTS valid și certificatul expiră apoi, vizitatorii nu pot da click prin avertisment. Acțiune imediată: reînnoiți certificatul; în urgențe reduceți HSTS max-age.

Let's Encrypt vs. certificate comerciale

Let's Encrypt este o CA gratuită, automatizată, operată de ISRG. Certificatele sunt tehnic identice cu certificatele DV comerciale și sunt de încredere pentru toate browserele moderne.

Când are sens un certificat plătit? Doar în cazuri speciale:

  • Extended Validation (EV): Obișnuia să afișeze o bară verde de adresă; astăzi abia se vede. Util doar pentru bănci sau platforme de tranzacționare când este cerut legal.
  • Wildcard fără DNS challenge: Let's Encrypt suportă wildcards doar prin DNS-01 challenge. Dacă nu aveți acces API la DNS, ZeroSSL Premium sau Sectigo sunt alternative.
  • Garanție și asigurare: CA comerciale oferă sume de asigurare în caz de mis-issuance. În practică rar relevant, dar unele framework-uri de compliance îl cer.

KernelHost Webhosting și cPanel includ integrare gratuită Let's Encrypt din start. Certificatele se reînnoiesc la fiecare 60 zile prin AutoSSL fără să faceți nimic. Certificatele wildcard prin DNS challenge sunt și ele posibile odată ce domeniul este găzduit pe DNS-ul KernelHost.

TLS 1.2 vs. TLS 1.3

TLS 1.2 este standard din 2008, TLS 1.3 a fost publicat ca RFC 8446 în 2018 și este larg implementat din 2020. Versiunile mai vechi (SSL 3.0, TLS 1.0, TLS 1.1) sunt nesigure și ar trebui dezactivate în configurația serverului.

Ce face TLS 1.3 mai bine:

  • Handshake mai rapid: 1-RTT în loc de 2-RTT, plus 0-RTT opțional pentru reluare. Vizibil mai rapid pe pagini TLS-heavy.
  • Set de ciphere mai curat: Doar 5 cipher suites AEAD permise. Fără mai mult schimb de chei RSA; întotdeauna forward secrecy.
  • Handshake criptat: Certificatul serverului însuși este transmis criptat. Cu ESNI/ECH, chiar și SNI este privat.
  • Compatibil cu versiunile anterioare: Serverele pot oferi TLS 1.2 și 1.3 în paralel. Browserele negociază automat cea mai înaltă versiune comună.

Ce înseamnă un certificat expirat?

Un certificat SSL expirat înseamnă concret: browserele afișează un avertisment pe ecran complet și blochează site-ul. Vizitatorii nu pot da click prin în majoritatea cazurilor, mai ales când există un header HSTS activ.

Consecințe pentru operator:

  • Pierdere de ranking pe Google (HTTPS este factor de ranking și semnale legate de încredere sunt evaluate).
  • Serverele de mail (MX/SMTP cu STARTTLS) refuză conexiuni de intrare; mailul face bounce sau este livrat cu întârziere.
  • Clienții API și aplicațiile mobile cu certificate pinning se rup și pot avea nevoie de update.

HSTS, CAA și OCSP stapling

Un certificat valid este doar începutul. Trei mecanisme suplimentare ridică securitatea TLS la nivel best-practice:

  • HSTS (HTTP Strict Transport Security): Header care forțează browserele să folosească doar HTTPS de acum încolo. Recomandat: max-age=63072000; includeSubDomains; preload (doi ani, toate subdomeniile, lista preload). Aveți grijă la activare: o configurare greșită nu este reversibilă cât timp max-age încă rulează.
  • CAA (Certification Authority Authorization): Înregistrare DNS care definește ce CA pot emite certificate pentru domeniul dvs. Exemplu: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' previne emiterea greșită de către alte CA.
  • OCSP stapling: Serverul web livrează el însuși răspunsul de status de revocare al CA în loc ca fiecare browser să întrebe CA separat. Mai rapid pentru vizitatori și mai ușor pentru infrastructura CA. Apache: SSLUseStapling On, nginx: ssl_stapling on.

Confidențialitate

KernelHost SSL Checker rulează în întregime în nodul nostru din Frankfurt fără apeluri către terți:

  • Niciun forward al intrării dvs. către API externe (fără SSL Labs, fără Hardenize, fără Cryptomon).
  • Nicio stocare a domeniului verificat dincolo de logging-ul standard de cereri (log webserver, retenție 14 zile).
  • Filtru anti-SSRF blochează cererile către intervale IP private, loopback și link-local.
  • Rate limit per IP împotriva abuzului. hCaptcha opțional la trimitere.

FAQ despre certificate SSL

Suportați și porturi non-standard?

Da. Introduceți ca host:port, ex. mail.example.com:993 pentru IMAPS sau vpn.example.com:8443. Portul implicit este 443.

De ce testul arată un certificat expirat chiar dacă browserul nu avertizează?

Cel mai probabil serverul dvs. web prezintă un certificat diferit per SNI decât ce vede testul. Verificați că testați subdomeniul corect și că serverul implementează SNI curat.

De ce testul eșuează pentru domeniul meu intern?

Checker-ul rulează la Frankfurt și poate verifica doar host-uri accesibile public. IP private (10.x, 192.168.x, 172.16-31.x), loopback și link-local sunt blocate intenționat (protecție SSRF).

Cât de des ar trebui să verific?

Cu reînnoire automată (Let's Encrypt + cronjob) o verificare după setup plus uptime monitoring este suficient. Fără automatizare, manual cel puțin la 30 zile.

Pot verifica subdomenii și servere de mail?

Da, orice hostname este suportat. Pentru servere de mail: smtp.example.com:25 sau imap.example.com:993. Testul face un TLS handshake curat cu SNI corect.

Ce înseamnă o notificare 'self-signed certificate'?

Serverul a semnat propriul certificat în loc să folosească o CA de încredere. Browserele nu acceptă asta decât dacă utilizatorul adaugă manual certificatul în trust store. Pentru producție folosiți întotdeauna o CA reală.

Ce dimensiuni de cheie recomandă KernelHost?

RSA 2048 bit ca minim, RSA 3072 sau 4096 bit pentru certificate de lungă durată, sau ECDSA P-256 când performanța contează (semnături semnificativ mai mici, handshake mai rapid). RSA 1024 sau mai mic este interzis de ani și este respins de browsere.

Care este diferența între DV, OV și EV?

DV (Domain Validation) confirmă doar că aplicantul controlează domeniul (implicit cu Let's Encrypt). OV (Organization Validation) verifică suplimentar compania (extras din registrul comercial). EV (Extended Validation) este cea mai strictă, cu verificare de adresă fizică. Din 2019 browserele nu mai arată o diferență vizuală, deci DV este suficient pentru 99 % din cazuri.

Toate produsele KernelHost

Ai nevoie de mai mult decât unelte? Descoperă oferta noastră comercială de hosting.