HTTPS către un IP privat: identitatea certificatului sau numele gazdei?
Un IP privat poate fi o identitate TLS validă dacă certificatul o spune. Alegeți între un SAN de IP și un nume de gazdă stabil, apoi planificați schimbarea adresei.
Serviciul dumneavoastră la https://10.60.0.25 poate avea TLS autentificat chiar și fără un nume DNS. Adresa este identitatea pe care clientul trebuie să o valideze, iar certificatul trebuie să o descrie exact. Decizia este dacă acea adresă este suficient de stabilă pentru a fi o identitate sau dacă un nume de gazdă ar fi mai ușor de întreținut. VPN-ul răspunde la accesibilitate; nu răspunde la aceasta.
Puneți corect identitatea și încrederea, iar un URL bazat pe IP este un proiect legitim.
Ce validează de fapt clientul
Clientul compară identitatea de referință din URL cu numele alternative de subiect ale certificatului. Pentru o adresă IP, aceasta înseamnă o intrare iPAddress egală cu adresa. Un nume comun prietenos nu este un substitut.
RFC 9525 separă identitățile de adresă IP de numele DNS și definește regula de potrivire. Plasarea adresei doar în eticheta subiectului, sau ca intrare de tip DNS, nu produce potrivire. De aceea SAN este câmpul de inspectat când apare un avertisment.
Încrederea este o a doua verificare, independentă. O potrivire de nume nu repară un lanț neîncrezut, un certificat expirat sau un certificat emis pentru alt scop.
Prima decizie: este adresa suficient de stabilă pentru a fi o identitate
Dacă adresa este fixă pe toată durata implementării, un certificat SAN de IP este simplu și onest. Dacă serviciul se poate muta, fiecare mutare devine o înlocuire de certificat și o actualizare coordonată a clienților.
Un nume de gazdă stabil reduce această cuplare. Clienții folosesc numele, DNS-ul aprobat îl mapează la adresa curentă, iar o schimbare de adresă nu mai este o schimbare de identitate. Certificatul are în continuare nevoie de reînnoire, dar URL-ul nu se schimbă.
O intrare administrată în fișierul hosts poate furniza maparea într-un mediu mic. Adaugă o responsabilitate de distribuție; nu înlocuiește verificarea TLS.
A doua decizie: cum va avea încredere clientul în emitent
Pentru o CA privată, distribuiți ancora de încredere dispozitivelor vizate printr-un mecanism aprobat. Nu obișnuiți utilizatorii să treacă peste avertismente sau să instaleze un certificat dat de o pagină de autentificare. Dacă doriți un certificat de încredere publică, verificați regulile actuale ale emitentului pentru adresele private înainte de a planifica în jurul lor. Majoritatea emitenților publici nu vor valida un IP privat ca identitate publică.
Examinați browserul sau aplicația reală. Magazinul său de încredere și comportamentul de validare contează mai mult decât documentația generală a certificatelor a sistemului de operare. Verificați-l pe dispozitivul real, nu doar în consolă.
Poate că gateway-ul VPN nu este mașina care rulează aplicația web, deci nu presupuneți că certificatul tunelului are vreo legătură cu acesta.
Planificați schimbarea adresei înainte să se întâmple
Dacă 10.60.0.25 devine 10.60.0.40, certificatul vechi nu mai descrie URL-ul. Planificați înlocuirea și actualizarea clientului împreună și nu dezactivați niciodată verificarea în timpul mutării.
Alegeți identitatea pe care utilizatorii o vor tasta sau pe care aplicațiile o vor configura, apoi aliniați emiterea, încrederea, implementarea și reînnoirea în jurul ei. O pagină accesibilă cu un avertisment ignorat nu este același rezultat ca un serviciu a cărui identitate este validată de client.