Diskussion:X.509

Erste Anmerkungen

Hab nur mal auf die Schnelle versucht, den Artikel aus der englischen WIkip. zu übersetzen... Zu Pkcs hab ich noch nix geschrieben und die Dateinamenerweiterung hab ich auch noch nicht. Vielleicht will das nochmal jemand machen... -cljk 00:39, 25. Okt 2004 (CEST)

Was genau steht nun in so einem Zertifikat? Wo sind Public & Private Key?

Ich komme aus der PGP-Welt. Dort wird sauber unterschieden zwischen "private key" (dort "secret key" genannt), "public key" und diversen "key signaturen", also quasi "Unterschriften/Beglaubingungen", die Dritte an einen Public Key dranhängen können mit der Ausage "Mit meiner Unterschrift/Signatur bestätige ich, dass der signierte Key dem angegeben Eigentümer gehört" usw.

Wie sieht das nun bei X.509 aus? Ich lese hier nur von "Zertifikaten". So wie ich das verstanden habe, sind diese Zertifikate halt "Unerschriften/Beglaubigungen von Public Keys / Public Key Hashes und ihren Metadaten", also in etwa: "Zertifizierungsstelle XY betätigt hiermit, dass der Public Key mit dem Has 0815CAFEBABE... zum Server www.example.org gehört. Gültig bis 1.April 2038, usw."

Wo / wie werden nun die eigentlichen Private & Public Keys gespeichert und ausgetauscht? --RokerHRO (Diskussion) 20:44, 8. Jun. 2018 (CEST)

Private Keys werden überhaupt nicht ausgetauscht, sie verlassen den eigenen Rechner niemals – auch nicht ganz zu Beginn, wenn das Zertifikat erzeugt wird. Public Keys sind – wie der Name sagt – öffentlich, sie enthalten kein Geheimnis. Der Ablauf ist üblicherweise der folgende:

• Das Subject erzeugt einen Zertifikat-Request auf seinem Rechner. Dieser Request besteht aus einem Private Key (der ab sofort geheim gehalten wird und der sich auch nicht mehr verändert) und einem halbfertigen Public Key, der noch nicht signiert ist.
• Das Subject schickt seinen halbfertigen Public Key an den Issuer („Certification Authority“).
• Der Issuer überzeugt sich auf irgendeinem zusätzlichen Weg, dass die Anfrage tatsächlich vom Subject kam. Hier kann eine „Registration Authority“ mithelfen – z. B. ein bestimmter Kollege, dem man seinen Personalausweis vorzeigt und der dann bei der Certification Authority anruft, um den Request freizugeben.
• Der Issuer signiert den Public Key und schickt ihn zurück an das Subject. Der Public Key ist damit fertig und vollwertig. Wenn man vom „Zertifikat“ spricht, meint man üblicherweise diesen signierten Public Key.

Danach geht es auf dem üblichen Weg weiter:

• Das Subject signiert irgendwelche Daten mit Hilfe seines Private Key. Zur Verifizierung der Signatur bietet es seinen Public Key an.
• Ein Kommunikationspartner empfängt die Daten und den Public Key. Er kann bestätigen, dass der Public Key zur Signatur passt.
• Der Kommunikationspartner weiß, dass die Daten tatsächlich vom Subject kamen, weil nur das Subject den Private Key zur Erzeugung der Signatur besitzen kann.
• Der Kommunikationspartner weiß, dass der Public Key wirklich zum Subject gehört, weil der Issuer dafür auf dem Public Key unterschrieben hat.
• (Meist gibt es eine Kette von Zertifikaten, in denen der Issuer eines Zertifikats selbst wieder das Subject des nächsten ist.)
• Der Kommunikationspartner weiß, dass diese Signatur tatsächlich vom Issuer kam, weil er dessen Public Key dauerhaft bei sich hinterlegt hat (!) und ihm vertraut.

Und genau am letzten Punkt erkennt man die hierarchische Struktur, die sich von PGP unterscheidet: Es gibt bestimmte „Root Certification Authorities“, denen jede(r) vertrauen muss. Solche Root CAs unterschreiben ihre Public Keys selbst (d. h. Subject und Issuer sind gleich), weil sie in der Zertifikats-Baumstruktur niemanden über sich haben. Ihre Zertifikate sind z. B. in den gängigen Browsern fest eingebaut, oder sie werden mit der Systemsoftware mitgeliefert. Man kann sie auch aus dem Netz herunterladen, aber damit würde das System – im Prinzip – angreifbar, weil man möglicherweise nicht sicher sein kann, mit wem man gerade kommuniziert. --77.176.160.96 10:19, 24. Jun. 2018 (CEST)

Die Zertifizierungsstelle bestätigt also: „Dieser Public Key gehört zu Karl Müller.“ Daraus folgt: „Die Person, die den passenden Private Key besitzt und benutzt, ist Karl Müller“. --77.176.160.96 10:30, 24. Jun. 2018 (CEST)

Danke für die ausführliche Antwort. Aber wenn ich auf der DS eine Frage stelle, dann üblicherweise, weil das eine Frage ist, die der Artikel beantworten sollte, nicht die DS. Sprich: Diese Info sollte man im Artikel finden, oder nicht? :-) --RokerHRO (Diskussion) 10:26, 25. Jun. 2018 (CEST)

Das meiste steht schon im Artikel über Public-Key-Infrastrukturen. Dort wird auch der Unterschied zwischen hierarchischen PKIs und dem „Web of Trust“ (wie bei PGP) dargestellt. Der PKI-Artikel enthält (natürlich) viele weitere Links, z. B. auch wieder hierher zu X.509. Vielleicht kann man den Zusammenhang noch klarer darstellen, aber man muss aufpassen, dass man nicht zu viel doppelt aufschreibt. Grüße, --89.14.104.148 13:52, 1. Jul. 2018 (CEST)

Fehler in "Beispiel für ein X.509 Zertifikat"?

Möglicherweise enthält der Abschnitt "Beispiel für ein X.509 Zertifikat" zwei Fehler:

Die Zeile:
Issuer: C=AT, ST=Steiermark, L=Graz, O=TrustMe Ltd, OU=Certificate Authority, CN=CA/Email=ca@trustme.dom
Müsste so aussehen:
Issuer: C=AT, ST=Steiermark, L=Graz, O=TrustMe Ltd, OU=Certificate Authority, CN=CA, emailAddress=ca@trustme.dom
Die Zeile:
Subject: C=AT, ST=Vienna, L=Vienna, O=Home, OU=Web Lab, CN=anywhere.com/Email=xyz@anywhere.com
Müsste so aussehen:
Subject: C=AT, ST=Vienna, L=Vienna, O=Home, OU=Web Lab, CN=anywhere.com, emailAddress=xyz@anywhere.com

Das heisst: der Attribut-Type email müsste emailAddress heissen und das Trennzeichen zwischen den Attributen ist immer ein Komma "," und nicht ein Schrägstrich "/". --Wehe00 (Diskussion) 08:46, 21. Jan. 2019 (CET)

Kein Fehler sondern eine übliche Darstellung von Multivalued-Relative-Distinguished-Name-Elementen. --MichaEL (Diskussion) 14:22, 21. Jan. 2019 (CET)

Danke für den Hinweis auf die Multivalued-RDNs. Falls es sich hier um einen solchen handelt, müsste der doch durch ein Pluszeichen "+" separiert werden, oder? Jedenfalls nach dem RFC 4514 . Das habe ich ausserdem mit dem Tool openssl unter Linux nachgestellt und ein Zertifikat mit Multivalued-RDN erzeugt:

openssl req -new -subj '/C=AT/ST=Vienna/L=Vienna/O=Home/OU=Web Lab/CN=anywhere.com+emailAddress=xyz@anywhere.com' -x509 -out privkey.pem -nodes -multivalue-rdn

Lässt man sich den relevanten Abschnitt des Zertifikates (Subject) anzeigen openssl x509 -text -in privkey.pem |grep "Subject:", erhält man als Ausgabe:

Subject: C = AT, ST = Vienna, L = Vienna, O = Home, OU = Web Lab, CN = anywhere.com + emailAddress = xyz@anywhere.com
Also mit Pluszeichen als Separator. Weiterhin würde eine Fehlermeldung entstehen, falls man den Attribut-Typ email (an Stelle von emailAddress) nimmt. --Wehe00 (Diskussion) 06:34, 22. Jan. 2019 (CET)