Puncte:0

Resetarea conexiunii pentru HTTPS pe ADFS

drapel pl

Am configurat un server Windows într-o cutie virtuală cu rețea numai gazdă ca mediu de laborator. Am o problemă la accesarea HTTPS din rețeaua numai gazdă. Am configurat un controler de domeniu și ADFS pe un server Windows 2019 folosind un certificat autosemnat pentru ADFS. Iată câteva teste pe care le-am făcut pentru a încerca să izolez problema. Testez cu adresa URL a metadatelor /FederationMetadata/2007-06/FederationMetadata.xml

  • Dacă deschid IE în VM și merg la punctul final de metadate pe localhost , primesc mesajul „Acest site nu este securizat”, dar pot ocoli avertismentul și pot obține metadatele.
  • Dacă merg la IP-ul interfeței numai gazdei, IE afișează doar un mesaj care spune „Nu se poate conecta în siguranță la această pagină” și nu este posibil să o ocolesc.
  • Dacă fac curl de la gazdă la gazdă numai adresa IP cu steag -k către portul 443, primesc resetarea conexiunii.
  • Dacă fac curl față de portul 80 de pe IP-ul gazdei, primesc o pagină 404 așa cum era de așteptat.
  • Ping funcționează bine de la gazdă.
  • Telnet de la gazdă la 443 se conectează

Am dezactivat firewall-ul Windows.

certificatul a fost generat folosind acest powershell

 $selfSignedCert = New-SelfSignedCertificateEx `
     -Subiect „CN=adfs.samlsecurity.com” `
     -ProviderName „Microsoft Enhanced RSA and AES Cryptographic Provider” `
     -KeyLength 2048 -FriendlyName 'OAFED SelfSigned' -SignatureAlgorithm sha256 `
     -EKU „Autentificare server”, „Autentificare client” `
     -KeyUsage „KeyEncipherment, DigitalSignature” `
     -Exportabil -Locație magazin „LocalMachine”

Așadar, se pare că există conectivitate, deoarece pot obține pagina HTTP 404, dar din anumite motive primesc conexiunea refuzată de la 443. Bănuiesc că este ceva în neregulă cu configurarea TLS pe ​​Windows, dar nu îmi pot da seama ce.

Jevgenij Martynenko avatar
drapel us
Vă rugăm să verificați configurația ascultătorului HTTP rulând următoarele comenzi: `netsh http show iplisten`, `netsh http show sslcert`
drapel pl
https://gist.github.com/rasmusson/434490754d0f6c2ae3c05555d361f5f1
Puncte:0
drapel pl

L-am gasit! am aruncat o privire la pachetele din Wireshark. Singura diferență între pachetele care au primit un răspuns de la server și cele care nu au primit răspuns a fost utilizarea extensiei SNI în clientul TLS salut.

Acest lucru m-a determinat să caut SNI și să resetez conexiunea pe serverul Windows. Se pare că folosește caracteristica SNI pentru a putea furniza certificate diferite bazate pe numele serverului recester în TLS SNI.

ADFS nu înregistrează în mod implicit niciun certificat alternativ pentru alte nume de server decât localhost și FQDN-ul pentru ADFS. Când am folosit adresa IP pentru ADFS, nu era aplicabil niciun certificat și serverul a închis conexiunea.

Am rezolvat mai întâi acest lucru prin înregistrarea unui certificat implicit folosind

netsh add sslcert ipport=0.0.0.0:442 appid='{<ADFS_GUID>}' certhash=<amprentă fără spațiu>

Mai târziu, am rezolvat-o adăugând FQDN și IP la fișierul hosts.

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.