Selbst signierte SSL-Zertifikate für Internet-Domains müssen nicht sein ...

Zunehmend werden passwortgeschützte oder anderweitig sicherheitskritische Anwendungen auf Webservern betrieben. Um die Übertragung der Daten gegen Abhören (Sniffing) zu schützen wird dazu meist eine per SSL/TLS-verschlüsselte Verbindung benutzt wie Sie im Web-Bereich das https-Protokoll bietet. Leider trifft man immer noch relativ häufig auf per https-Protokoll verfügbare Websites bei denen der Browser im Zuge des Verbindungsaufbaus eine sogenannte Zertifikatswarnung ausgibt.

Die Gründe für eine derartige Warnung können ihre Ursache z.B. bei folgenden Punkten haben:

1. Das zeitlich befristete Zertifikat ist abgelaufen. D.h. es war vermutlich einmal gültig, ist es jetzt aber nicht mehr.
2. Das Zertifikat gehört gar nicht zum kontaktierten Server.
3. Das Zertifikat wurde von einer unbekannten Zertifizierungsstelle, der sogenannten "Certification Authority (CA)", ausgestellt.

Die Punkte 1 und 2 sind Fehler des Diensteanbieters und müssen von selbigem korrigiert werden. Um die möglichen Ursachen für den 3. Fehler zu verstehen, hier zuerst eine (sehr) kurze Einführung in die Vorgänge die im Rahmen der Kontaktaufnahme zwischen dem Web-Browser und dem Web-Server im Hintergrund ablaufen.  Während des Sitzungsaufbaus wird von Web-Browsern zuerst versucht die Identität des Webservers durch Überprüfung des SSL-Zertifikats sicher zu stellen. Durch DNS-Spoofing, Domain-Hijacking, ARP-Spoofing im lokalen Netz, ... ist es nämlich möglich, dass ein Angreifer versucht Ihnen einen ganz anderen Server "unterzujublen" bzw. Ihre Daten über einen "man-in-the-middle"-Angriff abzuhören.

Um dies möglichst zu vermeiden prüft der Web-Browser wie bereits erwähnt das SSL-Zertifikat. Konkret beinhaltet dies die folgenden Schritte:

1. Prüfen ob das Zertifikat überhaupt zu diesem Server gehört / für diesen Server ausgestellt wurde. Dazu wird der direkt auslesbare Zertifikatsparameter "Common Name (CN)" mit der Serverangabe aus dem URL im Browser verglichen. Stimmen die Angaben nicht überein, ist das Zertifikat nicht für diesen Server ausgestellt worden.
   Beispiel: Lautet der "Common Name (CN)"-Eintrag, im evtl. sogar ansonsten gültigen Zertifikat, auf "www.postbank.de.com", die aufgerufene Adresse lautet aber https://www.postbank.de, misstraut der Browser zu Recht dem Vorgang und baut die Verbindung nicht auf.
2. Feststellen welche "Certification Authority (CA)" das Prüfverfahren für den Server durchgeführt und anschließend das Zertifikat ausgestellt hat.
3. Aus dem Zertifikatsspeicher des Browsers oder des Betriebssystems das Zertifikat (bzw. den Public-Key) der in 1. festgestellten "Certification Authority (CA)" laden.
4. Durch Entschlüsseln der digitalen Signatur der CA wird im Anschluss geprüft ob die Signatur überhaupt von dieser CA stammt. Falls Entschlüsselung erfolgreich ist, wurde der enthaltene Hashwert (Prüfsumme) tatsächlich von der CA verschlüsselt ... soweit schon mal gut.
5. Nun wird der Hashwert (die Prüfsumme) des vom Webserver erhaltenen Zertifikats selbst gebildet und mit dem aus dem vorherigen Schritt gewonnenen Werts verglichen. Sind die beiden Hashwerte (der selbst erstellte und der von der CA überlieferte) identisch, ist die Identität des Servers sichergestellt.

Eine Zertifikatswarnung, deren Ursache nun ein "unbekannter Aussteller" / "eine unbekannte Zertifizierungsstelle" ist, sieht z.B. in Firefox so aus:

Die Grund dafür, dass das Zertifikat der Certification Authority nicht gefunden wurde kann mehrere Gründe haben. Evtl. hat es die CA einfach noch nicht geschafft in die Zertifikatsspeicher der einschlägigen Browser oder Betriebssysteme aufgenommen zu werden - z.B. weil die Betreiberfirma noch relativ neu am Markt ist. Der schlimmste Fall wäre allerdings ein wie auch immer gearteter "Man-in-the-middle"-Angriff bei dem ein gefälschtes Zertifikat in die Kommunikation eingeschleust wird. Der Angreifer kann natürlich nicht mit einem offiziell anerkannten CA-Key unterschreiben und fliegt an der Stelle auf. Genau auf diesen Super-GAU-Fall versucht die Zertifikatsüberprüfung / -warnung hinzuweisen.

Die Zertifikatswarnung ist aber auch typisch für Self-Signed-SSL-Zertifikate. Dabei scheut der Betreiber des Webservers die Kosten für ein Zertifikat bei einem kommerziellen Dienstleister. Statt dessen wird in so einem Fall erst eine eigene Zertifizierungsstelle (CA) konfiguriert und dann das Zertifikat des Webservers damit ausgestellt. Das Problem ist, dass nun der obige Schritt 3 fehlschlägt. Der Browser versucht den Public-Key derjenigen CA aus dem Zertifikatsspeicher des Browsers zu laden, mit dem das Zertifikat gegengezeichnet wurde. Im Browser sind aber nur die einschlägigen, meist kommerziellen Betreiber von CAs hinterlegt. Insbesondere eine für Self-Signed-SSL-Zertifikate geschaffene CA ist natürlich nicht im Zertifikatsspeicher der Browser enthalten. Besucher der Website stehen nun vor dem Problem zu entscheiden ob das einfach nur "Schlamperei" des Betreibers oder eben ein echter Angriff ist!

Auch das Anbieten des selbst erstellten CA-Stammzertifikats als Download (zur Integration in den Zertifikatsspeicher des Browsers) ist eine verwerfliche Lösung und Anwender sind gut beraten diese Lösung nicht mitzumachen. Tun Sie dies trotzdem, vertrauen Sie jeder https-Verbindung die von dieser CA zertifiziert wurde. Wollen Sie das wirklich? Vertrauen Sie Ihrem Administrator so blind? Schließlich kann auch dieser einen "Man-in-the-middle"-Angriff auf Ihre Verbindungen durchführen. Sie bekommen nach Aufnahme des CA-Stammzertifikats dann keinerlei Warnungen mehr! Mein Rat: Lassen Sie es sein!

Für die Anwender so gut wie gar nicht mehr kontrollierbar ist es, einen https-Bereich per iFrame in eine normale http-Seite einzubinden!. Dabei sieht der Besucher in der Adressleiste des Browsers nur den http-URL. Gibt es Probleme mit der eingebetteten https-Seite, wird dort statt der eigentlichen Seite erst einmal die Zertifikatswarnung angezeigt.

Solche https- via iFrame in http-Seiten eingebettete Lösungen sind aber so ziemlich das Schlimmste was man als Betreiber einer Website den Besuchern antun kann. Begründung:

1. Besucher sehen in der Adressleiste nicht ob die Verbindung überhaupt verschlüsselt ist. Dort wird schließlich nur eine http-Adresse/-verbindung angezeigt!
2. Findet ein "Man-in-the-middle"-Angriff statt der die SSL-Verbindung komplett unterdrückt (Stichwort SSLstrip), erhält ein Besucher nicht einmal mehr obige Warnung sondern gelangt direkt zur gewollten, eingebetteten Seite. Dummerweise ist die Verbindung nun aber gar nicht mehr SSL-gesichert

Fazit: https-Seiten nie per iFrame in andere Seiten einbetten!

Möchte man Zertifikatswarnungen als Betreiber eines SSL-basierenden Webservers generell vermeiden, muss man das Zertifikat von einer anerkannten CA ausstellen lassen deren Public-Key in den einschlägigen Browsern schon vorinstalliert ist. In Bereichen mit beschränkten finanziellen Ressourcen (private Webserver, Vereine, ... aber auch Schulen) wird diese Investition allerdings häufig nicht getätigt. Dies hat zur Folge, dass Besucher/innen derartiger Websites auf das "Wegklicken" von Zertifikatswarnungen konditioniert werden. Gerade im Bildungsbereich ist aber in Hinblick auf den Erziehungs- und Bildungsauftrag - der natürlich auch die Medienerziehung beinhaltet - ein verantwortungsvoller Umgang mit Sicherheitswarnungen gefordert. Bei Vereinen, Firmen oder privaten Webservern erweckt es, um es vorsichtig zu formulieren, zumindest keinen professionellen Eindruck.

Seit einiger Zeit gibt es aber mit der Firma StartCom Ltd. eine Firma die über die Marke StartSSL™ kostenlose Class1-SSL-Zertifikate anbietet. Bei Class-1-Zertifikaten wird im allgemeinen nur per Rückmail geprüft ob der Antrag für das SSL-Zertifikat auch wirklich vom Domain-Inhaber stammt (Domain validated). Es gibt bei dieser Klasse von SSL-Zertifikaten insbesondere keine finanzielle Haftung der CA falls diese bei der Zertifikatsausstellung Verfahrensfehler gemacht hat. Wollen Sie aber nicht gerade einen Webshop oder eine Bank betreiben, ist ein Class1-Zertifikat absolut ausreichend da damit die leidigen Zertifikatswarnungen wegfallen und nur bei echten Angriffen eine Warnung angezeigt wird. Nachfolgend wird deshalb das Verfahren beschrieben um ein kostenloses Class1-Zertifikat von StartSSL™ zu erhalten. Das Zertifikat ist zwar "nur" ein Jahr gültig, danach kann aber derzeit problemlos ein neues erstellt werden. StartSSL™ warnt sogar rechtzeitig vor dem Ablaufdatum des alten Zertifikats per Mail.

SSL-Zertifikate mit StartSSL™ / StartCom Certification Authority

Erstellung eines persönlichen StartSSL-Accounts

Zuerst benötigen Sie einen Account bei der StartSSL™-Zertifizierungsstelle. Klicken Sie dazu auf deren Startseite oben rechts auf die Schaltfläche mit dem Schlüsselbund.

Auf der darauf folgenden Seite klicken Sie auf die Schaltfläche "Sing-Up" um sich einen Account anzulegen. Sie müssen daraufhin über ein Webformular Ihre persönlichen Daten erfassen und an StartSSL übermitteln.

Haben Sie alle Daten erfasst, sendet StartSSL eine E-Mail zur Validierung der angegebenen Mailadresse. Da dies im Hintergrund unmittelbar gemacht wird, kann die Website von StartSSL auch sofort rückmelden ob der Vorgang erfolgreich war. Insbesondere bei Greylisting auf ihrem Mailserver (zur Vermeidung von Spam-Mails) schlägt dies aber erst einmal fehl.

Sollte die Ursache wirklich Greylisting sein, müssen Sie das Formular erst einmal geöffnet lassen und es ca. alle 3-5 Minuten erneut absenden. Gängige Zeitwerte bei Greylisting sind 5-15 Minuten Verzögerung bevor die Mail akzeptiert wird. Nun sollten Sie eine Mail wie die nachfolgende erhalten.

Kopieren Sie den "Authentication Code" (siehe oben) in das von StartSSL angezeigte Formular.

Evtl. erhalten Sie nun die Rückmeldung, dass Ihr Account / pers. Daten noch von StartSSL validiert werden. In diesem Fall erhalten Sie erneut eine Mail wie z.B. die im folgenden Screenshot abgebildete. Andernfalls gelangen Sie direkt zur Schlüsselerzeugung (siehe übernächsten Screenshot).

Wie auch immer ... wird nun als nächstes ein persönliches User-SSL-Zertifikat (das ist nicht für einen Webserver) für Sie bzw. Ihre Mail-Adresse erzeugt und in Ihrem Browser installiert. Bei weiteren Besuchen der StartSSL-Website erfolgt die Anmeldung nämlich nicht über einen Usernamen und ein Passwort, sondern über genau dieses Zertifikat das nur Sie haben! Aber Schritt für Schritt. Zuerst wird nun ein asymmetrisches Schlüsselpaar für Sie erstellt.

Im Anschluss daran wird der zugehörige Public-Key (zusammen mit Ihren Klartextdaten) im X509-Format von der StartSSL-CA gegengezeichnet (und damit zertifiziert. Anschließend kann dieses erste Zertifikat, bestehend aus Private-Key, Public-Key und Zertifkat von StartSSL im Browser installiert werden.

Nach Anklicken der Schaltfläche "Install" wird das persönliche Zertifikat im Browser installiert. Es wird ähnlich wie im Browser gespeicherte Usernamen/Passwort-Kombinationen geschützt. D.h. Sie sollten z.B. unbedingt ein Master-Passwort vergeben!

Erstellen Sie nun eine Sicherungskopie dieses Zertifikats! Sie können sich sonst bei Datenverlust nicht mehr bei StartSSL anmelden! Erklärung zu Durchführung der Sicherung gibt es direkt von StartSSL.

Domain-Validierung durchführen

Nachdem Sie nun einen per E-Mail-Validierung überprüften StartSSL-Account haben, können Sie den nächsten Schritt zu einem SSL-Zertifikat für Ihren Webserver bzw. ganz allgemein für SSL-basierende Dienste in Ihrer Domain beschreiten. Bevor Sie für Ihren Webserver ein SSL-Zertifikat ausstellen lassen können, müssen Sie aber zuerst nachweisen, dass Sie wirklich der Domaininhaber sind. Dieser Vorgang nennt sich "Domain Validation". Starten Sie diesen Vorgang - nach erfolgreichem Login bei StartSSL - über den Reiter "Validation Wizard".

Wählen Sie wie gezeigt im Pull-Down-Menü für den Validation-Type die Option "Domain Name Validation" aus. Im darauf folgenden Formular tragen Sie den zu validierenden Domain-Namen ein. Die Top-Level-Domain (hier de für Deutschland) ist dabei getrennt in einem Pull-Down-Menü auszuwählen und darf deshalb nicht im ersten Textfeld stehen.

Der Validierungs-Vorgang verwendet nun das gleiche Prinzip wie bereits bei der Überprüfung Ihres persönlichen StartSSL-Accounts. Die Firma StartSSL geht einfach davon aus, dass der Zugriff auf die drei Mailkonten "postmaster", "hostmaster" und "webmaster" nur für den ausgewählten Kreis der Administratoren der Domain zugänglich ist. Sie können deshalb im nun folgenden Dialog nur auswählen an welche dieser drei Mailadressen Sie die Validierungs-Mail zugestellt bekommen wollen.

Genau wie im vorigen Teilkapitel sollten Sie nun eine Mail von StartSSL erhalten in der Sie einen "Verification Code" finden. Kopieren Sie diesen erneut einfach in das angezeigte Textfeld.

Sofern Sie alle Schritte erfolgreich durchgeführt haben sind Sie nun in den Augen von StartSSL der Domaininhaber. Dies zumindest für die nächsten 30 Tage - denn evtl. zahlen Sie ja Ihre Domainrechnung nicht und verlieren die Domain dadurch wieder . Als geprüfter Domain-Inhaber ist es nun möglich sich für die eigene Domain (incl. Subdomains) beliebig viele, kostenlose Class1-Zertifikate ausstellen zu lassen. Na dann ...

Ein SSL-Zertifikat für den Webserver einer validierten Domain erstellen

Die Ausstellung eines Zertifikats beginnt mit dem Reiter "Certificates Wizard". Wählen Sie hier "Web Server SSL/TLS Certificate" als Certificate Target aus.

Da in einem Zertifikat mindestens der Name des Servers in Kombination mit dem zugehörigen öffentlichen Schlüssel (Public Key) zertifiziert wird, benötigen Sie nun einen solchen "Public Key". Bei der asymmetrischen Verschlüsselung gehört aber zu jedem "Public Key" auch der dazu passende "Secret Key". Dieser geheime Schlüssel sollte nie Dritten in die Hände gelangen! Deshalb erzeugt man das Schlüsselpaar (bestehend aus "Public Key" und "Private Key") immer selbst!

Um es technisch weniger versierten Administratoren etwas einfacher zu machen, bietet StartSSL die Erzeugung des Schlüsselpaars als Online-Service an. Damit ist aber, zumindest für kurze Zeit, der private Schlüssel auch für StartSSL auf deren Servern verfügbar. Wie lange die "kurze Zeit" ist entscheidet in letzter Konsequenz die Firma StartSSL. Als auch nur leicht paranoider Admin nutzt man diesen Service deshalb nicht!

Meine Empfehlung: Überspringen Sie das nächste Unterkapitel durch Auswahl der Schaltfläche "Skip"! Installieren Sie sich openSSL und erzeugen Sie Ihr Schlüsselpaar selbst, offline!

Schlüsselpaar von StartSSL erzeugen lassen (diesen Unterabschnitt möglichst nicht durchführen!)

Sollten Sie meinen Rat in den Wind schlagen (Sie verleihen dann sicher auch Geld an Unbekannte in der Fußgängerzone ) lassen Sie sich das Schlüsselpaar eben von StartSSL erzeugen. Dazu ist ein Passwort für den Key festzulegen, eine Key-Größe auszuwählen und dann über "Continue" zu bestätigen. Hatte ich schon erwähnt, dass man das nicht macht!?

Nach der Schlüsselerzeugung von StartSSL (igit) sichern Sie wie angegeben den privaten Schlüssel wie erläutert in einer Datei (genauer gehe ich darauf nicht ein ... weil man das sowieso nicht machen soll!).

Schlüsselpaar selbst erstellen und nur den Public Key hochladen (zu bevorzugende Variante)

Schöööööön ... Sie befolgen also meinen Rat und haben im vorherigen Dialog "Skip" ausgewählt. Um nun selbst ein Schlüsselpaar zu erzeugen, müssen Sie sich das freie OpenSSL-Utility installieren. Unter Linux wird das durch die Distribution bereit gestellt, unter Windows starten Sie hier: http://www.openssl.org/related/binaries.html. Anschließend geben Sie in einem Kommandozeilen-Interpreter (DOS-Box unter Windows) das folgende Kommando ein:

openssl req -new -nodes \
> -keyout testserver-grupp-web-de.key \
> -out testserver-grupp-web-de.csr -newkey rsa:2048

Unter DOS ist das ein Kommando - ohne die Backslahes \ am jeweiligen Zeilenende und ohne die > Zeichen am Anfang der Fortsetzungszeile, also so:

openssl req -new -nodes -keyout testserver-grupp-web-de.key -out testserver-grupp-web-de.csr -newkey rsa:2048

Außerdem ersetzen Sie die beiden Dateinamen (testserver-grupp-web-de....) durch etwas für Sie sinniges.

Als Folge des Befehls wird nun ein Schlüsselpaar erzeugt. Anschließend werden Sie die Klartextparameter zu diesem Schlüsselpaar abgefragt. Antworten Sie hier sinngemäß wie nachfolgend gezeigt. WICHTIG ist normalerweise der Common Name (CN) des Schlüsselpaars. Er muss eigentlich zum URL Ihres Servers passen. Im nachfolgenden Beispiel ist das testserver.grupp-web.de. Das abschließend geforderte Passwort und die Firma lassen Sie leer!

Generating a 2048 bit RSA private key
.........................................................
............................................................+++
.................................+++
writing new private key to 'testserver-grupp-web-de.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 (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Baden-Wuerttemberg
Locality Name (eg, city) []:Tettnang
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Private
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:testserver.grupp-web.de
Email Address []:
 Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
 

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Das Ergebnis sind zwei Dateien. Einmal Ihr Private Key in der Datei testserver-grupp-web-de.key und in der Datei testserver-grupp-web-de.csr Ihr Public-Key zusammen mit Klartextinformationen in Form eines Certificate Signing Requests (CSR), also der Bitte an eine CA diesen zu zertifizieren.

Öffnen Sie nun die CSR-Datei mit einem Texteditor und kopieren Sie den Inhalt unverändert in das angezeigte Formular.

Nach dem Upload des CSR erhalten Sie, wenn alles gut lief und StartSSL die Daten erkennen konnte, die nachfolgende Bestätigung.

Wählen Sie nun aus für welche Hauptdomain Sie ein SSL-Zertifikat ausgestellt haben möchten.

Anschließend geben Sie den Namen des Servers ein (hier testserver). Ignorieren Sie, dass hier http angezeigt wird - es geht natürlich darum den Server zukünftig per https kontaktieren zu können.

Sofern StartSSL mit allen Zutaten zufrieden ist, erhalten Sie nun die nachfolgende Rückbestätigung.

Über "Continue" im vorigen Dialog wird nun Ihr Zertifikat ausgestellt.

In manchen Fällen kann es sein, dass offenbar noch ein Mitarbeiter von StartSSL eine Kontrolle des Zertifikats durchführt. In dem Fall wird die nachfolgende Meldung angezeigt ...

... und Sie müssen warten bis dies erfolgt ist. Ankündigung via Mail (siehe nächstes Bild).

Nun können Sie endlich die Früchte Ihrer Arbeit genießen und das Zertifikat herunterladen. Loggen Sie sich ggf. neu ein, gehen Sie zu Ihrer Toolbox (der 1. Reiter ganz links) und wählen Sie ggf. "Retrieve Certificate" aus. Im Pull-Down-Menü dieses Tool-Box-Dialogs können Sie nun das gewünschte Zertifikat auswählen.

Das Zertifikat wird anschließend in einer Textarea angezeigt. Kopieren Sie alle Zeilen in eine neue Textdatei auf Ihrem Rechner und benennen Sie diese so wie die obigen Dateien (Key und CSR) - dieses Mal allerdings mit der Endung crt (also z.B. testserver-grupp-web-de.crt).

Nun haben Sie ein offizielles, kostenloses SSL-Zertifikat - juhu! Das muss nun noch in Ihren Webserver, was im nächsten Unterkapitel erklärt wird.

Zertifikatskonfiguration im Apache-Webserver

Neben der Key- und der CRT-Datei aus den vorigen Unterkapiteln benötigen Sie noch die beiden folgenden Zertifikate (die Sie aber nur noch herunterladen müssen, Sie haben es gleich, Geduld):

1. StartCom Root CA (PEM encoded)
2. Class 1 Intermediate Server CA

Sie finden diese Dateien wieder in der Toolbox unter StartCom CA Certificates.

Speichern Sie auch diese beide Dateien (z.B. unter den Namen StartCom-Root-CA.pem und StartCom-sub.class1.server.ca.pem). Diese beiden Dateien laden Sie nun zusammen mit Ihrer Key- und Ihrer CRT-Datei auf den eigentlichen Server. Konfigurieren Sie nun Ihren SSL-Server damit er diese Dateien bei https-Verbindungen verwendet. Für den weit verbreiteten Apache-Webserver sind das die folgenden vier Zeilen (Pfad und Dateinamen ist natürlich an Ihre Gegebenheiten anzupassen).

SSLCertificateFile            /var/www/andreas/certs-grupp-web/testserver-grupp-web-de.crt
SSLCertificateKeyFile         /var/www/andreas/certs-grupp-web/testserver-grupp-web-de.key 
SSLCertificateChainFile       /var/www/andreas/certs-grupp-web/StartCom-sub.class1.server.ca.pem
SSLCACertificateFile          /var/www/andreas/certs-grupp-web/StartCom-Root-CA.pem

Anmerkung: Das Key-File (der Private-Key Ihres Servers) ist der sensibelste Teil. Der Key repräsentiert Ihren Server, gelangt er in falsche Hände kann ein "Man-in-the-middle"-Angriff mit echten Zertifikaten durchgeführt werden. Deshalb sollten Sie die Key-Datei dem User "root" und der Gruppe "root" übereignen. Entfernen Sie alle Rechte von der Datei und geben Sie nur dem User root das Leserecht. Die Befehle dafür lauten:

chown root:root /var/www/andreas/certs-grupp-web/testserver-grupp-web-de.key
chmod 400 /var/www/andreas/certs-grupp-web/testserver-grupp-web-de.key 

testserver-grupp-web-de