Ubuntu 16.04 Xenial Xerus
Ubuntu 14.04 Trusty Tahr
Ubuntu 12.04 Precise Pangolin
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Eine Certification Authority (CA) ist eine Instanz, die SSL-/TLS-Zertifikate ausstellt und beglaubigt. Die "Kunden" einer CA lassen sich dann ihre eigenen (Server-)Zertifikate von der CA kryptografisch signieren und können damit nachweisen, dass sie der sind, der sie zu sein vorgeben. Ubuntu bringt über das Paket ca-certificates eine ganze Reihe sogenannter Root-Zertifikate seriöser CAs mit, die von Client-Programmen wie Webbrowsern benutzt werden, um die Identität von SSL-verschlüsselten Serverdiensten zu verifizieren. Schlägt diese Prüfung fehl, präsentiert das Client-Programm dem Benutzer eine Warnung, weswegen es für Anbieter öffentlich zugänglicher Dienste eigentlich unverzichtbar ist, ein Zertifikat dieser bekannten Stellen zu erwerben.
Obwohl es inzwischen sogar kostenlose CA-Dienste gibt (siehe Links), möchte aber nicht jeder für seinen Heim- oder Firmenserver eine dieser Stellen bemühen. Eine Möglichkeit, an eigene SSL-Zertifikate zu kommen, ist die Benutzung sogenannter selbstsignierter Zertifikate, wie sie z.B. durch das Paket ssl-cert zur Verfügung gestellt werden. Solche Zertifikate erzeugen natürlich jedesmal eine Warnung, wenn ein Client das erste Mal diesen Dienst benutzt.
Wer also mehrere Dienste für mehrere Leute anbietet, z.B. in einem Firmen-Intranet, der möchte sich vielleicht selber seine eigene CA gründen. Dann muss man nur das eine CA-Root-Zertifikat auf allen potentiellen Clients installieren (bzw. zum Download anbieten, wenn die Benutzer keine Computer-Laien sind,) und alle Dienste funktionieren ohne das misstrauenerweckende Warnfenster.
Anfang April 2014 ist der Heartbleed-Bug (CVE-2014-0160) in OpenSSL bekannt geworden. Leider hat sich Canonical entscheiden, bis einschließlich Ubuntu 14.04 nicht die aktualisierte Version 1.0.1g oder neuer zu nutzen, sondern nur die Pakete in den offiziellen Paketquellen zu patchen. Seit dem 7. April 2014 stehen diese als Update zur Verfügung. Man sollte sich daher nicht durch die scheinbar betroffene Versionsnummer des Pakets täuschen lassen.
Allerdings wird empfohlen, vor diesem Datum mit Ubuntu 12.04 oder neuer erstellte Zertifikat zu verwerfen und neue zu erstellen.
Das folgende Paket bringt alles Nötige mit, um eine eigene CA zu erstellen. Bei den meisten Ubuntu-Derivaten ist es schon vorinstalliert. Nur wenn man die Minimal- oder die Serverinstallation gewählt hat, muss es nachträglich installiert [1] werden:
openssl
mit apturl
Paketliste zum Kopieren:
sudo apt-get install openssl
sudo aptitude install openssl
Das Paket openssl bringt ein Perlskript CA.pl als Frontend mit, mit dem man sich sehr bequem seine eigene CA erschaffen und verwalten kann. Das Skript befindet sich im Verzeichnis /usr/lib/ssl/misc/. Um es zu benutzen benötigt man keine erweiterten Rechte, man kann die CA einfach im eigenen Homeverzeichnis erstellen.
Je nachdem, wofür man die CA benutzen möchte, sollte man einen angemessenen Sicherheitsaufwand betreiben. Wer den privaten Schlüssel der CA stiehlt, kann sich später problemlos reihenweise SSL-Zertifikate im Namen der ausstellenden Instanz beschaffen. Wer solche Zertifikate in seinem Unternehmen benutzen will, sollte deswegen die CA auf einem abgeschotteten Rechner ohne Netzwerkzugang in einem abschließbaren Raum ablegen.
Alternativ könnte man die CA auch auf einem USB-Stick oder sonstigen Wechselmedium erstellen und vor jeder Benutzung die Netzwerkverbindung des Rechners kappen und von einer Live-CD booten.
Möchte man Zertifikate erstellen, die länger als ein Jahr gültig sind, muss in /etc/ssl/openssl.cnf "default_days
" auf einen höheren Wert als 365 eingestellt werden. Erst danach sollte man seine eigene CA erstellen.
Mit dem CA.pl-Skript ist die Erstellung der CA ziemlich einfach. Im Verlauf der verschiedenen Schritte wird man nach diversen Daten gefragt, die man eingeben kann, aber meistens nicht muss. Nur die Passphrase - die in diesem Fall ruhig besonders lang und kompliziert ausfallen kann, der "Organization Name" und der "Common Name" sollten auf jeden Fall angegeben werden. Auch eine Kontakt-E-Mail-Adresse ist sinnvoll. Das Ganze passiert im Terminal [2] und sieht dann in etwa so aus:
/usr/lib/ssl/misc/CA.pl -newca
Ausgabe;
CA certificate filename (or enter to create) # <Enter> drücken Making CA certificate ... Generating a 1024 bit RSA private key ................++++++ ......................................++++++ writing new private key to './demoCA/private/cakey.pem' Enter PEM pass phrase: # besonders lange und komplizierte Passphrase eingeben Verifying - Enter PEM pass phrase: # Passphrase wiederholen ----- 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 (2 letter code) [AU]: # z.B. DE State or Province Name (full name) [Some-State]: # z.B. Schleswig-Holstein Locality Name (eg, city) []: # z.B. Helgoland Organization Name (eg, company) [Internet Widgits Pty Ltd]: # z.B. Karl-Heinz Beispiel GmbH Organizational Unit Name (eg, section) []: # z.B. einfach <Enter> drücken, um was auszulassen Common Name (eg, YOUR name) []: # z.B. eine eigene Domain á la beispiel.de Email Address []: # z.B. abc@example.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: # Kann man auslassen (<Enter>) An optional company name []: # Kann man ebenfalls weglassen Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: # noch einmal die Passphrase von oben eingeben Check that the request matches the signature Signature ok Certificate Details: Serial Number: f3:43:40:d0:07:37:64:9a Validity Not Before: Jun 16 20:53:57 2007 GMT Not After : Jun 15 20:53:57 2010 GMT Subject: countryName = DE stateOrProvinceName = Schleswig-Holstein organizationName = Karl-Heinz Beispiel GmbH commonName = beispiel.de emailAddress = abc@example.com X509v3 extensions: X509v3 Subject Key Identifier: 47:EA:3D:2B:41:8B:29:EE:A5:56:E1:8E:3A:AD:15:0C:F8:AD:D0:73 X509v3 Authority Key Identifier: keyid:47:EA:3D:2B:41:8B:29:EE:A5:56:E1:8E:3A:AD:15:0C:F8:AD:D0:73 DirName:/C=DE/ST=Schleswig-Holstein/O=Karl-Heinz Beispiel GmbH/CN=beispiel.de/emailAddress=abc@example.com serial:C3:BA:A2:3F:4B:7A:C1:EB X509v3 Basic Constraints: CA:TRUE Certificate is to be certified until Jun 15 20:53:57 2010 GMT (1095 days) Write out database with 1 new entries Data Base Updated
Im aktuellen Verzeichnis sollte jetzt ein neues Verzeichnis demoCA mit einigen Dateien und weiteren Unterverzeichnissen entstanden sein. Folgende davon sind wichtig:
cacert.pem - Das öffentliche Zertifikat der CA. Diese Datei sollte auf allen Clients importiert werden. Danach vertrauen diese Clients automatisch allen von der CA ausgestellten weiteren Zertifikaten.
certs/ - Das Verzeichnis, wo die nachfolgenden Zertifikate untergebracht werden.
private/ - Das Verzeichnis für die privaten Schlüssel.
private/cakey.pem - Der private Schlüssel der CA. Dieser sollte die CA nie verlassen, außer zu Backup-Zwecken. (Und auch dann gesondert gesichert werden.)
Die Datei cacert.pem hat nichts mit der im Artikel CAcert beschriebenen Organisation zu tun.
Wenn man die CA auf einem Fat-Dateisystem, bspw. einem USB-Stick, erstellt, bekommt man auf Grund der Großbuchstaben im Verzeichnisnamen "demoCA" Probleme. Fat unterscheidet nicht zwischen Groß- und Kleinbuchstaben, so dass Linux alle Dateinamen als Kleinbuchstaben behandelt. Um Komplikationen aus dem Weg zu gehen sollte man in diesem Fall den Namen von vorneherein in etwas "kleines", z.B. democa, umwandeln. Das geschieht über die Datei /usr/lib/ssl/openssl.cnf, wo man folgende Deklaration abändern muss [3]:
[ CA_default ] dir = ./demoCA # Where everything is kept
Als nächstes sollte man sicherheitshalber noch allen Gruppen und anderen Benutzern sämtliche Rechte am private-Verzeichnis entziehen [4]. Die CA ist jetzt fertig und einsatzbereit.
Mit dieser CA kann man nun anfangen, die eigentlichen Zertifikate zu erstellen, die man dann bspw. auf seinen Servern einsetzt. Auch hierfür verwendet man das CA.pl-Skript. Die Erzeugung läuft in zwei Stufen ab. Als erstes erstellt man einen neuen Schlüssel und einen "Zertifizierungsantrag"(CA.pl -newreq
), und dann zertifiziert man diesen Schlüssel (CA.pl -sign
). Damit das Skript funktioniert, muss man sich im selben Verzeichnis befinden, von wo man auch die CA erstellt hat, also eines über demoCA.
Wichtig ist, dass man bei "Common Name" exakt den vollqualifizierten Domainnamen (FQDN; Beispiel: servername.domain.topleveldomain
) des Servers einträgt, sonst wird das Zertifikat von den Clients später nicht akzeptiert.
/usr/lib/ssl/misc/CA.pl -newreq
Ausgabe:
Generating a 1024 bit RSA private key .........................++++++ ....................++++++ writing new private key to 'newkey.pem' Enter PEM pass phrase: # eine andere Passphrase für dieses Zertifikat wählen Verifying - Enter PEM pass phrase: # Passphrase wiederholen ----- 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 (2 letter code) [AU]: # z.B. DE State or Province Name (full name) [Some-State]: # z.B. Niedersachsen Locality Name (eg, city) []: # z.B. Worpswede Organization Name (eg, company) [Internet Widgits Pty Ltd]: # z.B. Beispiel Ltd., ein Kunde der Karl-Heinz Beispiel GmbH Organizational Unit Name (eg, section) []: # kann man wieder auslassen Common Name (eg, YOUR name) []: # muss unbedingt der reale Name des Dienstes sein # z.B. www.beispiel-worpswede.de Email Address []: # z.B. def@example.net Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: # <Enter> drücken An optional company name []: # <Enter> drücken Request is in newreq.pem, private key is in newkey.pem
/usr/lib/ssl/misc/CA.pl -sign
Ausgabe:
Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: # Passphrase des CA-Schlüssels (erste Passphrase) angeben Check that the request matches the signature Signature ok Certificate Details: Serial Number: c3:ba:a2:3f:4b:7a:c1:ec Validity Not Before: Jun 16 22:25:19 2007 GMT Not After : Jun 15 22:25:19 2008 GMT Subject: countryName = DE stateOrProvinceName = Niedersachsen localityName = Worpswede organizationName = Beispiel Ltd. commonName = www.beispiel-worpswede.de emailAddress = def@example.net X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 7D:A0:95:41:D5:D5:8C:D2:37:C8:6C:02:24:29:7A:9D:EB:2C:8F:41 X509v3 Authority Key Identifier: keyid:47:EA:3D:2B:41:8B:29:EE:A5:56:E1:8E:3A:AD:15:0C:F8:AD:D0:73 Certificate is to be certified until Jun 15 22:25:19 2008 GMT (365 days) Sign the certificate? [y/n]: # unbedingt <y> eingeben, nicht nur <Enter> 1 out of 1 certificate requests certified, commit? [y/n] # ebenfalls <y> eingeben Write out database with 1 new entries Data Base Updated Signed certificate is in newcert.pem
Die Passphrase im Signierschritt ist natürlich die des CA-Schlüssels und nicht die des Schlüssels, den wir gerade erstellen. Außerdem muss man darauf achten, am Ende wirklich mit y zu bestätigen, sonst bricht das Skript mit einem Fehler ab.
Im aktuellen Verzeichnis, immer noch das der demoCA übergeordnete, befinden sich jetzt die drei Dateien newreq.pem, newkey.pem und newcert.pem.
newreq.pem ist inzwischen nutzlos geworden und kann gelöscht werden. Wichtig sind nur die beiden anderen. Diesen sollte man aussagekräftigere Namen geben und sie zur Archivierung in das jeweilige Verzeichnis der CA verschieben. Wenn man das Zertifikat auf einem Server benutzen will und nicht bei jedem Server(neu)start die Passphrase eingeben will, kann man diese noch vorher aus dem Schlüssel löschen und diesen unverschlüsselt abspeichern. In diesem Fall sollte man aber auf jeden Fall darauf achten, dass man ihn auch auf dem Server durch restriktive Dateirechte [4] vor neugierigen Blicken schützt:
openssl rsa -in newkey.pem > realkey.pem mv realkey.pem demoCA/private/worpswede_key.pem mv newcert.pem demoCA/certs/worpswede_cert.pem
Diese zwei Dateien sind es auch, die der betreffende Server zum SSL-Betrieb benötigt. Die Datei newkey.pem kann ebenfalls gelöscht werden. (Nachdem man sich davon überzeugt hat, dass mit der Umwandlung alles geklappt hat, und realkey.pem nicht etwa leer ist.) Wo diese Dateien letztendlich hinkopiert werden müssen, hängt vom benutzten Server ab, üblich sind aber die Verzeichnisse /etc/ssl/certs und /etc/ssl/private.
Abgesehen davon, dass man Zertifikate auch als einfacher Benutzer über Importfunktionen oder Konfigurationsdirektiven in den diversen Clientprogrammen nutzen kann, kann man das Root-Zertifikat auch systemweit installieren. Dafür muss folgendes Paket installiert sein (was im Allgemeinen bereits der Fall ist):
ca-certificates
mit apturl
Paketliste zum Kopieren:
sudo apt-get install ca-certificates
sudo aptitude install ca-certificates
Als erstes muss man dann die Datei cacert.pem nach /usr/share/ca-certificates/cacert.crt kopieren. Am Besten denkt man sich bei dieser Gelegenheit noch einen aussagekräftigeren Namen als "cacert.crt" aus, z.B. "organisationsname.crt". Wichtig ist aber, dass die Dateiendung von .pem auf .crt geändert wird. Dann wird folgender Befehl ausgeführt:
sudo dpkg-reconfigure ca-certificates
Auf die Frage, ob neue Zertifikate akzeptiert werden sollen, antwortet man entweder mit "ja", dann wird das neue Zertifikat ohne weitere Rückfrage in die Liste aufgenommen, oder mit "nachfragen". Im letzteren Fall erscheint ein neuer Dialog mit einer Liste aller Zertifikate, die in /usr/share/ca-certificates/ zu finden sind. Das neue Zertifikat ist noch nicht automatisch angewählt. Das muss man selber erledigen und dann mit "Ok" bestätigen.
Zertifizierungsstellen, denen man nicht vertraut, kann man in diesem Dialog auch abwählen. Insbesondere kann man alle abwählen außer der eigenen, wenn man das Paket ca-certificates ansonsten sowieso nicht gebraucht hätte. Es empfiehlt sich aber nicht, das auf Maschinen zu tun, wo Benutzer arbeiten. Ansonsten werden diese in Zukunft bei jeder SSL-verschlüsselten Seite mit einer Warnung belästigt. Benutzer dahingehend zu erziehen, permanent Warnfenster wegzuklicken, ist vom Sicherheitsstandpunkt her kontraproduktiv!
Da das Paket ca-certificates in den Paketquellen nur gelegentlich Updates bekommt, gibt es ab 12.04 die Möglichkeit, die Root-Zertifikate selbst auf den neuesten Stand zu bringen:
sudo update-ca-certificates -f
Selbstsignierte Zertifikate werden über entsprechende Warnhinweise prinzipiell als verdächtig bzw. unsicher eingestuft und der Client-Zugriff komplett blockiert. Daher müssen eigene Zertifikate erst heruntergeladen und über dauerhafte Ausnahmeregeln legimitiert werden. Falls Firefox dieses verweigert bzw. gar nicht erst anbietet, ruft man die Pseudo-Adresse about:config
auf und setzt den Wert des Schlüssels
browser.xul.error_pages.expert_bad_cert
auf true
. Inzwischen warnen auch andere Browser vor selbstsignierten Zertifikaten.
Soll das erstellte Zertifikat den eigenen Webserver authentifizieren (hier eine Synology Disk Station), müssen noch ein paar Anpassungen erledigt werden. Das Zertifikat (cert) muss mit einem Texteditor geöffnet werden und alles ausserhalb von -----BEGIN CERTIFICATE-----
und -----END CERTIFICATE-----
gelöscht werden. Anschließend muss der Schlüssel (private key) vom Passwort befreit werden:
openssl rsa -in KEY-DATEI -out KEY-DATEI_OHNE_PRIVATE_KEY
Achtung, der neue private key ist nicht mehr passwortgeschützt, deshalb direkt danach sicher löschen!
Beim manuellen Einlesen eines Zertifikates aus einer Datei muss alles vor dem "-----BEGIN CERTIFICATE-----" entfernt werden.
ssl-cert - selbstsignierte Zertifikate
Tiny CA - eine eigene kleine Zertifizierungsstelle (CA) betreiben
gnoMint - grafische Verwaltung einer CA (ab Ubuntu 9.04)
CAcert - Community, die kostenlose SSL-Zertifikate ausstellt
Let's Encrypt: Mozilla und die EFF mischen den CA-Markt auf - heise Security, 11/2014
SSL für lau - Kostenlose Zertifikate einrichten - heise Security, 01/2010
Diese Revision wurde am 26. Dezember 2016 12:47 von aasche erstellt.