SSL/TLS-Vertrauenskette - PKI und Zertifikatsprüfung

4 November 2025 in HEXSSL Insight, Sicherheit

Von uns: Mit diesem Artikel beginnen wir eine neue Publikationsreihe auf unserer Website: HEXSSL Insight. Dabei handelt es sich um ausführliche Fachbeiträge, die unser Wissen durch zahlreiche praxisnahe Beispiele ergänzen. Wir hoffen, dass die darin enthaltenen Informationen helfen, alle Aspekte der Online-Sicherheit besser zu verstehen.

Jede sichere HTTPS-Sitzung beginnt mit einer grundlegenden Frage: Kann man der Website, mit der ich eine Verbindung herstelle, wirklich vertrauen?
Die Antwort hängt nicht ausschließlich von der Verschlüsselung ab – entscheidend ist, wer die Identität des Servers bestätigt hat.
Dieser Mechanismus bildet das Fundament der PKI (Public Key Infrastructure), die die globale SSL/TLS-Vertrauenskette aufbaut und aufrechterhält.

In der Praxis vertraut ein Browser einer Website nicht, weil sie ein Zertifikat besitzt, sondern weil dieses Zertifikat von einer Zertifizierungsstelle (CA) signiert wurde, die sich in seinem vertrauenswürdigen Speicher (Trust Store) befindet.
Wenn der Browser oder das Betriebssystem eine bestimmte Root-CA kennt und ihr vertraut, und diese Root-CA direkt oder indirekt die Echtheit des Serverzertifikats bestätigt hat, gilt die Verbindung als sicher.

Dieser Mechanismus garantiert drei Dinge:

Authentifizierung – die Website ist tatsächlich diejenige, die sie vorgibt zu sein.
Integrität – die übertragenen Daten wurden während der Übertragung nicht verändert.
Vertraulichkeit – die Daten sind verschlüsselt und für Dritte unlesbar.

Erst wenn diese Bedingungen erfüllt sind, zeigt der Browser das Schlosssymbol 🔒 an.
Es ist wichtig zu verstehen, dass Verschlüsselung (HTTPS) ohne Vertrauen keine Sicherheit bedeutet – ein Server kann ein selbstsigniertes Zertifikat verwenden, das von keiner vertrauenswürdigen Stelle geprüft wurde.

Inhaltsverzeichnis

Vertrauensarchitektur – das Fundament der PKI.

Die Public Key Infrastructure (PKI) ist ein verteiltes System von Entitäten, Richtlinien und kryptografischen Mechanismen, das die gegenseitige Überprüfung von Identitäten ermöglicht.
Ihre Struktur besteht aus drei Schichten:

Root CA – eine übergeordnete, selbstsignierte Zertifizierungsstelle, die die Quelle des Vertrauens bildet.
Intermediate CA – untergeordnete Stellen, die Endzertifikate im Namen der Root-CA ausstellen.
End-Entity (Leaf) – Endzertifikate, die auf Webservern, E-Mail-Systemen oder Anwendungen installiert sind.

Jedes Zertifikat in der Kette enthält eine digitale Signatur – einen Hash seines Inhalts, verschlüsselt mit dem privaten Schlüssel des Ausstellers.
Der Browser überprüft diese Signatur mit dem öffentlichen Schlüssel des übergeordneten Zertifikats.
Dieser Prozess wiederholt sich bis zur Root-CA, die selbstsigniert und im Betriebssystem oder Browser lokal gespeichert ist.

Wie entsteht eine Vertrauenskette?

Die Root-CA stellt ein Zwischenzertifikat (Intermediate CA) aus.
Die Intermediate-CA signiert das Endzertifikat (z. B. für die Domain hexssl.pl).
Der Server präsentiert dem Browser sowohl sein Zertifikat als auch die Zwischenkette.
Der Browser verbindet alle Glieder der Kette und ordnet sie einer bekannten Root-CA im Trust Store zu.

Wenn ein Glied der Kette ungültig ist (z. B. fehlendes Intermediate oder falsche Signatur), wird die Verbindung abgelehnt.

Warum ein hierarchisches Modell?

Die hierarchische Struktur der PKI gewährleistet Kontrolle und Widerstandsfähigkeit.
Root-Zertifikate werden in sicheren HSM-Modulen (Hardware Security Modules) aufbewahrt und nur bei Bedarf aktiviert – z. B. zur Ausstellung neuer Intermediate-Zertifikate.
Dadurch wird das Risiko einer Kompromittierung des Root-Schlüssels auf ein Minimum reduziert.
Wird hingegen eine Intermediate-CA kompromittiert, kann sie von der Root-CA widerrufen werden, ohne das gesamte System zu gefährden.

Wichtige Zertifikatsparameter.

Jedes Zertifikat enthält Felder wie:

Subject CN/SAN – die Identität der Domain oder Organisation,
Issuer – der Aussteller (übergeordnetes Zertifikat),
Serial Number – eindeutige Seriennummer,
Signature Algorithm – Signaturalgorithmus (z. B. sha256RSA),
Validity – Gültigkeitszeitraum,
Key Usage / Extended Key Usage – zulässige Verwendungszwecke (Serverauthentifizierung, Code Signing usw.).

Administrator:innen können diese Felder lokal einsehen:

openssl x509 -in cert.pem -noout -text

So lässt sich der Aussteller, die Signatur, der Gültigkeitszeitraum und die gesamte Kette leicht prüfen.

Root-CA – das Herz des Vertrauenssystems.

Die Root-CA ist die oberste Instanz der PKI-Hierarchie – die „Quelle der Wahrheit“, von der alle anderen Zertifikate ableiten.
Sie ist selbstsigniert und hat keinen übergeordneten Aussteller. Ihr öffentlicher Schlüssel ist im Betriebssystem oder Browser als Teil des Trust Stores eingebettet.

Lebenszyklus der Root-CA.

Root-Zertifikate haben typischerweise eine Lebensdauer von 20 bis 30 Jahren.
Während dieser Zeit werden mehrere Generationen von Zwischenzertifikaten ausgestellt.
Private Schlüssel werden in physischen HSMs gespeichert, der Zugriff ist streng kontrolliert.
Da die Root-CA höchste Vertrauensstufe genießt, wird sie nur selten aktiviert – meist nur zur Ausstellung einer neuen Intermediate-CA, oft im Rahmen einer formellen „Signing Ceremony“.

Root-Store-Programme.

Jedes große Ökosystem pflegt sein eigenes Root-Programm:

Mozilla Root Program (Firefox, Thunderbird)
Microsoft Trusted Root Program (Windows)
Apple Root Store
Google Root Program (Chrome / Android)

Eine Root-CA muss strenge Sicherheits- und Compliance-Anforderungen erfüllen (WebTrust-Audit, CA/B-Forum-Regeln), um aufgenommen zu werden.

Beispiel: USERTrust RSA Root CA vs R46/E46.

In den Jahren 2024–2025 begannen viele Zertifikatsanbieter (darunter Sectigo) mit der Migration von der alten USERTrust RSA Root CA auf die neuen R46/E46-Roots mit längeren Schlüsseln und dem Algorithmus SHA-384.
Für Administrator:innen bedeutet das, dass alte Ketten durch neue ersetzt werden können und ältere Geräte ggf. Validierungsfehler melden.

Zur Überprüfung, welche Root-CA Ihr Zertifikat verwendet:

openssl s_client -connect example.com:443 -showcerts

oder nutzen Sie das Tool HEXSSL SSL Checker, das automatisch die Kette und den Root-Anker identifiziert.

Intermediate CA – die Ebene des vermittelten Vertrauens.

Eine Intermediate-CA (Zwischenzertifizierungsstelle) fungiert als Bindeglied zwischen der Root-CA und den Endzertifikaten.
Sie signiert tatsächlich die Zertifikate, die auf Webservern, APIs oder E-Mail-Diensten verwendet werden. Dadurch kann die Root-CA offline bleiben, während der Betrieb flexibel Zertifikate ausstellen und erneuern kann.

Warum sind Zwischenzertifikate unverzichtbar?

Sicherheit: Die Nutzung des Root-Schlüssels wird auf ein Minimum reduziert, wodurch das Risiko einer Kompromittierung stark sinkt.
Skalierbarkeit: Intermediates können geografisch oder thematisch verteilt werden (z. B. DV, OV, EV).
Kontrolle & Auditierbarkeit: Jede Intermediate-CA verfügt über eine eigene CPS-Richtlinie (Certification Practice Statement) und ist für ihre ausgestellten Zertifikate verantwortlich.

Typische Fehler im Zusammenhang mit Intermediate-CAs.

Der häufigste Implementierungsfehler ist das Fehlen der vollständigen Zertifikatskette auf dem Server.
Wenn das Zwischenzertifikat nicht korrekt mitgeliefert wird, kann der Browser die Vertrauenskette nicht aufbauen und zeigt den Fehler „incomplete chain“ an.

Korrekte Konfiguration für Nginx:

ssl_certificate     /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/domain.key;

Die Datei fullchain.pem muss zuerst das Domain-Zertifikat und anschließend alle Intermediates bis zur Root-CA enthalten (die Root selbst wird weggelassen).

In Apache:

SSLCertificateFile /etc/ssl/certs/domain.crt
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt
SSLCertificateKeyFile /etc/ssl/private/domain.key

Fehlende Ketten können mit dem HEXSSL SSL Checker sofort diagnostiziert werden, der die Struktur und Signatur aller Zertifikate analysiert.

Kurzlebigkeit von Intermediates.

Zwischenzertifikate sind üblicherweise 3–7 Jahre gültig, was regelmäßige Erneuerungen und die Einführung neuer Algorithmen ermöglicht.
Nach Ablauf dieses Zeitraums stellt die Root-CA ein neues Intermediate-Zertifikat aus – ein für Endnutzer transparenter, aber für die Vertrauensintegrität entscheidender Prozess.

Wie Browser und Systeme die Vertrauenskette prüfen.

Wenn ein Benutzer eine HTTPS-Verbindung zu einer Website herstellt, prüft der Browser nicht nur, ob ein Zertifikat vorhanden ist.
Er führt eine Reihe kryptografischer Tests durch, um sicherzustellen, dass:

das Zertifikat gültig signiert ist,
die Vertrauenskette vollständig ist,
das Zertifikat zeitlich gültig ist,
die Domain dem CN/SAN-Eintrag entspricht,
und das Zertifikat nicht widerrufen wurde.

Phasen der Zertifikatsvalidierung.

Der Validierungsprozess besteht aus mehreren Schritten:

Empfang des Serverzertifikats – während des TLS-Handshakes erhält der Client das Serverzertifikat und (sofern richtig konfiguriert) die komplette Zwischenkette.
Aufbau der Kette – der Browser oder die TLS-Bibliothek versucht, jedes Zertifikat mit seinem Aussteller zu verknüpfen, bis eine bekannte Root-CA erreicht ist.
Überprüfung der Signaturen – jede Signatur wird kryptografisch geprüft.
Überprüfung der Gültigkeitszeiträume – keine abgelaufenen oder zukünftigen Zertifikate.
Abgleich von CN/SAN – die Domain muss mit dem Eintrag im Feld Subject Alternative Name übereinstimmen.
Überprüfung auf Widerruf (OCSP/CRL).
Prüfung von Richtlinien und Erweiterungen – Extended Key Usage, Pfadlängenbeschränkungen usw.

Validierung mit OpenSSL.

Administrator:innen können die Validierung manuell prüfen:

openssl verify -CAfile chain.pem cert.pem

oder direkt vom Server aus:

openssl s_client -connect example.com:443 -showcerts -verify 5

Der Parameter -verify definiert die Prüftiefe (Kettenlänge).
Erscheint ein Fehler wie unable to get local issuer certificate oder self-signed certificate in chain, fehlt meist ein Intermediate-Zertifikat.

Unterschiede zwischen Implementierungen.

Jedes System hat eigene Validierungsmechanismen:

Chrome/Chromium – nutzt die eigene cert_verify_proc-Engine mit dynamischem Chain-Building,
Firefox – verwendet die NSS-Bibliothek und den Mozilla-Root-Store,
OpenSSL/cURL – basiert auf der Datei ca-bundle.crt,
Java/Tomcat – nutzt den Keystore cacerts.

Daher kann eine funktionierende Konfiguration in einem System in einem anderen fehlschlagen.
Es ist ratsam, Zertifikate in mehreren Browsern und Plattformen zu testen.

OCSP, CRL und Zertifikatswiderruf.

Vertrauen bedeutet nicht nur gültige Signaturen – ein korrekt ausgestelltes Zertifikat kann jederzeit ungültig werden, z. B. bei kompromittierten privaten Schlüsseln oder fehlerhafter Ausstellung.
Deshalb existieren Mechanismen zum Widerruf (Revocation), die es ermöglichen zu prüfen, ob ein Zertifikat vor Ablauf seiner Gültigkeit zurückgezogen wurde.

CRL – Certificate Revocation List.

Die CRL ist der älteste und einfachste Widerrufsmechanismus.
Die Zertifizierungsstelle veröffentlicht regelmäßig eine Liste mit Seriennummern widerrufener Zertifikate.
Jedes Zertifikat enthält das Feld CRL Distribution Points mit einer HTTP- oder LDAP-URL, unter der die Liste abrufbar ist.

Prüfung einer CRL lokal:

openssl crl -in crl.pem -noout -text

oder kombiniert:

openssl verify -crl_check -CAfile ca.crt cert.pem

Nachteile von CRLs:

Die Listen können sehr groß sein (mehrere MB),
Browser laden sie selten in Echtzeit,
Aktualisierungsverzögerungen von mehreren Stunden oder Tagen sind möglich.

Daher wird CRL zunehmend durch OCSP ersetzt.

OCSP – Online Certificate Status Protocol.

OCSP ermöglicht die Echtzeit-Überprüfung des Zertifikatsstatus.
Anstatt eine gesamte Liste herunterzuladen, sendet der Client eine Anfrage mit der Seriennummer des Zertifikats an den OCSP-Server der CA und erhält die Antwort: good, revoked oder unknown.

Beispiel mit OpenSSL:

openssl ocsp -issuer intermediate.pem -cert cert.pem -url http://ocsp.sectigo.com

OCSP Stapling.

Zur Beschleunigung kann der Webserver eine aktuelle OCSP-Antwort selbst im TLS-Handshake mitliefern – das sogenannte OCSP Stapling.
Dadurch muss der Browser keine externe Anfrage stellen, was Leistung und Datenschutz verbessert.

Beispielkonfiguration für Nginx:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt;
resolver 8.8.8.8;

Empfohlen ist auch die Erweiterung OCSP Must-Staple, die erzwingt, dass jede TLS-Sitzung eine gültige OCSP-Antwort enthält.
Fehlt sie, wird die Verbindung blockiert.

Moderne Alternativen.

CRLite (Mozilla) – komprimierte Revocation-Daten auf Basis von Bloom-Filtern, aktualisiert mit jedem Firefox-Update.
SCVP (Server-Based Certificate Validation Protocol) – serverseitige Validierung.
OCSP MultiResponder – Aggregation von Antworten mehrerer CAs.

Diese Lösungen sind noch nicht Standard, zeigen aber den Trend: weg von schweren CRLs, hin zu schnellen, automatisierten Revocation-Systemen.

Cross-Signing und Root-Migrationen – Praxis und Risiken.

Das PKI-Ökosystem ist dynamisch – Root-Zertifikate laufen ab, neue Algorithmen entstehen, und Browser ändern ihre Anforderungen.
Um die Kompatibilität zu erhalten, verwenden Zertifizierungsstellen (CAs) Cross-Signing – also die Ausstellung eines Intermediate-Zertifikats, das von zwei verschiedenen Root-CAs signiert wurde.

Wie funktioniert Cross-Signing?

Angenommen, eine CA führt eine neue Root-CA ein, die in älteren Geräten noch nicht als vertrauenswürdig gilt.
Sie stellt daher ein Intermediate-Zertifikat aus, das sowohl von der neuen als auch von der alten Root-CA signiert ist.
Dadurch können neue Systeme die neue Kette nutzen, während ältere weiterhin die alte Root verwenden.
So bleibt die Vertrauenskette übergangsweise funktionsfähig.

Beispiel aus der Praxis:
Let’s Encrypt setzte Cross-Signing zwischen der neuen ISRG Root X1 und der älteren DST Root CA X3 ein, um Unterstützung für Android 7 und ältere Geräte sicherzustellen.

Potenzielle Probleme.

Cross-Signing ist nützlich, kann aber zu Mehrdeutigkeiten führen.
Ein Browser kann mehrere mögliche Ketten aufbauen.
Wenn eine der beteiligten Roots widerrufen oder abgelaufen ist, erhalten einige Nutzer plötzlich die Fehlermeldung „certificate not trusted“.
Bei Root-Migrationen – etwa USERTrust RSA → R46/E46 (Sectigo) – tritt ein ähnliches Problem auf:
Neue Roots sind möglicherweise in älteren Trust Stores noch nicht vorhanden, weshalb CAs für eine Übergangszeit Cross-Signed Intermediates bereitstellen.

Wir empfehlen Administrator:innen, bei jeder Zertifikatserneuerung folgende Punkte zu beachten:

Überprüfen Sie die gesamte Kette mit dem HEXSSL SSL Checker.
Stellen Sie sicher, dass die neuen Root-Zertifikate auf Zielsystemen (Windows, Android, macOS) vorhanden sind.
Importieren Sie keine Root-Zertifikate manuell – verlassen Sie sich ausschließlich auf offizielle Trust Stores.

Praktische Analyse einer Zertifikatskette.

Angenommen, ein Server präsentiert folgende Zertifikate:

example.com (Leaf)
Sectigo RSA Domain Validation Secure Server CA (Intermediate)
USERTrust RSA Certification Authority (Root)

OpenSSL zeigt:

depth=2 CN = USERTrust RSA Certification Authority
verify return:1
depth=1 CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = example.com
verify return:1

Der Status verify return:1 bedeutet, dass alle Zertifikate erfolgreich validiert wurden.

Wenn stattdessen erscheint:

verify error:num=20:unable to get local issuer certificate

bedeutet das, dass das lokale System das entsprechende Root- oder Intermediate-Zertifikat nicht kennt oder der Server es nicht bereitstellt.

Wie testet man die Vollständigkeit einer Kette?

Neben OpenSSL ist der einfachste Weg, den HEXSSL SSL Checker zu verwenden.
Dieses Tool prüft nicht nur die Vertrauenskette, sondern auch:

Schlüsseltyp und -länge,
Signaturalgorithmus,
OCSP-Stapling-Status,
Übereinstimmung von CN/SAN mit dem Hostnamen,
Gültigkeitszeitraum und Ablaufwarnungen.

Der HEXSSL Checker erstellt zusätzlich einen Sicherheitsbericht (Bewertung A–F) mit Handlungsempfehlungen.
Das Tool eignet sich als Bestandteil von TLS-Audits gemäß NIS2 oder ISO 27001.

Typische Implementierungsfehler und deren Folgen.

In der Theorie scheint die Installation eines SSL/TLS-Zertifikats einfach – man fügt Zertifikat, privaten Schlüssel und Intermediate hinzu.
In der Praxis führen schon kleine Konfigurationsfehler zu Warnungen oder Sperrungen in Browsern.
Im Folgenden listen wir die häufigsten Probleme aus HEXSSL-Audits auf.

1. Fehlendes Intermediate-Zertifikat („incomplete chain“).

Der häufigste Fehler – insbesondere bei älteren Apache-, Tomcat- oder Load-Balancer-Installationen.
Der Server präsentiert nur das Leaf-Zertifikat, aber keine vollständige Kette.

Symptom:
Der Browser zeigt „certificate chain incomplete“ oder „unable to get local issuer certificate“.

Folgen:

Einige Browser rekonstruieren die Kette aus Cache, viele (v. a. mobile Geräte) verweigern die Verbindung komplett.
Android- oder IoT-Geräte zeigen „site not secure“, obwohl das Zertifikat gültig ist.

Lösung:
Immer die vollständige Kette (full chain) bereitstellen – Domainzertifikat + Intermediate.
Für Nginx:

ssl_certificate     /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/domain.key;

Für Apache:

SSLCertificateFile      /etc/ssl/certs/domain.crt
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

2. Selbstsigniertes Zertifikat in Produktionsumgebungen.

Selbstsignierte Zertifikate eignen sich für Tests oder interne Netzwerke, bieten aber kein öffentliches Vertrauen.
Browser betrachten sie als unsicher.

Symptom: „Your connection is not private“ (NET::ERR_CERT_AUTHORITY_INVALID).

Folgen:

Verlust des Nutzervertrauens,
Sicherheits-Scanner blockieren den Zugriff,
negative Auswirkungen auf SEO und Trust-Rating.

Lösung:
Zertifikate ausschließlich von anerkannten CAs verwenden – kostenlose (z. B. Let’s Encrypt) sind möglich, sofern keine OV/EV-Validierung erforderlich ist.
Für kommerzielle Websites empfehlen wir Sectigo OV– oder EV-Zertifikate mit vollständiger Vertrauenskette.

3. Falsches CN oder SAN (Subject Alternative Name).

Seit 2017 ignorieren Browser das Feld Common Name (CN) und verlassen sich ausschließlich auf Subject Alternative Name.

Symptom:
Die Verbindung funktioniert für eine Domain, aber nicht für Subdomains oder Aliase.

Lösung:
Vor der CSR-Generierung müssen alle Domains definiert werden:

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
CN = www.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = www.example.com
DNS.2 = example.com
DNS.3 = api.example.com

Der CSR Generator auf unserer Website erstellt automatisch korrekte CSR-Dateien mit allen erforderlichen SAN-Einträgen.

4. Abgelaufene Zertifikate oder fehlende automatische Erneuerung.

SSL-Zertifikate sind maximal 398 Tage gültig.
Viele Ausfälle entstehen durch versäumte Verlängerungen – insbesondere bei mehreren Domains.

Symptom:
„Certificate has expired“ oder „ERR_CERT_DATE_INVALID“.

Lösung:
Monitoring und Automatisierung einführen.
Unser HEXSSL SSL Expiry Monitor überwacht die Gültigkeit mehrerer Domains und sendet Warnungen vor Ablauf.

5. Mixed Content – unverschlüsselte Inhalte auf HTTPS-Seiten.

Manche Webseiten laden Grafiken oder Skripte weiterhin über HTTP, obwohl das Hauptdokument per HTTPS geladen wird.

Symptom:
„This page is not fully secure“ oder Warnsymbol ⚠️ neben dem Schloss.

Lösung:
HTTPS für alle Ressourcen erzwingen:

Content-Security-Policy: upgrade-insecure-requests;

In WordPress kann dies über wp-config.php oder das Plugin „Really Simple SSL“ konfiguriert werden.

6. Fehlerhaftes OCSP-Stapling.

Dieser Fehler tritt auf, wenn der Server eine veraltete oder ungültige OCSP-Antwort liefert – meist durch fehlerhafte Caches oder Netzwerkprobleme.

Symptom:
„OCSP response invalid“ oder „revocation check failed“.

Lösung:
OCSP-Cache leeren, neue Antwort anfordern und sicherstellen, dass ssl_trusted_certificate auf die aktuelle CA-Bundle-Datei zeigt.

Wie Administrator:innen Zertifikatsketten testen sollten.

Administrator:innen sollten ihre SSL/TLS-Implementierungen regelmäßig prüfen – nicht nur bei der Erstinstallation, sondern nach jeder Serveraktualisierung, CA-Migration oder Root-Änderung.

Lokale Tests.

Die einfachsten Prüfungen können mit OpenSSL durchgeführt werden:

Gesamte Kette anzeigen:

openssl s_client -connect domain.tld:443 -showcerts

Validierung gegen vertrauenswürdige CAs:

openssl verify -CAfile ca-bundle.crt cert.pem

OCSP-Status prüfen:

openssl ocsp -issuer intermediate.pem -cert cert.pem -url http://ocsp.sectigo.com

Online-Test mit dem HEXSSL SSL Checker.

Der HEXSSL SSL Checker automatisiert all diese Schritte und präsentiert die Ergebnisse in einer übersichtlichen Struktur:

vollständige Vertrauenskette (Root → Intermediate → Leaf),
Signaturalgorithmen und Schlüssellängen,
OCSP- und CRL-Status,
Gültigkeitsdauer und verbleibende Tage bis zum Ablauf,
Empfehlungen zur TLS-Konfigurationssicherheit.

Beispielausgabe:

Kette: vollständig → OK
OCSP-Stapling: aktiv
Algorithmus: SHA256RSA 2048-bit → empfohlen
NIS2-konform: JA
Bewertung: A+

Fehlinterpretationen – wenn alles korrekt aussieht, aber nicht funktioniert.

Browser-Cache-Probleme.

Nach einer Zertifikatserneuerung kann der Browser aus seinem Cache einen veralteten Status anzeigen.
Lösung: SSL-Cache löschen (certutil -urlcache * delete in Windows) oder im Inkognito-Modus testen.

Unterschiedliches Verhalten von Betriebssystemen.

Android, iOS, Windows und Linux verwenden unterschiedliche Root-Stores.
Ein Zertifikat, das auf macOS funktioniert, kann auf Android 7 fehlschlagen.
In Produktionsumgebungen sollten Tests auf mindestens drei Plattformen erfolgen.

SNI-Konfigurationsfehler (Server Name Indication).

Wenn ein Server mehrere Domains hostet, aber das Zertifikat nicht korrekt an den jeweiligen Host gebunden ist, kann der Benutzer ein falsches Zertifikat sehen.
Lösung:

server_name in Nginx prüfen,
oder VirtualHost in Apache,
und sicherstellen, dass jede Domain das passende Zertifikat verwendet.

Unsere Empfehlungen für Administrator:innen und Unternehmen.

Aus unserer Erfahrung heraus empfehlen wir einige Grundsätze, die Risiken minimieren und Compliance-Anforderungen (NIS2, eIDAS 2.0, ISO 27001) erfüllen.

1. Vertrauen gestalten, nicht nur verschlüsseln.

Ein Zertifikat bedeutet mehr als nur ein „grünes Schloss“.
Jedes Glied der Kette – von der Root-CA bis zur Domain – muss korrekt konzipiert sein.
Verwenden Sie ausschließlich vertrauenswürdige CAs, vermeiden Sie Self-Signed-Zertifikate und testen Sie Ihre Kette nach jeder Änderung.

2. Starke Algorithmen und aktuelle Root-Zertifikate.

Empfohlene Parameter:

RSA ≥ 3072 Bit
ECDSA P-256 / P-384
Signaturen: SHA-256 oder SHA-384

Veraltete Algorithmen wie SHA-1 oder RSA 1024 sind nicht mehr CA/B-Forum-konform.

3. Erneuerungen automatisieren.

Automatisieren Sie CSR-Erstellung, Zertifikatsinstallation und Dienstneustarts (nginx, apache).
In großen Umgebungen empfiehlt sich ein zentrales ACME-Client-System (z. B. certbot, acme.sh) mit API-Integration.

4. Zertifikate überwachen und rechtzeitig reagieren.

Der HEXSSL SSL Expiry Monitor erlaubt das Hinzufügen mehrerer Domains und sendet Warnungen rechtzeitig vor Ablauf.
Empfohlene Benachrichtigungsstufen:

30 Tage vor Ablauf,
7 Tage vor Ablauf,
48 Stunden vor Ablauf.

5. Infrastruktur mindestens einmal jährlich auditieren.

Ein Audit sollte prüfen:

Vollständigkeit der Vertrauenskette,
TLS-Konfiguration (Protokolle, Cipher Suites, OCSP-Stapling),
Zertifikatslaufzeiten und Erneuerungsprozesse,
Schlüsselmanagement-Politik.

HEXSSL bietet spezialisierte SSL/TLS-Audit- und Zertifikatsprüfungen für Server- und Cloud-Umgebungen.
Weitere Informationen finden Sie unter HEXSSL Kontakt.

Vertrauen und Regulierung – NIS2, eIDAS 2.0 und Compliance.

Mit der Einführung der NIS2-Richtlinie und der Verordnung eIDAS 2.0 hat die Bedeutung von SSL/TLS-Zertifikaten den Rahmen technischer Maßnahmen verlassen und ist zu einer rechtlichen Anforderung geworden.

NIS2 verpflichtet Betreiber kritischer Dienste zur Verschlüsselung und Integrität der Kommunikation.
eIDAS 2.0 definiert die Grundlagen des europäischen digitalen Vertrauensraums (Digital Identity Wallets, QTSP).
SSL/TLS-Zertifikate werden zu einem Bestandteil der europäischen Trust Services-Infrastruktur.

HEXSSL unterstützt Organisationen bei der Anpassung ihrer TLS-Infrastruktur an die Anforderungen von NIS2 und eIDAS – durch Audits, Empfehlungen und Analysewerkzeuge (SSL Checker, OCSP Validator).

Fazit.

Die SSL/TLS-Vertrauenskette ist das Fundament der globalen Internetsicherheit.
Dank der hierarchischen PKI-Struktur und strenger Validierungsprozesse ermöglicht sie nicht nur Verschlüsselung, sondern auch die Verifizierung der Identität beider Kommunikationsparteien.
Jedes Glied der Kette – von der Root-CA bis zum Leaf-Zertifikat – spielt eine entscheidende Rolle für die Vertrauenswürdigkeit.
Ein fehlerhaftes oder fehlendes Glied kann die gesamte Kette kompromittieren.

Eine sichere SSL/TLS-Implementierung erfordert daher:

regelmäßige Tests und Audits,
automatisierte Erneuerungen,
OCSP/CRL-Monitoring,
und eine bewusste Auswahl der CA und Algorithmen.

HEXSSL unterstützt Administrator:innen und Unternehmen mit Tools, die jeden Schritt des Zertifikatslebenszyklus vereinfachen – von der CSR-Erstellung bis zur vollständigen Kettenvalidierung und Ablaufüberwachung.

FAQ – Häufig gestellte Fragen.

1. Was ist der Unterschied zwischen Root-CA und Intermediate-CA?
Die Root-CA ist die übergeordnete Zertifizierungsstelle, die Intermediate-CAs signiert.
Intermediate-CAs stellen Endzertifikate für Domains aus.
Die Root bleibt offline und ist in Trust Stores verankert.

2. Warum zeigt der Browser „incomplete chain“?
Der Server sendet nicht die vollständige Zertifikatskette.
Die Datei fullchain.pem muss sowohl das Domain- als auch das Intermediate-Zertifikat enthalten.

3. Ist Let’s Encrypt so sicher wie kostenpflichtige Zertifikate?
Ja – hinsichtlich Verschlüsselung.
Der Unterschied liegt in der Validierung: Let’s Encrypt bietet nur DV (Domain Validation),
während kostenpflichtige OV/EV-Zertifikate die Organisation prüfen und finanzielle Garantien beinhalten.

4. Wie kann ich prüfen, welche Root-CA mein Zertifikat verwendet?
Mit:

openssl s_client -connect domain.de:443 -showcerts

oder über den HEXSSL SSL Checker.

5. Warum vertraut der Browser meinem Zertifikat trotz HTTPS nicht?
Meist fehlt der passende Root im Trust Store oder die Kette ist unvollständig.

6. Wie oft sollte ein SSL-Zertifikat erneuert werden?
Maximal gültig: 398 Tage.
Empfohlen: jährliche Erneuerung mit automatischem Monitoring (z. B. HEXSSL Expiry Monitor).

7. Was ist OCSP-Stapling und sollte ich es aktivieren?
OCSP-Stapling übermittelt den Zertifikatsstatus direkt vom Server.
Es erhöht Leistung und Datenschutz – unbedingt aktivieren!

8. Bietet EV-Zertifizierung mehr technische Sicherheit?
Nein – die Verschlüsselung ist identisch.
EV bietet aber höhere Identitätsprüfung und stärkt das Markenvertrauen.

9. Was bedeutet „cross-signed“?
Ein Intermediate-Zertifikat wurde von zwei verschiedenen Root-CAs signiert, um Kompatibilität während einer Root-Migration sicherzustellen.

10. Wie unterstützt HEXSSL das SSL/TLS-Management?
HEXSSL stellt eine Suite professioneller Tools bereit:

CSR Generator – erstellt korrekte Anfragen mit CN/SAN,
SSL Checker – prüft Kette und TLS-Konfiguration,
Expiry Monitor – überwacht Ablaufdaten,
Decoder & Validator – analysieren OCSP/CRL-Status und Metadaten.

SSL/TLS-Vertrauenskette in der Praxis – wie die Zertifikatsvalidierung wirklich funktioniert