SSL-Zugang zu den Servern der KU

B. Brandel

Alle über das Internet übertragenen Daten können prinzipiell von Dritten abgehört werden. Gerade die Übertragung vertraulicher Informationen, insbesondere von Kennungen und Passwörtern, sollte daher nur über verschlüsselte Datenkanäle erfolgen. Um auch sichere Verbindungen zur KU zu ermöglichen, wurden im Laufe der letzten Monate die Zugänge zu wichtigen Servern der KU mittels SSL-Unterstützung abgesichert. Um Ihnen als Nutzern die Echtheit unserer Serverschlüssel nachweisen zu können, haben wir außerdem diese von der Policy Certification Authority (PCA), der obersten Zertifizierungsinstanz für das Deutsche Forschungsnetz, zertifizieren lassen. Was SSL ist und wie Sie SSL an der KU nutzen können, ist Gegenstand dieses Artikels.

Was ist SSL?

Der Verkehr im Internet ist durch genau definierte Kommunikations- und Ablaufrichtlinien (Protokolle) geregelt. Beispielsweise erfolgt der Zugriff eines WWW-Browsers auf die von einem WWW-Server angebotenen Daten über das HTTP-Protokoll. Deswegen fängt die zum WWW-Zugriff benutzte Adresse, der URL, mit http: an.

Secure Sockets Layer (SSL) ist ein Verfahren, mit dem die Kommunikation über ein Internet-Protokoll (HTTP, IMAP etc.) zusätzlich verschlüsselt, signiert und authentisiert werden kann. Das zugrundeliegende Protokoll wird dabei nicht verändert. Wird etwa SSL beim Zugriff auf WWW-Seiten verwendet, dann werden genau dieselben Elemente des HTTP-Protokolls verwendet, mit denen man auch sonst auf einen WWW-Server zugreift, nur wird zusätzlich der gesamte Datenverkehr verschlüsselt; der Protokollname https: statt http:, der am Anfang des URL steht, bezeichnet also nicht ein anderes Protokoll, sondern die zusätzliche Verschlüsselung.

Per SSL wird eine verschlüsselte Verbindung über ein i. Allg. unsicheres Netz (z.B. zwischen Ihrem PC und einem Server der KU) aufgebaut, die es ermöglicht, gefahrlos sensible Daten wie Passwörter, Klausurergebnisse etc. zwischen beiden Rechnern zu übertragen.

SSL arbeitet nach dem Client-Server-Prinzip, d.h. der Client-Prozess auf Ihrem lokalen PC (z.B. Ihr WWW-Browser) wendet sich an einen Zielrechner und dessen Server-Prozess (z. B. den Verwaltungsserver der KU) mit der Bitte um Gewährung einer verschlüsselten Datenverbindung.

Wie funktioniert SSL?

Die Datenübertragung per SSL-Protokoll geschieht in zwei Schritten:

• dem Verbindungsaufbau (SSL Handshake) zwischen Ihrem PC und dem Server

• sowie der eigentlichen Datenübertragung (SSL Record).

Die genaue Funktionsweise des SSL-Protokolls ist ziemlich komplex, so dass eine detaillierte Darstellung an dieser Stelle zu weit führen würde. Diese können Sie jedoch z.B. unter http://atiswww.ira.uka.de/itdienste/ssl/ssl_2.html (Abschnitt: Das Secure Socket Layer Protokoll) finden.

In den beiden nächsten Abschnitten möchten wir Ihnen daher die Funktionsweise von SSL Handshake und SSL Record in etwas vereinfachter Form erklären.

Der Verbindungsaufbau (SSL Handshake) zwischen SSL-Client-PC und SSL-Server

Der Verbindungsaufbau zwischen Ihrem PC und dem Server besteht aus vier Schritten:

• Aushandeln der Verbindungsmodalitäten:
  Da SSL verschiedene Kompressions- und Verschlüsselungsverfahren unterstützt, müssen diese zwischen Client und Server vor dem eigentlichen Datenaustausch vereinbart werden. Wie es sich gehört, einigen sich beide auf den größten gemeinsamen Nenner.

• Austausch von Zertifikaten:

  • Ihr WWW-Browser fordert dazu vom Server dessen SSL-Zertifikat an. Dies ist ein digitaler Ausweis, der von einer (möglichst) übergeordneten Zertifizierungsstelle, die für die Echtheit des Ausweises bürgt, digital unterschrieben ist. Das Zertifikat enthält u.a. den Namen des Servers, zu dem sich Ihr Browser verbinden will, dessen öffentlichen Schlüssel sowie entsprechende Daten der Zertifizierungsstelle (siehe http://atiswww.ira.uka.de/itdienste/ssl/ssl_2.html, Abschnitt: Zertifikate).

  • Anschließend überprüft Ihr Browser an Hand der übermittelten Daten die Ausweispapiere des Servers, das heißt, er stellt fest,

    • ob das Zertifikat noch gültig ist,

    • ob es auch auf den im URL angegebenen Rechner ausgestellt ist,

    • ob er die Zertifizierungsstelle kennt und ihr vertraut,

    • ob deren Unterschrift echt ist.

    Was Sie tun müssen, wenn die Prüfung schief geht, wird im Abschnitt `Prüfung und Akzeptieren von SSL-Zertifikaten' beschrieben.

  • Umgekehrt könnte auch der Server die Zertifizierung des Client verlangen. Dieser relativ seltene Fall wird hier nicht besprochen, verläuft aber völlig analog.

• Schlüsselaustausch:
  Um die spätere Datenübertragung effizient durchführen zu können, muss die Sicherung mittels symmetrischer Verschlüsselung erfolgen. Dazu generiert Ihr Client-PC einen temporären symmetrischen Schlüssel, der für die Dauer der SSL-Verbindung gültig ist und verschlüsselt diesen mit dem im gerade überprüften Zertifikat aufgeführten öffentlichen Serverschlüssel. Diesen verschlüsselten symmetrischen Session Key sendet er anschließend an den Server. Dieser entschlüsselt mit seinem privaten Serverschlüssel den Session Key und akzeptiert diesen als Verschlüsselungskey für die nachfolgende Kommunikation. Da nur der echte Server den passenden privaten Serverschlüssel besitzt, ist somit auch dem Client gegenüber nachgewiesen, dass sich am anderen Ende der Leitung auch der richtige Server befindet.

• Überprüfung der Verbindung:
  Abschließend prüfen Client und Server noch mit kurzen Testnachrichten, ob die Kommunikation zwischen beiden Seiten funktioniert, und die eigentliche Datenübertragung kann beginnen.

Die Datenübertragung (SSL Record) zwischen Ihrem PC und dem Server

Nachdem die Verbindung aufgebaut ist, werden die zu übertragenden Daten in Blöcke geeigneter Größe gestückelt, die mit dem vereinbarten Session Key verschlüsselt und mit dem so genannten Message Authentication Code (MAC) signiert werden. Diese Datenpakete werden dann anschließend via TCP/IP an den Empfänger weitergeleitet. Dort angekommen, werden die Einzelpakete auf Unversehrtheit geprüft (Signaturcheck), entschlüsselt und wieder zusammengesetzt.

Was tun bei unbekannten SSL-Zertifikaten?

Bisher wurde verschwiegen, was Sie tun können, wenn beim SSL-Handshake die Prüfung des Zertifikats schief geht. Ihr Browser lässt Ihnen dann folgende Wahl:

• Sie vertrauen dem Zertifikat für die Dauer der Browsersitzung: Die Verbindung wird einmalig hergestellt.

• Sie lehnen das Zertifikat ab. Konsequenz: Die Verbindung wird sofort abgebrochen.

• Sie vertrauen dem Zertifikat trotz allem generell: Dieses wird permanent akzeptiert; SSL-Verbindungen zum Server werden hergestellt, so lange das Zertifikat gültig ist.

Überlegen Sie gut, was Sie tun:

• Bei Kreditkarten-Transaktionen oder Online-Banking sollten Sie in all diesen Fällen tunlichst das fragwürdige Zertifikat ablehnen und die Verbindung abbrechen.

• Bei anderen, weniger folgenreichen Aktionen können Sie nach eigenem Ermessen gegebenenfalls den Zugang einmalig akzeptieren, z.B. wenn das Zertifikat abgelaufen ist oder der Name des zugehörigen Rechners nicht mit dem auf dem Zertifikat angegebenen übereinstimmt.

  Manchmal meldet dieser Server sich mit seinem anderen Namen, z.B. eo-sun-us2a.ku-eichstaett.de, während das Zertifikat auf seinen Funktionsnamen mail.ku-eichstaett.de ausgestellt ist. In ähnlichen Fällen kann aber auch ein Hacker versuchen, Ihre Wunschverbindung zu einem anderen Server umzuleiten.

• Besonders vorsichtig sollten Sie sein, wenn die Unterschrift unter dem Zertifikat nicht stimmt. Dann sollten Sie die Verbindung unbedingt ablehnen.

• Wenn Ihr Browser die Zertifizierungsstelle nicht kennt und sie diese auch nicht auf die Schnelle durch Prüfung als vertrauenswürdig einschätzen können oder wollen, dann können Sie in unwichtigen Fällen (z.B. wenn Sie auch eine unverschlüsselte Verbindung akzeptieren würden) das Zertifikat u.U. einmalig annehmen.

• In wichtigen Fällen sollten Sie aber unbedingt die Echtheit des Zertifikats wie im nächsten Abschnitt beschrieben überprüfen.

• Im Zweifelsfall wenden Sie sich bitte sicherheitshalber an das URZ.

Überprüfung und Einbindung von SSL-Zertifikaten in Ihren WWW-Browser

Ähnlich wie bei PGP-Schlüsseln gibt es bei SSL ebenfalls zwei Möglichkeiten, das Vertrauen in SSL-Zertifikate herzustellen.

• Sie prüfen die Echtheit eines Zertifikats direkt, indem Sie den im Browserfenster angezeigten Fingerprint des Zertifikats mit dem in einer vertrauenswürdigen Quelle (z.B. in einem Aushang oder in verlässlichen Printmedien (z.B. in der )) veröffentlichten Fingerprint vergleichen. Dies ist aber recht mühsam, da Sie dann für jeden Server ein Zertifikat einzeln prüfen und in Ihren Browser einbinden müssen. Dazu müssen Sie bis zu 6 Dialogfenster ausfüllen.

• Die andere, wesentlich elegantere und flexiblere Methode ist die Herstellung eines Vertrauenspfads zu einer zentralen Zertifizierungsinstanz (ähnlich einer CA-Hierarchie bei PGP). Sie können Ihrem Web-Browser die SSL-Zertifikate der zertifizierten KU-Server auf diesem Weg ganz leicht dauerhaft bekanntmachen. Damit vermeiden Sie die ständige Wiederholung der Prozedur zum Akzeptieren bisher unbekannter Zertifikate der KU.

Die SSL-Keys unserer Server sind nämlich von der Policy Certification Authority (PCA), der Zertifizierungsinstanz für das Deutsche Forschungsnetz (DFN) (http://www.dfn-pca.de/), mit dem Key der DFN Server-CA, Generation 1-1, signiert. Dieser Key dient ausschließlich zur Zertifizierung von SSL-Servern.

Seinerseits ist dieser Schlüssel vom Key der DFN Toplevel-CA, Generation 1, unterschrieben, der ausschließlich zur Zertifizierung von anderen CAs verwendet wird.

Wenn Sie diese beiden Zertifikate in Ihrem Browser wie im nächsten Abschnitt beschrieben als vertrauenswürdig eintragen, werden über diesen Vertrauenspfad alle zertifizierten SSL-Server-Keys der KU automatisch als echt erkannt.

Aufnahme der Keys der DFN Toplevel-CA sowie der DFN Server-CA in Ihren WWW-Browser

Um eine SSL-Verbindung zu einem der zertifizierten KU-Server aufnehmen können, müssen Sie zunächst einmalig das Wurzelzertifikat der DFN Toplevel-CA in die Zertifikatsliste Ihres Browsers laden, da dieses Wurzelzertifikat nicht standarmäßig in der Grundinstallation Ihres Browsers mitgeliefert wird. Das Wurzel- oder Stammzertifikat hat die Aufgabe, als Ursprung der Kette von signierten Zertifikaten zu dienen.

• Aufnahme der beiden DFN-Zertifikate in die Zertifikatsverwaltung des MS-Internet-Explorer 6.0

  MS-Windows verwendet den Begriff Stammzertifikate an Stelle von Wurzelzertifikate. Zur Aufnahme des Wurzelzertifikats in die Zertifikatsverwaltung des MS-Internet-Explorer klicken Sie bitte auf:

  http://www.dfn-pca.de/certification/x509/g1/data/html/cacert/root-ca-cert.der

  und öffnen die Datei. Im folgenden Dialogfenster wird das Zertifikat als nicht vertrauenswürdig bezeichnet, weil es noch nicht in die Zertifikatsverwaltung aufgenommen ist. Wir sind ja gerade dabei, es aufzunehmen und damit unser Vertrauen auszusprechen! Daher sollten Sie auch zunächst unter Details den SHA1-Fingerabdruck überprüfen (z.B durch Vergleich mit dem Zertifikat der DFN Toplevel-CA), um die Echtheit des Zertifikats sicherzustellen.

  Klicken Sie dann unter Allgemein auf Zertifikat installieren und wählen Sie im darauf folgenden Installations-Assistenten zwei mal einfach Weiter und dann Fertig stellen . Es erscheint folgende Dialogbox:

  

  Wählen Sie dort Ja und schließen Sie die restlichen Fenster mit OK ab.

  Sie finden die Zertifikatsverwaltung des MS-Internet-Explorer im Menü Extras -> Internetoptionen und dann weiter unter Inhalte -> Zertifikate. Das neu aufgenommene Wurzelzertifikat der `DFN Toplevel Certification Authority´ befindet sich nun in der Liste unter Vertrauenswürdige Stammzertifizierungsstellen.

  Wiederholen Sie diesen Vorgang analog mit dem Zertifikat der DFN Server-CA, das Sie unter http://www.dfn-pca.de/certification/x509/g1/ca-ssl-tls-server/g1/data/html/cacert/ca-ssl-tls-server-cert.der finden.

  Das neu aufgenommene Zertifikat der DFN Server-CA befindet sich nun in der Liste unter Zwischenzertifizierungsstellen.

  Sie können über dieses Menü jederzeit Zertifikate bearbeiten oder löschen.

• Aufnahme der beiden DFN-Zertifikate
  in die Zertifikatsverwaltung von Netscape 7.0

  Die Netscape- und Opera-Browser verwenden eigene Listen, in die die Zertifikate eingefügt werden müssen. Das Laden des Wurzelzertifikats wird im folgenden Beispiel mit Netscape Communicator 7.0 gezeigt. Zur Aufnahme des Wurzelzertifikats in die Zertifikatsliste Ihres Browsers klicken Sie auf:

  http://www.dfn-pca.de/certification/x509/g1/data/html/cacert/root-ca-cert.der

  Es erscheint ein Dialogfenster mit dem Titel Zertifikate herunterladen, in dem Ihnen folgende drei Auswahlmöglichkeiten angeboten werden:

  • Diesem ZA bei der Identifikation von Netsites vertrauen.

  • Diesem ZA bei der Identifikation von eMail-Benutzern vertrauen.

  • Diesem ZA bei der Identifikation von Software-Entwicklern vertrauen.

  Unter Hilfe finden Sie eine Erklärung dieser drei Möglichkeiten. Prüfen Sie unbedingt als nächstes durch Anklicken von Anzeigen den SHA1- und/oder den MD5-Fingerabdruck des ZA-Zertifikats und schließen dieses Fenster wieder.

  

  

  Anschließend kreuzen Sie bitte alle drei Kästchen im noch offenen Fenster Zertifikate herunterladen an und nehmen mit OK das Zertifikat an:

  

  Wiederholen Sie diesen Vorgang analog mit dem Zertifikat der DFN Server-CA, das Sie unter

  http://www.dfn-pca.de/certification/x509/g1/ca-ssl-tls-server/g1/data/html/cacert/ca-ssl-tls-server-cert.der

  finden.

Im Nescape Communicator 7.0 können Sie das Zertifikat der gerade besuchten WWW-Site jederzeit ansehen, indem Sie auf das Sicherheitsschloss klicken. Es erscheint das Fenster Seiteninformation, in dem Sie auf den Reiter Sicherheit unter Allgemein den Fingerprint des Zertifikats, den Aussteller und den Namen des Rechners prüfen und unter Details den Zertifizierungspfad ansehen können.

Im Menü Bearbeiten -> Einstellungen und dann weiter unter Privatsphäre & Sicherheit -> Zertifikate finden Sie unter Zertifikate verwalten ... den Zertifikatsmanager, wo Sie die von Ihrem Browser akzeptierten Zertifikate einsehen, bearbeiten und löschen können.

Allgemeine Hinweise zur Nutzung der SSL-Zugänge zu den KU-Servern

Nachdem beide Zertifikate des DFN Ihrem Browser bekannt sind, werden über den damit erzeugten Vertrauenspfad alle Server der KU, die von der DFN-PCA zertifiziert wurden oder es in Zukunft werden, automatisch als vertrauenswürdig akzeptiert und geschützte Verbindungen mit ihnen aufgebaut.

Je nach Browser und Browsereinstellungen erhalten Sie nur noch eine Sicherheitsmitteilung, wenn Sie geschützte Webseiten betreten und wieder verlassen. Diese Dialogboxen sind aber nicht sehr aussagekräftig, da sie nicht sagen, welche Site man besucht und welche man gerade verlässt.

Nach erfolgreichem SSL-Zugang gibt der Browser dem Anwender eine entsprechende Information: Beim Netscape 7.0, Opera 6.x und Internet Explorer schließt sich das Bügelschloss, der Netscape 4.7x signalisiert eine sichere Seite durch den intakten Schlüssel.

Folgende SSL-verschlüsselten Zugangsmöglichkeiten zu den Server der KU sind derzeit möglich:

WebMailer (nur für IMAP-Nutzer)

IMAP-Nutzer können auf Ihr IMAP-Postfach auf dem IMAP4-Mail-Server der KU über einen sicheren WWW-Zugang zugreifen (WebMailer). Tragen Sie dazu in Ihrem Browser

https://mail.ku-eichstaett.de/

ein. Beim WebMailer-Zugang gibt es leider ab und zu das weiter oben beschriebene Problem, dass der Server sich beim Browser als https://eo-sun-us2a.ku-eichstaett.de/ meldet. Das hat eine Warnmeldung zur Folge, bei der Sie sich das Zertifikat nochmals anzeigen lassen können, bevor sie die Verbindung akzeptieren.

Dann aber ist die sichere Verbindung hergestellt und Sie können sich mit Ihrer IMAP-Kennung und IMAP-Passwort einloggen:

Der IMAP-Zugang über einen SSL-fähigen IMAP4-Client (Netscape 7.0 oder 4.78, PegasusMail etc.) ist momentan noch nicht möglich, wird aber beim nächsten Mailserver-Upgrade in Bälde realisiert werden.

Verwaltungsserver der KU:

Durch Eingabe des URLs

https://www-zuv.ku-eichstaett.de/flexnow/

und Anklicken von Dienste können Studierende der Wirtschaftswissenschaften auf das Prüfungsverwaltungssystem FlexNow zugreifen und sich beispielsweise zu Prüfungen an- oder abmelden:

Helpdesk des Universitätsrechenzentrums:

Auf das Helpdesk-System des Universitätsrechenzentrums können Sie durch Eingabe des URLs

https://urz-helpdesk.ku-eichstaett.de/

zugreifen.

Tobit David Professional Server:

Zum Tobit David Professional Server gibt es zwei SSL-Zugangsmöglichkeiten, einen WWW-Zugang über https und einen SSL-gesicherten IMAP-Zugang. Sowohl der WWW-Zugang zu Ihren Nachrichtenarchiven als auch der Zugang mit einem IMAP-Mail-Client wurden ausführlich in zwei Beiträgen in der INKUERZE 1/2000 und auf den Dokumentationsseiten des Rechenzentrums beschrieben, so dass bezüglich der Konfigurationseinstellungen auf diese Quellen verwiesen wird.

• Zum WWW-Zugang geben Sie im Browser den URL

  https://eo-nw-2.ku-eichstaett.de/Nachname, Vorname/

  ein. Im Fenster kreuzen Sie bitte Sichere Verbindung über TLS an (TLS ist eine Variante von SSL) und klicken auf Start. Danach müssen Sie nur noch Ihre Kennung (z. B. rza012) und Ihr Remote-Access-Passwort eingeben (Kennwort nicht speichern!) und mit OK bestätigen. Schon sind Sie `drin'!

  

  

  

• Zum IMAP4-Zugang müssen Sie sich z.B. im Netscape Messenger 7.0 im Menü Bearbeiten -> eMail und Diskussionsforen-Kontoeinstellungen durch Anklicken von Konto hinzufügen... ein zusätzliches IMAP-Konto einrichten. Die wichtigsten Einstellungen sollten Sie ähnlich wie in den folgenden Bildern vornehmen bzw. nachträglich entsprechend abändern.

  

  

  

Fingerprints wichtiger Zertifikate:

• Der Key der DFN Toplevel-CA, Generation 1:

  Mit diesem Schlüssel wurde der Public Key der DFN Server-CA signiert; er dient ausschließlich zur Zertifizierung von anderen CAs

  Zertifikat gültig von Dec 1 12:11:16 2001 GMT bis Jan 31 12:11:16 2010 GMT
  von DFN Top Level CA Generation 1:
  SHA1 Fingerprint=8E:24:22:C6:7E:6C:86:C8:90:DD:F6:9D:F5:A1:DD:11:C4:C5:EA:81
  MD5 Fingerprint=3E:1F:9E:E6:4C:6E:F0:22:08:25:DA:91:23:08:05:03

  In binärer Form zum Download:

  http://www.dfn-pca.de/certification/x509/g1/data/html/cacert/root-ca-cert.der

• Der Key der DFN Server-CA, Generation 1-1:

  Mit diesem Schlüssel wurden die Public Keys der KU-Server signiert; er dient ausschließlich zur Zertifizierung von SSL-Servern).

  Das DFN-PCA Server-CA-Zertifikat:

  Zertifikat gültig von Dec 1 12:39:27 2001 GMT bis Dec 1 12:39:27 2005 GMT
  von DFN Top Level CA Generation 1:
  SHA1 Fingerprint=C8:41:74:CE:DA:C2:02:87:B0:33:51:FE:67:07:CF:17:19:C1:12:F3
  MD5 Fingerprint=A3:66:10:4B:AF:2C:6F:ED:D3:96:5B:33:4D:12:94:FC

  In binärer Form zum Download:

  http://www.dfn-pca.de/certification/x509/g1/ca-ssl-tls-server/g1/data/html/cacert/ca-ssl-tls-server-cert.der

• mail.ku-eichstaett.de: (IMAP4-Mail-Server der KU)

  Zertifikat gültig von Apr 8 12:43:24 2002 GMT bis Apr 7 12:43:24 2004 GMT
  von DFN Server CA Generation 1.1

  SHA1 Fingerprint=97:C9:A7:65:36:74:15:31:2F:11:9B:D2:0C:45:A4:F6:E1:CD:01:1A
  MD5 Fingerprint=81:88:61:E7:84:2C:B9:F3:2A:17:4D:C0:46:58:6B:F6

• www-zuv.ku-eichstaett.de (Verwaltungsserver der KU: Abfrage von Prüfungsergebnissen)

  Zertifikat gültig von Apr 8 12:48:15 2002 GMT bis Apr 7 12:48:15 2004 GMT
  von DFN Server CA Generation 1.1

  SHA1 Fingerprint=DE:FB:CF:A9:36:62:AD:62:54:05:F8:CF:03:09:A1:89:9C:3E:63:82
  MD5 Fingerprint=C9:4E:12:B7:C8:CB:D4:01:2D:9A:19:49:90:A2:FE:65

• urz-helpdesk.ku-eichstaett.de (Helpdesk des URZ der KU)
  Zertifikat gültig von Apr 8 12:45:19 2002 GMT bis Apr 7 12:45:19 2004 GMT
  von DFN Server CA Generation 1.1

  SHA1 Fingerprint=82:7E:9F:5B:C7:1E:3D:AF:55:CB:AF:3C:00:2E:4F:B5:28:6F:0D:5D
  MD5 Fingerprint=2D:6D:59:74:15:E5:18:D1:26:90:BA:58:8B:8C:73:F7

• eo-nw-2.ku-eichstaett.de (Tobit David Fax-Server: Webzugang und IMAP4-Zugang)

  Zertifikat gültig von Apr 8 12:41:06 2002 GMT bis Apr 7 12:41:06 2004 GMT
  von DFN Server CA Generation 1.1

  SHA1 Fingerprint=11:A6:D4:82:42:06:35:27:2C:7C:95:67:D5:FC:D4:12:67:40:D8:4B MD5 Fingerprint=9A:45:49:F5:A4:EA:FB:E3:C8:E9:90:DB:A1:3B:51:CA

Literatur:

Ausführliche schriftliche Dokumentationen zum Thema SSL und Zertifizierung finden Sie unter folgenden URLs:

http://atiswww.ira.uka.de/itdienste/ssl/ssl_2.html

http://developer.netscape.com/docs/manuals/security/sslin/contents.htm

http://www1.tfh-berlin.de/~toby/vs/ssl/

http://www.ssw.uni-linz.ac.at/Teaching/Lectures/Sem/2000/Lehner/

http://www.dfn-pca.de/

Eine Liste aller ausgestellten X.509 SSL-Server-Zertifikate der DFN Server-CA Generation 1.1 finden Sie unter

http://www.dfn-pca.de/certification/x509/g1/ca-ssl-tls-server/g1/data/html/certs.html