Let's Encrypt für den Servername verwenden

  • - Welche Version von pd-admin wird eingesetzt? 4.58
    - Welche Version der Serverumgebung wird eingesetzt? 3 0.312


    Hallo,
    wie kann ich bei der Server Domain Let's Encrypt verwenden?


    Der VirtualHost sieht im Template wie folgt aus:


    $$SERVERNAME ist z.B. s3.example.org
    beim Aufruf von /opt/pdadmin/bin/letsencrypt erhalte ich jedoch folgende Meldungen


    Wo ist mein Fehler, dass http://s3.example.org/.well-kn…AkC5ovFVCi6aR15g70YwA2FgU nicht erreichbar ist? Warum funktioniert der Alias nicht?
    Für <VirtualHost $$STANDARD_IP:443> habe ich bereits ein Eintrag mit einem selbstsignierten Zertifikat erstellt, ist das evtl. das Problem?


    mfg
    Twilo

  • Hallo,


    der Server kann s3.example.org auflösen.
    Wenn das DNS nicht richtig funktionieren würde, wäre der HTTP-Status nicht "404 Not Found".


    Es sieht so aus, als würde der Alias nicht funktionieren …


    Wenn ich das mit einer anderen Subdomain probiere, werden für die Dauer der Scriptausführung von /opt/pdadmin/bin/letsencrypt unter /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/ Dateien angelegt.


    Warum geschieht dies nicht für den Hostnamen des Servers?


    mfg
    Twilo

  • Das Problem ist ein mismatch des document roots:


    Zitat

    Template:

    Code
    1. DocumentRoot /usr/local/pd-admin2/htdocs_80


    Certbot:

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


    Daher kommt es zu dem 404 Fehler. Vermutlich ist /usr/local/pd-admin2/htdocs in der letsencrypt binary fix implementiert. Was passiert denn wenn man den Pfad im Template anpasst?

  • Dann würde ich zunächst einmal händisch


    Code
    1. /usr/local/pd-admin2/htdocs/.well-known/acme-challenge/1.txt


    anlegen und diese (extern) mit


    Code
    1. curl -I http://s3.example.org/.well-known/acme-challenge/1.txt


    aufrufen. Wenn dies auch ein 404 ergibt, muss man sich die Apache Konfig anschauen. Dann wird vermutlich immer noch ein falsches DocumentRoot verwendet.

  • Hallo,



    in der error_log steht dann folgendes

    Code
    1. [Fri May 11 21:32:17 2018] [alert] [client 127.0.0.1] /usr/local/pd-admin2/htdocs/forbidden/.htaccess: deny not allowed here


    Code
    1. s3:~
    2. > cat /usr/local/pd-admin2/htdocs/forbidden/.htaccess
    3. deny from all


    wenn ich jedoch http://s3.example.org/.well-known/acme-challenge/test.txt bei mir lokal aufrufe, erhalte ich folgende Ausgabe

    Code
    1. kay@W530:/tmp$ curl --head http://s3.example.org/.well-known/acme-challenge/test.txt
    2. HTTP/1.1 200 OK
    3. Date: Fri, 11 May 2018 19:27:00 GMT
    4. Server: Apache
    5. Last-Modified: Fri, 11 May 2018 19:26:58 GMT
    6. ETag: "240d64-5-56bf31e9af5f7"
    7. Accept-Ranges: bytes
    8. Content-Length: 5
    9. Content-Type: text/plain


    8o


    mfg
    Twilo

  • nachdem ich in der Datei /etc/hosts, den Eintrag für s3.example.org geändert habe
    vorher

    Code
    1. 127.0.0.1 s3.example.org www.s3.example.org localhost.localdomain localhost


    aktuell

    Code
    1. 127.0.0.1 localhost.localdomain localhost
    2. 1.2.3.4 s3.example.org www.s3.example.org


    kam einmal diese Fehlermeldung


    und seit dem nur noch


    In /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/ wird aber während des Aufrufes immer noch keine Datei erzeugt :(


    mfg
    Twilo

  • Zitat

    Original von Twilo
    In /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/ wird aber während des Aufrufes immer noch keine Datei erzeugt :(


    Das liegt daran, dass weiterhin /usr/local/pd-admin2/htdocs als WebRoot beim certbot verwendet wird.


    Zitat

    Original von Twilo

    Code
    1. [...]
    2. Using the webroot path /usr/local/pd-admin2/htdocs for all unmatched domains.
    3. [...]


    Wenn /opt/pdadmin/etc/ssl-validation verwendet werden soll, müsste in diesem Fall der certbot einmal manuell ausgeführt werden. Den Befehl findet man auch im letsencrypt log unter /var/log/letsencrypt.


    Ich denke auch nicht, dass dies ein DNS Problem, sondern viel mehr ein Konfig Problem ist...

  • Hallo,


    hm, stimmt bei den anderen Domains steht
    Using the webroot path /opt/pdadmin/etc/ssl-validation for all unmatched domains.
    woher kommt dieser Pfad?


    habe den certbot-auto jetzt wie folgt aufgerufen …

    Code
    1. > /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 s3.example.org -d www.s3.example.org
    2. Saving debug log to /var/log/letsencrypt/letsencrypt.log
    3. Plugins selected: Authenticator webroot, Installer None
    4. Obtaining a new certificate
    5. An unexpected error occurred:
    6. There were too many requests of a given type :: Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/
    7. Please see the logfiles in /var/log/letsencrypt for more details.


    ;(


    pd-admin verursacht bei uns etliche Fehlversuche, da der Aufruf von /.well-known/acme-challenge/ auch umgeleitet werden, wenn bei der Domain eine Umleitung eingerichtet ist
    :O


    EDIT: warum überhaupt --email daniel@bradler.com ?! ?(


    mfg
    Twilo

  • Zitat

    Original von Twilo
    woher kommt dieser Pfad?


    Ich vermute der Pfad ist in der letsencrypt binary fest implementiert. Zumindest habe ich weder in der DB, noch pdadmin.conf eine entsprechende Angabe gesehen. Sobald also ein Zertifikat für den Server Hostnamen ausgestellt werden soll, wird dieser Pfad verwendet.


    Zitat
    Code
    1. There were too many requests of a given type :: Error creating new authz :: too many failed authorizations recently: see [URL]https://letsencrypt.org/docs/rate-limits/[/URL]
    2. Please see the logfiles in /var/log/letsencrypt for more details.

    :evil: ;(


    Das ist natürlich jetzt ärgerlich. Aber das sollte in einer Stunde wieder funktionieren.


    EDIT:

    Zitat

    EDIT: warum überhaupt --email daniel@bradler.com ?! verwirrt


    Vermutlich ist auch dies in der binary so implementiert...


    Man kann dies aber glaub ich unter


    Code
    1. /etc/letsencrypt/accounts/...../regr.json


    anpassen. Ist aber nicht getestet...