Zertifikatsvalidierung in TLS

Ohne Zertifikatsvalidierung könnte eine TLS-Verbindung zu einem Angreifer aufgebaut werden, der sich als Server ausgibt (Man-in-the-Middle). Die Zertifikatsvalidierung stellt sicher, dass Sie mit dem legitimen Server kommunizieren, der den privaten Schlüssel kontrolliert.

Wichtige Felder: Subject (wem das Zertifikat gehört), SubjectAltName (DNS-Namen/IPs), Issuer (signierende CA), Validity (notBefore/notAfter), Public Key, Signature. Der Browser prüft all diese Felder.

Serverzertifikat → Intermediate-CA-Zertifikat → Root-CA-Zertifikat. Die Root-CA ist selbstsigniert und im Trust Store des Betriebssystems oder Browsers vorinstalliert. Der Server sendet sein Zertifikat zusammen mit den Zwischenzertifikaten in der Certificate-Nachricht des TLS-Handshakes.

Jedes Zertifikat wird vom übergeordneten Aussteller signiert. Der Client prüft: signature(cert_n) using public_key(cert_{n+1}). Wenn eine Signatur ungültig ist, wird die Kette abgelehnt. Der Root-CA wird durch Vorinstallation vertraut, nicht durch ihre Signatur.

Der Client prüft, ob der Hostname des Servers mit dem Subject oder SubjectAltName (DNS-Einträge) des Zertifikats übereinstimmt. Wildcards (*.example.com) stimmen mit genau einem Label überein. Seit 2000 hat SAN bei der Hostnamenprüfung Vorrang vor CN.

Der Client prüft für jedes Zertifikat in der Kette notBefore ≤ now ≤ notAfter. Abgelaufene Zertifikate werden auch dann abgelehnt, wenn ihre Signaturen gültig sind. Die Gültigkeitsdauer von Zertifikaten wurde verkürzt: Browser begrenzen sie inzwischen auf etwa 398 Tage.

Die CA veröffentlicht eine Certificate Revocation List (CRL) – eine signierte Liste der Seriennummern widerrufener Zertifikate. Der Client lädt die CRL-URL aus der Erweiterung CRL Distribution Points des Zertifikats herunter und prüft, ob die Seriennummer enthalten ist.

Das Online Certificate Status Protocol (OCSP) ermöglicht es Clients, den OCSP-Responder der CA nach dem Status eines einzelnen Zertifikats zu fragen. Es ist schneller als eine CRL, verursacht aber zusätzliche Latenz. Beim OCSP Stapling fügt der Server eine signierte OCSP-Antwort in den TLS-Handshake ein.

CT (RFC 6962) verpflichtet CAs, alle ausgestellten Zertifikate in öffentlichen, nur erweiterbaren Logs zu protokollieren. Browser prüfen Signed Certificate Timestamps (SCTs) im Zertifikat oder in einer TLS-Erweiterung. Dadurch bleibt eine fehlerhafte Ausstellung nicht unbemerkt.

HTTP Public Key Pinning (HPKP, veraltet) und Certificate Pinning in mobilen Apps legen einen bestimmten Public Key oder Zertifikat-Hash fest. Wenn der Server ein anderes Zertifikat präsentiert, wird die Verbindung auch dann abgelehnt, wenn es gültig ist – dadurch werden Angriffe nach einer Kompromittierung einer CA verhindert.

ERR_CERT_AUTHORITY_INVALID: Root-CA nicht vertrauenswürdig. ERR_CERT_DATE_INVALID: abgelaufen. ERR_CERT_COMMON_NAME_INVALID: Hostname stimmt nicht überein. NET::ERR_CERT_REVOKED: Laut OCSP/CRL widerrufen. Jeder Fehler entspricht dem Fehlschlagen eines bestimmten Validierungsschritts.

Was bewirkt OCSP Stapling?

Die Zertifikatsvalidierung in TLS umfasst die Prüfung der Kette und der Signaturen, den Abgleich des Namens, die Gültigkeitszeiträume und den Widerruf. Als Nächstes geht es um historische TLS-Angriffe und darum, wie TLS 1.3 sie abwehrt.