Tags:
create new tag
, view all tags

Gesicherte Datenverbindungen über SSL

Ursprüngliches Dokument: https://protos.ethz.ch/informatikdienste/services/list/ssl/index

Serverzertifikate

Gesicherte Datenverbindungen über SSL

Die ETH Zürich nimmt an dem Projekt der Schweizer Hoch- und Fachhochschulen teil, welches die Herausgabe von Zertifikaten für die Verschlüsselung der Datenkommunikation im Internet bei Webservern ermöglicht. (vgl. SWITCHpki).

Es sind im Augenblick drei verschiedene Zertifikats-Familien im Umlauf. Alle beziehen sich grundsätzlich auf Rechner, die in den Domains ethz.ch, cscs.ch und systemsx.ch stehen. Die Eidgenössiche Technische Hochschule Zürich trägt immer die Bezeichnung ETH Zuerich

Die eine Zertifikats-Familie ist von der Firma GlobalSign mit GTE Cyber Trust Global Root abgezeichnet. Diese Zertifikate sind gültig, wir stellen aber keine neuen mehr aus.

Die andere Zertifikats-Familie ist von der Firma QuoVadis mit QuoVadis Limited abgezeichnet und diese Zertifkate werden wir in Zukunft ausstellen.

Beide Formen sind vom SWITCHpki-Projekt unterstützt. Die ETH Zürich und SWITCH tragen gemeinsam die Verantwortung dafür, dass im Internet keine Zertifikate auftauchen, die auf diese Namen lauten, aber nicht von uns ausgestellt bzw. autorisiert wurden. Für die Benutzung der https-Verbindung haben die Endbenutzer an Ihren Browsern keinerlei Anpassungen durch zuführen. Jedoch ist es für den Antragsteller wichtig, dass er beim Antrag den Server-Typ (IIS, Apache, ...) mitteilt.

Ausserdem werden für Server, die unsere Studenten und Mitarbeiter ansprechen, Zertifikate von CAcert.org ausgestell. Hier müssen die Endbenutzer das Root-Zertifikat selbst importieren. Siehe den Abschnitt CAcert in der linken Navigation.

Ausserdem gibt es Hinweise, welche verwaltungstechnischen Dinge zu beachten sind und welche Schritte der Administrator in die Wege leiten muss, wenn ein Rechner (Server) ein solches Zertifikat braucht.

Und als Letztes gibt es technische Hinweise, wie man zu solch einer Zertifikats-Anforderung kommt. Wie man ein Zertifikat beantragt, ist in allen Fällen gleich. Wir bitten darum, dass für einen Probezeit die CAcert-Zertifikate nur von Mitarbeiten der Informatikdienste beantragt werden.

Für End-User-Zertifikate, die ebenfalls in einem Pilot-Verfahren für einen kleinen Personenkreis ausgestellt werden, gelten andere Bestimmungen. Bitte fragen Sie bei den Verantwortlichen der RA der ETH Zürich an.

Antrag

Antragstellung für ein Serverzertifikat

Für die Beglaubigung der Zertifikats-Anträge sind bei den Informatikdienste für die gesamte ETH Zürich verantwortlich:

Mark Buschor und Joel Greuter
Service-Desk
Stampfenbachstrasse 69
ETH Zentrum, STB G 20.2
8092 Zürich

und

Willi Furter
Service-Desk
Stampfenbachstrasse 69
ETH Zentrum, STB G 17
8092 Zürich
ethz.ra@id.ethz.ch

Diese RA (Registration Authority) ist für alle Mitarbeiter der ETH Zürich verbindlich. Anträge von Mitarbeitern anderer Hochschulen, die am SWITCHpki-Projekt teilnehmen, werden nicht beglaubigt. Die ausgeteilten Zertifikate gelten bis zu zwei Jahre und müssen rechtzeitg erneuert werden.

Bedingungen, die für einen Antragstellung erfüllt sein müssen

  • Der Administrator des Servers muss Mitarbeiter der ETH Zürich sein. Er muss sich mit einem Lichtbildausweis identifizieren und Kopien des Ausweises und seine Unterschrift im Original sind notwendig und müssen bei den Verantwortlichen (s.o.) hinterlegt werden.
  • Der Rechner muss im Domain Name Service der ETH Zürich eingetragen sein, wenn ein Alias (Alternate Name) benutzt wird, gilt dasselbe. Beide Typen von Namen müssen auf .ethz.ch enden.
  • Die E-Mail-Adresse, die im Zertifikate gewünscht wird, muss eine offizielle Adresse innerhalb der Domain ethz.ch sein.

Ausserdem werden von uns noch die Domainen systemsx.ch und cscs.ch bedient, die Kollegen vom CSCS wenden sich bitte an

Marco Consoli
CSCS
MAN E 110
Via Cantonale
6928 Manno

für systemsx.ch ist die RA im Helpdesk der ID zuständig. Die Regeln sind analog zu sehen.

Falls es zwingende Gründe gibt, die es nicht erlauben, die obigen Regeln zu erfüllen, bitten wir um eine vorherige Rücksprache.

Aus sicherheitstechnischen Gründen werden nur Anträge mit einem signierten Zertifikats-Antrag (Certificate Signing Request (CSR)) angenommen, selbst wenn SWITCH andere Verfahren anbietet. Diese Requests für Zertifikate, die das SWITCH-Projekt zu unseren Web-Domains ausstellt, sind zwingend an die oben genannte Adresse zu senden. Anträge, die andere Wege nehmen, werden von der RA aktiv abgeleht.

Nach einer Vorabprüfung werden sich ein Verantwortlicher der RA beim Antragsteller melden und einen Termin vereinbaren. Unter der Rubrik technische Hinweise wird erklärt, wie man so einen Request of Certificate in der Form eines sog. signierten Zertifikat-Antrags (Certificate Signing Request (CSR)) erstellen kann.

Für das Betriebssystem Windows gehört das dafür gut geeignete Programm Openssl nicht zum Lieferumfang, die anderen populären Betriebssysteme sind damit meist schon gesegnet. Wir bitten darum, die vorbereitete Beschreibungsdatei für Openssl zu benutzen, weil so die meisten Angabe-Fehler vermieden werden.

Für die Zertifikate tragen die Informatikdienste die Kosten.

Technische Hinweise

Die verschlüsselten Verbindungen, die ja angestrebt werden, beruhen beim Aufbau der Verbindung auf einer Verschlüsselung mit asymmetrischen Schlüsseln.

Ein Zertifikat kann beantragt werden, nachdem für einen Rechner das Schlüsselpaar (privater und öffentlicher Schlüssel) erzeugt wurde und ein Request of Certificate (CSR) erstellt wurde. Der private Schlüssel ist keines Falls weiter zu geben und sicher auf zu bewahren. Dies liegt in der Verantwortung des Rechner-Administrators. Und das bestätigt er inhaltlich mit seinem Antrag und seiner Unterschrift. Bitte geben Sie auch den html-Servertype (Apache, IIS, ...) an.

Der Request of Certificate enthält den öffentlichen Schlüssel, der dann im eigentlichen Zertifikate (nach dem X509-Standard) beglaubigt wird. Weitere Daten sind die Landeskennung (C=CH), die Organisation (O=ETH Zuerich) und die E-Mail-Adresse (muss auf ethz.ch enden), mit der der Administrator erreicht werden kann.

Alle anderen Felder sollten leer bleiben. Falls etwas voreingestellt ist (in der Datei openssl.cnf), man aber ein leeres Feld haben möchte, muss man einen Punkt eingeben, um zu einem leeren Feld zu kommen. Insbesondere wird entsprechend den Projekt-Bestimmungen nicht das Feld OU (Organizational Unit) ausgefüllt, dies hat bei neuen Browser, dass der Betreiber der Webseite als unbekannt deklariert wird.

Die Verantwortlichen der Informatikdienste erzeugen diesen Request of Certificate nicht, sondern prüfen und bestätigen ihn nur. Der Grund liegt einfach darin, dass man für die Erzeugung des CSR den privaten Schüssel braucht, und dieser verbleibt ja grundsätzlich beim Antragsteller, ist nicht per E-Mail zu verschicken, ...

Deswegen teilt sich das folgende in drei Teile.

  1. Das Erzeugen des Schlüsselpaares für den Server-Rechner.
  2. Das Erzeugen des Requests of Certificate.
  3. Das Prüfen dieses Requests.

Kurzfassung für Eilige

Es wird angenommen, dass man sich die openssl.cnf geholt hat, die hier angeboten wird. Dann benötigt man folgende zwei Kommando-Zeilen-Befehle, um zu einem CSR zu kommen:

(Der Server soll im ssl-Request mit ultra1.ethz.ch angesprochen werden, das muss also durch den Zielname, beispielsweise www.id.ethz.ch ersetzt werden. Im einfachen Fall ist das der DNS-Name, jedoch kein DNS-Alias, des Servers.)

openssl genrsa -des3 -out ultra1_key.key 2048

openssl req -new -key ultra1_key.key -out ultra1.ethz.ch.pem

Der Aufruf

openssl req -text -in ultra1.ethz.ch.pem

öffnet den Antrag und zeigt, was eingetragen ist.

Für kompliziertere Fälle, insbesondere Multi-Name-Zertifikate, melde man sich bitte bei den Verantwortlichen. Man bekommt dann dafür eine besonders präparierte openssl-Konfigurationsdatei.

Auf dieser Seite weiterlesen sollte wirklich nur jemand, der so ein Zertifikat beantragen muss.

Hinweise, die wichtig und im Augenblick einschränkend sind

  • Bitte benutzen Sie nur die unten angegebene Attribut-Felder (also Country Name, Organization Name, Common Name und Email Adress) und lassen die anderen Attribut-Felder leer. Die unten bereitgestellte Konfigurations-Datei für openssl berücksichtigt dies bereits.
  • Für jeden Zertifikats-Antrag (CSR) braucht es ein neues, bisher nicht benutztes Schlüsselpaar. Dies gilt auch für Verlängerungs-Anträge

1. Das Erzeugen des Schlüsselpaares für die Maschine.

Als allererstes sei die Version der Software, für welche die nachfolgenden Ausführungen gelten, angegeben:

openssl version

OpenSSL 0.9.8e 23 Feb 2007

Diese Software kann man über eine Datei openssl.cnf steuern. Hier ist einen Version angezeigt, die schon möglichst viele Dinge enthält, um nachher wenige Eingaben abzufragen. Diese Datei findet man bei der Distribution (für Microsoft Windows siehe unten) im Verzeichnis C:\Programme\Openssl\bin (Deutsche Standard-Installation) und unter Mac OS X im Verzeichnis /System/Library/openSSL.

Eine Distribution für Windows findet man über die Homepage von openssl.org und zwar hier unter den Stichwort Related.

Soweit diese angepasste Datei openssl.cnf. Nun geht es mit der Erzeugung eines Schlüsselpaares für den Rechner als eigentlich ersten von den drei Schritten los. Noch eine kurze Bemerkung zur Schlüssel-Länge, meist wurden früher 1024-bit-Schlüssel benutzt, mit den Hinweis auf einen günstigen Kompromiss zwischen Sicherheit und Performance. Ob dies wirklich noch so ist, sei dahingestellt. Wer sich aber normal verhalten will, nehme den Standard 2048 als Schlüssel-Länge. Wir stellen aber in begründeten Fällen Zertifikate für Schüssel mit der Länge 1024 auch aus, kürzere Schlüssellängen werden nicht akzeptiert.

Zuerst kommt ein Befehls-Sequenz, die diesen privaten Schlüssel erzeugt (Die fetten Zeichen betreffen das, was man eingeben muss.):

>openssl genrsa -des3 -out ultra1_key.key 2048

Loading 'screen' into random state - done
Generating RSA private key, 2048 bit long modulus
...+
..................+
e is 65537 (0x10001)
Enter pass phrase for ultra1_key.key:
Verifying - Enter pass phrase for ultra1_key.key:

Danach ist die Datei ultra1_key.key entstanden, sie sieht wie folgt aus:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,8DD7E1869ADD831F
0v83bd8+cQUJ47NYWy3Bu6voICaBXxpwLVUMRGrlpiYh6zdi7RQ+3Z4aVgVHfrAQ
svYlvInjLgAwrfQO3VUc2xWT8pmDpHRYrNB9/CIxO3jHSaP1YB2TivK4trSlkhGv
laTAfr5ElxDJY78FM/Xg7FaV5QU2b20kB8FRDbBDRBBYCPQWx/INsL1CmdZ4AriN
1iOMZYJS2HL7jzVv5wpC1i3npa05RbLBCl6ju3ObuLBXZYiMW0sOK9GCv2oFLvDG
yxEOdJEtFXhBm5nEPJzXPJSaOs+NPj5sr8KTUWrhN1yHBAkU+ZkSyo4yG4p3+m8z
6vwrwIWcNtXV86ckahtsA0sm02q932wnHmCwTB1L1du7swfYkvfm/auHirheMuV1
ei8Q1xLyEppYjMtp7RyKAh6Yu4oG278t0Peyc1PavhxjdOEp9eCFuFjyOhAYVQwn
ryhKXIseSKRVZ5Zd00siDnbNfJ0PCpXiunusbXDI578FpX2yk1RwUS4iGAGQpPmQ
uAjbCaJOO5FAMHqNxphasreEFljOuf/yTGPM545caQPu3D3+GAc9NrQsbHH6K9fI
mRcsZb13tDdKkRe4/DYgekfHb1sDXk1ms5I6khu/woj85CyvMSyImhe4Fa2Th4MH
u7OwVhtKXQtAPPqVRfhaL2e01UVimncnJsTDEPC/NPOHQLa3UHR/1hO89dLgFOxR
PdujIXqUWrZ/J8veV0mG/5L0nol8tfclrKkuyYVT3q6750f6S+WXtDZpeDg09Kun
VZD8helM51Jflrzy6Ay1qCA/bEwP854IZmX+UtPrJOYGEsdBdZt9Xi4OZr5m4q5r
YvzoM3U51tquWkvrmXEu1DqHxK/ZXQ2ZmDLnaDS9P4ZON0s+9MOZo628wFtvHEFW
Q4imSWDIHUAh0EluFic2qeGEyeihCeRAaxd/N76s6nErFSF1wb3CReOJ/89VQY4X
31YjpnsOU79KopiSNtwcU6zhFaJCjZ4mLEKNJzXjyR6bUMI8jbzFICUGGm3tprAH
p3upYWIGx/brvdv+6y/zoG2bwAjam2g28aHBQghiehe4snUaX8ovWVbLiRqdDGA4
0j4V9PhtNrg8uHU70g2hN6HrcaKqiazleXGXOh2AJxOCLu3GP4zk4dcM9atz+Pk+
1DJQBRSbUdh5PB3ImgST5biq/heUh0uTBksolk2sivoxruVyYMxGI5hx9hLPDtTI
1n33qJT1S0cm7duq1X5GxxZuy1Gtr4tXNs297SlpoLoxHRjc151uT1aPgSa1kGQX
69b2J6AQLzED2lz80wo1460uBAkESICDZV/eeAt7YKdrtATu6X1hnacMM4F5Ld5A
YKa2IEqD3GcY6P+mm2AwMXUqFaYegfijyzzHxrmkX1M3qjFoUM0XyLQlYJEvImAp
E2gSeqOR0NVMIsC8ZOI3iZdyT74Mok2n7a/M86TK32OSE+v1UEIXld1nc06xWLqQ
USNdBtNyVaCBIjFX145zpPdSsUpc9Sym7i1JqcgAe9CbXQB6DT/ApY1AxyJOiDZs
vo/nI7YfqQbYhhwfpx8kN4+918gNofGh4KRmdwZKhRqSHqH7vTnLCO26MlfO66H5
-----END RSA PRIVATE KEY-----

Die Passphrase ist mit triple DES verschlüsselt und der Schlüssel selbst ist mit einem RSA-Verfahren und einer Schlüssellänge von 2048 Bit erzeugt worden.

Zu der Frage, ob der Schüssel mit einer Passphrase geschützt sein soll oder nicht, gibt es umfangreiche Diskussionen. Wenn er es nicht ist, dann kann man den Web-Server starten, ohne diese Passphrase eingeben zu müssen (was manchmal recht praktisch ist), dabei man muss sich dann vollständig auf die Schutzmechanismen des Betriebssystems verlassen. Mit der angegeben Konfigurations-Datei wird aber eine Passphrase von mindestens 4 Zeichen Länge erzwungen.

2. Das Erzeugen des Requests of Certificate

Als nächstes wird der Request of Certifikate erzeugt, dies sieht dann so aus:

>openssl req -new -key ultra1_key.key -out ultra1.ethz.ch.pem

Enter pass phrase for ultra1_key.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (do not change, give only <enter>) [CH]:
Organization Name (do not change, give only <enter>) [ETH Zuerich]:
Common Name (example ultra1.ethz.ch) []:ultra1.ethz.ch
Email Address(example charliebrown@id.ethz.ch) []:charliebrown@id.ethz.ch

Bis auf charliebrown@id.ethz.ch ist alles der Realität entnommen. Ein Rechner mit dem DNS-Eintrag ultra1.ethz.ch existiert und auch die anderen Einträge sind eigentlich richtig. Das, was man eingeben musste, ist wieder fett geschrieben. Jetzt hat sich natürlich die Änderung an der Konfigurations-Datei bewährt und man musste recht wenig eingeben.

3. Das Prüfen dieses Requests.

Anschliessend kann man den Request of Certificate selbst prüfen, um zu wissen, was man da eigentlich abgibt. Man erhält folgendes:

> openssl req -text -in ultra1.ethz.ch.pem

Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CH, O=ETH Zuerich, CN=ultra1.ethz.ch/emailAddress=charliebrown@id.ethz.ch
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:dc:3f:4d:2e:eb:ac:de:33:44:25:c1:65:9d:ca:
4a:78:a3:74:3c:e0:bf:90:eb:d7:26:d3:84:64:95:
3a:41:e9:d1:9c:a0:96:67:b5:0c:62:8b:5f:17:7e:
00:61:4c:49:aa:02:0d:c9:41:9a:e1:8c:d9:df:7f:
59:a7:56:5d:da:66:c0:a7:44:f4:13:18:6c:63:f9:
17:70:f7:f9:6f:5f:61:c1:11:e4:c8:e8:3a:51:b2:
72:9d:f4:9c:01:67:2e:0d:50:04:5f:83:1b:3b:45:
44:95:8d:d6:e0:c0:e9:a7:82:22:60:9e:16:c9:40:
ff:ce:30:6b:f0:f6:80:36:a9:4a:bf:0c:c6:75:64:
7c:de:9e:87:7d:62:b0:58:19:4d:35:eb:c5:27:f1:
05:5d:1b:49:e4:b0:53:9d:4d:00:2e:f4:09:a6:c8:
ab:71:5b:18:00:74:7d:e1:54:80:91:e2:f4:52:d0:
9e:e6:8c:ee:1f:ec:a3:94:cd:fe:21:46:98:6d:89:
bf:8f:6c:94:ff:82:55:e2:9f:60:e8:bf:a8:a7:f2:
52:ad:b9:e0:70:d5:b4:14:fe:b2:99:38:3d:b2:87:
bd:0f:35:58:5f:e3:6f:90:d4:3e:53:36:36:35:48:
6d:00:40:9a:ff:ff:d7:3e:d3:02:9e:9b:2e:d7:73:
18:8f
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha1WithRSAEncryption
b9:b3:e5:5a:a2:0e:ee:68:a9:74:84:91:09:2b:a8:65:ed:e7:
b4:cd:ed:4e:32:f8:d0:7f:44:ee:95:f8:83:f3:c7:13:b6:dc:
27:b9:fa:7c:9a:77:5f:d7:93:e1:b3:ba:ea:1f:13:59:83:11:
88:ba:6c:8c:81:f1:29:dd:6b:2f:aa:f8:90:68:82:f9:d5:cb:
85:b4:a9:25:a3:59:92:22:ca:d6:2e:49:eb:e7:30:4b:84:74:
1f:11:8f:94:1b:2f:a8:36:c5:ef:9f:1c:64:2c:67:ed:f7:ad:
42:88:95:19:07:15:74:34:cb:94:cf:67:e5:b2:db:88:10:f5:
8f:d2:19:7e:fb:f1:aa:21:50:de:a6:4f:83:5a:f7:6d:c4:67:
e3:d5:9d:21:af:2e:90:33:f0:3d:f1:05:33:f1:b1:cc:15:f7:
e5:ec:17:6d:ce:a1:32:e7:4b:14:10:ff:4a:1a:40:c5:5d:4f:
e0:6f:c4:7c:c8:bf:ab:48:44:55:64:05:6e:d0:fb:ad:ce:3c:
76:12:cf:45:95:e6:52:df:ef:11:9c:22:4f:d3:bc:37:b2:5f:
80:4d:ea:61:ba:cb:ba:2d:57:8b:93:21:4d:2d:f7:f5:e6:0c:
ce:29:d3:dd:ad:ce:4c:8b:fd:8d:1b:a6:7f:54:d2:a7:e6:16:
7a:cc:d7:f9
-----BEGIN CERTIFICATE REQUEST-----
MIICqTCCAZECAQAwZDELMAkGA1UEBhMCQ0gxFDASBgNVBAoTC0VUSCBadWVyaWNo
MRcwFQYDVQQDEw51bHRyYTEuZXRoei5jaDEmMCQGCSqGSIb3DQEJARYXY2hhcmxp
ZWJyb3duQGlkLmV0aHouY2gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDcP00u66zeM0QlwWWdykp4o3Q84L+Q69cm04RklTpB6dGcoJZntQxii18XfgBh
TEmqAg3JQZrhjNnff1mnVl3aZsCnRPQTGGxj+Rdw9/lvX2HBEeTI6DpRsnKd9JwB
Zy4NUARfgxs7RUSVjdbgwOmngiJgnhbJQP/OMGvw9oA2qUq/DMZ1ZHzenod9YrBY
GU0168Un8QVdG0nksFOdTQAu9AmmyKtxWxgAdH3hVICR4vRS0J7mjO4f7KOUzf4h
Rphtib+PbJT/glXin2Dov6in8lKtueBw1bQU/rKZOD2yh70PNVhf42+Q1D5TNjY1
SG0AQJr//9c+0wKemy7XcxiPAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAubPl
WqIO7mipdISRCSuoZe3ntM3tTjL40H9E7pX4g/PHE7bcJ7n6fJp3X9eT4bO66h8T
WYMRiLpsjIHxKd1rL6r4kGiC+dXLhbSpJaNZkiLK1i5J6+cwS4R0HxGPlBsvqDbF
758cZCxn7fetQoiVGQcVdDTLlM9n5bLbiBD1j9IZfvvxqiFQ3qZPg1r3bcRn49Wd
Ia8ukDPwPfEFM/GxzBX35ewXbc6hMudLFBD/ShpAxV1P4G/EfMi/q0hEVWQFbtD7
rc48dhLPRZXmUt/vEZwiT9O8N7JfgE3qYbrLui1Xi5MhTS339eYMzinT3a3OTIv9
jRumf1TSp+YWeszX+Q==
-----END CERTIFICATE REQUEST-----

Wobei das, was inclusive letzter Anfangszeile und der letzten Endzeile steht, noch einmal den Request wiederholt. Man sieht, dass solch eine Anforderung für eine Zertifikate auch auf einem anderen Rechner ausgeführt werden kann, jenachdem, wo openssl installiert ist.

Die Datei im PEM-Format (also in meinem Beispiel ultra1.ethz.ch.pem) ist dann der gewünschte Certificate Signing Request, der dann bei den Verantwortlichen der ETHZ einzureichen ist.

Multi-Name-Zertifikate

Für html-Server, die Virtual Hosting bieten ( siehe Artikel zu Virtual Hosting), sind Multi-Name-Zertifikate notwendig, die grundlegende Dokumentation für so einen Antrag findet man bei SWITCH. Für uns ist dabei relevant, das wir eine funktionale Mailadresse noch zusätzlich in der Liste der alternativen Namen haben möchten, ein Beisipiel würde dann so aussehen:

ALTNAMES = DNS:$FQDN,DNS:bar.example.org,email:webmaster@example.org

Die dort angeführte Befehlszeile

openssl req -new -config myserver.cnf -keyout myserver.key -out myserver.csr

ist raffiniert, denn man erledigt in einem Gang die Schlüsselerzeugung und das Herstellen des CSR.

Installation der Zertifikate auf den Servern

Für den html-Server Apache und den Microsoft-IEE-Server 6.0 sind die Verfahren recht unterschiedlich, wie man das Zertifikat (im Prinzip ja ein unterschriebener öffentlicher Kryptographie-Schlüssel) installieren muss.

Hautsächlich geht es dabei um folgendes: Bei dem Zertifikat wird das Vertrauen dadurch hergestellt, dass es durch einen vertauenswürdige Instanz abgezeichnet wird. Diese Signatur (Unterschrift) kann mit dem öffentliche Schlüssel dieser Instanz geprüft werden und muss sich beim Leser im Browser befinden.

Jedoch wird mit diesem Schlüssel (also genauer mit seinem privaten Gegenstück) meist gar nicht direkt abgezeichnet, sondern die vertrauenswürdige Instanz erzeugt eine ganze Kette von solchen Schlüsselpaaren (praktisch um das Hauptschlüsselpaar zu schützen).

Diese Kette nennt man die Kette des Vertrauens (chain of certificates), und diese ist naturgemäss nun nicht im Browser. Deswegen muss der html-Server diese Schlüssel mitliefern (also die Zwischenglieder) und diese muss der Serverbetreiber neben seinem Zertifikat in den Server importieren.

Das für uns wichtige Zwischenzertifikat für QuoVadis ist das QuoVadis Global SSL ICA-Zertifikat, man findet es hier.

Früher benutzten wir GlobalSign, die folgenden Angaben sind historisch:

Die Zwischen-Zertifikate von GlobalSign waren:

Cybertrust Educational CA

während die Root-Zertifikate, die nicht importiert werden müssen, hier zu finden sind:

GTE CyberTrust Global Root

aber der Vollständigkeit halber angegeben sind.

Die folgenden Seiten versuchen auf die Besonderheiten der html-Server einzugehen.

Import der SWITCHpki-Zertifikate in den Apache-Server

Wie beim II-Server muss man auch beim Apache-Server die Vertrauenskette der Zertifikate im Server richtig angeben. Das eigentliche Zertifikate sollte im PEM-Format heruntergeladen werden.

Weitere Hinweise, wie man die verschiedenen Teile der übergeordneten Zertifikate anordnet, gibt es auf der Seite vom SWITCHaai-Projekt.

Wenn man den Apache-ssl von Debian benutzt, dann sind beispielsweise folgende Zeilen in /etc/apache-ssl/httpd.conf hilfreich:

SSLCertificateFile /etc/apache-ssl/cert_lerche.pem
SSLCertificateKeyFile /etc/apache-ssl/lerche_ohne.key
SSLCACertificateFile /etc/apache-ssl/intermediate.pem

Die erste Zeile gibt den Pfad zum Zertifikat an, die zweite zum privaten Schlüssel ohne Passwortschutz und die dritte den Pfad zum benötigten Zertifikat für die Vertaruenskette.

Die Passwort-Phrase sollte man von dem privaten Schlüssel entfernen, sonst startet der html-Server nicht. Dies kann wieder mit einem Aufruf des Openssl-Programms geschehen:

openssl rsa -in lerche_mit.key -out lerche_ohne.key

wobei lerche_mit.key der private Schlüssel (in diesem Fall vom Server lerche) mit Passwort-Phrase ist.

Hinweis: Unter Umständen sind die Dateien DOS-Format gespeichert, also mit Carriage Return und Line Feed pro Zeilenwechsel. Das Steuerzeichen für Carriage Return muss also entfernt werden.

Import der SWITCHpki-Zertifikate in den IIS 6.0-Server

Für den Microsoft html-Server IIS ist es bei dem vorher beschriebenen Weg der Erstellung des geheimen Schlüssels und der Zertifikats-Anforderung mit Hilfe von openssl nicht ohne Weiteres möglich, dass dann erhaltene Zertifikat in den Sicherheitsbereich des Microsoft-Server-Betriebssystem zu importieren.

Dazu sind noch einige weitere Schritte notwendig. All diese Schritte müssen nicht auf dem Server (können aber) ausgeführt werden. Nur der letzte Schritt, der Import der dann endgültigen Zertifikate in den Server-Sicherheitsbereich ist natürlich auf dem eigentlichen Server-Rechner notwendig.

Nach der erfolgreichen Prüfung des Antrags auf ein Zertifikat bekommt man einen temporären Link zugeschickt, wo man das Zertifikat sich herunterladen kann. Man kann dann die Formate PEM bzw. DER auswählen (siehe unten).

Das folgende wurde für das PEM-Format ausprobiert, den Hinweis in der Email für IIS konnten wir bisher nicht bestätigen: Hier ein Auszug aus dem Text:

Please find the signed certificate in attachment.
Your certificate is also available in different formats to be downloaded at:
http://secure.globalsign.net/phoenixng/services.cfm?id=5909844908&cert=123456789&reset=yes
Microsoft IIS users can install the attached file by renaming it with a .crt
extension. You then follow the IIS Import wizard to install the certificate.

Nehmen wir folgendes an:

Das Zertifikat liegt als so genannte PKCS7-Message vor. (Die Begriffe, die hier verwendet werden, gehen zurück auf die grundlegenden Erklärungen der RSA Laboratories.) Diese Datei heisse mycert.p7c. Der Standard bei SWITCHpki für das Auslieferformat ist das so genannte DER-Format (PKCS7-Mitteilungen können in zwei Formaten abgelegt werden, die ineinander umwandelbar sind. Das eine ist das PEM-Format, das anderer das DER-Format.)

PEM bezeichnet die Abkürzung für Privacy Enhanced Mail und DER die für Distinguished Encoding Rules, diese beiden Auslieferungsformate kann man mit Hilfe des OpenSSL-Programms ineinander umwandeln.

Nehmen wir weiter an, wir haben das Zertifikat im PEM-Format herunter geladen (also im Gegensatz zu dem Sinn des Email-Textes) und in der Datei mycert.pem abgelegt.

Dann sind im wesentlichen noch zwei Schritte notwendig:

Der erste Schritt ist das Erzeugen der PKCS12-Datei, die dann unmittelbar importiert werden kann. Dazu ist der geheime Schlüssel (hier: my_key.key) und sein Passwort erforderlich. Die resultierende PKCS12-Datei wird ebenfalls mit einem Export/Import-Passwort versehen, ich habe der Bequemlichkeit halber dasselbe genommen. Der Befehl lautet:

openssl pkcs12 -export -inkey my_key.key -in mycert.pem -out mycert.p12

Dann wird man nach dem Passwort für den geheimen Schlüssel gefragt und muss dieses Export/Import-Passwort festlegen. In dieser Form ist jetzt das Passwort, der private Schlüssel und der öffentliche Schlüssel (signiert und so ein Zertifikat) in einer Datei vereinigt. Auf diese Datei ist ähnlich gut aufzupassen wie auf den privaten Schlüssel.

Das resultierende Zertifikat in der PKCS12-Darstellung mycert.p12 kann jetzt als abschliessender (zweiter) Schritt unmittelbar importiert werden. Diese Datei enthält jetzt sowohl den privaten Schlüssel als auch das beglaubigte Zertifikat mit dem öffentlichen Schlüssel. Diese Datei ist jetzt zum Server zu transportieren und zu importieren.

Es sind also das Zertifikat in den Bereich Personal zu importieren sowie noch die Zwischenzertifikate (siehe oben) in den Bereich: Intermediate Certification Authorities.

Wenn alles gut gelaufen ist, sieht man folgendes Bild, wenn man das Zertifikat im Internet Explorer prüft:

Die Kette des Vertrauens

Dies ist in der sogenannten Microsoft Wissensdatenbank im Artikel 816794 beschrieben, der hier angedeutete Weg ist der dort als dritte Möglichkeit erwähnt. Für den IIS 5.0 (auf dem Windows 2000 Server ausgeliefert) gibt es eine ähnliche Beschreibung mit der Nummer (310178) und die ist dort auch ins Deutsche übersetzt.

Zertifikats-Erneuerung

Für eine Erneuerung des Zertifikates geht man bitte wie bei dem Neuantrag vor, die nochmalige Kontrolle der Identität ist in diesen Fällen nur in Ausnahmefällen oder bei Wechsel des Verantwortlichen notwendig. Da die dann alten Zertifikate zurückgezogen werden, bitten wir darum, die anzugeben, welche durch den Neuantrag betroffen sind.

CAcert-Zertifikate

Die nicht-profit-orientierte CAcert-Organisation stellt diese Zertifikate kostenlos aus und ist in etwa dem Gedanken für offene Software so verbunden wie die Entwickler von Linux. Die Eidgenössische Technische Hochschule Zürich und die Universität Zürich sind zeitgleich dieser CAcert-Organisation als Organisationsmitglieder beigetreten.

Das so genannte Root-Zertifikat ist nicht in den Browsern enthalten ist. Es ist also eine gute Gelegenheit, darüber nachzudenken.

  • In meinem Browser befinden sich zur Zeit 160 solche Root-Zertifikate vorinstalliert. Diesen vertraue ich ohne Rückfrage, weil mein Browserhersteller für mich diese Entscheidung getroffen hat.
  • Einige stammen von staatlichen Einrichtungen, die Mehrzahl sind von kommerziellen Anbietern.
  • Einige Regionen der Welt sind selten vertreten, andere überproportional häufig.

Der Import eines Zertifikates ist zwar durchaus leicht, aber im ersten Sinne ist es eine persönliche Entscheidung, einem Anbieter zu vertrauen. Im konkreten Fall vertrauen Sie den Informatikdiensten der ETH Zürich, dass wir die Zertifikate für die Web-Server in unserer Domain ordentlich geprüft ausstellen. Man holt sich das Root-Zertifikat immer vom Anbieter direkt ab. Im Falle von CAcert befinden sich diese Zertifikate hier

Mit den Fingerprints (digitalen Fingerabdrücken) kann man überprüfen, dass das heruntergeladene Zertifikat exakt dem entspricht, was auf der Herstellerseite angeboten wird. Diese sind für den Fingerprint SHA1:

13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33

und für den Fingerprint MD5:

A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B

Man sieht diese Fingerabdrücke, wenn man sich während der Installation das Zertifikat anzeigen lässt.

Installation im Firefox-Browser

Man muss nur das Root-Zertifikat (Root Certificate) installieren, dazu klickt man auf der Webseite das Zertifikat im PEM-Format an und der Import geht los.

Installation im Internet Explorer

Der Internet Explorer gibt sich schwerfälliger bei der Installation des Root Zertifikats, als andere Browser. Beim Internet Explorer muss das Zertifikat zuerst auf dem Computer gespeichert werden. Danach wird mit einem Doppelklick darauf die Importfunktion aufgerufen. Beim Schritt Zertifikatsspeicher muss der Ordner manuell ausgewählt werden. Der richtige Ordner für dieses Root Zertifikat heisst Vertrauenswürdige Stammzertifizierungsstellen. Ein Klick auf Fertig stellen importiert das Zertifikat.

Wenn Ihr Arbeitsplatz zentral verwaltet ist, helfen Ihnen die hier aufgezeigten Lösungen zum Import des Root-Zertifikats nicht, Sie müssen sich an Ihren Arbeitsplatz-Verwalter wenden, um Hilfe zu bekommen.

Installation im Apache-Server

Wir signieren die Serverzertifikate ausschliesslich mit dem Root-Zertifikat von CAcert. Für den Rechner www.tux.ethz.ch habe ich in der Apache-Konfiguration die folgenden Variablen belegt:

SSLCertificateFile /etc/apache2/ssl/cacert/www.tux.ethz.ch.crt
SSLCertificateKeyFile /etc/apache2/ssl/cacert/www.tux.ethz.ch.key
Das Serverzertifikat und der Schlüssel befinden sich in dem Verzeichnis: /etc/apache2/ssl/cacert Damit verhält sich die Konfiguration am Server genauso, wie bei den anderen Zertifikaten. Man muss darauf achten, dass der geheime Schlüssel nicht mit einem Passwort geschützt ist, sonst startet der html-Server nicht ohne Interaktion.
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatcnf openssl.cnf r1 manage 7.9 K 2015-06-24 - 12:09 UnknownUser Konfigurationsdatei für OpenSSL
Topic revision: r1 - 2015-06-24 - vermeul
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback