SSL-tanúsítvány ellenőrzése

Mit ellenőriz ez a teszt?

A KernelHost SSL Checker TLS-kézfogással lekéri a szerver tanúsítványát a frankfurti csomópontunkról, és külső szolgáltatás nélkül megmutatja a legfontosabb mezőket. A következőket ellenőrzi és jeleníti meg:

• Kibocsátva neki és kibocsátója: Common Name (Subject CN), a teljes Subject DN és az Issuer (melyik CA írta alá a tanúsítványt).
• Érvényességi időszak: Kezdő- és záródátum UTC-ben, plusz a hátralévő napok. Színkódolva: zöld (>30 nap), narancs (7 és 30 nap között), piros (kevesebb mint 7 nap, vagy már lejárt).
• Subject Alternative Names (SANs): A tanúsítvány által lefedett hosztnevek teljes listája, a wildcard bejegyzésekkel együtt.
• Hosztnév-egyezés: Ellenőrzi, hogy a megadott domaint valóban lefedi-e a Common Name vagy egy SAN wildcard (RFC 6125).
• Kulcs és aláírás: A publikus kulcs algoritmusa (RSA, ECDSA), a kulcs mérete bitben vagy a görbe neve, és az aláírási algoritmus.
• Fingerprintek és sorozatszám: A DER-kódolt tanúsítvány SHA-256 és SHA-1 fingerprintje, valamint a hexadecimális sorozatszám.
• Teljes lánc: A szerver által a kézfogás során elküldött összes tanúsítvány subject, issuer és szerep (leaf, köztes, gyökér) szerint.

Gyakori SSL-hibák és jelentésük

A böngészők gyakran rejtélyes hibákat mutatnak, mint NET::ERR_CERT_DATE_INVALID vagy SSL_ERROR_BAD_CERT_DOMAIN. Itt a leggyakoribb okok és megoldásaik:

• Tanúsítvány lejárt: A notAfter dátum a múltban van. A böngészők teljesen blokkolják az oldalt. Megoldás: újítsa meg a tanúsítványt. Let's Encrypt esetén ez 60 naponta automatikus a certbot vagy acme.sh révén.
• Hosztnév-eltérés: A hosztnév sem a Common Name-ben, sem egy SAN-ban nincs. Megoldás: újrakibocsátáskor adja hozzá az összes szükséges domaint és aldomaint SAN-ként.
• Önaláírt vagy ismeretlen CA: Az Issuer nem megbízható gyökér CA. A böngészők NET::ERR_CERT_AUTHORITY_INVALID-ot mutatnak. Megoldás: szerezzen tanúsítványt elismert CA-tól, mint a Let's Encrypt, ZeroSSL, Sectigo vagy DigiCert.
• Hiányos lánc: A szerver csak a leaf tanúsítványt küldi köztesek nélkül. Mobilböngészők és régi eszközök elhasalnak. Megoldás: állítsa be a teljes láncot (fullchain.pem) a webszerveren.
• Gyenge kulcs vagy gyenge aláírás: 2048 bit alatti RSA vagy SHA-1 aláírás már nem elfogadott. Megoldás: újrakibocsátás RSA 2048+ vagy ECDSA P-256 használatával.
• Mixed content és HSTS-csapda: Ha korábban érvényes HSTS fejlécet küldött, és a tanúsítvány lejár, a látogatók nem tudnak átkattintani a figyelmeztetésen. Azonnali teendő: újítsa meg a tanúsítványt, vészhelyzetben csökkentse a HSTS max-age-et.

Let's Encrypt és kereskedelmi tanúsítványok összehasonlítása

A Let's Encrypt egy ingyenes, automatizált CA, amelyet az ISRG működtet. A tanúsítványok technikailag azonosak a kereskedelmi DV-tanúsítványokkal, és minden modern böngésző megbízhatónak tekinti őket.

Mikor érdemes fizetős tanúsítványt választani? Valójában csak különleges esetekben:

• Extended Validation (EV): Korábban zöld címsorral, ma már alig látható. Csak bankoknak vagy kereskedési platformoknak éri meg, ha a jog megköveteli.
• Wildcard DNS-kihívás nélkül: A Let's Encrypt csak DNS-01 kihíváson keresztül támogatja a wildcardokat. Ha nincs API-hozzáférés a DNS-hez, a ZeroSSL Premium vagy a Sectigo alternatíva.
• Garancia és biztosítás: A kereskedelmi CA-k biztosítási összeget kínálnak hibás kibocsátás esetére. A gyakorlatban ritkán releváns, de bizonyos compliance-keretrendszerek megkövetelik.

A KernelHost Webhosting és cPanel alapértelmezésben tartalmazza az ingyenes Let's Encrypt-integrációt. A tanúsítványokat 60 naponta automatikusan megújítja az AutoSSL anélkül, hogy bármit tennie kellene. Wildcard tanúsítványok DNS-kihíváson keresztül is lehetségesek, amint a domain a KernelHost DNS-én van.

TLS 1.2 és TLS 1.3 összehasonlítása

A TLS 1.2 2008 óta szabvány, a TLS 1.3-at 2018-ban tették közzé RFC 8446-ként, és 2020 óta széles körben elterjedt. A régebbi verziók (SSL 3.0, TLS 1.0, TLS 1.1) nem biztonságosak, és le kell tiltani őket a szerverkonfigurációban.

Miben jobb a TLS 1.3:

• Gyorsabb kézfogás: 1-RTT helyett 2-RTT, plusz opcionális 0-RTT a folytatáshoz. TLS-nehéz oldalakon érezhetően gyorsabb.
• Tisztább cipher-készlet: Csak 5 engedélyezett AEAD cipher suite. Nincs több RSA kulcscsere, mindig forward secrecy.
• Titkosított kézfogás: Maga a szerver tanúsítványa titkosítva kerül átvitelre. ESNI/ECH esetén még a SNI is privát.
• Visszafelé kompatibilis: A szerverek a TLS 1.2-t és 1.3-at párhuzamosan kínálhatják. A böngészők automatikusan a legmagasabb közös verziót egyeztetik.

Mit jelent egy lejárt tanúsítvány?

Egy lejárt SSL-tanúsítvány konkrétan azt jelenti: a böngészők teljes képernyős figyelmeztetést mutatnak, és letiltják az oldalt. A látogatók a legtöbb esetben nem tudnak átkattintani, különösen aktív HSTS fejléc mellett.

Következmények az üzemeltetőre:

• Ranglista-veszteség a Google-nél (a HTTPS rangsorolási tényező, és a bizalomhoz kapcsolódó jelek számítanak).
• A levelezőszerverek (MX/SMTP STARTTLS-sel) elutasítják a bejövő kapcsolatokat, a levelek visszapattannak vagy késve kerülnek kézbesítésre.
• A certificate pinninget használó API-kliensek és mobilalkalmazások meghibásodnak, esetleg alkalmazásfrissítésre van szükség.

HSTS, CAA és OCSP stapling

Az érvényes tanúsítvány csak a kezdet. Három további mechanizmus emeli a TLS-biztonságot legjobb gyakorlat szintjére:

• HSTS (HTTP Strict Transport Security): Fejléc, amely arra kényszeríti a böngészőket, hogy mostantól csak HTTPS-t használjanak. Ajánlott: max-age=63072000; includeSubDomains; preload (két év, minden aldomain, preload lista). Aktiváláskor óvatosan, hibás konfiguráció nem visszafordítható, amíg a max-age fut.
• CAA (Certification Authority Authorization): DNS-rekord, amely meghatározza, mely CA-k bocsáthatnak ki tanúsítványt a domainjére. Példa: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' megakadályozza más CA-k téves kibocsátását.
• OCSP stapling: A webszerver maga adja át a CA visszavonási státusz válaszát ahelyett, hogy minden böngésző külön kérdezné a CA-t. Gyorsabb a látogatóknak, és kíméletesebb a CA-infrastruktúrával. Apache: SSLUseStapling On, nginx: ssl_stapling on.

Adatvédelem

A KernelHost SSL Checker teljes egészében a frankfurti csomópontunkon fut, harmadik féltől származó hívás nélkül:

• Nincs továbbítás külső API-knak (nincs SSL Labs, Hardenize vagy Cryptomon).
• Nem tároljuk az ellenőrzött domaint a szabványos kéréslogon kívül (webszerver-log, 14 napos megőrzés).
• Anti-SSRF szűrő blokkolja a privát IP-tartományokra, loopbackre és link-localra irányuló kéréseket.
• IP-nkénti rate limit visszaélések ellen. Opcionális hCaptcha küldéskor.

GYIK az SSL-tanúsítványokról