Was ist ein X.509-Zertifikat? Diese wichtige Sicherheitsvorkehrung verstehen

Ein X.509-Zertifikat ist ein wichtiger Schutz gegen böswillige Netzwerk-Identifikatoren. Ohne X.509-Server-Authentifizierung können Man-in-the-Middle-Angriffe von böswilligen Zugangspunkten, kompromittierten Routern usw. initiiert werden.

X.509 ist am meisten verwendet für SSL/TLS Verbindungen um sicherzustellen, dass der Client (z. B. ein Webbrowser) nicht von einem böswilligen Imitator getäuscht wird, der vorgibt, eine bekannte, vertrauenswürdige Website zu sein.

X.509-Zertifikate sichern jedoch alle Arten von Netzwerkkommunikation:

• Sicherung der Internetkommunikation
• Sicherung der Intranet-Kommunikation
• Sicherung der E-Mail-Kommunikation
• Sicherung der Gerätekommunikation

Dieser Artikel soll keinen umfassenden Überblick über einen X.509-Standard oder -Rahmen bieten. Vielmehr zielt dieser Artikel darauf ab das Verständnis zu vereinfachen von digitalen X.509-Zertifikaten und wie sie verwendet werden, um sichere Verbindungen herzustellen zwischen einem Client und einem Server während der Internet-Kommunikation.

SSL/TLS Händeschütteln 

Bei den Verbindungen SSL/TLS authentifiziert sich der Server gemäß den Protokollen Handshake und Record. Bei der Initiierung des Handshake-Protokolls legt der Server dem Client ein signiertes X.509-Zertifikat vor. Bei den meisten sicheren Browsing-Sitzungen muss nur der Server validiert werden. Die Client-Authentifizierung ist weniger verbreitet, erfordert aber, dass der Server auch das Zertifikat des Clients überprüft.

Die Signatur des X.509-Zertifikats muss vom Client überprüft werden, bevor eine HTTPS-Verbindung hergestellt wird. Das erforderliche Format und die in einem X.509-Zertifikat enthaltenen Informationen ermöglichen es dem Client, die Integrität der zertifizierten Identität sicher zu authentifizieren und zu überprüfen.

Trust Stores 

Client-Browser und -Anwendungen sind bei der ordnungsgemäßen Validierung von X.509-Zertifikaten in hohem Maße auf ihr Vertrauen in Zertifizierungsstellen (CA) angewiesen. Jede Client-Anwendung und jedes Betriebssystem unterhält eine Liste vertrauenswürdiger Stammzertifikate, die als "Trust Store" bezeichnet wird. Zum Beispiel enthält der Firefox-Vertrauensspeicher zum Zeitpunkt der Erstellung dieses Dokuments 150 Stammzertifikate, die automatisch vom Webbrowser als vertrauenswürdig eingestuft werden.

Im Gegensatz dazu verwendet Google Chrome den Vertrauensspeicher des zugrunde liegenden Betriebssystems, um festzustellen, ob ein Zertifikat vertrauenswürdig ist, mit einigen Ausnahmen. Google führt eine fest kodierte Liste "EV-qualifizierter" Stammzertifikate zusammen mit einer eindeutigen ID, die auf von diesem Stamm ausgestellten Zertifikaten erscheinen muss. Hinweis: Seit 2015 verlangt Chrome für alle EV-Zertifikate die Verwendung von Certificate Transparency.

Hierarchische Trust Chains 

Als Teil des X.509-Verifizierungsprozesses muss jedes Zertifikat von derselben ausstellenden CA signiert werden, die in seinem Zertifikat genannt ist. Der Client muss in der Lage sein, einen hierarchischen Zertifizierungspfad zu verfolgen, der rekursiv zu mindestens einer im Vertrauensspeicher des Clients aufgeführten Root-CA zurückführt.

Die Struktur des Zertifizierungspfads kann jedoch hierarchisch (wie ein Baum mit einer einzigen Stammzertifizierungsstelle) oder nicht-hierarchisch (wie ein Wald mit vielen kreuzzertifizierten Stammzertifizierungsstellen) sein. Es ist einfacher, sich die Kreuzzertifizierung vorzustellen, wenn man sich internationale Telefongespräche vorstellt. Wenn jede Landesvorwahl durch eine Root-CA repräsentiert wird, dann würden Cross-Zertifizierungsvereinbarungen zwischen den CAs die Reichweite der Anrufe erweitern. Wenn zwei Root-CAs ihre Zertifikate gegenseitig signieren, vertrauen sie von Natur aus allen anderen Zertifikaten im Pfad des jeweils anderen.

Der Aussteller und der Empfänger eines Zertifikats müssen für eine gültige Zertifizierung bestimmte Informationen bereitstellen. Der X.509-Standard definiert diese Anforderungen.

X.509-Zertifikatsfelder: 

• Version: Die Versionsnummer des x.509-Zertifikats. (wenn nicht angegeben, wird Version 1 angenommen)
• serialNumber: Eindeutige Seriennummer, die für jedes von einer CA erstellte Zertifikat erstellt wird.
• Unterschrift: Der Algorithmus, der zur Erzeugung der Signatur verwendet wird. Er muss mit dem signatureAlgorithm übereinstimmen.
• issuer: Der Distinguished Name (DN) der ausstellenden CA.
• Gültigkeit: Zwei Zeitangaben - von notBefore (Ausstellungsdatum) bis notAfter (Ablaufdatum).
• Betreff: Distinguierter Name der validierten Entität, für die das Zertifikat ausgestellt ist.
• subjectPublicKeyInfo: Der Algorithmus und Wert des öffentlichen Schlüssels (RSA, DSA oder Diffie-Hellman).

X.509 Version 3 Erweiterungsfelder: 

• extnId: Dient zur Identifizierung dieser Erweiterung.
• kritisch: Dies ist ein boolescher Wert, der angibt, ob die Erweiterung wichtig ist oder nicht.
• extnValue: Enthält eine Oktett-Zeichenkette, die von einer Gemeinschaft, die eine optionale Erweiterung verwendet, frei interpretiert werden kann.

Hinweis: Viele Erweiterungen, die durch X.509 Version 3 sind wesentlich für Geschäftsbeziehungen innerhalb und zwischen PKI Domänen.

X.509 definiert nicht, wie der Inhalt von Zertifikaten für die Speicherung in Dateien kodiert werden soll. Es gibt jedoch zwei gängige Kodierungsschemata für die Speicherung von X.509-Zertifikaten in Dateien: DER und PEM.

DER (Distinguished Encoding Rules) ist ein Schema zur Codierung von Datenobjekten, das zur Codierung von Zertifikatsobjekten verwendet werden kann. DER ist das gängigste Dateiformat zum Speichern von X.509-Zertifikaten. Bei DER-kodierten Zertifikaten handelt es sich um Binärdateien, die von Texteditoren nicht gelesen werden können, die aber von Webbrowsern und einigen Anwendungen problemlos verarbeitet werden können.

PEM (Privacy Enhanced Mail) ist ein verschlüsseltes E-Mail-Kodierungsschema, das zur Umwandlung von DER-kodierten Zertifikaten in Textdateien verwendet werden kann.

Im Jahr 1988 wurde X.509 Version 1 veröffentlicht. Die hierarchische Anordnung der Distinguished Names folgte den Regeln für X.500. Diese Regeln wurden von den Systemen inspiriert, die für die weltweite Vergabe von Telefonnummern verwendet werden.

1993 wurden mit X509 Version 2 zwei neue Felder hinzugefügt: Issuer Unique Identifier und Subject Unique Identifier. Diese Felder werden inzwischen von der IETF als veraltet angesehen und sollten in Ihren Zertifikaten nicht verwendet werden. Die weit verbreitete Nutzung des Internets gab den Anstoß zur Weiterentwicklung des hierarchischen Namenssystems.

Seit 1996 ermöglicht die Version 3 von X.509 mehrere Erweiterungen, die zu einem Zertifikat hinzugefügt werden können. Die Erweiterungen bieten erweiterte Informationen über die Verwendung von Schlüsseln, Zertifikatsrichtlinien und -beschränkungen, alternative Namensformen und mehr.

Wie erwähnt von Gartner, X.509-Zertifikate entscheidend, um digitales Vertrauen in der digitalen Welt zu schaffen. Ohne ordnungsgemäße Verwaltung derse-Zertifikate lassen Sicherheitsteams ihr Unternehmen für Ausfälle, Verstöße und fehlgeschlagene Audits anfällig werden.

Nehmen Sie eine Bestandsaufnahme Ihrer aktuellen X.509 Zertifikatsverwaltung Fähigkeiten und bewerten Sie ob eine neue Lösung erforderlich ist, um Adresse die kontinuierlich Anstieg Ihrer digitalen Zertifikate.