Ghid pentru SSL Checker
Ce citește SSL Checker de la XGM dintr-un certificat și dintr-o conexiune TLS, cum citiți nota, lanțul, protocolul și cifrurile și cum le reparați.
Ce dovedește un certificat
Un certificat TLS leagă un nume de gazdă de o cheie publică și este semnat de o autoritate de certificare (CA) în care browserele au încredere. Când un browser se conectează la https://example.com, serverul își prezintă certificatul, iar browserul verifică dacă acesta este valabil astăzi, dacă a fost emis pentru example.com și dacă se leagă în lanț până la o rădăcină de încredere. Abia atunci conexiunea este considerată sigură. Dacă fie și una singură dintre aceste condiții nu este îndeplinită, browserul afișează un avertisment pe toată pagina în locul site-ului, iar cei mai mulți vizitatori se întorc din acel ecran.
Certificatul este însă doar jumătate din poveste. Handshake-ul TLS negociază și o versiune de protocol și o suită de cifruri, iar acestea decid cât de bine este protejată conexiunea. Verificatorul TLS raportează ambele părți, astfel încât un certificat valabil aflat pe o configurație învechită să nu fie confundat cu o instalare sănătoasă. Cele două nu se înlocuiesc reciproc: aveți nevoie în același timp și de certificatul corect, și de configurația corectă.
Cum folosiți Verificatorul TLS
- Deschideți Verificatorul TLS și introduceți un nume de gazdă servit prin HTTPS, de exemplu
example.comsauwww.example.com. - XGM se conectează de pe serverul său la portul 443 al acelei gazde și finalizează un handshake TLS.
- Citiți nota și rezumatul: emitentul, expirarea, cheia, semnătura, OCSP stapling, starea HSTS preload și tabelul de protocoale.
- Parcurgeți constatările și remedierile, apoi partajați permalinkul sau exportați rezultatul. Fila Raport complet rulează raportul SSL / TLS punctat, cu recomandări.
Verificați separat fiecare nume de gazdă pe care îl serviți. example.com și www.example.com pot fi servite de certificate diferite sau chiar de platforme complet diferite, iar un CDN aflat în față poate prezenta un alt certificat decât serverul dumneavoastră de origine. Faptul că un singur nume iese curat nu spune nimic despre celelalte.
Ce înseamnă constatările
| Constatare | Severitate | Acțiune |
|---|---|---|
| Certificat intermediar lipsă | Critică | Serviți lanțul complet (fullchain.pem), nu doar certificatul final. |
| Certificatul nu este de încredere | Critică | Expirat, nume greșit sau CA necunoscută: emiteți un certificat nou. |
| Certificatul expiră în n zile (sub 14 / sub 30) | Critică / Avertisment | Reînnoirea ar fi trebuit să aibă loc deja; verificați automatizarea. |
| Cheie RSA de n biți (sub 2048) | Critică | Generați o cheie RSA de 2048 de biți sau una ECDSA P-256. |
| Certificat semnat cu SHA-1 sau MD5 | Critică | Reemiteți-l cu SHA-256; browserele resping aceste semnături. |
| TLSv1.0 și TLSv1.1 încă active | Avertisment | Permiteți doar TLS 1.2 și 1.3; limitează nota la B. |
| TLS 1.3 nu este acceptat | Avertisment | Actualizați OpenSSL (1.1.1+) și activați TLS 1.3; limitează nota la A-. |
| 3DES sau RC4 acceptate | Critică | Scoateți-le din lista de cifruri; limitează nota la C. |
| Schimb de chei RSA acceptat / CBC cu SHA-1 acceptat | Avertisment / Informativ | Preferați ECDHE cu cifruri AEAD (GCM, ChaCha20). |
| Fără OCSP stapling | Informativ | Activați stapling dacă CA-ul dumneavoastră mai rulează OCSP. |
| Fără antet HSTS / max-age scurt | Avertisment | Trimiteți HSTS cu cel puțin șase luni; necesar pentru A+. |
Ferestrele de reînnoire
Probleme frecvente cu certificatele
| Simptom în browser | Cauză | Remediere |
|---|---|---|
| „Conexiunea dumneavoastră nu este privată” împreună cu o eroare de dată | Certificat expirat | Reînnoiți-l; reparați sarcina de reînnoire |
| Eroare de nepotrivire a numelui | Certificatul nu listează numele de gazdă în SAN | Reemiteți-l incluzând fiecare nume de gazdă, precum www |
| Emitent necunoscut doar pe unele dispozitive | Certificatul intermediar lipsește de pe server | Serviți fișierul cu lanțul complet |
| Avertisment doar pe dispozitive vechi | Depozit de rădăcini vechi sau suport limitat pentru versiuni TLS | De obicei acceptabil; verificați platforma clientului |
| Funcționează pe www, eșuează pe domeniul simplu | Bloc de server sau certificat diferit pentru fiecare nume | Acoperiți ambele nume și configurați ambele gazde |
Un intermediar lipsă este o problemă clasică, pentru că browserele de desktop completează deseori golul din cache, în timp ce aplicațiile mobile, clienții de API și instrumentele din linia de comandă eșuează. Configurați serverul cu fișierul de lanț complet pe care îl oferă CA-ul dumneavoastră, nu doar cu certificatul final. Faptul că la dumneavoastră pagina se deschide fără avertisment nu înseamnă, prin urmare, că se deschide la fel și pentru utilizatori.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null | grep -E 's:|i:'Tipuri de certificate și emitenți
Certificatele de încredere publică diferă prin felul în care CA-ul a validat solicitantul, nu prin puterea criptării. Certificatele validate la nivel de domeniu (DV) dovedesc controlul asupra domeniului, iar cele validate la nivel de organizație (OV) și cu validare extinsă (EV) adaugă verificări despre organizație. Browserele le tratează la fel în privința lacătului, așa că certificatele DV emise de CA-uri automatizate sunt alegerea obișnuită pentru majoritatea site-urilor. Puterea criptării este identică la toate trei; diferă doar procesul de validare și prețul.
| Opțiune | Acoperă | Observații |
|---|---|---|
| Un singur nume de gazdă | example.com | Cel mai simplu; adăugați www ca al doilea nume |
| Cu mai multe nume (SAN) | example.com, www.example.com, api.example.com | Un certificat pentru un set fix de nume |
| Wildcard | *.example.com | Orice subdomeniu de un singur nivel, nu domeniul simplu și nu nivelurile mai adânci |
| Cheie ECDSA | Oricare dintre cele de mai sus | Mai mică și mai rapidă decât RSA; acceptată de clienții actuali |
Certificatele wildcard sunt comode, dar răspândesc o singură cheie privată în fiecare serviciu care o folosește. Compromiterea oricăruia dintre acele servere expune cheia pentru toate subdomeniile, așa că preferați certificate separate acolo unde serviciile sunt administrate de echipe sau de platforme diferite. Certificatele separate fac, în plus, ca reînnoirea fiecărui serviciu să fie independentă de a celorlalte.
Reînnoire și monitorizare
Durata de viață a certificatelor de încredere publică este limitată de regulile CA/Browser Forum și devine tot mai scurtă, ceea ce face reînnoirea manuală nepractică. Clienții ACME reînnoiesc automat cu CA-urile care acceptă protocolul, iar platformele de găzduire și CDN-urile fac acest lucru în locul dumneavoastră. Ce nu face automatizarea în mod fiabil este să vă anunțe atunci când se oprește din funcționat. De aceea faptul că reînnoirea este automatizată nu elimină nevoia unei monitorizări separate.
- Monitorizați expirarea independent de sistemul de reînnoire, cu o alertă la 21 de zile sau mai devreme.
- Urmăriți fiecare nume de gazdă, inclusiv serverele de e-mail, gazdele de API și panourile de administrare.
- După ce schimbați DNS-ul, CDN-ul sau găzduirea, confirmați că reînnoirea încă funcționează: validarea prin HTTP se poate strica atunci când traficul se mută.
- Păstrați înregistrările CAA în acord cu CA-urile pe care le folosiți efectiv, ca reînnoirile să nu fie refuzate.
Verificatorul TLS transformă expirarea în datele care contează - data emiterii la 90 de zile, data comenzii la 60 de zile, data reînnoirii la 30 de zile și expirarea însăși - și le oferă ca fișier .ics pe care îl puteți importa în orice calendar, cu câte un eveniment pentru fiecare dată și cu numele gazdei în fiecare. Un intermediar care expiră înaintea certificatului final sau un al doilea certificat cu propria expirare primește un eveniment separat. Fișierul este construit în browserul dumneavoastră din rezultatul de pe ecran: XGM nu păstrează datele și nu trimite mementouri, așa că singurul lucru care vă va aminti este calendarul pe care îl importați.
API-ul XGM oferă aceeași verificare în format JSON la /api/v1/ssl/example.com, ușor de apelat dintr-o sarcină programată. Ghidul TLS 1.3 acoperă configurarea protocolului și a cifrurilor, iar ghidul HSTS explică de ce expirarea se transformă într-o pană totală odată ce HSTS este activat.
Întrebări frecvente
SSL este același lucru cu TLS?
SSL este numele vechi. Toate versiunile SSL sunt depășite, iar certificatele se folosesc astăzi cu TLS. Termenul certificat SSL a rămas în uz, însă protocolul este TLS.
Ce port folosește verificatorul?
Portul 443, portul HTTPS standard. Serverele de e-mail și alte servicii aflate pe alte porturi nu sunt acoperite de această verificare.
De ce îmi arată verificatorul alt certificat decât browserul meu?
Gazda poate fi în spatele unui CDN sau al unui load balancer care servește certificate diferite în funcție de locație, sau browserul dumneavoastră poate ajunge la o adresă IPv6 în timp ce XGM folosește IPv4. Verificați adresa la care se rezolvă numele.
Ce este un Subject Alternative Name?
Extensia de certificat care listează fiecare nume de gazdă pentru care certificatul este valabil. Browserele o folosesc în locul câmpului mai vechi common name.
Pot verifica o gazdă privată sau internă?
Nu. XGM refuză adresele private, de loopback și interne. Pentru serviciile interne folosiți openssl s_client din interiorul rețelei dumneavoastră.
Un certificat valabil înseamnă că site-ul este sigur?
Înseamnă că legătura este criptată către un server care controlează domeniul. Nu spune nimic despre cât de demn de încredere este site-ul în sine.
Cât de des ar trebui să verific certificatele?
Continuu, prin monitorizare, cu alerte trimise cu mult înainte de expirare. Verificările manuale sunt utile după migrări și după schimbări de configurație.