[GELÖST - NICHT ERKLÄRT] Lets Encrypt - Fehler bei Zertifikatserstellung

[Emma2]

Ich bin "mal wieder" ein bisschen ratlos, und ehe ich bei Let's Encrypt" frage, versuche ich es lieber hier... 

Es gelingt mir aktuell nicht, ein bestimmtes Zertifikat zu erneuern, obwohl es bis vor Kurzem reibungslos funktioniert hat. Ich wage jetzt nicht zu sagen, ich hätte nichts geändert (bin mir aber dessen "ziemlich" sicher).

Was jedoch für mich das Seltsamste ist: es gibt zwei "parallele" Zertifikate, von denen eines gelingt und das andere eben nicht. Vielleicht habt Ihr ja eine Idee?

Situation:
Ich habe einen Apache auf Ubuntu laufen, auf dem es verschiedene Virtual Hosts gibt. Beide sind von außen problemlos zu erreichen! Die benötigten Einstellungen im HAProxy sind - nach mehrmaligem Vergleichen - für beide Ziele identisch. Die Daten der Zertifikate sind fast identisch (einziger Unterschied: das funktionierende hat sogar noch eine zweite Domain eingetragen).

Die nicht funktionierende Zertifizierung liefert mir im Log dieses:

Code: [Select]

[Fri Jul  2 12:38:20 CEST 2021] POST
[Fri Jul  2 12:38:20 CEST 2021] _post_url='https://acme-v02.api.letsencrypt.org/acme/finalize/31063332/10795776144'
[Fri Jul  2 12:38:20 CEST 2021] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header  -L '
[Fri Jul  2 12:38:31 CEST 2021] _ret='0'
[Fri Jul  2 12:38:31 CEST 2021] code='403'
[Fri Jul  2 12:38:31 CEST 2021] Sign failed, finalize code is not 200.
[Fri Jul  2 12:38:31 CEST 2021] {
  "type": "urn:ietf:params:acme:error:orderNotReady",
  "detail": "Order's status (\"invalid\") is not acceptable for finalization",
  "status": 403
}
[Fri Jul  2 12:38:31 CEST 2021] _on_issue_err
... und alles, was ich zu diesem Fehler bisher finden konnte, scheint auf mich nicht zuzutreffen.
Ich bin etwas ratlos und hoffe, dass Ihr wieder mal schlauer seid als ich es bin. 

[Emma2]

Oh... 
Hat niemand eine Idee, was ich wo überprüfen könnte?
(Denn natürlich nehme ich an, dass der Fehler irgendwo bei mir liegt...)

[JeGr]

Hast du mal die Dialoge geprüft, dass überall alles korrekt eingetragen ist? Da man es gerade beim NGinx Plugin gesehen hat, könnte es ja evtl. durch das letzte Update vielleicht einen Bug im ACME Modul gegeben haben. Ansonsten ist es schwer zu sagen, wenn man die Unterschiede des Zerts nicht sieht. Vielleicht auch irgendwo ein Sonder- oder Leerzeichen reingerutscht wo keines hin soll? Machst du das ansonsten gegen die Production API oder die Testing API? Ich würde immer Testing empfehlen bis es einmal sauber durch läuft und dann umschalten auf Production damit man nicht geblockt wird (LE hat nen Ban bei zu vielen Fehlschlägen bis zu einer Stunde?)

Cheers

[Emma2]

Ich werde es nun noch einmal ganz genau vergleichen.
(Kann ich eigentlich auch irgendwo die "Textversion" einsehen, oder muss ich das immer über die GUI machen - die dafür manchmal ein bisschen sperrig wirkt?)

[JeGr]

Im Zweifelsfall könntest du per SSH auf der Konsole die Files vergleichen oder ansehen. Das wäre zumindest meine erste Anlaufstelle

Mit dem Vergleichen habe ich nicht impliziert, dass du das nicht schon gemacht hast nur wenn ich nicht mehr habe zum Ansehen, wird es schwer einen Fehler zu finden und zu erkennen

[Emma2]

Moin. Ich fühlte mich nicht belehrt, überhaupt nicht. Ich wollte damit nur offen lassen, ob ich nicht doch einen Unterschied übersehen habe. Aber gern stelle ich die Infos zur Verfügung:

• Per SSH auf die OPNsense gehen kann ich wohl
• Welche Dateien bzw. welche Teile daraus sind denn interessant?
• Ich will das (anonymisiert) gern hier posten.

Damit Du mir sagen kannst, was ich hier posten soll, vielleicht kurz meine Architektur:
(NB: Ich habe das fast gleiche Problem noch mit einem anderen Zertifikat, aber die sind beide auf verschiedenen OPNsenses, deshalb gehe ich das erst im zweiten Schritt an.)

• Ich habe ein Ubuntu 18.04, und darauf laufen zwei DokuWiki "doc" und "dop" und eine Gallerie-Site "pix" als drei Virtual Hosts
• Jede dieser drei Websites ist aus meinem LAN heraus zu erreichen (habe passende DNS-Einträge)
• Um alle drei auch von außen erreichbar zu machen, habe ich entsprechende Nameserver-Einträge erstellt.
• Unterschied: "doc" liegt auf einer de-Domain, "dop" und "pix" auf einer anderen.
• Alle drei Sites sind von außen zu erreichen, aber "doc" dann eben mit Zertifikats-Warnung
• Auf meinem HAProxy-Dienst habe ich für alle drei URLs je eine "Host enthält"-Bedingung und eine "Verwende Backend-Pool"-Regel
• Jede der drei Regeln hat ihren "eigenen" Backend-Pool, der einen eigenen "Realen Server" nutzt. (Allerdings sind alle drei "Realen Server" in IP/Port identisch - und werden vom Apache als Virtual Hosts unterschieden.
• Bei den "Öffentlichen Diensten" habe ich für alle drei HTTP eine HTTPS-Weiterleitungsregel (die habe ich aber für alle Websites), und bei HTTPS habe ich für alle drei entsprechende Regeln und dort die Zertifikate angegeben.
• Im Let's Encrypt-Dienst habe ich ein Zertifikat für "doc" und eines für "dop" mit "pix" als Alternativname.
• Das Zertifikat für "dop (mit pix)" kann ich problemlos erneuern.
• Das Zertifikat für "doc" lsst sich nicht erneuern. Die Log-Einträge habe ich oben gepostet.

Was genau kann ich nun posten, damit Ihr mir vielleicht weiterhelfen könnt?

[Emma2]

Jetzt wird es seltsam, und ich befürchte, dass der Fehler doch irgendwo "bei mir" liegt:

• Ich habe nun "als Test" die nicht-funktionierende Domain "doc" zu einem funktionierenden Zertifikat "mail" dazugeschrieben und dieses neu angefordert. Das schlug erwartungsgemäß fehl.
• Nach dem Wieder-Löschen von "doc" - kann dieses Zertifikat "mail" nun auch nicht mehr erneuert werden!
• Aber nun habe ich es auch für "dop (mit pix)" nochmal versucht, und auch das schlägt fehl, obwohl es am 2.7. noch funktioniert hat.
• Und seitdem habe ich ganz sicher nichts an der OPNsense verändert.
• Zunächst scheint alles zu klappen bis "Verify finished, start to sign."
• Dann bekomme ich als Fehler immer "{ "type": "urn:ietf:params:acme:error:orderNotReady", "detail": "Order's status (\"invalid\") is not acceptable for finalization", "status": 403 }"
• Wie kann es denn sein, dass das "Verify" klappt und nur das "Sign" fehlschlägt?
• Das gleiche Problem tritt nun bei einer bisher funktionierenden anderen Website auf (andere de-Domain, sonst keine Änderungen)
• Ich würde ja vermuten, dass es an meinem Konto bei Let's Encrypt liegt, aber das Problem trat schon auf, als einige Zertifikate noch problemlos erneuert werden konnten.
• Ich habe jetzt mal auf "Testumgebung" umgestellt.

[Emma2]

Ich habe jetzt einen "Workaround" für mein Problem, habe aber keine Ahnung, warum der funktioniert bzw. warum es ohne ihn eben nicht funktioniert. Vielleicht könnt Ihr mir helfen, das noch herauszufinden?

Es war ja nun "plötzlich" so, dass ich überhaupt kein Zertifikat mehr erneuern konnte.

Als ersten Versuch habe ich ein neues Konto bei Let's Encrypt registriert. (Dabei weiß ich überhaupt nicht, was passiert: Ich muss nicht antworten, rein gar nichts. "Register" und fertig?) Das hat aber auch sowieso keine Änderung gebracht.

Dann jedoch habe ich den "Challenge Type" geändert von "HAProxy HTTP Frontend Integration (OPNsense plugin)" auf "OPNsense Webdienst (automatische Portweiterleitung)" - und damit funktioniert es auf Anhieb wieder!?
Ich bin sehr sicher, dass ich an den Elementen "Added by Let's Encrypt plugin" nichts geändert habe. Aber ich habe eine ganz vage Erinnerung, irgendwo gelesen zu haben, dass im HAProxy (oder im dazugehörenden ACME-Client) letztens ein Fehler war. Kann das sein? Ich finde das nicht mehr und bin deshalb nicht zu 100% sicher. Oder andersherum:

Wo liegt bei mir der Fehler, wenn es mit "OPNsense Webdienst" klappt, mit "HAProxy Frontend" aber nicht? Welches der automatisch hinzugefügten Objekte kann oder muss dann fehlerhaft sein? (Ein kurzer Blick da drauf zeigt für mich zumindest keinen Fehler... noch dazu: dann hätte ich auf zwei völlig getrennten OPNsenses den gleichen Fehler eingebaut haben müssen...)

So ein "Workaround" hinterlässt bei mir eine unangenehme Unsicherheit, weshalb ich das gern erklärt hätte. Danke!

[Emma2]

Hat keiner 'ne Idee? Oder bin ich zu ungeduldig? 

[lfirewall1243]

Hat keiner 'ne Idee? Oder bin ich zu ungeduldig? 

Hast du die vom Acme Plugin erstellte regeln im HAProxy auch aktiviert und im Frontend hinterlegt?

Hört dein haproxy auch auf Port 80 und 443?

Passen die fw Regel für 80/443?

[Emma2]

Was meinst Du mit "im Frontend hinterlegt"?

Es gibt folgende Bedingungen:

• find_acme_challenge - Pfad beginnt mit - /.well-known/acme-challenge/
• no_acme_challenge (von mir) - Pfad beginnt mit (NEGIERT) - /.well-known/acme-challenge/

und folgende Regel:

• redirect_acme_challenges - IF - find_acme_challenge -- DANN - Use backend pool "acme_challenge_backend"
• redirect_HTTP_to_HTTPS_website (von mir) - IF - no_acme_challenge AND HTTP AND WWW_mySite -- DANN - Umleitung HTTP auf HTTPS

Der Backend-Pool "acme_challenge_backend" ist unverändert.
Der öffentliche Dienst auf 443 nutzt meine Zertifikate und die Regeln für die Websites.
Der öffentliche Dienst auf 80 nutzt die Regeln "redirect_acme_challenges" und die für die Website-Umsetzungen (HTTP/HTTPS).

Momentaner Stand ist:

• Alles funktioniert, wenn ich bei Let's Encrypt im "Challenge Type" den "OPNsense Webdienst" einstelle.
• Nichts funktioniert, wenn ich bei Let's Encrypt im "Challenge Type" "HAProxy Frontend Integration" einstelle. Es scheint also "irgendwie" mit meinem HAProxy zu tun zu haben.

Ist es denkbar, dass sich am ACME-Client etwas geändert hat, so dass meine "no_acme_challenge"-Regel nicht mehr funktioniert und nun auch die ACME-Challenges ungewollterweise an die Website geleitet werden (was dann natürlich schiefgeht)? Wie kann ich das überprüfen? Ich könnte meine HTTP-zu-HTTPS-Regeln rauslöschen und es erneut probieren. (Aber das sind "viele".) Oder geht es auch einfacher? Kann ich Regeln eventuell deaktivieren?