Letsencrypt: Zertifikat automatisiert exportieren?

[Emma2]

Hallo.

Ich bin begeistert, dass man mit dem Letsencrypt-Plugin sehr komfortabel Zertifikate anfordern und wohl auch automatisiert erneuern kann.

Mein Problem ist nun, dass ich DAS SELBE Zertifikat auch auf einem anderen Rechner brauche.

(Hintergrund, kann ignoriert werden: Ich betreibe einen Applikationsserver/MS-RDP, und der braucht ebenfalls eine sichere Verbindung.
Unser Versuch, INTERN - also zwischen Firewall, RD-Gateway und RD-Applikationsserver - ein selbsterstelltes Zertifikat zu nutzen, funktioniert nicht richtig, denn die neuen MS-RDP-Clients (ab Win 8.1) prüfen anscheinend die gesamte Zertifikatskette und brechen bei nicht durchgehender Kette die Verbindung ab.)

Funktionierende Lösung: Das Zertifikat der opnSense wird exportiert und auf dem RD-Server installiert.
(Hintergrund: Sofort funktioniert es.)

Ich suche also nach einem Weg, das Zertifikat regelmäßig von der opnSense zu exportieren und in meinem LAN zugreifbar zu machen. Ist das möglich?
Ich möchte es dann per Powershell abholen und in meinen RD-Server importieren.

[JeGr]

> Mein Problem ist nun, dass ich DAS SELBE Zertifikat auch auf einem anderen Rechner brauche.

Warum? Wofür brauchst du das gleiche Zertifikat auf der Sense dann überhaupt, wenn du den Zugriff via RDP auf die Kiste durchreichst? Ich sehe da den Grund nicht, warum die Sense dann überhaupt das Zertifikat haben sollte?

[Emma2]

Hallo, Jens.

Auch auf die Gefahr hin, dass ich etwas übersehe oder bisher ganz falsch verstehe:
Wir machen KEIN Port-Forwarding, sondern brauchen den HAProxy zur Verteilung der hereinkommenden Anfragen,
die entweder auf unseren Webserver oder eben den RDP-Server umgeleitet werden.
Weiterhin verlangt die Portal-Webseite, auf der man sich anmeldet, zwingend eine SSL-Verbindung.
Somit brauchen wir auf der opnSense ein Zertifikat.

Wenn man dann eine RD-Applikation startet, erhält man eine RDP-Datei mit den Verbindungsdaten,
und die Microsoft-Lösung verpackt anschließend RDP in HTTPS, so dass auf dem RD-Server ebenfalls ein Zertifikat benötigt wird.
Hierfür hatten wir uns ein selbsterstelltes Zertifikat gebaut und uns selbst als CA auf dem RD-Server eingetragen. Das funktioniert auch... aber nur mit den RDP-Clients auf Android, iPhone und bis Win7. Der MS-RDP-Client ab Win 8.1 hat offenbar Probleme damit, bzw. bricht ganz plump die Verbindung ab.
(Um ehrlich zu sein: da es keine detaillierten Meldungen gibt, können wir nicht genau nachvollziehen, WEM und AN WELCHER STELLE da etwas nicht gefällt.)
Fakt ist aber, dass nach dem Kopieren und Installieren des SELBEN Zertifikats, das auch auf der opnSense verwendet wird, der Zugang auch mit den neueren RDP-Clients funktioniert.

Deshalb die Idee: wir nutzen das eine Zertifikat für beide Server... aber dazu würde ich es gern automatisiert von der opnSense exportieren und auf dem RD-Server importieren.

[JeGr]

> Auch auf die Gefahr hin, dass ich etwas übersehe oder bisher ganz falsch verstehe:
Dafür sind die anderen Augen da um dir das ggf. offenbar zu tun

> Wir machen KEIN Port-Forwarding, sondern brauchen den HAProxy zur Verteilung der hereinkommenden Anfragen,
die entweder auf unseren Webserver oder eben den RDP-Server umgeleitet werden.
OK Frage bereits beantwortet.

> Somit brauchen wir auf der opnSense ein Zertifikat.
Das stimmt so aber nicht ganz, oder? Du hast die Möglichkeit in HAProxy SSL zu terminieren und ins Backend neu zu verschlüsseln. Variante 1. Variante 2: Du sprichst ins Backend nur noch HTTP. Geht auch. Variante 3: Du machst weder re-encryption noch fallback auf HTTP, sondern HAProxy reicht die TCP Verbindung durch OHNE das TLS zu beantworten - dann antwortet ganz normal der Server selbst. Dann braucht auch HAProxy kein Zertifikat da er nicht selbst antwortet.

[Emma2]

> Auch auf die Gefahr hin, dass ich etwas übersehe oder bisher ganz falsch verstehe:
Dafür sind die anderen Augen da um dir das ggf. offenbar zu tun

Habe ich schon bemerkt - deshalb frage ich ja auch so eifrig 

> Somit brauchen wir auf der opnSense ein Zertifikat.
Das stimmt so aber nicht ganz, oder? (...)

Ich bin nicht sicher, ob einer Deiner Fälle auf mein Szenario passt... und wenn doch, wie ich ihn konfiguriere?

Variante 1: Kann ich auf der opnSense das SSL terminieren und dann die Aufrufe per Hostname/URL auf verschiedene interne Server neu verteilen? Dann könnte das klappen.

Variante 2: Kommt nicht in Frage, denn die MS-RDP-Lösung verlangt zwingend auch intern SSL.
(BTW: Mit unserer Website machen wir das so, da lassen wir den internen Verkehr zwischen opnSense und Webserver einfach unverschlüsselt.)

Variante 3: Könnte ich also "HHTPS einfach durchreichen"? Kann die opnSense dann trotzdem auf Basis Hostname/URL den Traffic an verschiedene interne Server weiterreichen? Und auf dem Client sieht es so aus, als würde er den ganzen Weg über "HTTPS sprechen"?

Gibt es für Variante 1 und Variante 3 schon Beschreibungen oder gar HOWTOs?

[JeGr]

1) Ich dachte genau das machst du gerade?

3) Normalerweise schon, wenn der Client brav den SNI Header mit durchreicht sollte sie das sehen. Müsste man einfach mal testen. Und das ist alles HAProxy Sache, nichts mit der OPNsense zu tun Und es sieht am Client nicht so aus, es ist so, dass durchgehend TLS gesprochen wird.

Ich kenne die Konfiguration nur von der pfSense, aber es wird im Frontend konfiguriert. Du brauchst die verschiedenen Backends (also deine internen Server auf die verteilt wird). Und im Frontend wird dann an mit ACLs und Actions die Domain auf Backends zugewiesen:
Bspw. ACL host1_acl mit Expression: Host matches und value host1.domain.tld wird dann in einer Action auf Backend "host1" zugewiesen (Action Use Backend, Condition/acl matches: host1_acl). Und dann genauso mit Host2 etc.

[Emma2]

1) Ich dachte genau das machst du gerade?

Ja, ist auch so... ich war nur gerade noch etwas mehr verwirrt.
Ich überprüfe das gerade noch einmal, was genau bei uns Sache ist.

3) Normalerweise schon, wenn der Client brav den SNI Header mit durchreicht sollte sie das sehen. Müsste man einfach mal testen. Und das ist alles HAProxy Sache

Ok, würde ich gern mal testen, aber dann ist mir nicht ganz klar, wie das abgeht:

Wenn ich auf dem HAProxy mit HTTP ankomme (wenn man also http://my.blablaapp.de/rdweb) eingibt, kann ich das auf HTTPS umleiten. So weit, so klar. Aber was steht dann im Browser des Clients? HTTP oder HTTPS?

Wenn der Kunde gleich https://my.blablaapp.de/rdweb eingibt, dann muss ich doch auf dem HAProxy dafür schon ein Zertifikat angeben? Oder nicht? Kann ich dem HAProxy sagen: "Kümmere Dich nicht drum, sondern lass das den Server xyz.intern.lan machen!"?

NB: Ich bin noch nicht ganz durch mit den verschiedenen "SSL-Häkchen" im HAProxy.
Für unsere Website (extern HTTPS, intern HTTP) haben wir es jetzt so gemacht:
- Public Service mit "Enable SSL offloading", Zertifikat eingetragen, Regel für den Hostname/URL
- Regel hierfür zur Nutzung des dafür vorgesehenen Backend Pools
- Backend Pool enthält Server, dieser hat KEIN SSL-Häkchen, aber es MUSS explizit Port 80 dort stehen
(wenn nicht, dann versucht der HAProxy intern über 443 weiter zu gehen und es geht NICHT ohne Zertifikat auf dem Webserver).
Das funktioniert zumindest, und ich hoffe, die Konstruktion ist einigermaßen sinnvoll.
Wie ich jetzt aber die "Umkehrung" machen kann, ist mir irgendwie noch schleierhaft  ...

[JeGr]

> - Public Service mit "Enable SSL offloading", Zertifikat eingetragen, Regel für den Hostname/URL
Und wenn du dort statt offloading als Typ TCP/SSL einstellst (ohne offloading) erscheint auch nirgends was für Zertifikate zum Hinterlegen, weil das vom Backend durchgereicht wird

[Emma2]

> - Public Service mit "Enable SSL offloading", Zertifikat eingetragen, Regel für den Hostname/URL
Und wenn du dort statt offloading als Typ TCP/SSL einstellst (ohne offloading) erscheint auch nirgends was für Zertifikate zum Hinterlegen, weil das vom Backend durchgereicht wird

Ja, danke, das hatte ich nicht gesehen, sieht gut aus...

... allerdings hilft das für mein eigentliches Problem nicht weiter:
Es sieht nun so aus, als würde der "neue" MS-RDP-Client sofort die Verbindung verweigern (Authentifizierungsfehler), wenn das Zertifikat nicht von einer echten CA ist. Ich brauche also auch hinter der opnSense ein "echtes" Zertifikat.

Das kann ich mir nun neu holen, oder ich nutze das, was sowieso schon auf der opnSense liegt.
Der zweite weg wäre mein Favorit.


Deshalb noch einmal meine ursprüngliche Frage:
Kann ich ein Zertifikat anders exportieren als über die Weboberfläche? Wie wär's mit SSH (also ähnlich der Anleitung zum automatisierten Backup)? Wenn ja, wo finde ich Doku zu den passenden Befehlen?

[JeGr]

> Ich brauche also auch hinter der opnSense ein "echtes" Zertifikat.

Dem habe ich ja nicht widersprochen, aber dann kann deine Kiste, die das Zertifikat eh braucht DIREKT das Zertifikat via ACME Client anfordern und du brauchst es nicht an beiden Stellen. Darum gings

[Emma2]

Nach dem Lesen der Preview-Darstellung, stelle ich mal um und das Wichtigste nach oben:

Alternative: Ich de-zertifikat-isiere die opnSense/HAProxy wieder und reiche es wie von Dir beschrieben doch an die Webserver weiter. Dazu dann aber: Kann ich das mischen?
Kann ich meine Websites so lassen (außen HHTPS, innen HTTP) und nur die RDP-Kommunikation umstellen (HTTPS ohne reingucken weiterleiten)? Wenn ja, wie? Brauche ich dann zwei Public Services, einen für jede "Gruppe"? Sorry für die vielen Einsteigerfragen  .

---

Ja, vermutlich ist meine ursprüngliche Vermutung falsch, und ich brauche nicht vor unter hinter der opnSense/HAProxy das selbe Zertifikat.
Dennoch wäre das ganz "schön", deshalb halte ich noch immer meine ursprüngliche Frage nach dem Export aufrecht  .

Warum bin ich so störrisch? Ich sehe neue Probleme:
Die MS-Architektur ist hier (zumindest für mich) ein bisschen "unübersichtlich", und es ist nicht ganz klar, wann und wie welche Namen (für Portalserver, Gatewayserver, Applikationsserver etc.) verwendet werden.
Deshalb "funktioniert es ganz gut", wenn die alle auf dem selben physischen Server laufen, und dazu heißen die dann auch alle gleich. Mit anderen Worten: die Portalseite heißt "my.blablubb.de", ist so von außen erreichbar, und deshalb heißt auch das Zertifikat so. Der Server intern ist aber genauso erreichbar (denn sonst müsste ich seinen Namen veröffentlichen, um nicht eine Warnung zu bekommen), und er braucht deshalb auch ein Zertifikat dieses Namens. Wenn ich dieses nun "von innen" anfordere, dann fängt doch schon die Challenge-Seite auf der opnSense die Anfrage ab. Oder etwa nicht?

[Emma2]

Es hat mir doch keine Ruhe gelassen, und ich wollte es "schnell mal" testen  ...

Kann ich meine Websites so lassen (außen HHTPS, innen HTTP) und nur die RDP-Kommunikation umstellen (HTTPS ohne reingucken weiterleiten)?

Das scheint wohl nicht zu gehen. Es sieht für mich so aus, als könnte es pro Port nur einen Listener (Public Service) geben. Wenn ich also die Zertifikate auf die Server veschieben will, dann muss ich das komplett machen, also auch für die "einfachen" Websites. Ist das so?

Ich de-zertifikat-isiere die opnSense/HAProxy wieder und reiche es wie von Dir beschrieben doch an die Webserver weiter.

Das hat jetzt "so ohne Weiteres" nicht funktioniert 
Ich habe den bestehenden (funktionierenden) Public Service so abgeändert, dass ich "Enable SSL offloading" abgeschaltet (und die Zertifikate entfernt) habe, dann habe ich den "Type" umgestellt auf "SSL/HTTPS (TCP mode)", habe ihn aber weiter auf Port 443 lauschen lassen.

Dann habe ich den Zugriff von extern mit Edge, IE11 und Opera versucht, erhalte aber immer die Meldung, dass keine sicherere Verbindung aufgebaut werden könne. Was mache ich falsch?