Jump to content
Froxlor Forum

rseffner

Members
  • Posts

    141
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by rseffner

  1. Hi,

     

    ich habe in die 0.10.18 bereits den 8 Tage jungen Patch der lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php eingebaut und glaube da war noch alles normal. Kurz darauf habe ich auf 0.10.19 aktualisiert und den Patch wieder durchgeführt.

    Seit dem beobachte ich fast täglich, aber nicht immer, dass genau 0 Uhr ein apache restart angefordert wird, der nicht erfolgreich ist, weil die php-fcgi-starter für den Froxlor-VHOST fehlt

    [Wed Jul 15 00:00:00.874456 2020] [mpm_prefork:notice] [pid 23916] AH00171: Graceful restart requested, doin
    AH00526: Syntax error on line 13 of /etc/apache2/sites-enabled/10_froxlor_ipandport_78.46.xx.xx.443.conf:
    Wrapper /var/www/php-fcgi-scripts/froxlor.panel/ns1.xxx-xxx.de/php-fcgi-starter cannot be accessed

    Wenn dann das Monitoring Alarm schlägt und ich mich - i.d.R. mehr als 5 Minuten später - einlogge, ist der Apache startbar und die Datei vorhanden.

    Ich vermute hier kommen sich Konfigurationsneuerstellung und Restart ins Gehege. Ich habe neben cron keinen weiteren Scheduler und weder in /var/spool/cron* noch /etc/cron* irgend etwas gefunden, was auch um 0 Uhr (ja, diese */5 Einträge habe ich auch berücksichtigt) am Apache rummacht außer den Froxlor-Tasks.

    # automatically generated cron-configuration by froxlor
    # do not manually edit this file as it will be re-generated periodically.
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    #
    */5 * * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --tasks 1> /dev/null
    2 0 * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --traffic 1> /dev/null
    0 */6 * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --mailboxsize 1> /dev/null
    */5 * * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --letsencrypt 1> /dev/null
    5 0 * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --backup 1> /dev/null
    

    Was trifft sich hier unglücklich und kann dann wie behoben werden?

    Gruß, Ronny

  2. Ich bin gerade über einen Zone gestolpert, die sich vom bind nicht laden lassen wollte.

    Darin gab es "* CNAME ...." und "* A ...". Das "* A ..." resultierte aus der Domaineinstellung Alias = "Wildcard" und das "* CNAME ..." hat wohl der Anwender einst gesetzt (warum dann keiner gemerkt hat, das gar nichts mehr geht?).

    Ich habe das reproduziert und man kann das auch jetzt noch so einrichten. Damit wird klar, dass der Eintrag hier eher in den Bugtracker sollte - mein Tag war aber schon so lang und ermüdende, ich hoffe man verzeiht mir.

  3. 25 minutes ago, d00p said:

    2) ein von dir beschriebener Fallback Ist vorhanden, siehe https://github.com/Froxlor/Froxlor/blob/3c7bdcb5e0b25be07003f1fe70b968f543f993ed/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php#L541

    3) willst du aus non-ecc ein ECC machen musst du es löschen und neu beantragen

    2) Das erklärt leider nicht, warum mir heute mehrere Dutzend abgelaufene Zertifikate um die Ohren geflogen sind, die auch ein --force nicht erneuerte ;-( Da klemmt es also woanders ...

    3) Dann ist der Halbautomatismus, den ich parallel hier vorgestellt habe, eher mit Vorsicht zu genießen und für welche, die nicht klickend viele Domains "upgraden" möchten

  4. Wenn man das Ergebnis (siehe /tmp/le) folgender quick-and-dirty-Behandlung zurück nach /root/.acme.sh kopiert, im FROXLOR EC-384 aktiviert und "/root/.acme.sh/acme.sh --cron --home /root/.acme.sh --force" gefolgt von "/usr/bin/php7.3 -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --force" aufruft, erhält man das Upgrade bisheriger Zertifikate hin zu ECC

    Es werden dabei alle Nicht-ECC Zertifikatsinfos nach /tmp/le kopiert und dort "4069" durch "ec-384" ersetzt. Jetzt der manuelle Kopierjob. Dann wird LE mittels acme.sh gezwungen die Zertifikate zu erneuern (ich hatte ja die Zeitstempel nicht angefasst) und zuletzt kümmert sich der Froxlor-Job um das Kopieren nach /etc/apache2/ssl und eintragen in die VHosts (oder eben analog für nginx).

     

    ns1:~# cat 2ecc
    #!/bin/bash
    
    mkdir -p /tmp/le
    
    cd /root/.acme.sh
    find ./ -mindepth 1 -maxdepth 1 -type d -not -name "*_ecc" -not -name "ca" -not -name "deploy" -not -name "dnsapi" -not -name "notify" | while read LINE; do
            if [ ! -d "$LINE"_ecc ]; then
                    cp -r "$LINE" /tmp/le/"$LINE"_ecc
                    sed -i "s/Le_Keylength='4096'/Le_Keylength='ec-384'/g" /tmp/le/"$LINE"_ecc/"$LINE".conf
            fi
    done
    

     

  5. Hi,

    ich habe irgendwann in den Einstellungen unter SSL mal eine ECC-Schlüssellänge gewählt und wohl gehofft, beim nächsten renew werden die Zertifikate "umgestellt". Bei Anlage neuer Domains mit wurde auch brav ECC berücksichtigt. Nun sind offenbar eine Menge nich-ECC Zertifikate abgelaufen und nicht verlängert worden. Rufe ich den cron-task --force --debug mit aktiviertem ECC auf so erhalte ich zu allen Domains, die schon vor ECC ein LE-Zertifikat hatten "[warning] ECC certificates activated but found only non-ecc file" und das Zertifikat in /etc/apache2/ssl beliebt ungeändert. Erst wenn ich ECC deaktiviere hat er endlich den renew gemacht.

    Entweder fehlt hier der fallback (hast du kein ECC such ein Zertifikat ohne) für so eine gewachsene Mischinstallation oder das ist so gewollt und ich muss jetzt überall LE deaktivieren, ECC aktivieren udn den Domains LE wieder aktivieren. Eine elegantere Methode zum Upgrade von noch-ECC auf ECC habe ich auch in acme.sh nicht gefunden.

    Übersehe ich etwas?

    Gruß

  6. Danke fürs unterstützen. Ich bin leider schon wieder darauf reingefallen, dass ein "Reseller" längst einen anderen A-record für www. eingetragen hat und vergas, das LE zu deaktivieren. Das mit 3 Domains und die Vierte, mit der ich die Gegenprobe machen wollte hatte längst den Provider gewechselt, ohne dass mir das der Kunde sagte. Ich freue mich riesig auf den Fix mit der DNS-Gegenprobe.

  7. Die Domain war vor den ganzen hier diskutierten Anpassungen am FROXLOR dort bereits in Verwaltung und mit LE versehen. Es geht also um einen RENEW. Im konkreten Beispiel rein IPv4. Ich habe in FROXLOR schon LE deaktiviert, den Zertifikatsordner aus /root/.acme gelöscht, Configs neu geschrieben und LE wieder für die Domain aktiviert sowie Configs neu geschrieben. Das konnte dann kein CRT beziehen, hat nur .conf, .csr und .key angelegt.

  8. Ich muss mich hier leider wieder melden, weil ich noch die hier genannte AcmeSh.php einsetze.

    Inzwischen häufen sich Meldungen wie:

    [Do 30. Apr 15:34:31 CEST 2020] DOMAIN.TLD:Verify error:The key authorization file from the server did not match this challenge
    [Do 30. Apr 15:34:32 CEST 2020] Please add '--debug' or '--log' to check more details.
    [Do 30. Apr 15:34:32 CEST 2020] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
    

     

  9. Auf dem 2. Server wo die Diskrepanz zwischen Expiration im Dateisystem und der DB war, ist jetzt "Einigkeit" ohne, dass sich an dem Zertifikat im Dateisystem etwas geändert hätte.

    Du hast es also offenbar geschafft, dass sich FROXLOR an den Daten im Dateisystem bedient und damit die DB füttert.

  10. Für offenbar jede Domain kommt

    PHP Warning:  Use of undefined constant LOG_WARN - assumed 'LOG_WARN' (this will throw an Error in a future version of PHP) in /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php on line 461

    Und bei einer der betroffenen Domains siehts so aus

    PHP Warning:  Use of undefined constant LOG_WARN - assumed 'LOG_WARN' (this will throw an Error in a future version of PHP) in /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php on line 461
    [unknown] ECC certificates activated but found only non-ecc file
    [information] Updated Let's Encrypt certificate for a.mein****.de
    

     

  11. root@ns1 ~/.acme.sh/a.mein****.de # ls -la /root/.acme.sh/a.mein****.de/
    insgesamt 36
    drwxr-xr-x  2 root root 4096 Jan 27 12:05 .
    drwx------ 73 root root 4096 Apr  4 13:45 ..
    -rw-r--r--  1 root root 2301 Mär 27 12:15 a.mein****.de.cer
    -rw-r--r--  1 root root  652 Mär 27 12:15 a.mein****.de.conf
    -rw-r--r--  1 root root 1716 Mär 27 12:15 a.mein****.de.csr
    -rw-r--r--  1 root root  242 Mär 27 12:15 a.mein****.de.csr.conf
    -rw-r--r--  1 root root 3247 Mär 27 12:15 a.mein****.de.key
    -rw-r--r--  1 root root 1648 Mär 27 12:15 ca.cer
    -rw-r--r--  1 root root 3949 Mär 27 12:15 fullchain.cer
    root@ns1 ~/.acme.sh/a.mein****.de # md5sum /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php
    59e6855a72207abc330d52db41368489  /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php
    root@ns1 ~/.acme.sh/a.mein****.de #

    Ich verstehe, das solch remotes debugging extrem anstrengend ist - drum gebe ich mir ja alle Mühe, Dir keinen Mist zu liefern.

  12. Ein zweiter Server mit FROXLOR 0.10.15

    ns1:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOMAIN.de/scripts/froxlor_master_cronjob.php --tasks
    [error] Could not get Let's Encrypt certificate for a.mein****.de:
    [Sa 4. Apr 13:51:20 CEST 2020] Renew: 'a.mein****.de'
    [Sa 4. Apr 13:51:20 CEST 2020] Skip, Next renewal time is: Mi 3. Jun 11:45:17 UTC 2020
    [Sa 4. Apr 13:51:20 CEST 2020] Add '--force' to force to renew.
    

    Und nun die ausgetauschte Datei und der cronjob mit --force --debug

    ...
    [error] Could not get Let's Encrypt certificate for sola****.de:
    
    [error] Could not get Let's Encrypt certificate for 2019.seff****.de:
    
    [error] Could not get Let's Encrypt certificate for a.mein****.de:
    
    [error] Could not get Let's Encrypt certificate for prof****.at:
    ...

    Im Filesystem Renew auf 26.05. in der DB expiration auf 27.06 - das kann ja passen - ich glaube renew beginnt einen Monat vor Ablauf.

  13. Auch die neue Version ändert an der Ausgabe nichts.

    Eine Stichprobe meint zum Zertifikat in /root/.acme CreateTimeStr="Fr 3. Apr ..." bzw. NextRenewTimeStr="Mi 2. Jun ..." und in der DB als expiration="2020-04-26 09:10:21".

    Ich weiß ja nicht was Dein Code tun soll, aber in der DB sind noch immer andere Zertifikate wie im Dateisystem.

  14. root@ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOAMIN.de/scripts/froxlor_master_cronjob.php --force --debug
    ...
    [information] Running Let's Encrypt cronjob prior to regenerating webserver config files
    [error] Could not get Let's Encrypt certificate for bam-****.de:
    
    [error] Could not get Let's Encrypt certificate for angl****.de:
    ...
    [information] Let's Encrypt certificates have been updated
    [information] apache::createIpPort: creating ip/port settings for  xxx.xxx.xxx.xxx:80
    
    

    Ich nahm an --force ist ein weiterer Parameter zu --tasks. Leider ist die Ausgabe mit --debug an der gesuchten Stelle um keinen Deut umfangreicher.

  15. 3 hours ago, d00p said:

    Feedback, gerne :)

    Danke für Deine Mühen.

    root@ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOMAIN.de/scripts/froxlor_master_cronjob.php --tasks --force
    [error] Could not get Let's Encrypt certificate for bam-****.de:
    
    [error] Could not get Let's Encrypt certificate for angl****.de:
    
    [error] Could not get Let's Encrypt certificate for anti****.de:
    
    ....

    Rechte? Wobei das php als root lief.

  16. 2 hours ago, d00p said:

    Froxlor aktualisiert nur die Zertifikate die laut der eigenen Datenbank renewed werden....habe ich doch gesagt, es gibt noch keinen Dateiabgleich und daran arbeite ich gerade.

    Ich habe die Ursache für den, durch den cron-job angestoßenen renew, ja im Froxlor vermutet.
    - in der DB steht, das Zertifikat läuft bald aus - es wird von FROXLOR der renew geplant
    - da beim renew acme.sh aber merkt, dass sein Zertifikat noch längst nicht fällig wird verwehrt es den renew -> der Fehler, mit dem ich hier einstieg
    = nun habe ich acme.sh um die Kenntnis der Gültigkeit beraubt und der renew durch FROXLOR-cron fand statt, in .acme/ liegt ein neues Zertifikat
    ? warum ist das nun nicht auch in der DB erneuert

    Was verstehe ich hier falsch?

  17. Bei  mir liegt der ganze acme.sh Krempel unter /root/.acme.sh.

    Da sind dann je (Sub-)Domain ein Ordner für die Zertifikate mit einer *.conf in der sich Le_CertCreateTime, Le_CertCreateTimeStr, Le_NextRenewTime und Le_NextRenewTimeStr befinden. Kommentiere ich diese 4 Zeilen aus und starte dann den froxlor_master_cronjob.php läuft die Zertifikatsbeschaffung ohne Fehler durch.

    Soweit so gut - man könnte jetzt hoffen einen Zertifikatsasynchronität durch einmaliges Ändern der *.conf's zu beheben, weil dann FROXLOR wieder "gewinnt" mit seinem Request und Glauben an den Zertifikatsablauf.

    Allerdings haut mir der Cronjob die eben erneuterten Zertifikate bei einer weitere Iteration wieder um die Ohren. Warum? Schaue ich in die SQL, sehe ich, dass dort noch immer eine "falsche" Expiration drinsteht. Kann es sein, dass wir hier einen Bug haben und die Daten von acme.sh gerade NICHT in die DB wandern bei renews?

  18. Das acme.sh --upgrade meint gerade aktuell zu sein und kommt so im Code sicher nicht an die Stelle, wo es wohl sonst scheitert.

    Die Inhalte der Zertifikatsdateien (die Version vor meinem Eingriff) im Filesystem und der FROXLOR-DB (panel_domains.id = domain_ssl_settings.domainid) unterscheiden sich bei der Beispieldomain. Kann ich da jetzt einfach aus dem Dateisystem die Inhalte in die DB kopieren um die Gültigkeit  an beiden Orten gleich zu haben? 

    Die Stichprobe mit einer noch nicht in den Tasks zum renew geführten Domain zeigt diese Unterschied zwischen Dateisystem und DB aber auch. Ist das jetzt alles asyncron? Kann man FROXLOR "zwingen" sich nochmal am .acme.sh-Verzeichnis zu bedienen?

  19. 2 minutes ago, d00p said:

    Ja, froxlor weiss nix von dem aktualisierten Zertifikat. Die Art der Implementierung ist hier noch nicht so wie ich sie haben will. Froxlor nimmt sich die Zertfikatsdateien nach dem issue/renew und legt sie in seiner datenbank ab, damit ich sie gleich behandeln kann wie nicht-lets-encrypt zertifikate. Führst du nun ein renew manuell ohne froxlor cron aus, bleibt eine Aktualisierung der Zertifikate in der Froxlor Datenbank aus und du hast unterschiedliche Datenstände

    Ok, dann habe ich es durch diesen einen händischen acme.sh-Aufruf schlimmer gemacht. Dafür gibt es ja zum Glück Backups. Und dann vergleiche ich mal Dateisystem mit FROXLOR-DB.

  20. 1 minute ago, d00p said:

    Ja ich bereu auch immer öfter auf acme.sh gesetzt zu haben und nicht bei der reinen API implementierung geblieben zu sein, irgendwie macht es bei vielen Leuten nur Probleme. Froxlor schaut ja nach ob acme.sh installiert ist und führt auch ggfls ein upgrade via acme.sh aus, damit das immer schön auf dem neuesten stand ist. Das schlug bei dir offenbar aus irgendeinem Grund fehlt. Wieso kann ich leider nicht sagen.

    Du vermutest also das Update/Upgrade von acme.sh itself? Das hat die Version und Checksumme, wie das gerade auf github.com verfügbare. Also irgendwann und irgendwie schein das Aktuellhalten auch mal zu funktionieren. Bis hierher habe ich den Eindruck, ich könnte die Cron-Meldungen, sofern sie nur vereinzelt auftauchen, einfach ignorieren.

  21. Ich habe mal das acme.sh mit --renew und DOMAIN1.de ausgeführt, das ging problemlos.

    ns1:~/.acme.sh# ./acme.sh -r -d DOMAIN1.de --force
    [Di 31. Mär 13:10:37 CEST 2020] Renew: 'DOMAIN13.de'
    [Di 31. Mär 13:10:37 CEST 2020] Creating domain key
    [Di 31. Mär 13:10:38 CEST 2020] The domain key is here: /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.key
    [Di 31. Mär 13:10:38 CEST 2020] Multi domain='DNS:DOMAIN1.de,DNS:www.DOMAIN1.de'
    [Di 31. Mär 13:10:39 CEST 2020] Getting domain auth token for each domain
    [Di 31. Mär 13:10:42 CEST 2020] Getting webroot for domain='DOMAIN1.de'
    [Di 31. Mär 13:10:42 CEST 2020] Getting webroot for domain='www.DOMAIN1.de'
    [Di 31. Mär 13:10:42 CEST 2020] DOMAIN1.de is already verified, skip http-01.
    [Di 31. Mär 13:10:42 CEST 2020] www.DOMAIN1.de is already verified, skip http-01.
    [Di 31. Mär 13:10:42 CEST 2020] Verify finished, start to sign.
    [Di 31. Mär 13:10:42 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/70743315/284201xxxx
    [Di 31. Mär 13:10:44 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/04cad67ea8430f8aaf05f4b2784axxxxxxxx
    [Di 31. Mär 13:10:45 CEST 2020] Cert success.
    -----BEGIN CERTIFICATE-----
    MIIGdjCCBV6gAwIBAgISBMrWfqhDD4qvBfSyeEpsZ6IsMA0GCSqGSIb3DQEBCwUA
    ...
    51LtN4Khp6c+z6j134QlCagAUF3OrYVVQyE=
    -----END CERTIFICATE-----
    [Di 31. Mär 13:10:45 CEST 2020] Your cert is in  /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.cer
    [Di 31. Mär 13:10:45 CEST 2020] Your cert key is in  /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.key
    [Di 31. Mär 13:10:45 CEST 2020] The intermediate CA cert is in  /root/.acme.sh/DOMAIN1.de/ca.cer
    [Di 31. Mär 13:10:45 CEST 2020] And the full chain certs is there:  /root/.acme.sh/DOMAIN1.de/fullchain.cer
    

    Habe ich jetzt ein Problem nur zu bestimmten Zeiten oder macht FROXLOR das Mithilfe der acme.sh in ganz anderen Verzeichnissen mit ganz anderen Parametern?

  22. Hallo,

    mit Einführung des begrüßenswerten LE-Supports in FROXLOR schien hier jede dritte Meldung damit zusammenhängen. Eigentlich wollte ich auf den Zug nicht auch noch aufspringen (müssen). Nun komme aber auch ich seit einigen Tagen nicht weiter.

    cron führt regelmäßig den froxlor_master_cronjob mit dem Parameter --tasks aus und meldet dabei neuerdings ca. 1x am Tag:

    gzip: stdin: not in gzip format
    tar: Child returned status 1
    tar: Error is not recoverable: exiting now
    /root/.acme.sh/acme.sh: Zeile 6310: gtar: Kommando nicht gefunden.
    [Di 31. Mär 02:00:02 CEST 2020] Extraction error.
    [Di 31. Mär 02:00:02 CEST 2020] Upgrade failed!

    Schaut man sich die Zeile 6310 in der acme.sh an, wird klar, dass nicht das fehlende "gtar" das Problem ist, sondern offenbar ein korruptes Archiv, welches zuvor mittels "tar" versucht wird zu entpacken.

        if ! (tar xzf $localname || gtar xzf $localname); then
    

    Auch ein manueller Aufruf des Task mit --force bleibt seit Tagen am Renew der gleichen Domains hängen.

    ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/FROXLOR_DOCROOT/scripts/froxlor_master_cronjob.php --tasks --force
    [error] Could not get Let's Encrypt certificate for DOMAIN1.de:
    [Di 31. Mär 12:46:08 CEST 2020] Renew: 'DOMAIN1.de'
    [Di 31. Mär 12:46:08 CEST 2020] Skip, Next renewal time is: Di 26. Mai 08:20:23 UTC 2020
    [Di 31. Mär 12:46:08 CEST 2020] Add '--force' to force to renew.
    [error] Could not get Let's Encrypt certificate for DOMAIN2.de:
    [Di 31. Mär 12:46:08 CEST 2020] Renew: 'DOMAIN2.de'
    [Di 31. Mär 12:46:08 CEST 2020] Skip, Next renewal time is: Do 28. Mai 08:30:24 UTC 2020
    [Di 31. Mär 12:46:08 CEST 2020] Add '--force' to force to renew.
    

    Wie kann ich das Problem weiter zu seiner Ursache hin verfolgen? Welche Angaben sind für weitere Hilfe nötig? Am Start ist die 0.10.15 auf Debian Buster.

    Danke fürs Lesen, Draufrumdenken und ggf. unterstützen.

      Ronny

  23. Hallo,

    ich bin einer der angeblich Wenigen, die von FROXLOR auch DNS verwalten lassen. Das führte am Wochenende zu einer leider ellenlangen Fehlersuche. Ich möchte anregen in den LE-Task eine zusätzliche Prüfung einzubauen, wobei ich noch nicht gänzlich durchdacht habe, ob das überhaupt realisierbar ist (z.B. Wildcard).

    Ein Kunde, der Jahr und Tag seine Domain und auch sein DocRoot bei mir auf dem Server hatte, hat auch LE aktivert.
    Nun ist er ohne mir ein Zeichen zu geben, auf anderen Webspace gewechselt und hat dazu im DNS-Editor für die Subdomain www einen A-record angelegt.
    Jetzt kam aber LE daher und wollte das Zertifikat erneuern und fand dann aber auf der Webseite das /.well-known/acme-challenge/ nicht.
    Ich Troll habe mir die Alias-Konfig angeschaut, LE für Die Domain aus und wieder an gemacht, nach .htaccess gesucht, mit anderen Domains verglichen - hat alles zu nix geführt. Wenn ich mal gleich geguckt hätte, wer da zur URL eigentlich Content ausliefert.

    Unschön an einer solchen Geschichte ist nicht nur der Aufwand sondern auch, das LE tagelang brach lag, weil ich dort wegen Fehlversuchen bereits gesperrt war. Toll wäre aus dieser Erfahrung einen Check abzuleiten, der vor Zertifikatsanforderung bzw. -verlängerung via DNS nachschaut, ob man überhaupt wieder auf der von FROXLOR verwalteten Kiste landet auf der auch die acme-challenge verwaltet wird.

    Als feature request in den bugtracker?

×
×
  • Create New...