*gäääääääääähn* Was für ein langweiliges Thema. Ich schlafe ja selbst beim Schreiben des Titels ein ;) Aber genau das Richtige für einen Freitag mittag, verregnet, düster und langweilig.
Immer wieder passiert es, das ich mit Kollegen diskutieren muss, wie nun SSL funktioniert und was man darüber wissen sollte, wenn man es konfiguriert. Selbst eingefleischte Entwicker und Adminprofis tun sich manchmal bei eigentlich trivialen Dingen schwer.
Herzlich Willkommen also zur Nachhilfestunde zum Thema SSL und HTTPS. (Du musst ja keinem davon erzählen, das Du diesen Artikel gelesen hast ;). Und man weiss ja nie, vielleicht erfährt man ja doch was Neues.
— Sendung mit der Maus AN —
Buh, sticknormales HTTP kann ja jeder.
Ja stimmt. Aber wofür braucht man denn überhaupt HTTPS, bzw. SSL? Naja das Grundübel ist eingentlich, das HTTP grundsätzlich unverschlüsselt übertragen wird: Jeder kann mitlesen. Ein paar Menschen hat abgehärtet, das es bei E-Mail und FTP auch so ist; ein paar andere fanden das Scheisse und haben sich überlegt, das was Sicheres her muss.
Um zu beweisen, das man einen sicheren Service anbietet, gibt es Zertifikate. Wenn man mit einem Texteditor reinguckt, sehen die Dinger verschlüsselt aus. Und sind es auch. Damit gewährleistet ist, das es sich um ein echtes Zertifikat handel (Ja es gibt auch unechte), werden die Teile von einer Zertifizierungsstelle ausgestellt (CA), die selbst wieder zertifiziert ist (CA-Zertifikat). Damit nicht jedes Zertifikat installiert werden muss, werden die Zertifikate der größten Zertifizierungsstellen schon im Browser vorinstalliert ausgeliefert.
Ein eigenes Zertifikat kostet mindestens 80-100 Euro pro Jahr und muss verlängert werden. Bei einem niedrigeren Preis sollte man die Dienstleitung bzw. Zertifizierungsstelle mal kritischer beäugen. Das Zertifikat (und damit die Verschlüsselung) ist um so sicherer, je höher die Bit-Stärke ist, mit der verschlüsselt wird. Beispiel: Ein 128 Bit verschlüsseltes Zertifikat ist nicht so sicher wie eines, das mit 256 Bit verschlüsselt wurde. Genauer will ich da jetzt nicht drauf eingehen, die Tatsache zählt.
Das Prinzip ist eigentlich ganz einfach: Man speichert das eigene Zertifikat auf dem eigenen Server. Bei einer SSL-Anfrage über HTTPS wird das Zertifikat ausgeliefert und vom Browser auf Echtheit geprüft. Wenn alles in Ordnung geht, steht die sichere Verbindung.
— Sendung mit der Maus AUS —
Die Tücken stecken allerdings wie immer im Detail:
- Ein SSL-Zertifikat ist immer an einen Hostnamen gebunden. www.phpblogger.net ist dabei ein anderer Hostname als phpblogger.net (ohne www.) - man sollte sich also vorher gut überlegen, für welchen Hostnamen man ein Zertifikat benötigt. Es gibt auch Wildcard-Zertifikate, die verschiedene Subdomains zulassen. Wildcard-Zertifikate sind allerdings recht teuer.
- Pro Zertifikat wird eine IP-Adresse benötigt. Für ein Zertifikat benötigt man eine IP-Adresse (die auch mit nicht SSL-geschützten Seiten geteilt werden kann), für jedes weitere Zertifikat eine weitere IP-Adresse. Warum? Weil der SSL-Handshake auf IP-Basis stattfindet. Die Domain wird via DNS zur IP aufgelöst und dort wird direkt auf Port 443 der Handshake gestartet - ein Hostname wird dabei nicht übermittelt. Technisch ist es also nicht möglich mehrere Zertifikate unter einer IP laufen zu lassen, weil der Webserver nicht ermitteln kann, welches Zertifikat zu welcher Domain gehört.
- Um ein Zertifikat zu beantragen benötigt man einen Certificate Signing Request (CSR). Diese Datei wird auf dem Webserver generiert, der das SSL Zertifikat einsetzen möchte. Im Zuge der Generierung wird in der Regel gleich noch ein Key mit erzeugt. Der CSR wird an die ausstellende Behörde (CA) übermittelt, die daraus dann das Zertifikat (CRT) generiert.
- Wichtig: Die Key-Datei muss geheim bleiben und wird nicht an die CA übermittelt. SSL verwendet eine asynchrone Verschlüsselung. Die Key-Datei ist der private Key, während das Zertifikat der public Key ist, der für die Entschlüsselung (und umgekehrt) vom Browser verwendet wird.
- Beim Erstellen der CSR-Datei kann man ein Passwort (Passphrase) angeben - das muss dann jedes Mal beim Start des Webservers eingegeben werden. Mann muss aber nicht und spart sich dann den Act, ein Post-It an den Monitor zu kleben. *zwinker* Ist natürlich ne schlechte Idee.
- Zertifikat und Key muss man bei der SSL-Konfiguration angeben. Das CSR jedoch nicht. Je nach Server-Distribution kann es sein, das auch das CA-Zertifikat besorgt werden muss. Das bekommt man dann bei der ausstellenden Zertifizierungsstelle zum Download.
- Die Domains muss via DNS auf die selbe IP aufgelöst werden, unter der das Zertifikat ausgeliefert wird. Eigentlich eine Selbstverständlichkeit, wird aber trotzdem oft vergessen. Der Fehler, der dadurch unter anderem entstehen kann, heißt “(Fehlercode: ssl_error_rx_record_too_long)”
- Die Zertifikate sind Textdateien. Meist bekommt man die Zertifikate von der Zertifizierungsstelle oft inline in einer Textmail zugesendet. Um eine CRT-Datei daraus zu machen, erstellt man eine leere ASCII Text-Datei, kopiert alles von —–BEGIN CERTIFICATE—– bis —–END CERTIFICATE—– (die beiden BEGIN bzw. END Zeilen werden mitkopiert) und fügt das ganze in die leere Textdatei ein. Speichern, Hochladen fertig!
- Root bzw. CA-Zertifikate können ablaufen. Das war z.B. bei Verisign im Jahr 2004 mal so. Ich kann mich noch bestens daran erinnern: Dann wird das eigene SSL Zertifikat für ungültig erklärt, weil die Beweiskette durch das abgelaufene CA-Zertifikat unterbrochen wurde. Die Zertifikatshierarchie kann man sich übrigens in jedem Browser angucken. Im Firefox unter “Seiteninformationen” / “Sicherheit” / “Zertifikat anzeigen” / “Details”. Das CA-Zertifikat muss zum Bugfix auf dem Server gegen ein Neues ausgetauscht werden.
Zum Schluss noch ein paar nützliche Code-Schnipsel und Links, wenn man mit SSL-Zertifikaten arbeiten will oder muss:
Das Generieren eines CSR (Certificate Signing Request) mit OpenSSL:
openssl req -new -keyout my-domain_de.key -out my-domain_de.csr
Die SSL-Konfiguration testen mit dem s_client (gehört zu OpenSSL):
openssl s_client -connect my-domain_de:443
CA- bzw. Root-Zertifikate gibts hier:
z.B. von VeriSign, thawte (bekannt durch die günstigen 1-2-3 Zertifikate), GeoTrust und GlobalSign.
Auf dem Server vorinstallierte (CA-)Zertifikate:
- Debian: /etc/ssl/certs
- Fedora bzw. RedHat: /etc/httpd/conf/ssl.*
- SuSE / SLES: /etc/apache2/ssl.*
SSL-Pflichtlektüre in gedruckter Form:
Wer einen Apache mit SSL konfigurieren möchte, dem sei das Apache Kochbuch.
Wer gerne seine eigene Zertifizierungsstelle wäre, erfährt bei Werthmöller (wer das auch immer ist) recht anschaulich, wie es funktioniert.
Ähnliche Artikel:
