letsencrypt - unable to install the certificate

  • Hallo zusammen,

    ich hoffe mir kann, mal wieder, jemand hier weiterhelfen. Ich bin im Begriff ein letsencrypt Zertifikat auf meinem VServer mit folgender Software zu installieren.


    Software:

    • Ubuntu 18.4
    • apache2
    • Nextcloud 21
    • phpmyadmin
    • mysql 8
    • php 7.3
    • utw firewall (Freigabe in SSH, HTTP, HTTPS)
    • certbot
    • und ein paar kleinen Erweiterungen


    Beim Installieren des Zertifikats schlägt mir nun der folgender Fehler entgegen:


    - Unable to install the certificate

    - Congratulations! Your certificate and chain have been saved at:

    /etc/letsencrypt/live/de/fullchain.pem

    Your key file has been saved at:

    /etc/letsencrypt/live/de/privkey.pem

    Your cert will expire on 2021-08-17. To obtain a new or tweaked

    version of this certificate in the future, simply run certbot again

    with the "certonly" option. To non-interactively renew *all* of

    your certificates, run "certbot renew"


    Folgendes habe ich schon Versucht:

    • Zertifikat löschen und neu anlegen
    • VHost file erneuert


    Villeicht kann mir ja einer von euch weiterhelfen oder hatte evtl. schon den selben Fehler.


    Viele Grüße,

    Lucas

  • Ich verwende certbot nicht, aber wie es aussieht, wurden die Zertifikate wie gewünscht erzeugt und abgerufen. Was scheitert, ist die versuchte Aktualisierung der "VHost"-Definition. Dafür kann es eine Reihe von Ursachen geben: Etwa fehlende Zugriffsrechte durch certbot oder nicht-zuzuordnende "VHost"-Definitionen für Zertifikate (falls es mehrere gibt).

    Enthält die Apache2-Konfiguration denn schon Direktiven für die TLS-Unterstützung (angefangen bei Bedienung von Port 443 bis zur Einbindung der beiden Zertifikatsdateien mittels SSLCertificateKeyFile und SSLCertificateFile)?

    Die entsprechende Fehlermeldung wurde auch mehrfach in den LetsEncrypt-Diskussionsforen diskutiert, da könnte sich eine entsprechende Suche lohnen.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Hallo m_ueberall,

    erst einmal Danke für die schnelle Antwort.

    Ich verwende certbot nicht, aber wie es aussieht, wurden die Zertifikate wie gewünscht erzeugt und abgerufen. Was scheitert, ist die versuchte Aktualisierung der "VHost"-Definition. Dafür kann es eine Reihe von Ursachen geben: Etwa fehlende Zugriffsrechte durch certbot oder nicht-zuzuordnende "VHost"-Definitionen für Zertifikate (falls es mehrere gibt).

    Wo wird denn die "VHost"-Definition gespeichert und was müsste hier aktualisiert werden, ich persönlich tippe auch auf fehlende Berechtigungen.


    Enthält die Apache2-Konfiguration denn schon Direktiven für die TLS-Unterstützung (angefangen bei Bedienung von Port 443 bis zur Einbindung der beiden Zertifikatsdateien mittels SSLCertificateKeyFile und SSLCertificateFile)?

    Wo sollte denn im normal Fall der Speicherort für diese Direktiven sein?


    Entschuldige die evtl. Unwissenheit.


    Liebe Grüße,

    Lucas

  • Wo wird denn die "VHost"-Definition gespeichert und was müsste hier aktualisiert werden, ich persönlich tippe auch auf fehlende Berechtigungen.

    Wo sollte denn im normal Fall der Speicherort für diese Direktiven sein?

    Normalerweise findet man alles unterhalb von /etc/apache2/ – Ein Aufruf von apachectl -S (ggf. gefolgt von -D DUMP_INCLUDES) auf der Kommandozeile listet aber auf, welche Definitionen konkret von apache2 verwendet werden (inklusive Dateinamen).

    Je nachdem, wie der zuerst erwähnte Schritt der Neuerstellung der "VHost-Datei" durchgeführt wurde, kann es natürlich sein, dass dies unter Verwendung eines Hilfsprogramms geschehen ist, welches andere Verzeichnisse zur Verwaltung verwenden kann (ich lese das so, dass die Datei nicht händisch kopiert/editiert wurde, sonst wäre die Frage nach dem "Wo" oben ja unlogisch):

    Folgendes habe ich schon Versucht:

    • […] VHost file erneuert

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Hallo,

    Normalerweise findet man alles unterhalb von /etc/apache2/ – Ein Aufruf von apachectl -S (ggf. gefolgt von -D DUMP_INCLUDES) auf der Kommandozeile listet aber auf, welche Definitionen konkret von apache2 verwendet werden (inklusive Dateinamen).

    Die geannten Befehle gaben das folgende aus (Soweit ich das ruaslesen aknn fehlen die gewünschten Dateien. Kann ich diese manuell erstellen und wenn ja wießt du auch wie?):


    Included configuration files:

    (*) /etc/apache2/apache2.conf

    (146) /etc/apache2/mods-enabled/access_compat.load

    (146) /etc/apache2/mods-enabled/alias.load

    (146) /etc/apache2/mods-enabled/auth_basic.load

    (146) /etc/apache2/mods-enabled/authn_core.load

    (146) /etc/apache2/mods-enabled/authn_file.load

    (146) /etc/apache2/mods-enabled/authz_core.load

    (146) /etc/apache2/mods-enabled/authz_host.load

    (146) /etc/apache2/mods-enabled/authz_user.load

    (146) /etc/apache2/mods-enabled/autoindex.load

    (146) /etc/apache2/mods-enabled/deflate.load

    (146) /etc/apache2/mods-enabled/dir.load

    (146) /etc/apache2/mods-enabled/env.load

    (146) /etc/apache2/mods-enabled/filter.load

    (146) /etc/apache2/mods-enabled/mime.load

    (146) /etc/apache2/mods-enabled/mpm_prefork.load

    (146) /etc/apache2/mods-enabled/negotiation.load

    (146) /etc/apache2/mods-enabled/php7.3.load

    (146) /etc/apache2/mods-enabled/proxy.load

    (146) /etc/apache2/mods-enabled/proxy_fcgi.load

    (146) /etc/apache2/mods-enabled/reqtimeout.load

    (146) /etc/apache2/mods-enabled/setenvif.load

    (146) /etc/apache2/mods-enabled/status.load

    (147) /etc/apache2/mods-enabled/alias.conf

    (147) /etc/apache2/mods-enabled/autoindex.conf

    (147) /etc/apache2/mods-enabled/deflate.conf

    (147) /etc/apache2/mods-enabled/dir.conf

    (147) /etc/apache2/mods-enabled/mime.conf

    (147) /etc/apache2/mods-enabled/mpm_prefork.conf

    (147) /etc/apache2/mods-enabled/negotiation.conf

    (147) /etc/apache2/mods-enabled/php7.3.conf

    (147) /etc/apache2/mods-enabled/proxy.conf

    (147) /etc/apache2/mods-enabled/reqtimeout.conf

    (147) /etc/apache2/mods-enabled/setenvif.conf

    (147) /etc/apache2/mods-enabled/status.conf

    (150) /etc/apache2/ports.conf

    (222) /etc/apache2/conf-enabled/charset.conf

    (222) /etc/apache2/conf-enabled/localized-error-pages.conf

    (222) /etc/apache2/conf-enabled/other-vhosts-access-log.conf

    (222) /etc/apache2/conf-enabled/php7.2-fpm.conf

    (222) /etc/apache2/conf-enabled/phpmyadmin.conf

    (222) /etc/apache2/conf-enabled/security.conf

    (222) /etc/apache2/conf-enabled/serve-cgi-bin.conf

    (225) /etc/apache2/sites-enabled/000-default.conf

    (225) /etc/apache2/sites-enabled/cloud.bitzeit.de.conf

    VirtualHost configuration:

    *:80 is a NameVirtualHost

    default server v2202105101314153876.goodsrv.de (/etc/apache2/sites-enabled/000-default.conf:1)

    port 80 namevhost v2202105101314153876.goodsrv.de (/etc/apache2/sites-enabled/000-default.conf:1)

    port 80 namevhost cloud.bitzeit.de (/etc/apache2/sites-enabled/cloud.bitzeit.de.conf:1)

    alias http://www.cloud.bitzeit.de

    ServerRoot: "/etc/apache2"

    Main DocumentRoot: "/var/www/html"

    Main ErrorLog: "/var/log/apache2/error.log"

    Mutex proxy: using_defaults

    Mutex default: dir="/var/run/apache2/" mechanism=default

    Mutex mpm-accept: using_defaults

    Mutex watchdog-callback: using_defaults

    PidFile: "/var/run/apache2/apache2.pid"

    Define: DUMP_VHOSTS

    Define: DUMP_RUN_CFG

    Define: DUMP_INCLUDES

    User: name="www-data" id=33 not_used

    Group: name="www-data" id=33 not_used



    Je nachdem, wie der zuerst erwähnte Schritt der Neuerstellung der "VHost-Datei" durchgeführt wurde, kann es natürlich sein, dass dies unter Verwendung eines Hilfsprogramms geschehen ist, welches andere Verzeichnisse zur Verwaltung verwenden kann (ich lese das so, dass die Datei nicht händisch kopiert/editiert wurde, sonst wäre die Frage nach dem "Wo" oben ja unlogisch):

    Nein die Datei wurde manuell erstellt, ich dachte nur hier würde es sich um eine zweite Datei handeln. Entschuldige bitte die Verwirrung.


    Danke und liebe Grüße,

    Lucas

  • Mit welchen User führst du certbot aus?


    Mit root (sudo) sollte es gehen. Denke dein normaler User hat keine Rechte die vhost zu bearbeiten. Oder eben manuell die Zertifikate in die vhost eintragen.

  • Mit welchen User führst du certbot aus?


    Mit root (sudo) sollte es gehen. Denke dein normaler User hat keine Rechte die vhost zu bearbeiten. Oder eben manuell die Zertifikate in die vhost eintragen.

    Ich habe es sowohl mit einem root (sudo) und einem "normalem" Nutzer versucht. Ein normaler Nutzer hat, wie du bereits erwähnt hast, nicht die benötigten Rechte.


    Liebe Grüße

    Lucas

  • Ok, also alles manuell editiert. Das erleichtert die Fehlersuche/Konfiguration.

    Aus der vorgenannten Ausgabe (Tip: Im Forum ist es üblich, längere Terminalausgaben oder Quellcode unter Verwendung des code.png-Symbols in der Editor-Menüleiste einzufügen, was das Lesen/Überspringen erleichtert) ist zu entnehmen, dass Apache2 bislang keinerlei TLS-relevante Definitionen enthält.


    Inwieweit certbot diese Konfiguration im Erfolgsfall ergänzt, kann ich nicht sagen. Ich verwende ein anderes Hilfswerkzeug, bin aber unabhängig dessen kein Freund von "Mischkonfigurationen", bei denen Teile der Konfiguration einer Anwendung quasi "im laufenden Betrieb" abgeändert werden können. certbot selbst erlaubt auch einen Modus, bei welchem Webserver-Konfigurationsdateien überhaupt nicht angefasst werden; diesen würde ich persönlich bevorzugen.

    • Zuerst zu dem potenziellen Zugriffsproblem: Ich habe certbot in einem Ubuntu 18.04-Container installiert und sehe nicht, dass hier ein eigenes System­nutzer­konto angelegt wurde. Wenn man certbot als Administrator/root ausführt, kann es eigentlich keine Zugriffsrechtsprobleme geben. Ich würde also vermuten, das Problem liegt darin begründet, dass certbot bestimmte Definitionen erwartet und ggf. nur Zertifikats-relevante Definitionen hinzufügt/modizifiert.
    • Jetzt zur fehlenden TLS-Unterstützung durch Apache2: Hier fehlen eine ganze Reihe von Einstellungen/Module.
      • Mit Eingabe von a2enmod ssl wird Apache2 nach einem Neustart auch auf Port 443 lauschen (siehe Datei /etc/apache2/ports.conf).
      • Die Definitionen in Datei /etc/apache2/sites-enabled/cloud.bitzeit.de.conf sind entsprechend zu ergänzen/modifizieren, indem für eben­diesen Port 443 ein ei­gener Abschnitt mit denselben Einstellungen verwendet wird wie für Port 80, ergänzt um TLS-spezifische Angaben. Ein gutes Beispiel für diese Definitionen findet sich beim Mozilla SSL Configuration Generator. Hierfür kann es nötig werden, zusätzliche Module zu installieren/aktivieren (bspw. a2enmod http2). Die Pfade für die beiden erforderlichen Zertifikatsdateien hat certbot ja bekannt gegeben: /etc/letsencrypt/live/de/{fullchain|privkey}.pem

    Ausblick: Wenn die Einstellungen einmal funktionieren, sollte man grundsätzlich alle Zugriffe auf Port 80 (http://) auf Port 443 (https://) umleiten, welche eigene Seiten/Anwendungen wie Nextcloud betreffen.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Ok, also alles manuell editiert. Das erleichtert die Fehlersuche/Konfiguration.

    Aus der vorgenannten Ausgabe (Tip: Im Forum ist es üblich, längere Terminalausgaben oder Quellcode unter Verwendung des code.png-Symbols in der Editor-Menüleiste einzufügen, was das Lesen/Überspringen erleichtert) ist zu entnehmen, dass Apache2 bislang keinerlei TLS-relevante Definitionen enthält.


    Inwieweit certbot diese Konfiguration im Erfolgsfall ergänzt, kann ich nicht sagen. Ich verwende ein anderes Hilfswerkzeug, bin aber unabhängig dessen kein Freund von "Mischkonfigurationen", bei denen Teile der Konfiguration einer Anwendung quasi "im laufenden Betrieb" abgeändert werden können. certbot selbst erlaubt auch einen Modus, bei welchem Webserver-Konfigurationsdateien überhaupt nicht angefasst werden; diesen würde ich persönlich bevorzugen.

    • Zuerst zu dem potenziellen Zugriffsproblem: Ich habe certbot in einem Ubuntu 18.04-Container installiert und sehe nicht, dass hier ein eigenes System­nutzer­konto angelegt wurde. Wenn man certbot als Administrator/root ausführt, kann es eigentlich keine Zugriffsrechtsprobleme geben. Ich würde also vermuten, das Problem liegt darin begründet, dass certbot bestimmte Definitionen erwartet und ggf. nur Zertifikats-relevante Definitionen hinzufügt/modizifiert.
    • Jetzt zur fehlenden TLS-Unterstützung durch Apache2: Hier fehlen eine ganze Reihe von Einstellungen/Module.
      • Mit Eingabe von a2enmod ssl wird Apache2 nach einem Neustart auch auf Port 443 lauschen (siehe Datei /etc/apache2/ports.conf).
      • Die Definitionen in Datei /etc/apache2/sites-enabled/cloud.bitzeit.de.conf sind entsprechend zu ergänzen/modifizieren, indem für eben­diesen Port 443 ein ei­gener Abschnitt mit denselben Einstellungen verwendet wird wie für Port 80, ergänzt um TLS-spezifische Angaben. Ein gutes Beispiel für diese Definitionen findet sich beim Mozilla SSL Configuration Generator. Hierfür kann es nötig werden, zusätzliche Module zu installieren/aktivieren (bspw. a2enmod http2). Die Pfade für die beiden erforderlichen Zertifikatsdateien hat certbot ja bekannt gegeben: /etc/letsencrypt/live/de/{fullchain|privkey}.pem

    Ausblick: Wenn die Einstellungen einmal funktionieren, sollte man grundsätzlich alle Zugriffe auf Port 80 (http://) auf Port 443 (https://) umleiten, welche eigene Seiten/Anwendungen wie Nextcloud betreffen.

    Hallo,

    vielen herzlichen Dank es hat funktioniert. Der einfachheit halber, werde ich meine ausgeführten Befehle nochmals zusammenschreiben und hochladen, sodass es jeder leicht nachmachen kann. Vielen Vielen Dank!

  • Wie versprochen hier eine Zusammenfassung, wie das ganze Schritt für Schritt zu installieren ist.


    Ausgangssituation:

    • ubuntu ist eingerichtet
    • es existiert ein Nutzer mit Sudo Rechten
    • apache2 ist eingerichtet

    Lösung:

    1. Einloggen
    2. VHost einrichten -> siehe Anleitung: https://www.webhosterwissen.de…he-virtual-hosts-anlegen/
    3. SSL Zertifikat einrichten -> siehe Anleitung: https://www.webhosterwissen.de…-encrypt-fuer-ssl-schutz/
    4. sudo a2enmod ssl
    5. sudo a2enmod http2
    6. sudo a2enmod socache_shmcb
    7. sudo a2enmod rewrite
    8. sudo a2enmod headers
    9. apache2 neu starten sudo systemctl restart apache2
    10. https://ssl-config.mozilla.org…nssl=1.1.1d&guideline=5.6 -> Inhalt in z.B. Notepad einfügen
    11. in <VirtualHost *:80> & <VirtualHost *:443> den unten genannten "Code-VirtualHost" am Anfang einfügen
    12. den unten geannten "Code-Directory" nach einfügen <VirtualHost *:443> einfügen
    13. den gesamten Text aus Notepad in VHost Datei einfügen sudo nano /etc/apache2/sites-available/domain.de.conf
    14. sudo certbot run --cert-name de --apache -d "domain.de,www.domain.de"
    15. apache2 neu starten sudo systemctl restart apache2 und fertig
    Code: VirtualHost
        ServerAdmin mail@domain.de
        ServerName domain.de
        ServerAlias www.domain.de
        DocumentRoot /var/www/domain.de
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
    Code: Directory
    <Directory /var/www/domain.de>
        AllowOverride All
    </Directory>


    Hoffe ich habe nichts vergessen.