Mit HA-Proxy die Zertifikate der Server benutzen

slu

@Wireguard
vielen Dank für die Hilfe.

Ich werde das Abends/Nachts mal mit einem Server probieren.
Im Moment ist eine NAT Regel vorhanden weil derzeit noch 1 IPv4 IP auf ein Server zeigt, die muss dafür auch weg.

Vor allem geht es mir in erster Linie darum kein Mist in Form von einem Sicherheitsproblem zu bauen, für alles andere habe ich Gedult ;)

JeGr

@slu said in Mit HA-Proxy die Zertifikate der Server benutzen:

Was genau meinst Du mit Mixbetrieb?
Ungern weil ein Sicherheitsproblem?
Ich stehe genau vor dem gleichen Problem:
1x IPv4 und dahinter zwei Server welche beide auf 443 lauschen.
Je nach Domain sub1.example.com bzw. sub2.example.com soll es dann auf Server1 oder Server2 gehen.

Mixbetrieb: Man kann nicht mit dem gleichen Frontend einmal TLS annehmen und terminieren und einmal Layer4 annehmen und weiterreichen (ohne die TLS Verbindung zu terminieren). Gemischt geht nicht. Man kann nur eins von beidem. Eigentlich will man meistens eh terminieren, dann kann man die Zertifikate auch auf der Sense handlen und muss nicht auf jedem Client damit rumkaspern.

Und dein Problem ist das einfachste und schnellste was man anlegen kann :) Sei froh ;)

slu

@JeGr said in Mit HA-Proxy die Zertifikate der Server benutzen:

Und dein Problem ist das einfachste und schnellste was man anlegen kann :) Sei froh ;)

So nachdem es ja ganz viele Knöpfe im HAProxy gibt habe ich mir zur Sicherheit ein Testsystem (VM) aufgebaut.

https://server1.example.com -> 10.10.10.10
https://server2.example.com -> 10.10.10.11

Hab ich das so richtig konfiguriert (Frontend Type ist "http/https(offloading)")?

slu

Nach weiterem lesen der Doku ist der Type falsch, es muss ssl/https(TCP mode) sein, richtig?

Damit wäre die ACL Expression "Server Name Indication TLS extension matches"
Und Value "server1.example.com"

JeGr

@slu said in Mit HA-Proxy die Zertifikate der Server benutzen:

Nach weiterem lesen der Doku ist der Type falsch, es muss ssl/https(TCP mode) sein, richtig?

Für was genau denn? :D

slu

@JeGr said in Mit HA-Proxy die Zertifikate der Server benutzen:

@slu said in Mit HA-Proxy die Zertifikate der Server benutzen:

Nach weiterem lesen der Doku ist der Type falsch, es muss ssl/https(TCP mode) sein, richtig?

Für was genau denn? :D

https -> server1.example.com 4444 -> server1 10.10.10.10:4444
https -> server2.example.com 4444 -> server1 10.10.10.11:4444

https://github.com/PiBa-NL/pfsense-haproxy-package-doc/wiki#https-for-multiple-domains-using-sni-from-1-frontend

~~Edit: Ich stelle gerade fest das ich den Thread etwas zweckentfremde, kannst Du den abtrennen und ein neuen Thread draus machen?~~

JeGr

Ja das ist klar, aber muss es weitergeleitet werden (Layer 4) oder willst du SSL terminieren und die Zerts auf der pfSense konfigurieren um alles an einem Platz zu haben?

slu

Die Zertifikate sollen auf den jeweiligen Server bleiben, also nicht auf der pfSense/HAProxy.
Es handelt sich also im Layer 4.

JeGr

OK dann muss es ein https Backend sein (ssl/https TCP mode). Zu erkennen auch daran, dass unten dann die Rubrik für die Zertifikate verschwindet und entfällt

Ansonsten nach SNI filtern, das ist unverschlüsselt und müsste funktionieren, genau. Harter Match oder Regex oder Teilstring je nachdem wie es für dich passt und dann auf die Backends verteilen :)

Wenn du beim Aufruf einen 503 bekommst, dann musst du dir die Stats anschauen, dann sind die Backends ggf. offline (dann kann das Frontend auch nix routen). Wenn die Backends rot sind, dann klappt die Erkennung nicht bzw. der Health Check passt nicht.

Für SSL sollte das mit "enc(SSL) = yes und SSL checks = yes" bei der Server List pro Eintrag und beim Health Check "HTTP" klappen.
Wenn nicht, testweise mal auf "none" oder "Basic" (Ping) stellen, dann müssten sie auf jeden Fall gehen. Dann kann man das "warum" bzw. "wie" mit dem HTTP check später fixen :)

slu

So ich hatte heute die nötige Ruhe und habe das mal konfiguriert, leider ohne Erfolg.

Wenn ich von extern die Domain aufrufe kommt ein SSL_ERROR_RX_RECORD_TOO_LONG.
Hat jemand ein Hinweis für mich was ich falsch gemacht habe?

(IP und DNS Namen sind natürlich anonymisiert und nicht so in der echten Konfig)

frontend VDSL
	bind			WAN_IP:443 name WAN_IP:443   
	mode			tcp
	log			global
	timeout client		30000
	tcp-request inspect-delay	5s
	acl			ACLWebServer	req.ssl_sni -m sub -i web.example.com
	tcp-request content accept if { req.ssl_hello_type 1 }
	use_backend WebServer443_ipvANY  if  ACLWebServer 

backend WebServer443_ipvANY
	mode			tcp
	id			100
	log			global
	timeout connect		30000
	timeout server		30000
	retries			3
	option			httpchk OPTIONS / 
	server			WebServer443 192.168.10.45:443 id 101 ssl check-ssl check inter 1000  verify none

JeGr

Kannst du mal die Screens aus Front- und Backend posten? Ich hab eine Ahnung, aber das müsste ich da sehen. Hatte das gerade auch für nen Kunden eingerichtet und es gab erst die gleiche Fehlermeldung bevor ich den Fehler gefunden und gefixt habe :)

Ist das Backend laut Status Online?

slu

**Ja Backend ist laut Status Online.

So langsam dämmert mir was, ich denke "Encrypt(SSL)" darf nicht gesetzt sein, das erklärt auch weshalb da ein pfSense Cert mit der Fehlermeldung gekommen ist.**

Edit:
https://www.haproxy.com/de/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/

JeGr

Mach mal im Backend bitte den Haken bei "Encrypt(SSL)" raus - da du ja nicht re-encodest :)

slu

@jegr
ich habe den alten Thread wieder gefunden und es ist ja Ostern :)

Mit dem Type "ssl/ https(TCP mode)" habe ich keine Chance auf den User Agent zu filtern da wir im Layer 4 sind, richtig?

JeGr

@slu Wenn du nicht offloadest eher nicht, da dann weder HTTP Header noch sonstige Dinge unverschlüsselt zur Verfügung stehen. Das Einzige IMHO ist der SNI Header der dann noch zu lesen ist um überhaupt die Zustellung zu machen. Für alles andere müsste er die Verbindung annehmen.