Da sich die meisten doch noch nicht so ganz gut mit dem Verschlüsseln und der Zertifizierung auskennen, haben wir mal ein paar erklärende Sätze verfasst/kopiert und hoffen, damit die häufigsten Fragen beantworten zu können.
Was ist eine X509-Zertifizierung?
Wie komme ich zu einem Zertifikat?
Was sind Zertifizierungsketten?
Warum erkennt mein Browser die Zertifikate nicht?
Was bringt mir eine Zertifizierung durch die FHB Server CA?
Was ist der Unterschied zwischen SSL und SMIME?
Was sind öffentliche und private Schlüssel?
Wie überprüfe ich ein Zertifikat auf Richtigkeit?
X.509-Zertifikate werden von Rechnern zur Authentifizierung bei einer verschlüsselten Übertragung von Daten (per SSL, Secure Socket Layer) verwendet, z.B. von WWW-Servern (https-URLs).
Prinzipiell kann jeder Server-Betreiber sich selbst ein Zertifikat ausstellen und selbst signieren. Eine CA bestätigt durch ihre digitale Signatur, dass der Zertifikatsinhaber auch wirklich der ist, für den er sich ausgibt. Auf welche Art und Weise eine CA das überprüft, steht in ihrer Policy.
Zertifikate ausgestellt von der FHB Top Level CA und ihrer SUB-CAs finden sie hier.
Sie erstellen einfach einen Request, der Ihre Daten enthält. Diesen Request schicken Sie an die CA. Dann füllen Sie noch einen Teilnahmeantrag aus und schauen persönlich bei der CA vorbei (Ausweis nicht vergessen!). Die CA überprüft Ihre Angaben und bestätigt dies durch eine digitale Signatur unter Ihrem Request und schickt das ganze an Sie zurück. Möchten Sie ein Zertifikat, welches von der FHB Server CA signiert wird, wenden Sie sich bitte an das Rechenzentrum.
Ein Vertrauen in eine CA setzt voraus, dass die CA gewissenhaft arbeitet und sich an gewisse Vorschriften hält. Diese Vorschriften beinhalten zu Beispiel, wer wen wann und wie lange zertifizieren darf und auf welche Art er sich von dessen Identität überzeugen muss. Die Sammlung dieser Vorschriften nennt man Policy, und diese ist bindend für die Mitarbeiter einer CA.
Policies ändern sich im Laufe der Zeit, aber meistens nur geringfügig. Da man aus einem Zertifikat stets den Zeitpunkt der Zertifizierung erkennen kann, wird eine Historie der Policies mitgeführt, um erkennen zu können, unter welchen Bedingungen eine Zertifizierung durchgeführt wurde.
X.509 sieht in der Version 3 Zertifizierungsketten vor. Zur einfachen Erklärung sei hier mal der Fall angenommen, ein Benutzer verbindet sich mit seinem Browser mit einem SSL-Server. Der Server übersendet sein Zertifikat. In diesem Server-Zertifikat steht drin, welche CA die Zertifizierung vorgenommen hat. Von einigen CAs besitzen Browser bereits das Wurzel-Zertifikat. Handelt es sich um eine solche CA, dann kann der Browser sofort überprüfen, ob das Zertifikat echt ist.
Besitzt der Browser das Zertifikat der genannten CA nicht, dann geht er auf die Suche nach den fehlenden Zertifikaten. Verschiedene Browser machen das auf verschiedene Weise, verschiedene Server antworten auf verschiedene Weise. Bei manchen reicht es, das Wurzelzertifikat zu installieren, also nur das oberste, der Beginn der Kette quasi. Andere benötigen auch alle zwischenliegenden. Am besten fährt man, wenn man alle zwischenliegenden gleich installiert. Wir haben extra eine Zusammenstellung.
Unsere WWW-Servers wurden von der FHB Server CA zertifiziert, und diese wiederum von der FHB Top Level CA, welche das Wurzelzertifikat bildet. Dies wird nicht standardmäßig mit den Browsers ausgeliefert und muss daher einmalig in den Browser integriert werden.
Das Wurzelzertifikat der FHB Top Level CA ist nicht standardmäßig in den Browsern enthalten. Sie müssen es einmalig für jeden Client integrieren. Dies geht recht einfach, wie auf der Seite mit der Zusammenstellung beschrieben.
Indem Sie der FHB Top Level CA vertrauen, vertrauen Sie gleichzeitig auch allen Zertifikaten, die diese ausgestellt hat, also auch für weitere CAs.
Stellen Sie sich einmal vor, Ihr SSL-Server wurde von der FHB Server CA zertifiziert. Ein weiterer SSL-Server, zum Beispiel aus dem Fachbereich Wirtschaft, wurde ebenfalls durch die FHB Server CA zertifiziert. Jeder Benutzer, der also das Wurzelzertifikat der FHB Top Level CA in den Browser integriert hat, kann ohne weiteres die Identität beider Server überprüfen und verschlüsselt kommunizieren.
Man möge die etwas ungenaue Formulierung entschuldigen. Es geht hier nicht um die detailgetreue Wiedergabe diverser RFCs, sondern um eine einfache Erklärung.
SSL steht für Secure Socket Layer und beschreibt ein Verfahren, dass verwendet wird, um eine sicherere Verbindung zwischen einem Client und einem Server herzustellen. X.509 beschreibt ein Format, welches für Zertifikate verwendet wird. SSL verwendet wiederum solche Zertifikate für die Autentifizierung beim Verbindungsaufbau.
SMIME ist eine Erweiterung des MIME-Standards für Emails und arbeitet ebenfalls mit X.509-Zertifikaten. Eine CA stellt also genaugenommen keine SSL-Zertifikate aus (obwohl die immer wieder so genannt werden), sondern Zertifikate nach dem X.509-Standard, die für SSL-Verbindungen (Server-Certs) oder SMIME-Emails (Client-Certs) verwendet werden können. Genau genommen sind das X.509v3-Zertifikate, aber das sind schon wieder Feinheiten. Alles klar?
Bei der sogenannten asymmetrischen Verschlüsselung besitzt jeder Teilnehmer einen öffentlichen und einen privaten Schlüssel. Ohne jetzt hier ins Detail zu gehen, sollen nur zwei grundlegende Eigenschaften genannt werden:
1. Zu jedem öffentlichen Schlüssel gibt es genau einen privaten Schlüssel und umgekehrt.
2. Was mit dem einen der beiden verschlüsselt wurde, kann nur mit dem anderen entschlüsselt werden.
Was sich hier ganz harmlos anhört, hat weitreichende Konsequenzen und die Entdeckung stellte in der Geschichte der Kryptographie (und der Nachrichtendienste) eine wahre Revolution dar.
Während der öffentliche Schlüssel für jeden zugänglich gemacht wird (je mehr, desto besser), beruht die Sicherheit des Verfahrens auf der Geheimhaltung des privaten Schlüssels. Dieser darf niemals (weil es so wichtig ist, noch mal: niemals!) irgend jemandem zugänglich gemacht werden. Auch nicht der CA. Die bekommt nur den öffentlichen Schlüssel zu sehen.
Es wird empfohlen den Fingerprint des installierten Zertifikates mit dem vom Aussteller des Zertifikates zu vergleichen. Der Aussteller wird auf einer WEB-Seite die Fingerprints veröffentlichen. Eine Anleitung finden Sie hier.
© 2013 FH Brandenburg letzte Aktualisierung: 16.07.2007 Autor: [Webadmin]


