kein administrator - Zugang mehr

  • Hi @ all,

    bin mittlerweile auf pdadmin ver 4.58 und se 0.317.
    Der Server läuft unter Debian 8.11 auf Cloudserver-50


    Problem: kann meine administrator - Oberfläche mit Mozilla Firefox nicht mehr aufrufen.
    Meldung von Mozilla:
    Der Inhaber von vpscobra.service4it.com hat die Website nicht richtig konfiguriert. Firefox hat keine Verbindung mit dieser Website aufgebaut, um Ihre Informationen vor Diebstahl zu schützen.

    Diese Website verwendet HTTP Strict Transport Security (HSTS), um mitzuteilen, dass Firefox nur über gesicherte Verbindungen mit ihr kommunizieren soll. Daher ist es nicht möglich, eine Ausnahme für dieses Zertifikat anzulegen.


    So, nun habe ich über meine vpscobra.service4it.com das letsencrypt-Zertifikat neu erstellt.

    mit dem AUfruf von /opt/pdadmin/bin/letsencrypt vpscobra.service4it.com

    erscheint nun die weitere Meldung:

    Saving debug log to /var/log/letsencrypt/letsencrypt.log

    Plugins selected: Authenticator webroot, Installer None

    Obtaining a new certificate

    Performing the following challenges:

    http-01 challenge for vpscobra.service4it.com

    Using the webroot path /usr/local/pd-admin2/htdocs for all unmatched domains.

    Waiting for verification...

    Cleaning up challenges

    Failed authorization procedure. vpscobra.service4it.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://vpscobra.service4it.com…JuJCbi48xqd2HS05Mt3XinWk: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

    <html><head>

    <title>404 Not Found</title>

    </head><body>

    <h1>Not Found</h1>

    <p"


    IMPORTANT NOTES:

    - The following errors were reported by the server:


    Domain: vpscobra.service4it.com

    Type: unauthorized

    Detail: Invalid response from

    http://vpscobra.service4it.com…JuJCbi48xqd2HS05Mt3XinWk:

    "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

    <html><head>

    <title>404 Not Found</title>

    </head><body>

    <h1>Not Found</h1>

    <p"


    To fix these errors, please make sure that your domain name was

    entered correctly and the DNS A/AAAA record(s) for that domain

    contain(s) the right IP address.

    certbot-auto failedWriting /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf

    webserver = <AP24>

    Apache 24 is already selected


    Was ist seit dem Update auf 0.317 schief gelaufen?
    Hatte vorher wochenlang keine Probleme und auch nix verändert, seltsam.
    PS: alle anderen Domains laufen problemlos mit letsencrypt unter https,
    warum die Administrator-Domain nicht?

    Bitte um Eure Unterstützung.
    Im Voraus schon mal, Vielen Dank,
    RudiX

  • Also, wenn ich das Zertifikat hier


    https://sslanalyzer.comodoca.c…l=vpscobra.service4it.com


    prüfen dann zeigt er an, dass das Zertifikat selbst signiert wurde.


    Also scheint er kein Let’s Encrypt Zertifikat erstellt zu haben, was die Fehlermeldung ja auch aussagt.


    Es scheint ja irgendwo ein DNS-Problem zu geben. Am besten teste den DNS noch einmal durch.


    Was steht denn genau in /var/log/letsencrypt/letsencrypt.log?

  • Es kommt zu einem 404 Fehler. Sprich die hinterlegte Validierungsdatei wird nicht gefunden.

    Sofern die IP im DNS mit der in pd-admin übereinstimmt, muss man prüfen wo let's encrypt die Datei anlegt. Wahrscheinlich /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/

    Dort Mal eine Testdatei anlegen und versuchen abzurufen. Wichtig ist, dass der Aufruf per http klappen muss.

  • Ich sehe gerade, der Pfad ist

    Code
    1. Using the webroot path /usr/local/pd-admin2/htdocs

    es kann sein, dass durch die Weiterleitung auf HTTPS beim Hostnamen der Aufruf der Validierungsdatei fehlschlägt. In dem Fall muss der vhost für den Hostnamen in der Apache angepasst werden.

    Einfach die Zeile

    Code
    1. ## REDIRECT_TO_HTTPS ##

    durch

    Code
    1. RedirectMatch ^(?!/\.well-known/acme-challenge).* https://$$SERVERNAME$0

    ersetzen.

  • Hallo Sumeragi, Hallo Eisenherz,

    der RedirectMatch hat leider auch zu keinem Erfolg geführt ;-((

    Da ich inzwischen zu oft den letsencrypt-Aufruf gestartet habe erscheint erstmal eine Sperre.
    There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/
    Please see the logfiles in /var/log/letsencrypt for more details.

    certbot-auto failedWriting /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf


    Er schreibt hier failedWriting, bei mir hat diese httpd.conf die Rechte 644 O=root G=www, dort muss er ja nicht schreiben da der Apache auf 2.4 läuft. Den RedirectMatch habe ist aber im httpd24.conf-template geändert und das hat er sauber in die httpd-2.4/conf/httpd.conf übernommen.

    Eisenherz

    der Cloud-Server läuft bei Bradler&Krantz, da gehe ich mal davon aus das da alles passt.
    Obwohl nach Supportanfrage im BK-Manager beim Cloudserver der hostname auf den hostname des Servers geändert werden soll.
    Nehme mal an dies die Ausgabe ist, die auf der Konsole bei hostname -f raus kommt oder???


    Also, Problem immer noch vorhanden.
    Wenn der letsencrypt-Aufruf wieder funktioniert kann ich das log ja mal als Datei anhängen.


    Viele Grüße,
    RudiX

  • Hallo Eisenherz,

    also beim Aufruf von /opt/pdadmin/bin/letsencrypt vpscobra.service4it.com wird dieser Log-file geschrieben.

    Nochmal zum Verständnis:
    der hostname -f ist: vpscobra.vpscontrol.net

    der ServerName in der /usr/local/pd-admin2/httpd-2.4/conf ist: vpscobra.service4it.com

    und es existiert eine angelegte Domain service4it.com


    In der /etc/hosts steht lediglich:

    127.0.0.1 localhost

    127.0.1.1 vpscobra.vpscontrol.net vpscobra

    # The following lines are desirable for IPv6 capable hosts

    ::1 localhost ip6-localhost ip6-loopback

    ff02::1 ip6-allnodes

    ff02::2 ip6-allrouters


    Ebenso ist beim Cloudserver von B&K als hostname vpscobra.vpscontrol.net hinterlegt, als Reverse DNS aber vpscobra.service4it.com.
    Den Reverse DNS kann ich leider nicht mehr herausnehmen, warum auch immer. Ich kann einen neuen Reverse-DNS angeben, aber den vorhandenen leider nicht löschen.


    Vielen Dank für Eure Mühe,
    Gruß RudiX

  • Es scheint ja, dass der Config File unter /etc/letsencrypt/renewal/vpscobra.service4it.com.conf


    2018-09-20 21:10:20,003:DEBUG:certbot.cert_manager:Renewal conf file /etc/letsencrypt/renewal/vpscobra.service4it.com.conf is broken. Skipping.

    2018-09-20 21:10:20,004:DEBUG:certbot.cert_manager:Traceback was


    irgendwie ein Problem hat, kannst Du denn mal anhängen?


  • Nicht nur irgendwie, sondern das Problem wird auch konkret benannt im Log:


    Code: letsencrypt.log
    1. 2018-09-20 21:10:20,003:DEBUG:certbot.cert_manager:Renewal conf file /etc/letsencrypt/renewal/vpscobra.service4it.com.conf is broken. Skipping.
    2. 2018-09-20 21:10:20,004:DEBUG:certbot.cert_manager:Traceback was:
    3. Traceback (most recent call last):
    4. File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/cert_manager.py", line 382, in _search_lineages
    5. candidate_lineage = storage.RenewableCert(renewal_file, cli_config)
    6. File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/storage.py", line 439, in __init__
    7. self._check_symlinks()
    8. File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/storage.py", line 498, in _check_symlinks
    9. "expected {0} to be a symlink".format(link))
    10. CertStorageError: expected /etc/letsencrypt/live/vpscobra.service4it.com/cert.pem to be a symlink


    Die Dateien unter /etc/letsencrypt/live/vpscobra.service4it.com/ sind keine Symlinks. Eigentlich sollten die Dateien dort auf /etc/letsencrypt/archive/vpscobra.service4it.com/ zeigen. Dies ist jedoch ein anderer/weiterer Fehler und erst einmal nachgelagert, nach dem eigentlichen Problem.


    Trotz des Fehlers wird die Validierung ja durchgeführt, schlägt jedoch fehl.



    Hier sieht man wo das Validation File erzeugt wird, wie es aufgerufen wird und welchen Fehler es gibt. Ich würde jetzt einmal so vorgehen:


    Shell-Script
    1. mkdir -p /usr/local/pd-admin2/htdocs/.well-known/acme-challenge/
    2. echo "/usr/local/pd-admin2/htdocs/" > /usr/local/pd-admin2/htdocs/.well-known/acme-challenge/1.txt
    3. mkdir -p /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/
    4. echo "/opt/pdadmin/etc/ssl-validation/" > /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/1.txt


    Anschließend einmal


    Shell-Script
    1. curl -L http://vpscobra.service4it.com/.well-known/acme-challenge/1.txt


    aufrufen und schauen welche Ausgabe kommt. Meine Vermutung ist, dass der Certbot das File unter /usr/local/pd-admin2/htdocs ablegt, der Apache jedoch bei dem Aufruf /opt/pdamin/etc/ssl-validation verwendet. Dadurch kommt es dann zu dem 404 Fehler.


    Die Ausgabe von /etc/letsencrypt/renewal/vpscobra.service4it.com.conf wäre in dem Fall interessant.

  • Please see the logfiles in /var/log/letsencrypt for more details.

    certbot-auto failedWriting /usr/local/pd-admin2/conf/httpd.conf

    Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf


    Er schreibt hier failedWriting, bei mir hat diese httpd.conf die Rechte 644 O=root G=www, dort muss er ja nicht schreiben da der Apache auf 2.4 läuft. Den RedirectMatch habe ist aber im httpd24.conf-template geändert und das hat er sauber in die httpd-2.4/conf/httpd.conf übernommen.


    Hierbei nicht bitte irritieren lassen. Es fehlt lediglich das Newline hinter certbot-auto failed. Richtig sähe es so aus:


    Code
    1. Please see the logfiles in /var/log/letsencrypt for more details.
    2. certbot-auto failed
    3. Writing /usr/local/pd-admin2/conf/httpd.conf
    4. Writing /usr/local/pd-admin2/httpd-2.4/conf/httpd.conf


    Es hat nichts mit dem Schreiben der httpd.conf zu tun ;)

  • Hallo,

    also der curl -L ... Aufruf bringt folgende Ausgabe:

    curl: (60) SSL certificate problem: self signed certificate

    More details here: http://curl.haxx.se/docs/sslcerts.html


    curl performs SSL certificate verification by default, using a "bundle"

    of Certificate Authority (CA) public keys (CA certs). If the default

    bundle file isn't adequate, you can specify an alternate file

    using the --cacert option.

    If this HTTPS server uses a certificate signed by a CA represented in

    the bundle, the certificate verification probably failed due to a

    problem with the certificate (it might be expired, or the name might

    not match the domain name in the URL).

    If you'd like to turn off curl's verification of the certificate, use

    the -k (or --insecure) option.


    Die Datei /etc/letsencrypt/renewal/vpscobra.service4it.com.conf

    # renew_before_expiry = 30 days

    version = 0.25.0

    archive_dir = /etc/letsencrypt/archive/vpscobra.service4it.com

    cert = /etc/letsencrypt/live/vpscobra.service4it.com/cert.pem

    privkey = /etc/letsencrypt/live/vpscobra.service4it.com/privkey.pem

    chain = /etc/letsencrypt/live/vpscobra.service4it.com/chain.pem

    fullchain = /etc/letsencrypt/live/vpscobra.service4it.com/fullchain.pem


    # Options used in the renewal process

    [renewalparams]

    authenticator = webroot

    installer = None

    account = 2cc807de7d2aa847d06f2f154c72a793

    webroot_path = /usr/local/pd-admin2/htdocs,

    [[webroot_map]]

    vpscobra.service4it.com = /usr/local/pd-admin2/htdocs


    Tja, so siehts aus,
    Gruß RudiX

  • ... so Männers, nachdem ich mir inzwischen Twilo's Thread "Let's Encrypt für den Servername verwenden" angeschaut habe, bin ich endlich ans Ziel gekommen.

    Habe nun folgenden Aufruf manuell gestartet:
    /opt/pdadmin/bin/certbot-auto certonly --agree-tos --non-interactive --email daniel@bradler.com --no-self-upgrade --keep-until-expiring --expand --webroot -w /opt/pdadmin/etc/ssl-validation -d vpscobra.service4it.com -d www.vpscobra.service4it.com


    Allerdings liefen die Symlinks in /opt/pdadmin/sslcerts immer noch ins Leere. Daraufhin habe ich mir die Struktur /etc/letsencrypt/live angeschaut und musste feststellen das er vpscobra.service4it.com-001 und ...-002 angelegt hatte, da ich auch 2 mal gestartet hatte.

    So nun die Certs aus ...-002 ins richtige Verzeichnis kopiert und schon klappt der Aufruf für den pdadmin-Administrator wieder.


    Stellt sich nur die Frage, was passiert wenn das Zertifikat wieder abgelaufen ist?
    Solche Dinge müssten sich doch gegebenenfalls über ein Script lösen lassen, das kann doch alles nicht sein!

    Na ja, auf alle Fälle vielen, vielen Dank für Eure tolle Unterstützung.
    Ich werde Euch gleich einen Daumen nach oben eintragen.


    Viele Grüße,

    RudiX

  • RudiX

    Hat das Label [erledigt] hinzugefügt
  • Hi,
    habe /opt/pdadmin/bin/certbot-auto renew --dry-run gestartet, (siehe txt-file im Anhang) es werden einige Fehler ausgegeben.
    Er sucht nach den vpscobra.service4it.com-001 und ...-002 files, die ich gestern gelöscht habe. Aber das Zertifikat für vpscobra.service4it.com wird sich wohl nicht automatisch verlängern.
    Das letsencrypt läuft einfach nicht problemlos.

    Gruß RudiX

  • Die Zertifikate wurden offenbar nur aus /etc/letsencrypt/live gelöscht, jedoch nicht aus /etc/letsencrypt/renewal/. Im Log sieht man ja, dass er die Konfig daraus verarbeitet.


    Bei vpscobra.service4it.com kommt es erneut zu einem 404 Fehler. Also immer noch dem gleichen Problem wie zuvor. Anhand der Datei /etc/letsencrypt/renewal/vpscobra.service4it.com.conf sieht man, dass als Webroot /usr/local/pd-admin2/htdocs konfiguriert ist. Das Problem hierbei ist, dass Anfragen an den Hostnamen mit einem 301 Redirect auf HTTPS weitergeleitet wird. Hier muss, wie zuvor beschrieben, im httpd.conf-template der Redirect angepasst werden. Hier der Teil aus meiner httpd.conf-template:


    Damit klappt es bei mir mit der Validierung.


    Edit:


    Wenn man die httpd.conf Template Dateien bearbeitet, muss anschließend

    Code
    1. /opt/pdadmin/bin/httpd_vhosts.pl 

    ausgeführt werden.

  • Hi,

    den RedirectMatch hatte ich bereits eingetragen sowie die httpd_vhosts.pl gestartet.

    Nachdem ich nun nochmal /etc/letsencryp/archive und renewal überprüft hatte, liefen /opt/pdadmin/bin/certbot-auto renew --dry-run sowie die entsprechenden cronjobs ohne Fehlermeldungen durch. Zudem habe ich den Script "certbot-renew.sh" aus Deinem Blog in der crontab integriert.

    Aber Mozilla war wieder der Meinung das ich ein ungültiges Zertifikat habe.
    Also wiederum den manuellen Job aus Twilos Thread gestartet, certbot-auto renew und die cronjobs wiederum.
    Jetzt funktioniert es wieder, allerdings hat er im archive und renewal wieder vpscobra.service4it.com-0001 angelegt.


    Das ist doch alles seltsam, aber nun bin ich dahinter gestiegen.

    Er holt sich die Pfade und filenames aus der /etc/letsencrypt/renewal/<domain>.conf und die war noch nicht korrigiert ;-((

    Alles gerichtet, alles gut.

    Nun läuft erstmal alles.

    Danke nochmal an alle für die Unterstützung.


    Gruß RudiX