Blog of Manuel Manhart

A techie blog

IT, Web

Webseiten über HTTPS ausliefern mithilfe von Letsencrypt

Um eine Seite vollständig auf HTTPS umzustellen ist heutzutage nicht mehr viel notwendig. Mit letsencrypt existiert seit längerem ein Dienst, bei welchem man einfach, unkompliziert, automatisiert und sogar gratis domain validated Zertifikate erstellen kann.

Wie es funktioniert:

Inhalt

  1. Verzeichnis-Pfad für die Challenges
  2. Nginx Konfiguration (ssl & Zertifikate, .well-known)
  3. letsencrypt-bot & Beantragung des Zertifikats
  4. Erneuerung der Zertifikate
  5. Fazit
  6. Quellen

Hinweis: Ich gehe das ganze anhand des Beispiels cms.manhart.space durch.

Verzeichnis-Pfad für die Challenges

Wir benötigen einen Pfad, in welchem die Challenges abgelegt werden können. Dies hat den Vorteil, dass wir unabhängig von der tatsächlichen Konfiguration (zB proxy forward auf tomcat oder ähnliches) oder des Status des Zertifikats (zB ausgelaufen) immer ein erneuertes Zertifikat beantragen können.

Man legt hierzu im nginx docroot ein neues Verzeichnis an:

sudo mkdir -p /usr/share/nginx/html/letsencrypt/.well-known

und ändert den Owner auf den nginx User (in meinem Fall www-data)

sudo chown www-data:www-data -R /usr/share/nginx/www/letsencrypt

Es hat sich bewährt immer auch eine index.html Datei zum Prüfen anzulegen:

sudo echo "<html><body>Letsencrypt Challenge Testseite cms.manhart.space</body></html>" >/usr/share/nginx/www/letsencrypt/.well-known/index.html

Das reicht aus, damit letsencrypt seine Challenges unter diesem Pfad ablegt. Prüfen ob es korrekt funktioniert kann man, sobald die Nginx Konfiguration gemacht wurde.

Nginx Konfiguration (ssl & Zertifikate, .well-known)

Erstellen wir also eine simple nginx-Konfiguration mittels

sudo vim /etc/nginx/sites-available/cms.manhart.space

als Inhalt fügen wir folgendes ein:

server {
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/cms.manhart.space/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cms.manhart.space/privkey.pem;

root /usr/share/nginx/www/cms;
index index.html index.htm index.php;
server_name cms.manhart.space;

location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ /index.php?q=$request_uri;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
if ($request_uri ~* ".(jpg|jpeg|gif|gz|zip|flv|rar|wmv|avi|css|swf|png|htc|ico|mpeg|mpg|txt|mp3|mov|js)(\\?v=[0-9.]+)?$") {
expires 30d;
access_log off;
break;
}
}
}

# This is for redirection to https and letsencrypt renewal
server {
listen 80;
# the root is the parent directory of our previously created .well-known directory
root /usr/share/nginx/www/letsencrypt;
server_name cms.manhart.space;
# this is the important exclusion of .well-known, all other requests are redirected to https
location /.well-known/ {
}
# redirect all http requests to https
location / {
return 301 https://$host$request_uri;
}
}

Inhalt des ersten server {} Blocks ist die Konfiguration des Services, welches man über https anbieten möchte (in meinem Fall, mein php basiertes CMS)

Inhalt des zweiten server {} Blocks ist der Redirect aller http requests zu https mit Ausnahme aller Requests zu http://cms.manhart.space/.well-known/ und die Konfiguration zu unserem zuvor erstellten Verzeichnis.

Hinweis: Man muss das Verzeichnis oberhalb dem .well-known als root angeben, da es durch die URL (automatisch) diese tiefere Ebene erreicht.

Wenn wir nun die Konfiguration testen:

sudo nginx -t

und alles in Ordnung ist, können wir den nginx mittels

sudo service nginx restart

neu starten.

Nun rufen wir im Browser noch die URL http://cms.manhart.space/.well-known/ auf um zu prüfen ob wir unsere zuvor angelegte html Seite angezeigt bekommen. Wenn dies funktioniert, können wir noch den Gegencheck mit http://cms.manhart.space/ machen, welcher uns auch https://cms.manhart.space/ weiterleiten sollte.

letsencrypt-bot & Beantragung des Zertifikats

Danach installiert man sich den Certbot zB mittels

sudo apt-get install certbot

oder lädt ihn herunter. Danach kann man mittels folgendem Befehl ein Zertifikat generieren.

certbot-auto certonly --webroot -w /usr/share/nginx/www/letsencrypt -d cms.manhart.space

Damit wird im unter -w angegebenen Verzeichnis ein Challenge File erstellt, und vom Letsencrypt Server über die unter -d angegebene Domain gegengeprüft. Ist alles in Ordnung, wird das Zertifikat ausgestellt und am Server unter

/etc/letsencrypt/live/

abgelegt. Diese Art Zertifikate zu erstellen hat den Vorteil, dass der vorhandene Webserver genutzt werden kann, um die Challenge zu prüfen (dieser muss somit nicht gestoppt werden).

Da wir in unserer Nginx Konfiguration das SSL Zertifikat bereits angegeben haben, und auch nur noch HTTPS Verbindungen zu dieser Subdomain zulässt, ist bis das Zertifikat abläuft alles erledigt.

Erneuerung der Zertifikate

Ein welches mittes Webroot erstelltes letsencrypt Zertifikat ist recht einfach erneuert:

certbot-auto renew

Trägt man dieses nun noch als Cron Job ein, braucht man sich um das Zertifikat keine weiteren Gedanken mehr machen.

Fazit

Wir haben unsere Webseite mittels SSL Zertifikats eines renommierten Anbieters auf HTTPS umgestellt und liefern diese nun ausschliesslich verschlüsselt aus.

Dadurch, dass wir es mittels Cron Job alles 2 Wochen automatisch prüfen und ggf. erneuern lassen, ist es nach einmaliger Einrichtung wartungsfrei.

Durch die beschriebene Nutzung des webroot-Mechanismus, stört es auch nicht den Betrieb, da kein Server herunter gefahren werden muss.

Somit sind die einzigen entstehenden Kosten, die für die initiale Generierung investierte Zeit

Quellen

https://letsencrypt.org/getting-started/

https://certbot.eff.org/

Comments are Closed