SSL/TLS-Zertifikate — Was diese Felder und Ablaufdaten tatsächlich bedeuten

Zu einem Zeitpunkt haben Sie sich an den kleinen Schlossschild in dem Browser gewandt, geklickt „Zertifikat anzeigen“ und mit einer Wand von Feldern konfrontiert, die wichtig erscheinen, aber nichts erklären: „Subject Alternative Names“, „OCSP“, „SHA-256 mit RSA-Verschlüsselung“. Sie schließen das Fenster. Das Zertifikat ist grün. Das ist genug.

Bis es abläuft. Um Mitternacht an einem Freitag. In der Produktion.

Dieser Artikel führt Schritt für Schritt durch, was tatsächlich in einem TLS-Zertifikat enthalten ist – Feld für Feld – damit Sie beim nächsten Mal ein Zertifikat debuggen können und wissen, was Sie lesen.

Ein Zertifikat ist einfach ein signiertes Dokument

Entfernen Sie die Zeremonien und ein TLS-Zertifikat ist ein Textdokument, das einige Fakten enthält – wer dieses Domänen besitzt, welchen öffentlichen Schlüssel sie verwendet, wann das Dokument abläuft – das kryptografisch von einer Zertifizierungsbehörde (CA) signiert wurde. Die Signatur der CA ist das, was Browsern das Vertrauen verleiht. Alles andere ist nur Anmerkung.

Der zugrundeliegende Format ist X.509. Er wurde 1988 definiert, mehrfach überarbeitet und ist jetzt in RFC 5280spezifiziert. Deswegen sehen Browser-Zertifikat-Detail-Fenster aus, als seien sie von Menschen entworfen worden, die 1988 als eine moderne Zeit betrachten.

Die wichtigen Felder, erklärt

Hier ist eine kommentierte Aufteilung der Felder, die Sie in einem echten Zertifikat sehen werden. Der unten stehende roh-Pem-Text ist repräsentativ (kein aktives Zertifikat):

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

Allgemeiner Name (CN)

Das ursprüngliche Feld, um anzugeben, welche Domäne das Zertifikat abdeckt. Sie werden es immer noch sehen – CN = example.com — aber Browser haben sich größtenteils darauf verlassen. Seit 2000 ist die Erweiterung „Subject Alternative Names“ das autorisierte Feld für Domänenabgleich. Der CN ist in dieser Hinsicht nun fast veraltet; wenn SAN existiert, verwenden Browser SAN ausschließlich.

Subject Alternative Names (SAN)

Dies ist die echte Liste der Domänen, die das Zertifikat sichert. Ein einzelnes Zertifikat kann Dutzende von Namen abdecken – Wildcard-Einträge (*.example.com), genaue Namen, sogar IP-Adressen. Mehrdomänen-Zertifikate (manchmal auch SAN-Zertifikate oder UCC-Zertifikate) sind Standardpraxis. Die CA erstellt gegen diese Liste, und Browser vergleichen den Hostnamen, den Sie besuchen, mit dieser Liste.

Eines der Dinge, die Wildcards können tun: Unterdomänen abdecken. *.example.com abdeckt app.example.com aber nicht api.v2.example.com. Viele Menschen entdecken das erst auf schwere Weise.

Gültigkeitszeitraum

Zwei Zeitstempel: Nicht vor und Nicht nach. Das Zertifikat ist außerhalb dieses Zeitraums ungültig – vor dem Startdatum, nach der Ablaufdatum. Beide sind UTC.

Die maximalen Zertifikatlaufzeiten verringern sich kontinuierlich. Im Jahr 2015 war die maximale Laufzeit drei Jahre. Im Jahr 2018 sank sie auf zwei Jahre. Im Jahr 2020 startete Apple einseitig die Ablehnung von Zertifikaten, die länger als 398 Tage (etwa 13 Monate) dauern, und zwang Browserhersteller und CAs, dies zu folgen. Ab 2026 hat das CA/Browser-Forum einen Plan verabschiedet, um diese Dauer bis 2027 auf 47 Tage zu reduzieren.

Der Grund für kürzere Laufzeiten ist gut: Wenn ein privater Schlüssel kompromittiert ist, begrenzt ein kurzes Zertifikat den Auswirkungsbereich. Die praktische Realität ist jedoch, dass kürzere Laufzeiten mehr Druck auf Ihre Automatisierung für die Erneuerung ausüben. Die 90-Tage-Zertifikate von Let’s Encrypt waren 2015 wegen des gleichen Grundes umstritten; heute gelten sie als beste Praxis und automatisierte Erneuerung wird erwartet.

Aussteller und die Kette des Vertrauens

Der Emittent Feldnamen die Einheit, die das Zertifikat signiert hat. Für die meisten öffentlichen Websites ist dies eine mittlere CA (wie Let’s Encrypts R11), nicht eine Wurzel-CA. Wurzel-CA signieren mittlere CA-Zertifikate; mittlere CA signieren End-Entität-Zertifikate (die Ihre Server präsentieren). Diese Kette existiert, weil die privaten Schlüssel der Wurzel-CA offline in luftdicht isolierten HSMs gespeichert werden und Sie einen nicht auslagern können, um Millionen von Domänen-Zertifikaten pro Jahr zu signieren.

Wenn ein Browser Ihr Zertifikat validiert, geht er entlang der Kette: Ihr Zertifikat → mittlere CA → Wurzel. Wenn die Wurzel im Browser-Vertrauensspeicher ist, wird die Kette validiert. Wenn ein Zertifikat in der Kette fehlt, abgelaufen ist oder mit einem widerrufenen Schlüssel signiert wurde, scheitert die Validierung.

Das ist der Grund, warum die häufigste TLS-Fehlkonfiguration darin besteht, das mittlere Zertifikat neben Ihrem Blattzertifikat zu dienen. Ihr Browser könnte das mittlere Zertifikat im Cache speichern und scheint in Ordnung zu sein, während andere Clients – curl, mobile Apps, Server, die außerhalb API-Aufrufe tätigen – fehlschlagen, weil sie keinen Weg zum Wurzel haben.

Signaturalgorithmus

Zwei Dinge, die in einem Feld verpackt sind: die Hash-Funktion, die verwendet wird, um die Daten des Zertifikats zu verdichten, und der Schlüsselalgorithmus, der verwendet wird, um diese Verdichtung zu signieren. sha256WithRSAEncryption bedeutet SHA-256-Hash, RSA-Signatur. ecdsa-with-SHA256 bedeutet SHA-256-Hash, ECDSA-Signatur.

SHA-1-Signaturen wurden 2017 von Browsern abgeschafft und verursachen nun harte Fehlschläge. MD5-Signaturen wurden früher abgeschafft und sind praktisch ausgestorben. Wenn Sie etwas betreiben, das interne SHA-1-Zertifikate ausstellt, aktualisieren Sie Ihre CA-Konfiguration, bevor ein Browser-Update dies für Sie macht.

ECDSA (meistens P-256 oder P-384) erzeugt kleinere Schlüssel und Signatur als RSA für gleiche Sicherheit. Ein 256-Bit-EC-Schlüssel ist etwa gleichwertig zu einem 3072-Bit-RSA-Schlüssel. Der Handel: RSA ist mit sehr alten Clients besser kompatibel; ECDSA ist schneller und leichter. Moderne Bereitstellungen konfigurieren oft beide und lassen das TLS-Verhandlungsverfahren entscheiden.

Zweck der Schlüssel und erweiterte Zweck der Schlüssel

Zweck der Schlüssel ist ein Bitmask, das angibt, was der Schlüssel erlaubt ist: Daten signieren, Daten verschlüsseln, andere Zertifikate signieren (nur für CA). Erweiterte Zweck der Schlüssel verfeinert dies für bestimmte Protokolle: TLS Web Server Authentication ist das, was das Zertifikat für HTTPS erlaubt. TLS Web Client Authentication ist für mTLS-Kunden-Zertifikate. Code Signing ist für Software-Signatur-Zertifikate.

Wenn Sie versuchen, ein Zertifikat für einen Zweck zu verwenden, der außerhalb seiner erklärten Schlüsselzweck liegt, lehnen moderne TLS-Implementierungen es ab. Sie können ein Code-Signing-Zertifikat nicht auf einem Webserver verwenden, selbst wenn die Domain übereinstimmt.

Grundlegende Beschränkungen: CA:FALSE

Dieses Feld gibt an, ob das Zertifikat verwendet werden kann, um andere Zertifikate zu signieren. CA:FALSE bedeutet, dass es nicht möglich ist – es ist ein Blattzertifikat (End-Entität). CA:TRUE bedeutet, dass es ein CA-Zertifikat ist, das erlaubt, andere Zertifikate in der Kette zu signieren.

Der pathLenConstraint das manchmal neben diesem erscheint, sagt Ihnen, wie viele mittlere CAs unter diesem Zertifikat erlaubt sind. Wurzel-CA legen oft diese Einstellung fest, um die Tiefe der Kette zu begrenzen.

OCSP und Widerruf

Die OCSP-URL (Online Certificate Status Protocol) im Zertifikat gibt den Client an, wo er prüfen kann, ob das Zertifikat vor dem Ablauf widerrufen wurde. Der Widerruf erfolgt, wenn ein privater Schlüssel kompromittiert ist oder das Zertifikat fehlerhaft ausgestellt wurde.

In der Praxis hat die OCSP-Prüfung in Browsern eine komplizierte Geschichte. Chrome hat jahrelang keine Live-OCSP-Prüfung durchgeführt, sondern hat stattdessen CRLSets (eine vorab abgerufene Liste von widerrufenen hochwertigen Zertifikaten) verwendet. Firefox führt noch OCSP durch, aber standardmäßig auf „Soft-Fail“, was bedeutet, dass wenn der OCSP-Server nicht erreichbar ist, das Zertifikat als gültig behandelt wird. Die Gesamteffekt: Für die meisten Zertifikate ist der Widerruf im Alltag eher theoretisch. Dies ist einer der Gründe für kurze Lebensdauer-Zertifikate – bei 47 Tagen hat der Widerruf weniger Bedeutung, weil das Zertifikat bald abläuft.

Warum Zertifikate ablaufen

Das Ablaufdatum ist keine bürokratische Hürde. Es ist das Mechanismus, der begrenzt, wie lange ein kompromittiertes Kennwort gültig bleibt. Die Alternative – dauerhafte Kennwörter – ist, wie Sie zu SHA-1-Zertifikaten und Jahrzehnte alten CA-Schlüsseln in der Produktion kommen, was im Jahr 2010 weit verbreitet war.

Die Abwägung ist operativ: kürzere Laufzeiten erfordern zuverlässige Automatisierung. Wenn Ihre Erneuerung auf einen Systemadministrator-Kalender-Alarm angewiesen ist, werden Sie in der Produktion auslaufen. Die richtige Lösung ist automatisierte Erneuerung über ACME (das Protokoll von Let’s Encrypt) oder über die API Ihrer CA, mit Überwachung, die mehrere Wochen vor Ablauf eine Warnung ausgibt, anstatt am Abend, an dem es endet.

Wie man ein Zertifikat ohne Befehlszeile liest

Die Standardmethode, um ein Zertifikat zu inspizieren, ist openssl x509 -in cert.pem -text -noout, die eine Ausgabe erzeugt, die für Menschen geeignet ist, die RFC 5280 leicht lesen können. Wenn Sie die gleiche Information in einer Format haben, die nicht die Erinnerung an openssl-Flags erfordert, dann ist die SSL/TLS-Zertifikat-Dekoder und X.509 Zertifikatsanalysator auf iotools.cloud beide nehmen ein PEM-geschriebenes Zertifikat und geben jedes Feld mit Etiketten und organisiert – nützlich, wenn Sie mitten in der Nacht eine Kette-Problem debuggen und die wall of text von openssl nicht hilft.

Das könnte Ihnen auch gefallen