Sicherer Kanal: von Alice zu Bob PKI, Zertifikate, Alternativen & Grenzen

Prüfungstermine (August) Modul(e): VL IT-Sicherheit Grundlagen Prüfungstermin(e): Mi., 08.08.2012, Do., 09.08.2012 Prüfer/in: Dr. Wolf Müller Ort: Haus 3, Raum 327 Prüfungsart: mündliche Prüfung Anmeldung: Beginn: am 01.07.2012 bis 24.07.2012 bei: Name: Frau Albrecht/ Frau Schoch Raum-Nr.: Haus 3, R. 302 Sprechzeiten: 10 – 16 Uhr Abmeldung: unter: albrecht@informatik.hu-berlin.de Dr. Wolf Müller

Digitale Unterschrift: Lücke bisher Woher hat Bob den public-Key von Alice? Kann Bob sicher sein, dass der public-Key wirklich zu Alice gehört? Public-Key Verteilung muss gewisse Anforderungen erfüllen! Dr. Wolf Müller

Anforderung an Verteilung Authentizität des Public Keys muss sichergestellt sein. Verifizierbar durch Empfänger z. B. PGP-Verifizierung durch Benutzer anhand eines Fingerprints Dr. Wolf Müller

Begriff: Zertifikat Bindung zwischen Benutzer und einem öffentlichen Schlüssel (Elektronische Beglaubigung) Schlüssel A gehört Benutzer B, Keine Aussage über Vertrauenswürdigkeit von B Aber WER zertifiziert WEN ???? ... Dr. Wolf Müller

Zertifikat Deutsche Bank Dr. Wolf Müller

Möglichkeiten der Verteilung Persönlicher Kontakt schlecht skalierbar auf große Benutzergruppen Sicherer Kanal (Standleitung, ...) nicht immer verfügbar Vertrauenswürdiger Dritter am praktikabelsten „Zertifikate von Benutzern“ Dr. Wolf Müller

Zertifikate von Benutzern (1) Gegenseitige Zertifizierung von Benutzern (z.B. PGP) Auf Key-Signing-Parties werden Informationen (Finger- prints) ausgetauscht / Identitäten überprüft. Unpraktikabel bei verstreuten Benutzergruppen Keine festen Vertrauenspfade (Wem muss ich vertrauen ?) Dr. Wolf Müller

Zertifikate von Benutzern (2) Qualität der Zertifikate unklar, da nicht alle Benutzer bekannt / unterschiedliche Zertifizierungsregeln Gültigkeit eines Zertifikates gegeben? (PGP) Widerruf von Schlüsseln / Zertifikaten problematisch. Keine festen Regeln für die Verteilung der Zertifikate Dr. Wolf Müller

Zertifikate von Instanzen (1) Übergeordnete Zertifizierungsinstanzen Verteilung von Zertifikaten über unsicheren Kanal möglich (Signatur des Public-Key) Prinzipiell vertrauen müssen der Zertifizierungsinstanz nur die Benutzer, nicht der Zertifikatsnehmer Feste Vertrauenspfade Meist allgemein anerkanntes Zertifikatsformat (X.509) Dr. Wolf Müller

Zertifikate von Instanzen (2) Zertifizierungsinstanzen zertifiziert von „Policy Certification Authorities“ PCA legen Zertifizierungsrichtlinien (Policy) fest, die Vorgaben enthalten zur Überprüfung der Identität Policy ist öffentlich, überprüfbar für jeden Benutzer. (Aber wer tut dies schon?) Dr. Wolf Müller

Signatur „die Zweite“ (1) Dr. Wolf Müller

Signatur „die Zweite“ (2) Instanz Dr. Wolf Müller

Signatur „die Zweite“ (3) Dr. Wolf Müller

Signatur „die Zweite“ (4) Instanz Dr. Wolf Müller

Widerruf von Zertifikaten (1) Z.B. Zertifizierungsschlüssel einer CA bei unkorrekter Identitätsprüfung. Nur Zertifizierer kann ein Zertifikat widerrufen. Verteilung widerrufener Zertifikate über „Certificate Revocation List“ (CRL) Über unsichere Kanäle möglich, da CRL von CA genau wie Zertifikate digital signiert. Aktualität der CRL muss sichergestellt sein Einführung des „Online Revocation Checking“ mit Hilfe des Online Certificate Status Protocol OCSP, RFC 2560 Dr. Wolf Müller

Merkmale einer Zertifizierungsinstanz Operiert nach festgelegten öffentlichen Regeln (Policy) Verpflichtet Policy einzuhalten ( u.a. gesetzlich) Vertrauenswürdigkeit wichtigstes Kapital Garantiert Richtigkeit der ausgestellten Zertifikate Problem: Prüfung der Policies entlang einer Zertifikatskette durch Nutzer ist unrealistisch. Viele Root-CAs built in in Browsern Dr. Wolf Müller

Dienstleistungen einer „Certification Authority“ (CA) Identitätsprüfung (Registrierung) Zertifizierung Bereitstellung und Verteilung von Zertifikaten Sperrmanagement für zurückgerufene und abgelaufene Zertifikate Ggf. Verlängerung abgelaufener Zertifikate (Rezertifizierung) Dr. Wolf Müller

Registrierung & Zertifizierung Überprüfung der CA angegebenen Daten Minimal: proof of possession Kann von CA ausgelagert sein Überprüfung vor Antragstellung Überprüfung im Auftrag der CA Zertifizierung : Signierung mit privatem Schlüssel der CA Dr. Wolf Müller

Veröffentlichung der Zertifikate und CRL´s Durch CA selbst oder dritte i.a. der CA Verzeichnisdienste E-mail / Post-Abonnement Online Abfrage (OCSP, Online Certificate Status Protocol) RFC 4806 „Online Certificate Status Protocol (OCSP) Extensions to IKEv2” Bei Verteilung durch Dritte : Schwerpunkt kann auf Performance gelegt werden Vertrauen ausschließlich durch Signatur der CA Dr. Wolf Müller

Trustcenter Alle Dienstleistungen einer CA Weitergehende Dienste werden angeboten: Erzeugung eines Schlüsselpaares Sichere Verwahrung des privaten Schlüssel des Users Archivierung abgelaufener Schlüssel Benötigt deutlich mehr Vertrauen vom User als reine CA Habe wirklich nur ich den privaten Schlüssel? Dr. Wolf Müller

Problem der Skalierbarkeit Persönliche Identifikation bei Registrierung notwendig -> Nähe zum Nutzer vs. Sicherungsmaßnahmen für CA sehr aufwendig  zentrale Zertifizierung Lösung : Infrastrukturen aufbauen Dr. Wolf Müller

Einzelne CA (1) Zertifikate werden nur an User vergeben. Informatik Alice Bob Zertifikate werden nur an User vergeben. User akzeptieren nur Zertifikate und CRL von der eigenen CA akzeptiert. Dr. Wolf Müller

Einzelne CA (2) Vorteile: Nachteile: Informatik Alice Bob Einfachheit (keine Vertrauenspfade, direkte Verifizierung) Nachteile: Nur für kleine User-Gruppen geeignet. Single Point of Failure. Bei kompromitierung der CA müssen alle Zertifikate neu ausgestellt werden Dr. Wolf Müller

Basic Trust Lists (1) Alices Trust List Informatik Physik Informatik Bob Carol Doug Physik … Einfachste Erweiterung der „Einzelnen CA“ Keine Vertrauensverhältnisse zwischen CA´s User hat Trust List mit CA´s dessen Zertifikaten er vertraut. Dr. Wolf Müller

Basic Trust Lists (2) Vorteile: Nachteile: Keine Vertrauenspfade, nur einfache Zertifikate Erweiterbarkeit durch Erweiterung der TrustList Nachteile: Erweiterung der Trustlist sollte genau überlegt sein Problem bei Kompromittierung einer CA Alices Trust List Informatik Physik … Problem bei Kompromittierung einer CA: Wie soll eine User, der dieser CA vertraut davon erfahren, wenn er kein Zertifikat-Nehmer dieser CA ist, sondern sie nur auf seiner Trust List hat ? Und dann ungerechtfertigterweise weiterhin vertraut... Dr. Wolf Müller

Zertifizierungshierarchien (1) HUB Informatik Physik Chemie Alice Bob Carol Doug Ernie Frank Alle User vertrauen der Root CA Alle CA´s (bis auf Root-CA) haben genau eine übergeordnete CA CA verteilt Zertifikate an untergeordnete CA oder direkt an User Dr. Wolf Müller

Zertifizierungshierarchien (2) HUB Informatik Physik Chemie Alice Bob Carol Doug Ernie Frank Vorteile : Vertrauenspfade sind einfach zu konstruieren, Einfache Wiedereinbindung ausgefallener CAs Nachteile : Bei Kompromittierung der Root CA Totalausfall der Infrastruktur Dr. Wolf Müller

Vertrauensnetz (1) Chemie Informatik Alice Frank Physik Bob Mathe Carol Doug Auch „Web of Trust“ genannt CA sind direkt miteinander verbunden (peer-to-peer) CA zertifizieren sich gegenseitig Jeder User vertraut zumindest seiner CA Dr. Wolf Müller

Vertrauensnetz (2) Vorteile: Nachteile: Chemie Informatik Alice Frank Physik Bob Mathe Carol Doug Vorteile: Neue CA´s können leicht aufgenommen werden Robust gegen Ausfall und Kompromittierung Nachteile: Aufwendige Vertrauenspfad-Bildung Zertifikate sind komplizierter, da sie jeweils noch Informationen über die ausstellende CA enthalten muß, denn im WoT sind keine allgemeinen Informationen über die einzelnen CA vorhanden Dr. Wolf Müller

Hybrid PKI Architekturen Bisherige PKI: PKI für ein Unternehmen / Institut oder eine Nutzergruppe TU-Berlin HU-Berlin 1 und 1 Gruppe HUB Web.de TU Informatik Physik Alice Bob GMX 1+1 Carol Doug Hybrid Architekturen: Verbinden PKI-Strukturen untereinander Dr. Wolf Müller

Extended Trust List TU-Berlin HU-Berlin 1 & 1 Gruppe Alices Trust List HUB Web.de TU TU Informatik Physik Alice Bob GMX 1+1 HU 1&1 Carol Doug Erweiterung der Trust List auf Vertrauenspfade länger als 1 Pro PKI muss nur noch ein Point of Trust gesetzt werden Erhält sowohl Vor- als auch Nachteile der Trust List Komplexe Vertrauenspfad-Bildung Basic Trust Lists Vorteile: Erweiterbarkeit durch Erweiterung der TrustList Nachteile: Erweiterung der Trustlist sollte genau überlegt sein Problem bei Kompromittierung einer CA Dr. Wolf Müller

Cross-Zertifizierung HU-Berlin HUB Peer-to-peer Verbindung zwischen jeweils einer CA der PKI Jeder User hat genau einen Trust Point Informatik Physik TU-Berlin Carol TU Alice Bob 1 & 1 Gruppe Web.de Vertrauenspfad-bildung : Da es vorher nicht bekannt ist, was für einen aufbau die Cross-Zertifizierte PKI hat, müssen mechanismen für jede art von PKI vorhanden sein Für Cross-Zertifizierung von n Unternehmen sind (n²-n)/2 peer-to-peer Verbindungen und n²-n Zertifikate notwendig => 8 Unternehmen – 28 Verbindungen – 56 Zertifikate GMX 1+1 Doug Dr. Wolf Müller

Cross-Zertifizierung Nicht der User, sondern Administrator entscheidet, ob andere PKI vertrauenswürdig ist Pfadbildung komplex Nur für kleine Anzahl an PKI geeignet Dr. Wolf Müller

Bridge CA HU-Berlin Bridge CA vergibt Zertifikate an CA´s – nicht an einzelne User Bridge ist nicht Trust Point sondern immer nur Zwischenstation bei Pfadbildung HUB Informatik Physik Bridge-CA TU-Berlin Carol TU Alice Bob 1 & 1 Gruppe Web.de GMX 1+1 Doug Dr. Wolf Müller

Bridge CA Pfadbildung einfacher als bei Cross-Zertifizierung Auch für größere Anzahl an PKI noch überschaubar Bridge-CA Dr. Wolf Müller

X.509-Zertifikate 154 sha1WithRSAEncryption CN=HU-DCA version v3 serialNumber 154 signature sha1WithRSAEncryption issuer CN=HU-DCA validity Not Before: Oct 13 11:17:44 2004 GMT Not After : Oct 13 11:17:44 2005 GMT subject CN=goya3.informatik.hu-berlin.de subjectPublicKeyInfo rsaEncryption/1024 bit... extensions X509v3 Basic Constraints: critical CA:FALSE ... signatureAlgorithm signatureValue 61:15:78:c6:b2:95:… Zertifikat des Webmail-Servers, ausgestellt von der CA des Informatikums Dr. Wolf Müller

X.509-Zertifikate (2) Standard-Format für Zertifikate CCITT Empfehlung zur Authentifizierung in X.500 Verzeichnissen (1988) Codiert in ASN.1/DER Heutzutage fast nur noch X.509v3, mit dieser Version wurden Erweiterungen eingeführt. In RFC 2459 werden von der IETF für den Einsatz im Internet benötigte Erweiterungen definiert Jede Erweiterung kann als kritisch markiert werden CCITT= comite consultatif Internationale de Telegraphique et Telefonique DER=Distinguished Encoding Rules Kritische Erweiterung: wenn sie nicht geparst wird muss das Zertifikat verworfen werden Dr. Wolf Müller

Basic Certificate Content SerialNumber signature issuer validity notBefore notAfter subject SubjectPublicKeyInfo Issuer DN of CA SubjectPublicKeyInfo enhält Algorithmenangaben und Public Key Es gibt Parameter-Vererbung, Issuer und Subject haben bei keinen Optionen die gleichen optionen Dr. Wolf Müller

Extensions SubjectType Extensions CA oder Benutzer Pfadlängenbeschränkung Name Extensions Alternative Names Name Constraints Key Attributes Key Usage Private Key Validity Key Identifier Pfadlängenbeschränkeung sollte nur für cas vergeben werden AlternativeNames bei CA mail-adresse, bei ipsec-routern ip-adresse, sonst dns-namen Name-Constraints: schließen gewisse Pfade/unterbäume aus key-Usage : nur signieren/verschlüßeln... Bis wann ist der PrivateKey gültig KeyIdentifier wenn eine Person mehrere Schlüssel hat Dr. Wolf Müller

Extensions (2) PolicyInformation Certificate Policies Policy Mapping Policy Constraints Additional Information CRL Distribution Points Authority Information Access Subject Directory Information Welche Polcy gilt, wo bekommt man mehr infos. PolicyMapping Wie passt Policy 1 von CA A zu Policy 2 von CA B Ist PolicyMapping erlaubt? Wenn ja wie oft? Wo gibt es CRLs Wo gibt es weitere Infos von der CA SubjectDirectoryInfo kann jedes X.500-Attrib enthalten Dr. Wolf Müller

Empfehlungen für X.509 X.500 oder DNS als Distinguished Names max. 3, für CAs 5 Jahre Gültigkeit KeyUsageExtensions als „critical“ markieren Policies als non-critical aufnehmen Alternative Names und SubjectInformationAccess ins Zertifikat aufnehmen SHA-1 besser SHA-256 RSA 1024, besser 2048 Bit Details: RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Dr. Wolf Müller

Veröffentlichung der Zertifikate Verzeichnisdienste( X.500/LDAP) FTP HTTP E-Mail Eine neuere Überlegung ist die Verteilung der Schlüssel mit Hilfe von DNS Meist X.500 mit Ldap-Zugriff Ftp: ftp.foo.org/id48.cert http http://www.foo.org/id48.cert EMail ist ziemlich problematisch DNS später Dr. Wolf Müller

Probleme Durch die Komplexität können leicht Inkompatibilitäten entstehen. Probleme bei Namensvergleichen durch unterschiedliche Codierungen. Dadurch sind einige Extensions unbrauchbar Fehlende Zeitstempel beim Signieren Viele Zertifikate werden für zu lange Zeiträume ausgestellt. Sichere Verwahrung des privaten Schlüssels Stärke von Signaturverfahren Stärke der Hashfunktion Wenn jeder seinen eignenen Standart schafft entstehen neue Probleme Dr. Wolf Müller

Gesetzliche Vorschriften Signaturgestz von 1997 Eu-Richtlinie Signaturgesetz (SigG) von 2000 Signaturverordnung Gesetz zur Anpassung der Formvorschriften (2001) Dr. Wolf Müller

Signaturgesetz von 1997 Erstes Gesetz dieser Art weltweit. Sehr strenge Anforderungen an CAs. Haftungsfragen, Gültigkeit und die Gleichstellung der digitalen Signatur mit der Unterschrift wurden nicht behandelt. CAs brauchten Genehmigung der RegTP. Auslöser für die Entwicklung der EU-Richtlinie. Eine CA einzurichten kostete 10MioDM Nach 2 Jahren nur 2 CAs Dr. Wolf Müller

EU-Richtlinie Verbindliche gemeinsame Richtlinie für alle EU-Staaten Soll für steigende Akzeptanz der digitalen Signatur und die Öffnung des Binnenmarktes für CAs sorgen CAs brauchen keine Genehmigung mehr, dafür werden Haftungsregelungen eingeführt. Es werden keine technischen Details sondern nur Begriffe und Eigenschaften definiert. Durch kompromisse ziemlich komplex Dr. Wolf Müller

Signaturgesetz (2001) Setzt die EU-Richtlinie um Unterscheidet (entsprechend der EU-Vorgabe) zwischen Elektronische Signatur Fortgeschrittene elektronische Signatur Qualifizierten Signatur Definiert allgemeine Regelungen für CAs, es gibt: Angezeigte Zertifizierungsdienste Akkreditierte Zertifizierungsdienste Elektronische Signatur: eingescannte Unterschrift fortges.. PublicKey z.b. PGP qualifizierte Signatur ist mit qualifiziertem Zertifikat erstellt, welches von einer CA ausgestellt wurde, noch besser ist qualifiezierte Sig. mit Zert. von akkred. Zert.A Dr. Wolf Müller

Signaturverordnung Enthält Anforderungen an CAs. Folgende Themen werden behandelt: Sicherheitskonzept Identitätsprüfung Inhalt der Zertifikate Speicherung und Sperrung Einstellung der Tätigkeit Umgang mit ausländischen CAs Akkreditiert ist härter, die sicherheit wird wirklich überprüft, kostet auch mehr Speicherung der Daten 30 Jahre, die Zertifikate dürfen bei Einstellung nicht gesperrt werden Dr. Wolf Müller

DNSSEC Erweiterung des DNS-Protokolls, voll abwärtskompatibel Es werden 3 neue Record-Types eingeführt: „Key“ enthält den Public-Key für die Zone. „Sig“ zu jedem Reord existiert eine Signatur, gespeichert unter dem sig-Record. NXT enthält die für einen Host nicht definierten Records. 1H IN KEY 0x0100 3 1 (AQPFsXW3GQe5z4nvqG+V6tw3LdjDhzPXRBlI+Nky26gpZlbX LMJJnJsAjaSOw y0p7Cwkb8FyL 8QGGqrOtuDTILfr ) ; 1H IN SIG KEY 1 2 3600 20030207121434 20030108121434 8375 @ ( XzX2P+5+af3e84KhA54u5QdslLVaqLzA8541ApW90gV8kDK3 qIfq2KV4J+pCHsFqPV9DH CI/zJsDH/WG4OkCcg== ) DNS ist unsicher, deshlab erweiterungen Dr. Wolf Müller

DNSSEC (2) Der eigene Zonen-Schlüssel kann von der Parent-Zone signiert werden. So entsteht eine Chain-of-Trust bis zu den Root-Servern, deren Public-Keys bekannt sein müssen. DNSSEC ist in RFC 2535 definiert und mit BIND Version 9 erstmals implementiert Nur die Antworten eine Servers sind signiert, es findet weder Verschlüsselung noch Client-Authentifizierung statt. Probleme: Kein Revokeation-Mechanismus. NXT-Feld ermöglicht Zone-Download. Hilft nur gegen DNSSpoofing Dr. Wolf Müller

PKI: Fazit In letzen Jahren viele PKI-Projekte gestartet, aber Ernüchterung: Erhebliche Kosten Großer Organisatorischer Aufwand Mangelnde Nutzerakzeptanz Heterogenität der Lösungen Lösungsvorschlag: European Bridge CA Specification Fehlende Anwendung (in der Masse) E-Mail Elster Gesundheitskarte Dr. Wolf Müller

PKI- Grenzen und Probleme Wem vertraue ich? Große „trust list“ >100 CAs in Browsern Welche Policy bei welcher CA? Welche CA darf für welchen CA Zertifikate ausstellen? Unfälle: DigiNotar http://heise.de/-1336603 Man-in-the-Middle-Zertifikat http://heise.de/-1429722 Konsequente Prüfung? Komplette Prüfung, hierarchisch: Zeiträume, Pfadlänge, Extensions, … Revocation CRLs oder OCSP Was bedeutet gültiges Zertifikat? Authentizität (Ursprung), mehr nicht! Keine Aussage über Dienst, Software oder … Dr. Wolf Müller

Ideen Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing (Usenix 2008) http://perspectives-project.org/ Dezentralisiertes System von Notaren im Netzwerk Welche Zertifikate sehen diese Notare von verschiedenen Punkten im Netz? Vertrauen trust list  Gruppe von Notaren. Convergence: Another Way to Trust (Dan Brown) Firefox-Plugin das Notare statt Built-In CAs nutzt. ABER: Ultimatives Vertrauen in dieses Plugin Dr. Wolf Müller

Anhang: goya3.crt openssl x509 -in goya3.crt -noout -text wolfm@wolftux:~> openssl x509 -in goya3.crt -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 290 (0x122) Signature Algorithm: sha1WithRSAEncryption Issuer: C=DE, O=Humboldt-Universitaet zu Berlin, OU=HU-CA, CN=HU-DCA 3 Validity Not Before: Sep 25 14:34:23 2006 GMT Not After : Sep 25 14:34:23 2007 GMT Subject: C=DE, O=Humboldt-Universitaet zu Berlin, OU=Informatik, CN=goya3.informatik.hu-berlin.de/serialNumber=290 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:e9:15:01:88:7a:ee:a7:37:68:6f:95:65:60:f7: 58:b1:77:56:14:bf:ac:cf:2a:b0:b8:2e:93:30:96: 4f:b3:16:44:a0:6b:5e:4a:fd:8d:bd:63:ad:53:60: ed:95:9c:3f:39:24:28:79:c5:dd:51:a9:2f:80:00: 48:80:49:e0:de:2b:45:59:44:4a:21:76:44:7d:ea: 0f:39:7d:8c:40:33:6d:8d:22:65:b2:6d:8b:d9:54: 42:c3:1d:9e:16:e2:c3:7f:a8:ec:87:66:cf:89:65: 45:42:ae:e6:f6:cd:29:19:e5:a6:ae:73:a5:e7:db: 1d:06:7c:11:45:5c:e7:4a:8f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication Netscape Comment: WWW-Server of Humboldt-Universitaet zu Berlin X509v3 Subject Key Identifier: 8B:AC:09:FA:EA:19:ED:C0:A6:EA:6E:6F:51:C6:F0:BB:3F:04:81:B7 X509v3 Authority Key Identifier: keyid:D6:24:EF:5D:0F:25:7A:F2:BA:25:9A:13:0E:ED:71:C9:70:92:70:DF DirName:/C=DE/O=Humboldt-Universitaet zu Berlin/OU=HU-CA/CN=HU-CA 1 serial:03 X509v3 Subject Alternative Name: email:bell@informatik.hu-berlin.de, DNS:goya3.informatik.hu-berlin.de, IP Address:141.20.20.84 X509v3 Issuer Alternative Name: email:pki@hu-berlin.de Netscape CA Revocation Url: http://ra.pki.hu-berlin.de/hudca3/pub/crl/cacrl.crl Netscape Revocation Url: X509v3 CRL Distribution Points: URI:http://cdp1.pki.hu-berlin.de/hudca3/pub/crl/cacrl.crl URI:ldap://cdp2.pki.hu-berlin.de/hudca3/pub/crl/cacrl.crl URI:http://cdp2.pki.hu-berlin.de/hudca3/pub/crl/cacrl.crl URI:ldap://cdp1.pki.hu-berlin.de/hudca3/pub/crl/cacrl.crl X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.13687.300.1.1.1 CPS: https://ra.pki.hu-berlin.de/hudca3/policy.html Signature Algorithm: sha1WithRSAEncryption b6:68:b7:03:2a:dc:da:6d:fc:81:d6:f7:2f:9f:9a:b6:f9:4d: 7d:5f:dd:49:d9:b3:ec:ee:d0:e6:71:ad:d6:a6:13:0e:d1:24: 2d:c7:02:aa:19:43:6c:9c:cc:ad:46:b3:9a:45:b2:72:c8:0d: d8:44:07:2c:16:c0:be:92:cc:e6:33:5f:ac:82:2f:87:ca:b6: d2:fd:3e:94:01:d4:d4:7a:ac:6f:72:c0:15:d5:ce:06:74:07: 10:a7:f1:c8:96:ce:d7:9e:26:9c:d7:30:44:43:b0:58:42:20: 82:7f:2d:d2:35:71:5a:bc:8b:7c:f2:29:c7:4b:09:97:fa:c4: c1:20:cb:96:27:6f:ff:60:74:57:b6:d9:78:ea:c0:61:c0:c0: 81:4c:3b:48:85:f7:dd:57:c7:b1:78:e7:77:6f:ca:c8:07:d6: fe:87:87:b9:a0:84:3d:1b:39:47:c7:71:c3:be:05:7b:c1:c0: a6:c9:55:82:37:2c:8b:88:71:da:1e:d8:6b:60:80:d4:82:79: a3:a9:d7:6c:f5:4c:e1:ea:8d:42:e0:0f:af:0d:4f:a0:9a:22: 30:15:6b:da:23:c5:20:53:8c:32:14:ec:42:dd:b9:79:18:c8: 3b:5c:aa:ec:b6:c5:c2:37:fd:aa:8f:a2:6a:3d:27:4e:85:61: 39:5e:41:60 Dr. Wolf Müller

Anhang: cacrl.crl openssl crl -inform DER -in cacrl.crl -noout -text Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: /C=DE/O=Humboldt-Universitaet zu Berlin/OU=HU-CA/CN=HU-DCA 3 Last Update: Oct 23 08:43:15 2007 GMT Next Update: Nov 22 08:43:15 2007 GMT CRL extensions: X509v3 CRL Number: 42 Revoked Certificates: Serial Number: 0A Revocation Date: Jun 30 09:07:04 2006 GMT Serial Number: 2A Revocation Date: Aug 24 08:38:51 2006 GMT Serial Number: 4E Revocation Date: Feb 23 12:06:59 2006 GMT Serial Number: 52 Revocation Date: Feb 23 12:07:10 2006 GMT Serial Number: 5C Revocation Date: Feb 23 12:06:33 2006 GMT Serial Number: 5F Revocation Date: Feb 23 12:06:46 2006 GMT Serial Number: 60 Revocation Date: Mar 31 07:09:14 2006 GMT Serial Number: 61 Revocation Date: Apr 4 10:54:57 2006 GMT Serial Number: A7 Revocation Date: Apr 4 10:35:55 2006 GMT Serial Number: BE Revocation Date: Jul 19 09:03:32 2006 GMT Serial Number: C4 Revocation Date: Aug 16 09:34:56 2006 GMT Serial Number: D1 Revocation Date: Sep 20 03:40:00 2006 GMT Serial Number: D2 Revocation Date: Apr 24 12:13:03 2007 GMT Serial Number: DD Revocation Date: Nov 27 00:20:19 2006 GMT Serial Number: FA Revocation Date: Jul 19 09:03:46 2006 GMT Serial Number: 0103 Revocation Date: Dec 16 11:37:43 2005 GMT Serial Number: 010A Revocation Date: Aug 28 10:36:19 2006 GMT Serial Number: 010C Revocation Date: Aug 28 10:36:18 2006 GMT Serial Number: 010D Revocation Date: Aug 28 10:36:17 2006 GMT Serial Number: 0116 Revocation Date: Oct 4 11:33:49 2006 GMT Signature Algorithm: md5WithRSAEncryption ad:76:36:fd:d6:e1:88:f6:24:d5:a2:90:c8:9a:fe:64:48:7c: 33:37:fe:7a:41:16:7f:39:90:b8:10:b9:c8:95:28:0a:e6:41: b5:68:aa:68:3a:f7:01:d4:45:0f:09:6b:56:5c:c1:b2:21:53: f1:0a:83:54:32:81:b2:9c:96:97:bc:18:64:fe:e1:91:55:2e: 33:6a:fe:55:e5:b8:79:8f:94:0f:7d:27:50:7e:a6:76:16:ce: 50:99:12:ae:34:43:ea:9c:82:c1:6e:b4:59:fa:6b:7e:97:11: cb:93:cf:aa:3d:03:fd:49:8a:71:69:20:d1:29:4d:7e:87:b8: bb:9b:38:30:77:6e:f8:ce:29:8b:a0:54:e9:60:f1:9c:b5:51: 8d:16:3a:f3:82:5b:79:39:8d:6e:57:82:c7:9e:03:d3:b4:6b: a7:80:9a:73:ad:6d:27:97:6a:75:c2:f6:77:81:af:de:33:65: b3:97:45:fd:c0:54:9e:59:9f:87:7e:b4:c7:5c:f1:1a:3f:57: 2e:41:fc:86:a6:b2:f3:26:ac:82:33:40:25:5a:8e:01:ef:9f: c5:06:84:79:98:af:bc:7d:34:d9:e9:7a:d4:8b:f3:58:c1:69: 29:4a:51:c7:43:2c:2e:02:e9:ba:af:aa:37:67:88:5d:48:bb: 04:82:96:38 Dr. Wolf Müller

Anhang: fetch: meine.deutsche-bank.de openssl s_client -connect meine.deutsche-bank.de:443 wolfm@wolftux:~> openssl s_client -connect meine.deutsche-bank.de:443 CONNECTED(00000003) depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=DE/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=HRB30000/C=DE/postalCode=60323/ST=Hessen/L=Frankfurt Am Main/streetAddress=Alfred-Herrhausen-Allee 10a/O=Deutsche Bank AG/CN=meine.deutsche-bank.de i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority Server certificate -----BEGIN CERTIFICATE----- MIIGMTCCBRmgAwIBAgIQPBb+2OhYfVZIS+v0EfZxpTANBgkqhkiG9w0BAQUFADCB vjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE4MDYGA1UEAxMv VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBTR0MgQ0Ew HhcNMDcwOTE4MDAwMDAwWhcNMDgwOTE3MjM1OTU5WjCB8TETMBEGCysGAQQBgjc8 AgEDEwJERTEbMBkGA1UEDxMSVjEuMCwgQ2xhdXNlIDUuKGIpMREwDwYDVQQFEwhI UkIzMDAwMDELMAkGA1UEBhMCREUxDjAMBgNVBBEUBTYwMzIzMQ8wDQYDVQQIEwZI ZXNzZW4xGjAYBgNVBAcUEUZyYW5rZnVydCBBbSBNYWluMSQwIgYDVQQJFBtBbGZy ZWQtSGVycmhhdXNlbi1BbGxlZSAxMGExGTAXBgNVBAoUEERldXRzY2hlIEJhbmsg QUcxHzAdBgNVBAMUFm1laW5lLmRldXRzY2hlLWJhbmsuZGUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDLUNzWHIdvqWtImMZLoqVeajVuabWuNmj40JjK Xg/R2tZHAAXM+yvPPZ/Q4lUavV4U+H7Kv4eynqRMttMtUP7GO2e5KkpAUb4FaDCY eRwQgouZvcHeeGFhGoUjtp7MB257s+Yl9QO58N56gJNX80LOld1YDwvIP0Xl/+kT gmFdnE4wdtcTPDYDQFeHnpLsp8Nwfh3Wu2wtd8katFoCDNT0WuhjPtFe2cbBWmid jqOzGo3F6uvnsfkoE3u8aHWJYlfXLGa7JGNzLTgcUOm+yjH35Sz6Am3GShSzW4Yf nPf2fmrTz1/rEO11aGT1pgS+XNmaUlMTh4x78tctj3PzfQNBAgMBAAGjggH0MIIB 8DAJBgNVHRMEAjAAMB0GA1UdDgQWBBRsumeDvF7MnqHQzAQUNrL3Q1NFazALBgNV HQ8EBAMCBaAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXBjAqMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMD4GA1UdHwQ3MDUwM6AxoC+G LWh0dHA6Ly9FVkludGwtY3JsLnZlcmlzaWduLmNvbS9FVkludGwyMDA2LmNybDAo BgNVHSUEITAfBggrBgEFBQcDAQYIKwYBBQUHAwIGCWCGSAGG+EIEATAfBgNVHSME GDAWgBROQ8gddu83U3pP8lhvlPM44tW93zB2BggrBgEFBQcBAQRqMGgwKwYIKwYB BQUHMAGGH2h0dHA6Ly9FVkludGwtb2NzcC52ZXJpc2lnbi5jb20wOQYIKwYBBQUH MAKGLWh0dHA6Ly9FVkludGwtYWlhLnZlcmlzaWduLmNvbS9FVkludGwyMDA2LmNl cjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAfMAcGBSsO AwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2ln bi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQADggEBAAKeE8mghM6bxAlB HFMLl0aykKjOVRtAq5P8oqLk/KXIO4iBPhv+9OaYYmN8ar1mTGXCHzavggoGwgnb uWX+6NsRxPR85+VlnqWpXXRBmhVgJDMCDuA8g2+SOUSbsKqLuo3Ys3FK6wPD0GDQ T3icob9R7zBvriKQLmuuqqIpNOzfjlflJg5qodxpPPNwKzwvT+nx/4y1/wedwzj9 rL9MxvwIid9tONytDMJtomlP9KSl+lk3dwOW+A79VqjJqny8nef6Z5Q90FWxj8CJ E1pGVezs0pf8/tX2hYXABCq4sh2rUfRZX94IYKc/+cMhejmUuqSYZRmbd4QOM6Pf +7e0TXc= -----END CERTIFICATE----- subject=/1.3.6.1.4.1.311.60.2.1.3=DE/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=HRB30000/C=DE/postalCode=60323/ST=Hessen/L=Frankfurt Am Main/streetAddress=Alfred-Herrhausen-Allee 10a/O=Deutsche Bank AG/CN=meine.deutsche-bank.de issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA ... Dr. Wolf Müller

Anhang: db.pem openssl x509 -in db.pem -inform PEM -noout -text olfm@wolftux:~> openssl x509 -in db.pem -inform PEM -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 3c:16:fe:d8:e8:58:7d:56:48:4b:eb:f4:11:f6:71:a5 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA Validity Not Before: Sep 18 00:00:00 2007 GMT Not After : Sep 17 23:59:59 2008 GMT Subject: 1.3.6.1.4.1.311.60.2.1.3=DE/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=HRB30000, C=DE/postalCode=60323, ST=Hessen, L=Frankfurt Am Main/streetAddress=Alfred-Herrhausen-Allee 10a, O=Deutsche Bank AG, CN=meine.deutsche-bank.de Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:cb:50:dc:d6:1c:87:6f:a9:6b:48:98:c6:4b:a2: a5:5e:6a:35:6e:69:b5:ae:36:68:f8:d0:98:ca:5e: 0f:d1:da:d6:47:00:05:cc:fb:2b:cf:3d:9f:d0:e2: 55:1a:bd:5e:14:f8:7e:ca:bf:87:b2:9e:a4:4c:b6: d3:2d:50:fe:c6:3b:67:b9:2a:4a:40:51:be:05:68: 30:98:79:1c:10:82:8b:99:bd:c1:de:78:61:61:1a: 85:23:b6:9e:cc:07:6e:7b:b3:e6:25:f5:03:b9:f0: de:7a:80:93:57:f3:42:ce:95:dd:58:0f:0b:c8:3f: 45:e5:ff:e9:13:82:61:5d:9c:4e:30:76:d7:13:3c: 36:03:40:57:87:9e:92:ec:a7:c3:70:7e:1d:d6:bb: 6c:2d:77:c9:1a:b4:5a:02:0c:d4:f4:5a:e8:63:3e: d1:5e:d9:c6:c1:5a:68:9d:8e:a3:b3:1a:8d:c5:ea: eb:e7:b1:f9:28:13:7b:bc:68:75:89:62:57:d7:2c: 66:bb:24:63:73:2d:38:1c:50:e9:be:ca:31:f7:e5: 2c:fa:02:6d:c6:4a:14:b3:5b:86:1f:9c:f7:f6:7e: 6a:d3:cf:5f:eb:10:ed:75:68:64:f5:a6:04:be:5c: d9:9a:52:53:13:87:8c:7b:f2:d7:2d:8f:73:f3:7d: 03:41 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 6C:BA:67:83:BC:5E:CC:9E:A1:D0:CC:04:14:36:B2:F7:43:53:45:6B X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Certificate Policies: Policy: 2.16.840.1.113733.1.7.23.6 CPS: https://www.verisign.com/rpa X509v3 CRL Distribution Points: URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto X509v3 Authority Key Identifier: keyid:4E:43:C8:1D:76:EF:37:53:7A:4F:F2:58:6F:94:F3:38:E2:D5:BD:DF Authority Information Access: OCSP - URI:http://EVIntl-ocsp.verisign.com CA Issuers - URI:http://EVIntl-aia.verisign.com/EVIntl2006.cer 1.3.6.1.5.5.7.1.12: 0`.^.\0Z0X0V..image/gif0!0.0...+......Kk.(.....R8.).K..!..0&.$http://logo.verisign.com/vslogo1.gif Signature Algorithm: sha1WithRSAEncryption 02:9e:13:c9:a0:84:ce:9b:c4:09:41:1c:53:0b:97:46:b2:90: a8:ce:55:1b:40:ab:93:fc:a2:a2:e4:fc:a5:c8:3b:88:81:3e: 1b:fe:f4:e6:98:62:63:7c:6a:bd:66:4c:65:c2:1f:36:af:82: 0a:06:c2:09:db:b9:65:fe:e8:db:11:c4:f4:7c:e7:e5:65:9e: a5:a9:5d:74:41:9a:15:60:24:33:02:0e:e0:3c:83:6f:92:39: 44:9b:b0:aa:8b:ba:8d:d8:b3:71:4a:eb:03:c3:d0:60:d0:4f: 78:9c:a1:bf:51:ef:30:6f:ae:22:90:2e:6b:ae:aa:a2:29:34: ec:df:8e:57:e5:26:0e:6a:a1:dc:69:3c:f3:70:2b:3c:2f:4f: e9:f1:ff:8c:b5:ff:07:9d:c3:38:fd:ac:bf:4c:c6:fc:08:89: df:6d:38:dc:ad:0c:c2:6d:a2:69:4f:f4:a4:a5:fa:59:37:77: 03:96:f8:0e:fd:56:a8:c9:aa:7c:bc:9d:e7:fa:67:94:3d:d0: 55:b1:8f:c0:89:13:5a:46:55:ec:ec:d2:97:fc:fe:d5:f6:85: 85:c0:04:2a:b8:b2:1d:ab:51:f4:59:5f:de:08:60:a7:3f:f9: c3:21:7a:39:94:ba:a4:98:65:19:9b:77:84:0e:33:a3:df:fb: b7:b4:4d:77 Dr. Wolf Müller

Anhang: EVIntl2006.crl (816 Einträge, gekürzt) openssl crl -in EVIntl2006.crl -inform der -noout -text wolfm@wolftux:~> openssl crl -in EVIntl2006.crl -inform der -noout -text Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA Last Update: Dec 17 11:00:51 2007 GMT Next Update: Dec 31 11:00:51 2007 GMT Revoked Certificates: Serial Number: 0101502A77BBA4601C14C9A65EDA72E6 Revocation Date: Sep 7 19:03:29 2007 GMT ... Serial Number: 7FC258BD3DB4980813FB71D353FF3163 Revocation Date: Dec 13 14:56:36 2007 GMT 2d:f0:82:30:36:91:18:74:41:37:1d:45:42:cd:52:0d:52:09: b5:95:23:52:13:81:58:03:40:15:46:f2:31:c7:f3:a1:14:05: 00:7a:8a:f9:8a:ca:97:94:cf:90:3d:07:35:4e:1b:2c:df:d9: f2:03:13:0f:40:4d:6e:d3:f1:b9:41:d3:7a:ed:91:8a:eb:e4: 55:7d:07:9d:19:41:d8:a7:ba:98:53:ac:81:57:63:e2:15:c2: 05:25:3e:b9:d5:1b:26:30:ce:58:8a:93:35:ec:a6:ef:94:2c: c5:b8:51:64:d5:c2:f1:b7:cd:bf:fd:3a:66:d8:2f:40:9d:51: 74:26:9d:73:81:ef:80:71:0f:ed:e1:66:25:9d:d3:fc:6a:3e: 20:5d:12:cd:c1:ba:bd:0d:6a:54:d5:b2:3f:db:d4:76:bf:b4: 89:6f:0a:67:d3:76:47:a5:a2:c0:6c:0d:33:52:04:0c:12:fc: de:30:5f:31:63:7e:ea:cd:66:88:70:d8:ce:1b:4c:c7:a1:94: bf:74:d2:65:6f:b6:7e:a5:08:8d:68:6e:a2:b0:4a:9e:7e:eb: 5d:fe:ec:e3:9c:12:e7:b6:be:bb:9d:4d:a0:3f:e1:f4:07:bd: d3:0c:da:70:a6:87:b2:80:22:10:f7:e1:d7:fa:9f:af:32:74: 79:df:e6:c7 Dr. Wolf Müller