Skip to content

Let'sEncrypt auf Debian-Server einbauen

Verschoben Let's Encrypt
  • Dieses Beispiel bezieht sich auf einen Debian-Server auf dem NodeBB einwandfrei läuft. Der Hostname ist erreichbar und alles läuft. Ich nutze eine Redis-DB und Nginx als Proxy.

    Installation Let'sEncrypt

    Nach dieser Anleitung -> https://willy-tech.de/ssl-zertifikat-mit-lets-encrypt-erstellen/

    Zertifikat erzeugen

    Nginx stoppen

    root@one /opt/letsencrypt # /etc/init.d/nginx stop
    [ ok ] Stopping nginx (via systemctl): nginx.service.
    

    Zertifikate erzeugen

    root@one /opt/letsencrypt # ./letsencrypt-auto certonly --standalone -d frank-mankel.org -d www.frank-mankel.org
    Saving debug log to /var/log/letsencrypt/letsencrypt.log
    Plugins selected: Authenticator standalone, Installer None
    Obtaining a new certificate
    Performing the following challenges:
    http-01 challenge for frank-mankel.org
    http-01 challenge for www.frank-mankel.org
    Waiting for verification...
    Cleaning up challenges
    
    IMPORTANT NOTES:
    - Congratulations! Your certificate and chain have been saved at:
       /etc/letsencrypt/live/frank-mankel.org/fullchain.pem
       Your key file has been saved at:
       /etc/letsencrypt/live/frank-mankel.org/privkey.pem
       Your cert will expire on 2018-07-13. To obtain a new or tweaked
       version of this certificate in the future, simply run
       letsencrypt-auto again. To non-interactively renew *all* of your
       certificates, run "letsencrypt-auto renew"
     - If you like Certbot, please consider supporting our work by:
    
       Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
       Donating to EFF:                    https://eff.org/donate-le
    

    Das hat schon mal geklappt!!

    Hier liegen jetzt die Zertifikate:

    /etc/letsencrypt/live/frank-mankel.org
    

    Dort liegen jetzt folgende Files:

    root@one /etc/letsencrypt/live/frank-mankel.org # ls -l
    total 4
    lrwxrwxrwx 1 root root  40 Apr 14 15:15 cert.pem -> ../../archive/frank-mankel.org/cert1.pem
    lrwxrwxrwx 1 root root  41 Apr 14 15:15 chain.pem -> ../../archive/frank-mankel.org/chain1.pem
    lrwxrwxrwx 1 root root  45 Apr 14 15:15 fullchain.pem -> ../../archive/frank-mankel.org/fullchain1.pem
    lrwxrwxrwx 1 root root  43 Apr 14 15:15 privkey.pem -> ../../archive/frank-mankel.org/privkey1.pem
    -rw-r--r-- 1 root root 543 Apr 14 15:15 README
    

    Die bauen wir jetzt in Nginx ein!

    Nginx konfigurieren

    Nginx stoppen:

    /etc/init.d/nginx stop
    

    Meine alte Nginx Datei OHNE https:

    server {
    if ($host != 'frank-mankel.org' ) {
    rewrite ^/(.*)$ http://frank-mankel.org/$1 permanent;
    }
    
    listen 80;
    
    server_name frank-mankel.org;
    
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
    
        proxy_pass http://127.0.0.1:4567;
        proxy_redirect off;
    
        # Socket.IO Support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
     }
    }
    

    Neue Datei mit https!!

    ### redirects http requests to https
    
    server {
        server_name  www.frank-mankel.org;
        rewrite ^(.*) http://frank-mankel.org$1 permanent;
    }
    
    
    
    server {
        listen 80;
        server_name frank-mankel.org;
        return 302 https://$server_name$request_uri;
    }
    
    ### the https server
    server {
        # listen on ssl, deliver with speedy if possible
        listen 443 ssl spdy;
    
        server_name frank-mankel.org;
    
    
        # change these paths!
        ssl_certificate /etc/letsencrypt/live/frank-mankel.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/frank-mankel.org/privkey.pem;
    
        # enables all versions of TLS, but not SSLv2 or 3 which are weak and now deprecated.
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    
        # disables all weak ciphers
        ssl_ciphers 'AES128+EECDH:AES128+EDH';
    
        ssl_prefer_server_ciphers on;
    
        location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header Host $http_host;
            proxy_set_header X-NginX-Proxy true;
    
            proxy_pass http://127.0.0.1:4567;  # no trailing slash
            proxy_redirect off;
    
            # Socket.IO Support
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
    }
    

    Der Ganze http Verkehr wird nach https umgeleitet.

    Als allererstes strippen wir www aus dem Namen.

    if ($host != 'frank-mankel.org' ) {
    rewrite ^/(.*)$ http://frank-mankel.org/$1 permanent;
    }
    

    Der Rest entspricht der Nginx Doku!

    Jetzt bauen wir das Zertifikat ein. Pfade anpassen.

    # change these paths!
        ssl_certificate /etc/letsencrypt/live/frank-mankel.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/frank-mankel.org/privkey.pem;
    

    Danach speichern und Nginx wieder starten

    /etc/init.d/nginx start  
    

    Alles Testen und schauen ob alles funktioniert. Das Let'sEncrypt Zertifikat läuft nur 90 Tage, danach muss es erneuert werden! Also legen wir uns einen crontab an

    Crontab einrichten (Zur Zeit habe ich keine Ahnung ob das funktioniert)

    crontab -e
    

    Wir fügen folgende Zeile hinzu.

    * 3  1 * * certbot renew --pre-hook "service nginx stop" --post-hook "service nginx start"
    

    Speichern das Ganze und hoffen, das es funktioniert 😉

    Bei einem Test kam folgendes:

    root@one /opt/letsencrypt # certbot renew --dry-run --pre-hook "service nginx stop" --post-hook "service nginx start"
    Saving debug log to /var/log/letsencrypt/letsencrypt.log
    
    -------------------------------------------------------------------------------
    Processing /etc/letsencrypt/renewal/frank-mankel.org.conf
    -------------------------------------------------------------------------------
    Attempting to parse the version 0.23.0 renewal configuration file found at /etc/letsencrypt/renewal/frank-mankel.org.conf with version 0.10.2 of Certbot. This might not work.
    Cert not due for renewal, but simulating renewal for dry run
    Running pre-hook command: service nginx stop
    Renewing an existing certificate
    Performing the following challenges:
    http-01 challenge for frank-mankel.org
    http-01 challenge for www.frank-mankel.org
    Waiting for verification...
    Cleaning up challenges
    Generating key (2048 bits): /etc/letsencrypt/keys/0002_key-certbot.pem
    Creating CSR: /etc/letsencrypt/csr/0002_csr-certbot.pem
    ** DRY RUN: simulating 'certbot renew' close to cert expiry
    **          (The test certificates below have not been saved.)
    
    Congratulations, all renewals succeeded. The following certs have been renewed:
      /etc/letsencrypt/live/frank-mankel.org/fullchain.pem (success)
    ** DRY RUN: simulating 'certbot renew' close to cert expiry
    **          (The test certificates above have not been saved.)
    Running post-hook command: service nginx start
    

    Das --dry-run macht nur einen Testlauf ohne was zu ändern!!

    Wer was zu der Zeile "Attempting to parse the version 0.23.0 renewal ....." sagen kann, immer her damit. Die Zeile ist rot eingefärbt!

    Quelle: https://certbot.eff.org/docs/using.html#renewal

  • 0 Stimmen
    1 Beiträge
    85 Aufrufe
    Niemand hat geantwortet
  • Crowdsec - Ein fail2ban Ersatz?

    Linux
    2
    0 Stimmen
    2 Beiträge
    486 Aufrufe
    FrankMF

    Ich kann jetzt hier von meiner ersten Erfahrung berichten und wie CrowdSec mich gebannt hat 🙂

    Was war passiert? Ich war gestern sehr intensiv mit der Konfiguration von Nextcloud <-> Collabora Online beschäftigt. Nachdem ich irgendwie nicht weiterkam habe ich mich der Erstellung eines Dokumentes gewidmet. Nach einiger Zeit war die Nextcloud nicht mehr erreichbar.

    Ok, hatte ich bei der Konfiguration auch schon mal, den Server einmal neugestartet und fertig. Doch jetzt kam es, Server neugestartet - hilft nicht. Gut, schauen wir mal nach, Der SSH Login ging auch nicht 😞

    Jetzt war guter Rat gefragt. Zu diesem Zeitpunkt ging ich noch davon aus, das auf diesem Server kein CrowdSec installiert war, sondern fail2ban. Und fail2ban hatte eine sehr kurze Bantime vom 10M.

    Also blieb wohl nur noch das Rescue System von Hetzner.

    488866bc-3dcf-4abc-9e98-6107d65aa4c7-grafik.png

    Da hatte ich ja so gut wie gar keine Erfahrung mit. Also mal kurz den Nico angetriggert und es kam folgender Link.

    Link Preview Image Hetzner Rescue-System - Hetzner Docs

    favicon

    (docs.hetzner.com)

    Das Laufwerk war schnell bestimmt und schnell nach /tmp gemountet. Danach musste man sich noch mit chroot in diese Umgebung anmelden.

    chroot-prepare /mnt chroot /mnt

    Nachdem das klappte, habe ich eben fail2ban disabled.

    sysmctl disable fail2ban

    Danach das Rescue beendet. Der Server startete wieder und ich kam wieder per SSH drauf. Puuh.
    Bei meiner ersten Kontrolle fiel mir was auf

    root@:~# pstree systemd─┬─2*[agetty] ├─atd ├─cron ├─crowdsec─┬─journalctl │ └─8*[{crowdsec}] ├─crowdsec-firewa───9*[{crowdsec-firewa}]

    Wie? Da läuft CrowdSec? Da ich dabei bin die Server auf CrowdSec umzustellen, war das wohl hier schon gemacht, aber leider nicht vernünftig. fail2ban hätte mindestens disabled werden müssen und in meiner Dokumentation war das auch nicht enthalten. 6 setzen!

    CrowdSec besteht ja aus zwei Diensten, CrowdSec und dem Firewall-Bouncer. Der CrowdSec Dienst lief aber nicht, der war irgendwie failed. Ok, starten wir ihn und schauen was passiert. Nachdem er gestarte war mal die Banliste angeschaut.

    cscli decisions list

    ergab diesen Eintrag.

    2551501 │ crowdsec │ Ip:5.146.xxx.xxx │ crowdsecurity/http-crawl-non_statics │ ban │ │ │ 53 │ 1h5m55.391864693s │ 1671

    Meine IP war gebannt. Dann wissen wir ja , woher die Probleme kamen.

    cscli decisions delete --id 2551501

    Nach Eingabe war der Ban entfernt. Na gut, aber da ich aktuell immer noch an der richtigen Konfiguration von NC <-> CODE bastel, könnte das ja wieder passieren. Was machen? Kurz gegoogelt. Es gibt eine Whitelist. Aha!

    /etc/crowdsec/parsers/s02-enrich/whitelists.yaml

    name: crowdsecurity/whitelists description: "Whitelist events from private ipv4 addresses" whitelist: reason: "private ipv4/ipv6 ip/ranges" ip: - "127.0.0.1" - "::1" - "5.146.XXX.XXX" cidr: - "192.168.0.0/16" - "10.0.0.0/8" - "172.16.0.0/12" # expression: # - "'foo.com' in evt.Meta.source_ip.reverse"

    Danach den Dienst neustarten. Jetzt hoffen wir mal, das es hilft.

    Zum Schluss noch was, was mir aufgefallen war und was mich auch sehr verwirrt hatte. CrowdSec hatte wegen einem crowdsecurity/http-crawl-non_statics gebannt. Dadurch konnte ich meine
    subdomain.<DOMAIN> nicht erreichen. Ok, logisch, wenn der Ban von da ausgeht. Ich konnte aber gleichzeitig eine andere subdomain mit derselben <DOMAIN> auch nicht erreichen. Komplett verwirrte es mich dann, als ich eine andere <DOMAIN> auf dem selben Server erreichen konnte. Und zum Schluss ging auch der SSH nicht.

    Also, wieder viel gelernt.. 🤓

  • Passkeys

    Linux
    2
    0 Stimmen
    2 Beiträge
    167 Aufrufe
    FrankMF

    Passend dazu aus dem Bitwarden Blog

    Link Preview Image Bitwarden to launch passkey management | Bitwarden Blog

    Welcome, passkeys – FIDO credentials stored directly on your phone or computer.

    favicon

    Bitwarden (bitwarden.com)

  • Star64 - UART

    Hardware
    1
    0 Stimmen
    1 Beiträge
    38 Aufrufe
    Niemand hat geantwortet
  • Let's Encrypt - acme.sh

    Verschoben Let's Encrypt
    6
    0 Stimmen
    6 Beiträge
    212 Aufrufe
    FrankMF

    Der Monat ist um, es war Zertifikatsmonat. Und nichts lief mehr..... 😞

    Was war passiert?

    Sonntags mache ich von meinem Haupt-PC ein Backup (per Hand) mittels Restic auf meinen Rest-Server. Doch ich bekam eine Fehlermeldung, blabla Zertifikat usw.

    Ok, ab auf den Server und mit der Fehlersuche gestartet. Das Zertifikat war erneuert worden, aber der Restart Command versuchte immer eine server.service zu starten, die es gar nicht gab!?

    Da musste ich doch beim @Nico mal kurz nachfragen. Und das kam dann dabei raus.

    Fehlerursache

    Der ReloadCmd versuchte einen server.service zu restarten, den es gar nicht gibt.

    Suche

    Im acme Pfad liegen die Ordner für die Domains. In diesem Ordner liegt eine Datei DOMAIN.conf

    In dieser Datei werden bei der Installation des Zertfikiates eine Reihe von Dingen eingetragen.

    Le_Domain='DOMAIN' Le_Alt='no' Le_Webroot='no' Le_PreHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v02.api.letsencrypt.org/directory' Le_Keylength='2048' Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/<ID>' Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/<ID>' Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/>ID>' Le_CertCreateTime='1680440374' Le_CertCreateTimeStr='2023-04-02T12:59:34Z' Le_NextRenewTimeStr='2023-05-31T12:59:34Z' Le_NextRenewTime='1685537974' Le_RealCertPath='/mnt/rest-server/DOMAIN/cert.pem' Le_RealCACertPath='' Le_RealKeyPath='/mnt/rest-server/DOMAIN/key.pem' Le_ReloadCmd='__ACME_BASE64__START_c3lzdGVtY3RsIHJlc3RhcnQgc2VydmVyLnNlcnZpY2U=__ACME_BASE64__END_' Le_RealFullChainPath='/mnt/rest-server/DOMAIN/fullchain.pem'

    Ok, da ist der ReloadCmd, aber der ist base64 kodiert!? Was machen.

    # echo c3lzdGVtY3RsIHJlc3RhcnQgc2VydmVyLnNlcnZpY2U= | base64 -d systemctl restart server.service

    Ok, hier sehen wir die fehlerhafte Eintragung, die genau meinem Beispiel oben entspricht (unter Installation Zertifikat) Man könnte jetzt die Installation des Zertifikates mit dem korrigierten EIntrag durchführen, oder diese Base64 Zeile korrigieren. Ok, wie geht das?

    # echo systemctl restart rest-server.service | base64 c3lzdGVtY3RsIHJlc3RhcnQgcmVzdC1zZXJ2ZXIuc2VydmljZQo=

    Diese Ausgabe kopieren wir dann in die Konfigurationsdatei. Kurze Kontrolle

    # echo c3lzdGVtY3RsIHJlc3RhcnQgcmVzdC1zZXJ2ZXIuc2VydmljZQo= | base64 -d systemctl restart rest-server.service

    Passt 😊 Und wieder jede Menge gelernt. Danke @Nico

  • Redis - Datenbanken löschen

    Redis
    1
    0 Stimmen
    1 Beiträge
    135 Aufrufe
    Niemand hat geantwortet
  • Mainline 5.13.x

    Images
    1
    0 Stimmen
    1 Beiträge
    176 Aufrufe
    Niemand hat geantwortet
  • Let's Encrypt - Crontab

    Let's Encrypt
    1
    0 Stimmen
    1 Beiträge
    204 Aufrufe
    Niemand hat geantwortet