PHP Blogger

Startseite Schreib mir ne Mail! RSS Abo Webnews

Wissenswertes über SSL und HTTPS

*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. empfohlen. Ohnehin eine Pflichtlektüre für Admins, die viel mit dem Apache machen (möchten).

Wer gerne seine eigene Zertifizierungsstelle wäre, erfährt bei Werthmöller (wer das auch immer ist) recht anschaulich, wie es funktioniert.

Ähnliche Artikel:

  1. Port-Fetischismus oder dirty Games mit Ports

Alphager meint dazu:

14. Dezember 2009 um 13:56

Der Punkt “Pro Zertifikat wird eine IP-Adresse benötigt.” stimmt so nicht zu 100%.
Es gibt SNI (http://en.wikipedia.org/wiki/Server_Name_Indication), was das Problem löst. Leider weigert sich Microsoft, SNI auf Windows XP zu portieren; solange also noch viele XP-Maschinen unterwegs sind macht es noch nicht wirklich SInn, SNI einzusetzen.

timi meint dazu:

14. Dezember 2009 um 14:06

Hey Alphager, weil es eben weder 100% praktikabel noch etablierter Standard ist, habe ich das Thema schlicht übergangen.

Trotzdem danke für den Hinweis - wir wollen ja vollständig bleiben!

Frank meint dazu:

15. Dezember 2009 um 10:38

Leider ist SNI derzeitig noch nicht flächendeckend in den Distributionen verfügbar.

Eine 3. Möglichkeit: Man kann mehrere Zertifikate unter einer IP laufen lassen - vorausgesetzt die Ports unterscheiden sich. Sicherlich nicht für jedes Projekt praktikabel aber u. U. erspart man sich ein Zertifikat. Allerdings sollte man die Lizenzbedingungen des Zertifikats im Auge behalten.

timi meint dazu:

15. Dezember 2009 um 17:44

@Frank: Gebe Dir da ganz Recht. Ich glaube ich bin allerdings Port-Fetischist und stehe auf saubere URLs - ein “hässlicher” Port geht da gar nicht… Aber rein technisch ist es natürlich möglich!

PHP Blogger: Port-Fetischismus oder dirty Games mit Ports - Ein PHP Blog auf deutsch meint dazu:

17. Dezember 2009 um 10:02

[...] Schöne Portangaben, sind nicht vorhandene Portangaben. Aber wie ein aufmerksamer Leser im Artikel zu HTTPS und SSL richtig angemerkt hat, kann man über verschiedene Ports unter ein und derselben IP mehrere [...]

lautsprecher thx meint dazu:

8. April 2010 um 09:10

Haben Sie jemals mit Wildcard SSL behandelt? Es löst viele der Negative, die Sie in Ihrem Beitrag beziehen.

Stereo Kopfhörer meint dazu:

8. April 2010 um 09:12

Das erinnert mich an. Empfehlen Sie 256bit SSL-Zertifikate überhaupt? Was sind die besten angewendet?

Der PHP-Community Watch #2 | PHP hates me - Der PHP Blog meint dazu:

16. April 2010 um 07:12

[...] und Datenbankabstraktionen – wie? Local-Testing-Live System Debug Ausgaben im Code vergessen? Wissenswertes über SSL und HTTPS Zend langsamer als Amfphp? Der Dinosaurier PHP Wann kommt PHP6 [...]

In-Ear-Kopfhörer meint dazu:

16. Juli 2010 um 11:33

Wie sieht es eigentlich mit SSL und IP V6 aus? Der IP-Adressraum für Zertifikate wird immer geringer, während ich persönlich inzwischen immer häufiger Zertifikats-Nutzung sehe. Leider fallen mir auch häufig abgelaufene Zitate auf, dort scheinen sich weder die Seitenbetreiber noch die Kunden sich ausreichend mit dem Thema auseinanderzusetzen.

Chrissi Drallmann meint dazu:

16. August 2010 um 11:53

Finde das Thema echt total langweilig, aber wenn du darüber schreibst geht es sogar, das ist echt ein Kompliment ;) Schon in früheren Informatik Vorlesungen konnte ich nicht einmal zuhören.

MP3 meint dazu:

7. September 2010 um 20:27

In der heutigen Zeit ist SSL ein wichtiger Punkt im Internet und man sollte darauf achten, dass eine Seite dies nutzt.

Schläfer meint dazu:

22. September 2010 um 14:19

Das schlaf ich glatt mit ein. Wie sehr hasse ich es sich durch dieses Thema durchzuackern. Dabei habe ich früher oftmals das ein oder andere graue Haar dazubekommen.
Nun funktioniert wenigsten alles. Aber gut geschrieben.

Christian meint dazu:

16. Februar 2011 um 18:54

Es steht ja wohl außer Frage ob man SSL braucht oder nicht,
melde ich mich bei meinem Paypal Account an und jeder der die Leitung anzapft kann mitlesen, ist das nichts sicher, also ist Paypal notwendig.

reifrund meint dazu:

19. Februar 2011 um 18:52

PayPal ist schon ein ganz günstiger Dienst. Allerdings nerven die auch schnell mit Spam, wenn man sein Konto eine längere Zeit ruhen lässt. An sich schon eine sinnvolle Dienstleistung, aber dieser Spam nervt mich. Deshalb habe ich PayPal auch generell auf meiner Spam-Liste … ;-)

Timo meint dazu:

1. April 2011 um 16:02

Wirklich ein langweiliges Thema, leider muss ich mich damit gerade im Studium befassen. Dein Artikel hat es mir ein wenig verständglicher gemacht. Unser Dozent hat es zumindest nicht geschafft. Dank dir!

Caro meint dazu:

24. August 2011 um 11:41

@reifrund: Wie kommt man denn beim Thema SSL und HTTPS auf die Idee, einen (zugegebenermaßen richtigen) Kommentar über Paypal zu schreiben? /-)

WatchBlog-TV meint dazu:

31. Oktober 2011 um 20:12

Danke für den interessanten Artikel zum Thema SSL und HTTPS. Ich beschäftige mich auch gerade mit dem Thema, da kam das Thema gerade recht ;) Gruß, Lars

wawi meint dazu:

21. November 2011 um 13:25

vielen dank für den Artikel - der hat mir sehr weitergeholfen! endlich hab ich das mal verstanden!

Markus meint dazu:

22. November 2011 um 11:28

Naja, ich verstehe es immer noch nicht ganz,

aber trotzdem Danke für den Versuch. Muss mich leider damit heute auch beschäftigen, wenigstens weiß ich jetzt mehr.

Danke!

Vlad meint dazu:

15. September 2012 um 11:15

Klingt vielleicht zunächst mal langweilig, aber die wenigsten wissen ausreichend über https bescheid….

RSS für Kommentare zu diesem Artikel · TrackBack URI

Schreib Deine Meinung