[Solved]Frage zu LE-Zertifikaten (ACME-Client): Formate unterscheiden sich -- warum?

[white_rabbit]

Hallo.
Ich habe eine Frage zum Herunterladen und Weiterleiten von Let's Encrypt Zertifikaten.
Es ist so, dass bei uns die OPNSense zusammen mit HAProxy als reverse Proxy dient. Der ACME-Client erneuert für unterschiedliche Server die LE-Zertifikate regelmäßig direkt auf der OPNSense. Bis dahin alles kein Problem.
Wenn ich von außen etwas versuche wie

Code Select Expand

openssl s_client -connect mein-server.meine-domain.de:443
erhalte ich die vollständige Zertifikateskette

Code Select Expand

depth=3 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=2 C = US, O = ISRG, CN = Root YR
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = YR1
verify return:1
depth=0 CN = mein-server.meine-domain.de
verify return:1
---
Nun ist es aber so, dass ich diese Zertifikate auch herunterlade (und zwar: firewall:/var/etc/acme-client/cert-home/$id/$hosts/fullchain.cer !!) und lokal direkt auf die Server verteile, damit man auch lokal bzw im Intranet damit arbeiten kann. Wenn ich das mache, ist die "Chain of Trust" plötzlich kürzer und besteht nur noch
aus

Code Select Expand

Certificate chain
 0
und nicht mehr aus

Code Select Expand

0
1
2
Ich kenne mich nicht gut genug aus, um sagen zu können, was da genau fehlt, aber nach allem, was ich gelesen habe, scheint es so zu sein, dass in dem Fall, dass ich aus dem Intranet den Befehl

Code Select Expand

openssl s_client -connect mein-server.meine-domain.de:443
verwende, nicht die fullchain.cer/pem verwendet wird, sondern dass in diesem Fall (warum?) das Intermediate-Zertifikat fehlt? Stimmt das so?
Meine Frage ist natürlich, warum und wie man das verhindern kann?

(Der Hintergrund der Frage ist eigentlich ein völlig anderer: Ich wollte einen LXC-Container unter Proxmox installieren, der immer merkwürdige Fehler ausgespuckt hat. Dort funktioniert auf der Shell aber schon ein einfaches "curl https://..." nicht
("curl: (60) SSL certificate problem: unable to get local issuer certificate"))

Wie kann man das Problem lösen? Die ACME-Zertifikate werden auf alle genau gleich erstellt. (Challenge Typ http-01)
Danke für einen guten Tipp.

[viragomann]

Hallo,

Es ist so, dass bei uns die OPNSense zusammen mit HAProxy als reverse Proxy dient. Der ACME-Client erneuert für unterschiedliche Server die LE-Zertifikate regelmäßig direkt auf der OPNSense.

Nun ist es aber so, dass ich diese Zertifikate auch herunterlade (und zwar: firewall:/var/etc/acme-client/cert-home/$id/$hosts/fullchain.cer !!) und lokal direkt auf die Server verteile, damit man auch lokal bzw im Intranet damit arbeiten kann.

Andere Herangehensweise:
Ich verwende ebenfalls HAproxy, tlw. mit LE Zertifikaten vom ACME Client, und ebenfalls TLS Verbindungen zu den Backends. Allerdings habe ich auf diesen Zertifikate von einer internen CA auf OPNsense installiert.

Ich verwende hierfür kein Split-DNS, so dass die Hostnamen auf die auf WAN-IP aufgelöst werden. So laufen interne Verbindungen ebenfalls über HAproxy und die Clients bekommen das passende Zertifikat.

Wenn du allerdings einen Router davor geschaltet hast, müsstest du dennoch DNS Overrides konfigurieren, aber diese eben auf die OPNsense WAN setzen.

Grüße

[white_rabbit]

Hallo.
Danke für die Tipps. Ich wollte eigentlich schon länger auf caddy als reverse Proxy wechseln -- komme aber im Moment nicht dazu. HAProxy finde ich (leider) recht unübersichtlich. Aber das eigentliche Problem steckte hier tatsächlich in dem verwendeten Zertifikat auf dem Server. Da es sich dort um zwei Installationen (LXC- bzw docker) handelte, war die Einstellung ziemlich versteckt. Ich musste den Containern beibrigen, dass sie die fullchain.cer nehmen sollen. Seitdem hat curl funktioniert und die Verbindung kam zustande.
Dennoch danke für's Mitdenken.

[meyergru]

Was ich nicht ganz kapiere: Was musst Du den Containern beibringen?

Wenn Du mit HAproxy als Reverse Proxy arbeitest, macht der doch die TLS-Terminierung inkl. der Beantragung der ACME-Zertifikate?

Wozu dann also Zertifikate auf den Backends? Wenn das wegen TLS-Verschlüsselung benötigt wird, mache ich das genauso wie Viragomann, nämlich mit eigener CA, wodurch das Gezauber mit Übertragung von Zertifikaten vermieden wird. Andererseits ist das oft gar nicht notwendig, z.B. weil die Backends in einer DMZ eingesperrt sind, auf die sonst nichts Zugriff hat. Deswegen arbeite ich auf den Backends meist unverschlüsselt.

Aufgrund der Level 7 Übersetzung im Proxy muss man ja die Client-Infos sowieso per Header übertragen, dann hat man auch die richtigen Infos über eingesetzte Mechanismen usw. für die Backend-Protokollierung.

[white_rabbit]

Hi.

Wenn Du mit HAproxy als Reverse Proxy arbeitest, macht der doch die TLS-Terminierung inkl. der Beantragung der ACME-Zertifikate?

Ja, das macht der HAProxy auch -- und eigentlich funktioniert das auch. Allerdings haben wir hier zusätzlich auf dem unbound diverse Domain-/IP-Überschreibungen. Wenn ich mich richtig erinnere, hat das immer wieder Ärger gemacht, wenn dann das Zertifiktat nicht direkt auf dem Host war. Für die DMZ bin ich mir da gerade nicht sicher aber bei anderen Servern (einer davon ist nochmal wie weiter oben schon vermutet hinter einem Router), musste ich das Zertifikat dann leider immer lokal übertragen. Wie gesagt: Es ist sehr gut möglich, dass das viel eleganter geht.
In diesem Fall war es auch so, dass sich der Webserver nicht so pingelig angestellt hat wie openssl/curl.


Diese Seite hat mir übrigens weitergeholfen ... vielleicht auch für andere hilfreich:
https://linuxconfig.org/testing-https-client-using-openssl-to-simulate-a-server

[meyergru]

Ja, klar. Bei Reverse Proxying muss man schon etwas tun, damit das Backend a. die richtigen Infos sieht und b. sich selbst für den "externen" Server hält, z.B. für absolute Redirects oder Pfad-Umschreibungen. Da gibt es Details, die nicht mal im Tutorial von @TheHellSite stehen, z.T. sogar anwendungsspezifische Regeln für NextCloud.