Puncte:0

Depanare LDAPS/TLS/HAproxy, se utilizează certificat SSL greșit

drapel jp

Ok, deci am două servere.. unul vechi (Ubuntu 16) și unul nou (Ubuntu 20).

Ambii au Haproxy și, în cadrul config, sunt legați la același port și același certificat .PEM. Când testez certificatul SSL folosind s_client al OpenSSL de la o gazdă Windows.. Văd certificatul așteptat când testez vechiul server.. dar noul server din anumite motive trimite certificatul serverului backend care este un certificat intern.

Deci, pentru a ajuta la pictarea imaginii, serverul vechi trimite ldaps.domain.cominformațiile certificatului lui. Dar noul server trimite internDC.domain.comcertificatul lui.

Ambele servere Haproxy au TCP/636 permis de la DMZ la LAN, ambele folosesc exact aceleași servere Backend, așa că sunt total nedumerit.

Orice sfat ar fi super apreciat!

Ginnungagap avatar
drapel gu
Folosiți `-servername` când testați cu `s_client`? Certificatele depind de SNI în HAProxy?
drapel jp
Da, șirul cmd pe care l-am folosit este: `openssl s_client -connect ldaps.domain.com:636` pentru ambele teste.. comutarea IP-ului serverului în fișierul Hosts. AFAIK Haproxy urmărește domeniul, deoarece asta este tot ceea ce este menționat în configurația sa.
Ginnungagap avatar
drapel gu
Nu utilizați `-servername`, care este numele indicat de OpenSSL atunci când efectuați strângerea de mână TLS, așa cum este, vă conectați la IP-ul la care se rezolvă ldaps.domain.com fără SNI.
drapel jp
Ma insel.. SNI asta este da?: https://stuff-things.net/2016/11/30/haproxy-sni/. Dacă da, atunci nu.. Nu îl folosesc. configurația mea este mai simplă: client LDAPS -> haproxy -> backend DC/LDAPS deci ldaps.domain.com pentru frontend, atunci backend-ul este o pereche de controlere de domeniu.. atât frontul, cât și backend-ul sunt setate pentru portul 636.
Ginnungagap avatar
drapel gu
Arată configurația HAProxy, dacă nu este SNI, terminarea TLS este configurată incorect.
drapel jp
Iată fișierul conf igienizat: https://paste.centos.org/view/52a6000b Deci problema mea este că atunci când mă conectez la ldaps.domain1.com folosind acest nou server, primesc certificatul SSL pentru domain1-dc01.
drapel jp
A trecut mult timp, iar răspunsurile la această întrebare s-au oprit dintr-un motiv oarecare. Dar până la urmă ai avut dreptate @Ginnungagap La vremea respectivă habar nu aveam că s_client nu a transmis sau nu a luat în alt mod domeniul în valoarea -connect și l-a folosit spre SNI. A trebuit să specific -servername a funcționat și m-a condus pe un drum către rezolvarea problemelor. Deci, dacă adăugați un răspuns, îl voi accepta. Mulțumiri
Ginnungagap avatar
drapel gu
Sunteți într-o poziție mai bună pentru a răspunde efectiv la întrebare, deoarece aveți detaliile relevante. Răspunsurile proprii nu sunt un lucru rău și ar trebui să vă simțiți liber să documentați ce ați făcut, ce indicații ați folosit și cum v-ați rezolvat problema, deoarece este mai probabil să ajute pe cineva cu aceeași întrebare decât ceea ce aș putea scrie, ceea ce ar fi mult. răspuns mai generic orientat TLS din care ServerFault are deja multe.
drapel jp
Bănuiesc că am postat o sumă destul de mare aici și Stackoverflow în general, doar pentru a primi un răspuns mai târziu. Întotdeauna am presupus că acest lucru era descurajat atunci când putea fi evitat. De multe ori îmi voi posta problema, apoi, după ce o înving timp de o oră, găsesc o soluție înainte ca cineva să comenteze. Dar cred că așa se termină uneori. Mulțumesc că ai revenit @Ginnungagap
Puncte:0
drapel jp

În cele din urmă, soluția a fost într-adevăr folosirea comutatorului „-servername” în s_client. Habar n-aveam că nu se ocupă de SNI doar implicit. @Ginnungagap m-a îndreptat în acea direcție.

De asemenea, m-a făcut să descopăr că configurația mea SNI în haproxy.cfg nu era corectă. Inițial aveam o linie precum:

use_backend if { ssl_fc_sni_reg domain.com }

Iar idiotul care sunt nu și-a dat seama că „reg” înseamnă regex. Odată am schimbat la „sfârșit” pentru că încercam să potrivesc cu numele domina în sine.. lucrurile s-au rezolvat.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.