Inhalt:
Diese Anleitung basiert auf dem „Mini-Howto zur Zertifikat-Erstellung“ von Michael Heimpold mit OpenSSL unter Linux aus dem Jahre 2004 (http://www.heimpold.de/mhei/mini-howto-zertifikaterstellung.htm). Dem Autor sage ich für seine kompetente Erläuterungen, die mir viele Tage Arbeit erspart haben, herzlichen Dank.
Es wird die schrittweise Erstellung von X.509-Zertifikaten unter Windows mit OpenSSL beschrieben, wie man sie zum Beispiel für den Betrieb eines Webservers mit SSL oder für die Signierung und Verschlüsselung in E-Mail-Programmen benötigt. OpenSSL in der Binärdistribution für Windows können Sie herunterladen von http://www.openssl.org/related/binaries.html Die Installation oder Verwendung der erstellten Zertifikate in Apache wird nicht beschrieben, wohl aber in Thunderbird, Outlook, oder ähnlichen Programmen.
Das Erstellen eines Zertifikats lässt sich grob in drei Schritte gliedern. Zunächst muss ein Schlüsselpaar, das heißt ein privater und ein öffentlicher Schlüssel, erstellt werden. Der öffentliche Schlüssel wird anschließend zusammen mit anderen Informationen (Namen und anderen Parametern des Schlüsselinhabers) als so genannter Certificate Signing Request (CSR) an die Certificate Authority (= Zertifizierungsinstanz, kurz: CA) geschickt. Aufgabe der CA ist es, durch geeignete Maßnahmen die Richtigkeit dieser Angaben zu überprüfen und den CSR mit der Signatur der CA zu bestätigen, ihn damit zu beglaubigen und als fertiges Zertifikat zurück zum Antragsteller zu schicken.
Natürlich kann man sich digitale Zertifikate für Programme, SSL-Server und E-Mail-Verkehr auch über hierfür spezialisierte Dienstleister besorgen (Thawte, Geotrust, Verisign, usw.) besorgen, allerdings muss man diese Dienstleistung bezahlen. Der Vorteil solcher „professioneller“ Zertifikate ist allerdings, dass viele Browser die Stammzertifikate dieser CAs schon kennen und ihnen damit automatisch vertrauen. Bei selbst erstellten Stammzertifikaten ist das natürlich nicht der Fall. Hier muss man durch die nachträgliche Installation des CA-Stammzertifikats im Browser selbst das Vertrauen erklären.
OpenSSL für Windows benötigt die „Visual C++ 2008 Redistributables“. Diese können (in verschiedenen Varianten, je nach der verwendeten Windows-Version) vom oben angegeben Link aus heruntergeladen werden. OpenSSL ist eine reine Kommandozeilen-Programmsammlung. Als Arbeitsverzeichnis, in dem die Zertifikate erstellt werden, sollte man OpenSSL\bin oder besser noch einen Unterordner davon verwenden. Zumindest auf dem Arbeitsverzeichnis benötigt der Benutzer volle Zugriffsrechte. Auch im Ordner OpenSSL\bin müssen Konfigurationsdatein verändert werden, sodass auch dort Schreibrechte vorhanden sein müssen.
Damit OpenSSL nicht in Ordner schreibt, in denen keine ausreichenden Zugriffsrechte bestehen, muss vorab die Umgebungsvariable HOME auf das zu verwendende Arbeitsverzeichnis gesetzt werden. Am besten erledigt man das mit den Mitteln des Betriebssystems dauerhaft beim Systemstart. Nur wenn eine Umgebungsvariable HOME existiert, schreibt OpenSSL die temporäre Datei mit der erzeugten Zufallszahl mit dem Namen „.rnd“ in das aktuelle Arbeitsverzeichis. Ansonsten wird versucht, in eine Datei C:\.rnd zu schreiben. Da dort für einen Windows-Standardbenutzer keine Schreibrechte bestehen, erhalten Sie in diesem Fall die Fehlermeldung „unable to write random state“.
Die nachfolgend aufgeführten Aufrufoptionen gehen der Einfachheit halber immer davon aus, dass OpenSSL\bin als Arbeitsverzeichnis gewählt wurde. Ist dies nicht der Fall, müssen die verwendeten Dateiparameter mit entsprechenden Pfadangaben versehen werden.
In einem ersten Schritt muss die CA aufgesetzt werden. Hierzu muss zunächst für die CA selbst ein Schlüsselpaar erzeugt werden. Dazu verwendet man folgenden Befehl:
openssl genrsa -out ca.key 1024 |
Das Schlüsselpaar landet dabei in der Datei "ca.key" und ist - da wir entsprechende Kommandozeilenparameter weggelassen haben - unverschlüsselt! Sicherer ist es natürlich, wenn man das Schlüsselpaar verschlüsselt speichert. Sollen die zu erstellenden Zertifikate in einer professionellen Umgebung zum Einsatz kommen, ist dies eindeutig die empfohlene Variante. Dazu wird der obige Befehl abgeändert zu:
openssl genrsa -des3 -passout pass:xyz ca.key 1024 |
Mit dem Parameter „-des3“ wird das Schlüsselpaar verschlüsselt abgespeichert (DES im ede cbc Modus mit 168-Bit-Schlüssel). Mit „-passout pass:xyz“ übergibt man das Passwort „xyz“. Da man nun das Passwort im Klartext in der Befehlszeile sieht, ist der Parameter „-pass“ nur für den Einsatz in Batch-Dateien sinnvoll, bei denen das Passwort anderweitig gegen unbefugte Einsicht gesichert wird. Lässt man den Parameter „-pass“ weg, wird man zur Eingabe des Passwortes aufgefordert und das Passwort wird beim Tippen nicht angezeigt.
Jetzt muss aus dem Schlüssel die Zertifikatsanforderung zusammengestellt werden (Certificate Signing Request - CSR). Um nicht an die systemweit gültige, mit OpenSSL installierte Konfigurationsdatei openssl.cfg gebunden zu sein, verwenden wir hier und auch später eigene Konfigurationsdateien. Hier zunächst der relevante Ausschnitt der eigenen Konfigurationsdate für die Erstellung des CSR der CA. (Der Rest der Konfigurationsdatei wird aus openssl.cfg übernommen.)
|
ca.cfg: |
[ req ] default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert [ req_distinguished_name ] countryName = countryName_default = DE countryName_min = 2 countryName_max = 2 stateOrProvinceName = stateOrProvinceName_default = Rheinland-Pfalz localityName = localityName_default = Bad Duerkheim 0.organizationName = 0.organizationName_default = Berufsbildende Schule # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = organizationalUnitName_default = Schulleitung commonName = commonName_default = Berufsbildende Schule Bad Duerkheim Certificate Authority (CA) commonName_max = 64 emailAddress = emailAddress_default = hostmaster@bbs-duew.de emailAddress_max = 64 |
Mit folgendem Befehl wird nun der CSR erstellt:
openssl req -batch -config ca.cfg -new -key ca.key -passin pass:xyz -out ca.csr |
Falls man das erstellte Schlüsselpaar mit einem Passwort geschützt hat, kann man das Passwort mit dem Parameter „-passin“ übergeben. Lässt man den Parameter weg, wird das Passwort abgefragt, damit auf den Schlüssel zugegriffen werden kann. Wenn man den Parameter „-batch“ verwendet, werden die Daten, die man in der Konfigurationsdatei ca.cfg definiert hat. ohne Zwischenabfrage in den CSR eingetragen Lässt man „-batch“ weg, wird man zur Eingabe der CSR-Daten aufgefordert. (Hatte man die Konfigurationsdatei schon an seine Verhältnisse angepasst, braucht man alle Angaben nur noch bestätigen.)
Das endgültige Zertifikat der CA erhält den Namen ca.cer. Es enthält noch ein paar Erweiterungen, die wir in der Konfigurationsdatei Datei ca.ext festlegen.
|
ca.ext: |
extensions = x509v3 [ x509v3 ] basicConstraints = CA:true,pathlen:0 nsCertType = sslCA,emailCA,objCA nsCaPolicyUrl = "http://domain.de/ca/policy.htm" nsCaRevocationUrl = "http://domain.de/ca/revocation.crl" crlDistributionPoints = URI:http://domain.de/ca/revocation.crl nsComment = "Kommentartext in comment listbox von Netscape" |
Mit Hilfe des Parameters nsCaPolicyUrl kann man einen URL auf der eigenen Website angeben, unter welchem die Richtlinien der Zertifikatsvergabe für die angeschlossenen Anwender eingesehen werden können (siehe z.B. http://root.bbs-duew.de/ca/policy.htm).
Der Parameter nsCaRevocationUrl gibt die URL an, unter der man später die Certificate Revocation List (CRL), also die Liste mit zurückgezogenen und für ungültig erklärten Zertifikaten, veröffentlicht (dazu mehr in Punkt 6).
Mit dem Eintrag crlDistributionPoints wird ein alternatives Verfahren bereit gestellt, eine oder (durch Komma getrennt) mehrere CRLs anzugeben. Der zuerst gefundene Verteilungspunkt-Eintrag wird verwendet. (crlDistributionPoints=URI:http//www.ca.de/ca1.crl[, URI:http//www.ca.de/ca2.crl …])
Das eigentliche (selbstsignierte) CA-Zertifikat erzeugen wir nun mit:
openssl x509 -days 1095 -extfile ca.ext -signkey ca.key -passin pass:xyz -in ca.csr -req -out ca.cer |
Der Parameter „-days“ gibt die Gültigkeitsdauer des Zertifikats in Tagen an.
Zusammengefasst haben wir für die CA nun zwei wichtige Dateien: die ca.key, welche den privaten und öffentlichen Schlüssel enthält, und die ca.cer, worin der öffentliche Schlüssel der CA und ein paar weitere Angaben über die CA (aus ca.csr) abgelegt sind.
Genau diese Kombination ca.cer eines öffentlicher Schlüssel mit Informationen über den Schlüsselinhaber bezeichnet man als Zertifikat. Handelt es sich - wie in diesem Fall - um ein Zertifikat einer CA, so spricht man auch von Root-, Wurzel- oder Stammzertifikat.
Alle ausgestellten Zertifikate, auch das Stammzertifikat, müssen in die so genannte Zertifikat-Datenbank aufgenommen werden, doch dazu siehe Punkt 5.
Die Vorgehensweise zum Erstellen eines Server-Zertifikats ist nicht wesentlich anders. Man benötigt wieder ein Schlüsselpaar:
openssl genrsa -out server.key 1024 |
Idealerweise speichert man auch dieses Schlüsselpaar nur verschlüsselt ab, indem man - wie oben beim CA-Schlüsselpaar - noch den Parameter -des3 (und bei Bedarf auch –passout) ergänzt. Jedoch wird der private Schlüssel später vom Webserver verwendet, um Client-Verbindungen zu verschlüsseln. Das bedeutet aber, dass der Server das Passwort kennen muss, um an den Schlüssel zu gelangen. Üblicherweise wird dann bei jedem Start des Webservers dieses Passwort abgefragt. Diese Abfragen kann man wiederum nur verhindern, wenn man das Schlüsselpaar doch unverschlüsselt abspeichert - man entscheide selbst, welche Sicherheit man benötigt.
Im nächsten Schritt erstellen wir das Zertifikat, das von unserer oben erzeugten CA signiert ist. Um den CSR zu erstellen, verwenden wir wieder eine Konfigurations- und eine Erweiterungsdatei:
|
server.cfg: |
[ req ] default_bits = 1024 distinguished_name = req_distinguished_name string_mask = nombstr [req_distinguished_name ] countryName = countryName_default = DE countryName_min = 2 countryName_max = 2 stateOrProvinceName = stateOrProvinceName_default = Rheinland-Pfalz localityName = localityName_default = Bad Duerkheim 0.organizationName = 0.organizationName_default = Berufsbildende Schule # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = organizationalUnitName_default = Schulleitung commonName = commonName_default = Berufsbildende Schule Bad Duerkheim Certificate Authority (CA) commonName_max = 64 emailAddress = emailAddress_default = hostmaster@bbs-duew.de emailAddress_max = 64 |
|
server.ext |
extensions = x509v3 [ x509v3 ] nsCertType = server keyUsage = digitalSignature,nonRepudiation,keyEncipherment extendedKeyUsage = msSGC,nsSGC,serverAuth |
Um den CSR und danach das eigentliche Zertifikat zu erzeugen, verwendet man die zwei folgenden openssl-Kommandos.
openssl req –batch -config server.cfg -new -key server.key -out server.csr openssl x509 -days 730 -extfile server.ext -CA ca.cer -CAkey ca.key -set_serial 0001 -in server.csr -req -out server.cer |
Beim zweiten Befehl fällt der Parameter –set_serial auf: Jedes von der CA ausgestellte Zertifikate erhält eine Seriennummer. Normalerweise hat das erste von der CA ausgestellte Zertifikat (das Stammzertifikat der CA) die Nummer 0. Deshalb haben unter Punkt 3 den Parameter –set_serial weggelassen. Alle auf das Stammzertifikat folgenden Zertifkate werden jedoch fortlaufend nummeriert. Die Nummer muss unbedingt mir geradzahliger Stellenzahl angegeben werden (00, 0000, usw.), ansonsten erhalten Sie eine Fehlermeldung.
Das Server-Zertifikat ist nun fertig. Es muss nur noch in die Zertifikat-Datenbank eingefügt werden (siehe Punkt 5).
Ein Client-Zertifikat kann verwendet werden, um E-Mails zu signieren und zu verschlüsseln. Zur Erstellung ist wieder die bereits bekannte Reihenfolge Schlüssel, CSR, Zertifikat einzuhalten. Dazu werden wieder eine andere Konfigurations- und eine andere Erweiterungsdatei verwendet:
|
user.cfg |
[ req ] default_bits = 1024 distinguished_name = req_distinguished_name string_mask = nombstr [ req_distinguished_name ] countryName = countryName_default = DE countryName_min = 2 countryName_max = 2 stateOrProvinceName = stateOrProvinceName_default = Rheinland-Pfalz localityName = localityName_default = Bad Duerkheim 0.organizationName = 0.organizationName_default = Berufsbildende Schule # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = #organizationalUnitName_default = commonName = commonName_default = Vorname Zuname commonName_max = 64 emailAddress = emailAddress_default = v.zuname@bbs-duew.de emailAddress_max = 64 |
|
user.ext |
extensions = x509v3 [ x509v3 ] nsCertType = client,email,objsign keyUsage = digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment |
Die ersten drei der folgenden Befehle sind uns schon bekannt. Auch hier ist es wieder möglich, den erstellten privaten Schlüssel mit einem Passwort zu schützen. Es bietet sich an, die erstellten Dateien nach der E-Mail-Adresse des Benutzers zu benennen. (Für jeden Benutzer muss die Konfigurationsdatei user.cfg entsprechend angepasst werden.)
openssl genrsa -out v.zuname.key 1024 openssl req –batch -config user.cfg -new -key v.zuname.key -out v.zuname.csr openssl x509 -days 730 -extfile user.ext -CA ca.cer -CAkey ca.key -passin pass:xyz -set_serial 0002 -in v.zuname.csr -req -out v.zuname.cer openssl x509 -outform der -in v.zuname.cer -out v.zuname.der openssl pkcs12 -export -in v.zuname.crt -inkey v.zuname.key -out v.zuname.p12 -passout pass:zyx |
Der vierte Befehl konvertiert das Client-Zertifikat vom Format *.cer (auch *.pem genannt) in das Format *.der. Nur dieses Format kann in E-Mail-Programmen wie Thunderbird als Client-Zertifikat (unter „Personen“) importiert werden. Der letzte Befehl pkcs12 ist ebenfalls neu und erfordert ein neues Client-Passwort (zyx), entweder mit dem Parameter –passout in der Komandozeile oder, falls der Parameter fehlt, per Direkteingabe über die Tastatur. Mit diesem Befehl wird das Zertifikat zusammen mit dem privaten Schlüssel in eine Datei gepackt, welche von allen gängigen E-Mail-Programmen importiert werden kann. Da diese Datei den privaten Schlüssel enthält, muss sie unbedingt mit einem Client-Passwort verschlüsselt werden, das spezifische für den jeweiligen E-Mail-Benutzer ist. Dieses Passwort benötigt man dann auch, um die Datei "v.zuname.p12" im E-Mail-Programm zu importieren.
Über die von der CA ausgestellten Zertifikate wird eine Datenbank geführt, der man jedes neu erstellte Zertifikat hinzufügen muss. Die Zertifikat-Datenbank ist eine normale zeilenorientierte Textdatei mit dem Namen index.txt.
Sie enthält 6 Spalten, die durch Tabulatoren getrennt sind. Die erste Spalte enthält den Status des Eintrags, entweder "V" für valid, "E" für expired oder "R" für revoked. In der zweiten Spalte folgt das Ablaufdatum des Zertifikats, in der Form YYMMDDHHmmss und einem angehängtem "Z" (das "Z" steht für Zulu, also Greenwich Mean Time). Die nächste Spalte ist für gültige Zertifikate leer, bei zurückgerufenen Zertifikaten enthält sie das Rückrufdatum in der gleichen Syntax wie das vorangegangene Datum. Die vierte Spalte enthält die Seriennummer, die fünfte den Speicherplatz der Zertifikates, der zur Zeit immer mit "unknown" ausgefüllt wird. Die letzte Spalte enthält den "distinguished name" (DN) des Zertifikates in der Form
/C=DE/ST=Bundesland/L=Ort/O=Firma/CN=Vorname Zuname/Email=v.zuname@domain.de
|
Beispiel einer index.txt (die letzte Spalte ist gekürzt): |
V 040229094920Z 00 unknown /C=DE... V 030301094939Z 01 unknown /C=DE... R 030301094954Z 020101000000Z 02 unknown /C=DE... V 030301095026Z 03 unknown /C=DE... |
Sobald ein Zertifikat von der CA ausgestellt wurde, sollte ein entsprechender Eintrag in diese Datenbank eingefügt werden. Dabei beschreibt die erste Zeile (mit der Seriennummer 0000) das Stammzertifikat. Einen Neueintrag erstellt man von Hand oder mit den in DoMakeCer.zip beigelegten Batchdateien. Bei einer Erstellung von Hand kann man die benötigten Einträge Ablaufdatum, Seriennummer und DN folgendermaßen erhalten:
|
Ermitteln der Spaltenwerte von index.txt |
openssl x509 –in v.zuname.cer –noout –enddate openssl x509 –in v.zuname.cer –noout -serial openssl x509 –in v.zuname.cer –noout –subject |
Zu jeder CA gehört noch eine CRL. Diese Liste enthält Angaben über die Zertifikate, die für ungültig erklärt und damit zurückgezogen wurden. Auch hierfür wird wieder eine Konfigurationsdatei benötigt.
|
crl.cfg |
[ ca ] default_ca = CA_default # the default ca section [ CA_default ] dir = ./ # Where everything is kept database = $dir/index.txt # database index file. certificate = $dir/ca.cer # The CA certificate crl = $dir/revocation.crl # The current CRL private_key = $dir/ca.key # The private key # default_days = 365 # how long to certify for default_crl_days= 30 # how long before next CRL default_md = sha1 # which md to use. |
Die CRL wird nun erstellt mit:
openssl ca -config crl.cfg -gencrl -passin pass:xyz -out revocation.crl |
Die Angaben über ungültige Zertifikate entnimmt der Befehl natürlich der Zertifikat-Datenbank, daher muss die CRL immer dann neu erstellt werden, wenn sich Einträge in index.txt verändert haben.
Um ein Zertifikat zu widerrufen muss logischerweise der Eintrag in der Datenbank geändert werden, und anschließend die CRL neu erstellt werden. Das Ändern der Einträge erfolgt mit folgendem Befehl:
openssl ca -config crl.cfg -revoke name.crt |
Der Befehl aktualisiert die Datenbank selbst. Die neue CRL erstellt man dann wie oben beschrieben.
Zunächst müssen Sie das Stammzertifikat der CA installieren und diesen in Ihrem E-Mail-System vertrauen. In einem zweiten Schritt installieren Sie Ihr persönliches Zertifikat in Ihrem E-Mail-System. Danach können Sie eine erste nach dem S/MIME-Verfahren signierte und/oder verschlüsselte E-Mail versenden. Die einzelnen Schritte sind an den folgenden Stellen beschrieben.
(Beispiel-CA: Berufsbildende Schule Bad Dürkheim, Beispiel-E-Mail-Programm: Thunderbird)
· Installieren des Stammzertifikats der CA:
- mit Mozila Thunderbird - mit Microsoft Outlook
· Installieren des persönlichen Zertifikats:
- mit Mozila Thunderbird - mit Microsoft Outlook
· Senden einer ersten signierten und verschlüsselten E-Mail:
- mit Mozilla Thunderbird - mit Microsoft Outlook
Allgemeine Informationen zum Thema finden Sie hier:
· Beschreibung des S/MIME-Verfahrens für abgesicherte E-Mails.
Die oben beschriebenen Konfigurationsdateien sowie zwei Batch-Dateien DoCer.cmd und MakeCer.cmd zum automatisierten Erstellen von Zertifikaten finden Sie hier:
In MakeCer.cmd wird das Kommanodzeilen-Tool ssr.exe zum schnellen Ersetzen von Einträgen in den Konfigurationsdateien verwendet.
Beim Einsatz von WLANs für einen größeren Benutzerkreis reicht die simple Authentifizierung mit WPA nicht aus, da das zughörige Passwort nicht geheim gehalten werden kann. Man sichert große Drahtlos-Netze mit WPA Enterprise.
Hierbei lässt die W-LAN-Basisstationen Verbindungen nur zu, wenn sich
der Client mit korrektem Benutzernamen und Passwort über das Protokoll IEEE 802.1x bei einem Radius-Server angemeldet hat.
Zum Aufsetzen eines Radius-Servers kann man unter Linux Freeradius in Kombination mit OpenSSL verwenden. Unter Windows-Servern ab 2003 arbeitet der Dienst IAS (Internet Authentication Service) als Radius-Server. Zur sicheren Authentifizierung der Clients werden Zertifikate verwendet. Sowohl auf dem Radius-Server als auch auf dem Client muss ein Stammzertifikat installiert werden, von dem das Zertifikat des Radius-Servers signiert ist. Die benötigten Zertifikate kann man zwar auch mit Windows-Zertifizierungsdiensten erstellen, es bietet sich jedoch an, auch hierfür OpenSSL zu verwenden und das Radius-Server-Zertifikat vom bereits erstellen Stammzertifikat abzuleiten. Dieser Prozess wird nun beschrieben.
Ein Radius-Server-Zertifikat zur Authentifizierung mittels PEAP (Protected Extensible Authentication Protocol) wird grundsätzlich erstellt wie jedes andere Server-Zertifikat auch (siehe Kapitel 3. ) Es müssen jedoch einige Zusatzbedingungen eingehalten werden, um die Microsoft-Zertifikatskonventionen zu erfüllen:
openssl genrsa -out ias.key 1024 |
Danach erstellen wir das Server-Zertifikat, das von unserer CA signiert ist. Zur Erstellung des CSR verwenden wir wieder eine Konfigurations- und eine Erweiterungsdatei:
|
ias.cfg: |
[ req ] default_bits = 1024 distinguished_name = req_distinguished_name string_mask = nombstr [req_distinguished_name ] countryName = countryName_default = DE countryName_min = 2 countryName_max = 2 stateOrProvinceName = stateOrProvinceName_default = Rheinland-Pfalz localityName = localityName_default = Bad Duerkheim 0.organizationName = 0.organizationName_default = Berufsbildende Schule # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = organizationalUnitName_default = Schulleitung commonName = commonName_default = ias-server.bbs-duew.localcommonName_max = 64 emailAddress = emailAddress_default = hostmaster@bbs-duew.de emailAddress_max = 64 |
|
ias.ext |
extensions = x509v3 |
Um den CSR und danach das eigentliche Zertifikat zu erzeugen, verwendet man die zwei folgenden openssl-Kommandos.
openssl req –batch -config ias.cfg -new -key ias.key -out ias.csr -set_serial 0001 -in isa.csr -req -out isa.cer |
Der
letzte Befehl pkcs12
erfordert ein Passwort (zyx) für das Server-Zertifikat und speichert
das Server-Zertifikat zusammen mit seinem privaten Schlüssel in einer
p12-Datei, die auf dem IAS-Server im Speicher "Eigene Zertifikate"
hinterlegt werden muss. Hierzu muss man das entsprechende Passwort
eingeben. Die Programmargumente -name, -CSP und -LMK sorgen für die oben erwähnten Microsoft-spezifischen Attribute im Zertifikat.
Im Windows-Server müssen nun zwei Zertifikate gespeichert werden: Das Stammerztifikat ca.cer ist in den Speicher "Vertrauenswürdige Stammzertifizierungsstellen" zu importieren und das IAS-Server-Zertifikat ias.p12 in den Speicher "Eigene Zertifikate". Hierbei ist unbedingt darauf zu achten, dass in den Zertifikatsspeicher des lokalen Computerkontos
importiert wird und nicht etwa in den Speicher des aktuellen
Benutzerkontos oder den Zertifikatsspeicher für Dienste. Nur wenn
dieser Speicherort eingehalten wird, kann eine
Radius-Serverauthentifizierung stattfinden.
Zum Importieren der Zertifikate in den jeweiligen Speicher für das lokale Computerkonto gehen Sie folgendermaßen vor: