Anwendungsfälle für Zertifikate

Transport Layer Security (TLS)

Welche zwei Fragen muss ein Client stellen, wenn er ein Zertifikat von einem Server erhält?

1. Ist das Zertifikat gültig und vertrauenswürdig? Der Client muss prüfen, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde und ob es weder abgelaufen noch gesperrt ist. Dazu gehört, den Gültigkeitszeitraum des Zertifikats zu prüfen und sicherzustellen, dass es von einer CA signiert ist, der der Client vertraut.
2. Passt das Zertifikat zur Identität des Servers? Der Client muss sicherstellen, dass die Angaben im Zertifikat, etwa der Common Name (CN) oder der Subject Alternative Name (SAN), zum Domainnamen des Servers passen. So bestätigt sich, dass das Zertifikat tatsächlich für den Server gedacht ist, zu dem der Client eine Verbindung aufbauen will.

Wie prüft der Client, ob einem Zertifikat vertraut werden kann?

1. Vertrauenskette des Zertifikats prüfen: Der Client prüft die Zertifikatskette, zu der das Zertifikat des Servers, etwaige Intermediate-Zertifikate und das Stammzertifikat gehören. Jedes Zertifikat der Kette muss von der jeweils nächsthöheren Instanz signiert sein und letztlich zu einem vertrauenswürdigen Stammzertifikat führen.
2. Gültigkeitszeitraum des Zertifikats prüfen: Der Client prüft den Gültigkeitszeitraum des Zertifikats, um sicherzustellen, dass es weder abgelaufen noch noch nicht gültig ist. Dazu gehört die Prüfung der Daten „Not Before“ und „Not After“ im Zertifikat.
3. Zertifikat der Identität des Servers zuordnen: Der Client stellt sicher, dass der Common Name (CN) oder der Subject Alternative Name (SAN) des Zertifikats zum Domainnamen des Servers passt. Damit ist bestätigt, dass das Zertifikat für den Server gedacht ist, mit dem sich der Client verbindet.
4. Auf Sperrung prüfen: Der Client prüft, ob das Zertifikat gesperrt wurde, indem er die Certificate Revocation List (CRL) abfragt oder das Online Certificate Status Protocol (OCSP) nutzt. Einem gesperrten Zertifikat wird nicht mehr vertraut.
5. Digitale Signatur prüfen: Der Client prüft die digitale Signatur des Zertifikats, um sicherzustellen, dass es nicht manipuliert wurde. Dazu wird die kryptografische Signatur gegen den öffentlichen Schlüssel der ausstellenden CA geprüft.

Wie prüft der Client, ob der Server wirklich der Inhaber eines Zertifikats ist?

1. Prüfung der Zertifikatskette: Der Client prüft die Zertifikatskette und stellt sicher, dass jedes Zertifikat der Kette von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) signiert ist. Diese Kette beginnt beim Zertifikat des Servers und endet bei einem vertrauenswürdigen Stammzertifikat.
2. Abgleich des Domainnamens: Der Client prüft, ob der Common Name (CN) oder der Subject Alternative Name (SAN) des Zertifikats zum Domainnamen des Servers passt. Damit ist sichergestellt, dass das Zertifikat für den Server gedacht ist, mit dem sich der Client verbindet.
3. Prüfung der digitalen Signatur: Der Client prüft die digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der ausstellenden CA. Damit ist sichergestellt, dass das Zertifikat nicht manipuliert wurde und tatsächlich von einer vertrauenswürdigen CA ausgestellt ist.
4. Gültigkeitszeitraum des Zertifikats: Der Client prüft den Gültigkeitszeitraum des Zertifikats, um sicherzustellen, dass es aktuell gültig und nicht abgelaufen ist.
5. Prüfung des Sperrstatus: Der Client prüft, ob das Zertifikat gesperrt wurde, indem er die Certificate Revocation List (CRL) abfragt oder das Online Certificate Status Protocol (OCSP) nutzt. Einem gesperrten Zertifikat wird nicht mehr vertraut.

Warum ist die Inhaberschaft wichtig, wenn du bereits geprüft hast, dass dem Zertifikat vertraut wird?

Gültigkeit und Vertrauenswürdigkeit des Zertifikats: Dieser Schritt stellt sicher, dass das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde, innerhalb seines Gültigkeitszeitraums liegt und nicht gesperrt wurde. Er bestätigt, dass das Zertifikat legitim ist und nicht manipuliert wurde.

Prüfung der Serveridentität: Selbst wenn ein Zertifikat gültig und vertrauenswürdig ist, muss zusätzlich bestätigt werden, dass es zu dem Server gehört, mit dem du dich verbindest. Dazu wird geprüft, ob der Common Name (CN) oder der Subject Alternative Name (SAN) des Zertifikats zum Domainnamen des Servers passt. Dieser Schritt stellt sicher, dass das Zertifikat für genau diesen Server gedacht ist, und verhindert Man-in-the-Middle-Angriffe, bei denen ein Angreifer ein gültiges Zertifikat für eine andere Domain vorlegt.

Mit welchen zwei Methoden beantwortet der Client diese Frage? Welche zwei Ergebnisse gibt es bei beiden Methoden?

1. Prüfung über das Domain Name System (DNS): Der Client prüft, ob der Common Name (CN) oder der Subject Alternative Name (SAN) des Zertifikats zum Domainnamen des Servers passt.
   Ergebnis:
   • Übereinstimmung: Stimmen die Namen überein, kann der Client die Verbindung fortsetzen, sicher in dem Wissen, dass das Zertifikat für diesen Server gedacht ist.
   • Abweichung: Stimmen die Namen nicht überein, beendet der Client die Verbindung in aller Regel oder zeigt eine Warnung, die auf ein mögliches Sicherheitsrisiko hinweist.
2. Prüfung über die Public Key Infrastructure (PKI): Der Client prüft die digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der ausstellenden Zertifizierungsstelle (Certificate Authority, CA).
   Ergebnis:
   • Gültige Signatur: Ist die Signatur gültig, ist damit bestätigt, dass das Zertifikat nicht manipuliert wurde und von einer vertrauenswürdigen CA ausgestellt ist.
   • Ungültige Signatur: Ist die Signatur ungültig, beendet der Client die Verbindung oder zeigt eine Warnung, die darauf hinweist, dass das Zertifikat kompromittiert oder gefälscht sein könnte.

Wovon hängt ab, welche Methode verwendet wird?

Prüfung über das Domain Name System (DNS):

• Verwendung: Diese Methode kommt immer als Teil des TLS-Handshakes zum Einsatz. Der Client gleicht den Common Name (CN) oder den Subject Alternative Name (SAN) des Zertifikats mit dem Domainnamen des Servers ab und stellt so sicher, dass sie übereinstimmen.
• Ausschlaggebende Faktoren: Das ist fester Bestandteil des TLS-Protokolls und wird vom Client beim Aufbau einer sicheren Verbindung automatisch durchgeführt.

Prüfung über die Public Key Infrastructure (PKI):

• Verwendung: Auch diese Methode kommt beim TLS-Handshake immer zum Einsatz. Der Client prüft die digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der ausstellenden Zertifizierungsstelle (Certificate Authority, CA).
• Ausschlaggebende Faktoren: Auch das ist fester Bestandteil des TLS-Protokolls. Der Client führt diese Prüfung automatisch durch, um sicherzustellen, dass das Zertifikat gültig ist und nicht manipuliert wurde.

Welche Zertifikate sollte der Server an den Client schicken?

Beim TLS-Handshake sollte der Server dem Client die folgenden Zertifikate schicken:

• Endzertifikat: Das ist das eigene Zertifikat des Servers, mit dem er seine Identität gegenüber dem Client nachweist.
• Intermediate-Zertifikate: Diese Zertifikate verbinden das Endzertifikat mit dem vertrauenswürdigen Stammzertifikat. Sie helfen dabei, eine Vertrauenskette vom Zertifikat des Servers zurück zu einem vertrauenswürdigen Stammzertifikat herzustellen.

Was sind Domain-Validation- und Extended-Validation-Zertifikate?

Domain-Validation-Zertifikate (DV) sind eine Art von TLS-Zertifikat, bei der die Zertifizierungsstelle (Certificate Authority, CA) prüft, ob der Antragsteller die Kontrolle über die Domain hat. Üblicherweise geschieht das so:

• Antwort auf eine E-Mail an den administrativen Kontakt der Domain.
• Anlegen eines DNS-TXT-Eintrags.
• Hochladen einer Datei auf den Webserver.

Wesentliche Eigenschaften:

• Schnelle Ausstellung: Sie lassen sich schnell ausstellen, oft innerhalb weniger Minuten, weil nur eine minimale Prüfung nötig ist.
• Grundlegende Sicherheit: Sie bieten Verschlüsselung und die grundlegende Gewissheit, dass die Domain von der Stelle kontrolliert wird, die das Zertifikat beantragt hat.
• Günstig: Oft preiswerter oder sogar kostenlos, damit auch für kleine Websites und private Projekte zugänglich.

Extended-Validation-Zertifikate (EV) sind eine höherwertige Art von TLS-Zertifikat, die ein strengeres Prüfverfahren voraussetzt. Die CA prüft die rechtliche, physische und operative Existenz der Stelle, die das Zertifikat beantragt. Dazu gehört:

• Rechtliche Identität und Status der Stelle bestätigen.
• Physische und operative Präsenz der Stelle prüfen.
• Sicherstellen, dass die Stelle die exklusiven Rechte an der Domain hat.

Wesentliche Eigenschaften:

• Hohe Verlässlichkeit: Bietet Nutzern das höchste Maß an Vertrauen und Verlässlichkeit, weil eine gründliche Prüfung dahintersteht.
• Sichtbare Kennzeichen: In manchen Browsern haben EV-Zertifikate früher den Namen der Organisation in der Adressleiste angezeigt, heute ist das allerdings seltener.
• Mehr Vertrauen: Ideal für Websites, die mit sensiblen Informationen umgehen, etwa Finanzinstitute und E-Commerce-Sites.

Welche sind sicherer?

Extended-Validation-Zertifikate (EV) gelten wegen ihres strengen Prüfverfahrens im Allgemeinen als sicherer als Domain-Validation-Zertifikate (DV). Hier der Vergleich:

Domain-Validation-Zertifikate (DV)

• Prüftiefe: Prüft nur die Kontrolle über die Domain.
• Sicherheit: Bietet grundlegende Verschlüsselung und Verlässlichkeit.
• Anwendungsfall: Geeignet für private Websites, Blogs und kleine Unternehmen.

Extended-Validation-Zertifikate (EV)

• Prüftiefe: Prüft die rechtliche, physische und operative Existenz der Stelle.
• Sicherheit: Bietet wegen der gründlichen Prüfung ein höheres Maß an Vertrauen und Verlässlichkeit.
• Anwendungsfall: Ideal für Finanzinstitute, E-Commerce-Sites und alle Websites, die mit sensiblen Informationen umgehen.

Warum EV-Zertifikate sicherer sind:

• Gründliche Prüfung: EV-Zertifikate erfordern eine umfangreiche Prüfung, was es böswilligen Akteuren erschwert, an sie zu kommen.
• Vertrauensanzeigen: Heute zwar seltener, aber EV-Zertifikate haben früher den Namen der Organisation in der Adressleiste des Browsers angezeigt und Nutzern so eine sichtbare Bestätigung geliefert.
• Höhere Verlässlichkeit: Das ausführliche Prüfverfahren stellt sicher, dass die Stelle hinter dem Zertifikat legitim ist, und verringert so das Risiko von Phishing und anderen Angriffen.

Wie läuft die Sperrung mit OCSP Stapling ab

OCSP Stapling verbessert das übliche OCSP-Verfahren, indem es die Latenz senkt und den Datenschutz erhöht. So funktioniert es:

1. Server fordert OCSP-Antwort an: Der Webserver fragt in regelmäßigen Abständen den Sperrstatus seines Zertifikats beim OCSP-Responder ab, einem Server, den die Zertifizierungsstelle (CA) betreibt. Diese Anfrage läuft im Hintergrund und nicht bei jeder Clientverbindung.
2. OCSP-Responder liefert Antwort: Der OCSP-Responder schickt eine signierte und mit Zeitstempel versehene OCSP-Antwort zurück, die den Status des Zertifikats angibt, etwa „good“, „revoked“ oder „unknown“. Der Server legt diese Antwort im Cache ab.
3. TLS-Handshake mit angehefteter Antwort: Baut ein Client, etwa ein Webbrowser, eine Verbindung zum Server auf, legt der Server die zwischengespeicherte OCSP-Antwort dem TLS-Handshake bei. Das wird als „Stapling“ der Antwort an den Handshake bezeichnet.
4. Client prüft die OCSP-Antwort: Der Client prüft die angeheftete OCSP-Antwort. Da sie von der CA signiert ist, kann der Client ihrer Gültigkeit vertrauen. Weist die Antwort das Zertifikat als gesperrt aus, baut der Client keine sichere Verbindung auf.
5. Regelmäßige Aktualisierung: Der Server aktualisiert seine zwischengespeicherte OCSP-Antwort weiterhin in regelmäßigen Abständen, damit er beim TLS-Handshake immer einen aktuellen Status liefern kann.

Dieses Verfahren verringert die Notwendigkeit, dass Clients eigene OCSP-Anfragen stellen, und verbessert damit Performance und Datenschutz.