PHPGangsta - Der praktische PHP Blog

Ab heute ist phpgangsta.de auch über https erreichbar. Wer also sicher gehen möchte dass er auch auf dem richtigen Server landet und keinen “Mann in der Mitte” zuhören kann ab jetzt auch https://www.phpgangsta.de besuchen.

Warum hat das eigentlich nicht jeder? Gäbe es keine Nachteile wäre das wohl so, aber normalerweise kosten SSL-Zertifikate Geld, viel Geld, je nachdem wieviele Funktionen das Zertifikat erfüllen soll. Es ist zwar auch möglich, sich selbst Zertifikate zu erstellen, dann bekommt der Benutzer jedoch eine Fehlermeldung zu dem selbst signierten Zertifikat, und das möchte man eigentlich seinen Usern nicht zumuten.

Es gibt aber auch kostenlose, von einer Certified Authority (CA) signierte Zertifikate, und genau solch eins habe ich hier nun installiert. Wie man ein solches Zertifikat von StartSSL bekommt könnt ihr im Heise-Artikel “SSL für lau” nachlesen. Es gibt natürlich auch noch weitere Anbieter, zB CaCert.

Danach haben wir also 3 Dateien:

• Ein Zertifikat für die Domain (hier phpgangsta.de.crt)
• Eine Datei mit dem privaten Key(hier phpgangsta.de.key)
• Ein sogenanntes Intermediate Zertifikat, auch Chain-Certificate oder Kettenzertifikat genannt (hier sub.class1.server.ca.pem)

Nachdem man ein solches Zertifikat erhalten hat, muss man es noch im Webserver installieren. Ich gebe hier 2 Anleitungen, einmal für den Apache2 und einmal für nginx.

Der Apache2 benötigt zuerst einmal SSL-Support, dazu sollte man das entsprechende Modul installieren:

sudo a2enmod ssl

Dann benötigen wir einen zusätzlichen VirtualHost, der die SSL-Verbindungen entgegennimmt. Darin definieren wir auch die Pfade zu den Zertifikaten:

<VirtualHost 85.214.28.26:443>
  ServerName phpgangsta.de
  ServerAlias www.phpgangsta.de php-gangsta.de www.php-gangsta.de
  ServerAdmin username@gmx.de
  DocumentRoot "/path/to/phpgangsta/wordpres/"

  SSLEngine On
  SSLCertificateFile /etc/apache2/ssl/phpgangsta.de.crt
  SSLCertificateKeyFile /etc/apache2/ssl/phpgangsta.de.key
  SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem

<hier noch viele Anweisungen zum Logging, safe-mode, open_basedir, deflate, expires usw.>
</VirtualHost>

Nach dem Ändern der Apache-Konfigration benötigen wir natürlich noch einen Restart des Dienstes:

sudo /etc/init.d/apache2 configtest
sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 start

Danach sollte die Domain auch verschlüsselt zur Verfügung stehen.

Im nginx geht es ähnlich einfach:

Um SSL nutzen zu können muss nginx mit dem configure-Parameter –with-http_ssl_module kompiliert sein. Dann fügt man einen weiteren VHost hinzu, ähnlich wie im Apache:

server {
        listen       443 ssl;
        server_name  www.phpgangsta.de php-gangsta.de www.php-gangsta.de;

        ssl_certificate      /etc/apache2/ssl/phpgangsta.de.crt;
        ssl_certificate_key  /etc/apache2/ssl/phpgangsta.de.key;

        ssl_session_timeout  5m;

        ssl_protocols  SSLv3;
        ssl_ciphers HIGH:!ADH:!MD5;
        ssl_prefer_server_ciphers   on;

        keepalive_timeout    70;

        location / {
             proxy_pass http://backendwebserverupstream;
        }
}

Wie man sieht ist das hier ein Reverse-Proxy-VHost, der die SSL-Verbindung terminieren soll. Auch fällt auf, dass man hier nur 2 Angaben machen muss, es fehlt das Intermediate-Certificate. Das muß man beim nginx an das Domain-Zertifikat anhängen:

cat /etc/apache2/ssl/sub.class1.server.ca.pem >> phpgangsta.de.crt

Dann noch den nginx neustarten und alles ist wunderbar:

sudo /etc/init.d/nginx configtest
sudo /etc/init.d/nginx restart

Bei der Recherche zu nginx (ich habe mal das Mail-Proxy-Modul ausprobiert, funktioniert super auf den ersten Blick!) bin ich über diese Seite bei Calomel gestossen, die ich unbedingt weiterempfehlen möchte, eine schöne umfangreiche Seite die noch einige Informationen bereithält, die das nginx-Wiki nicht bietet.

Ein Problem gab es bei WordPress allerdings noch: Wenn man die Seite über https aufgerufen hat, waren die Links darin noch http://… Das konnte ich jedoch relativ einfach durch das Addon HTTPS for WordPress lösen, dann werden die Links alle korrigiert. Hätten WordPress und die ganzen Addons diese “absoluten URLS” nicht benutzt hätte es das Problem auch nicht gegeben.

Keine ähnlichen Artikel.