letsencrypt...

...ist ja gerade der heiße scheiß. ich musste das natürlich auch sofort ausprobieren. dank meiner relativ komplexen infrastruktur blieb mir bisher nur mein gitlab server bei dem ich es sinnvoll testen konnte.

Gitlab läuft bei mir nicht hinter seinem eingebauten nginx sondern hinter meinem weil da noch mehr dinge laufen und so.

Ich traue letsencrypt aber noch nicht genug um es an meiner nginx config rum pfuschen zu lassen, daher habe ich das folgendermaßen gelöst.

bisher habe ich so alle requests auf https umgeleitet:

server {
    listen 80;
    listen [::]:80;
    server_name git.example.com;
    server_tokens off;
    return 301 https://git.example.com;
}

nachdem letsencrypt ja prüfen muss, ob ich wirklich zugriff auf die domain habe, möchte es dinge in das webdir legen (oder einen eigenen http server starten). das funktioniert so nicht weil diese überprüfung natürlich nicht über https stattfindet und auf http ja der redirect läuft. deswegen:

server {
    listen 80;
    listen [::]:80;
    server_name git.example.com;
    server_tokens off;
    root /var/www/letsencrypt_magic;
    location / {
        try_files $uri @router;
    }
    location @router {
        rewrite ^(.*)$ https://git.example.com;
    }
}

dadurch können alle dateien abgerufen werden, die sich im entsprechenden webroot befinden. alles andere wird umgeleitet.

letsencrypt dann in etwa so:

letsencrypt-auto certonly --webroot --renew-by-default --text --email admin@example.com --webroot-path /var/www/letsencrypt_magic/ --domain git.example.com

und im virtual host für gitlab dann entsprechend den pfad zum zertifikat anpassen:

  ssl on;
  ssl_certificate /etc/letsencrypt/live/git.example.com/cert.pem;
  ssl_certificate_key /etc/letsencrypt/live/git.example.com/privkey.pem;

dann noch nginx neu starten und glücklich sein.

fröhliches Verschlüsseln.