HTTPS naar een privé-IP: certificaatidentiteit of hostnaam?
Een privé-IP kan een geldige TLS-identiteit zijn als het certificaat dat zegt. Kies tussen een IP SAN en een stabiele hostnaam en plan daarna de adreswijziging.
Uw dienst op https://10.60.0.25 kan geauthenticeerde TLS hebben, zelfs zonder DNS-naam. Het adres is de identiteit die de client moet valideren, en het certificaat moet die exact beschrijven. De beslissing is of dat adres stabiel genoeg is om een identiteit te zijn, of dat een hostnaam eenvoudiger te onderhouden zou zijn. De VPN beantwoordt de bereikbaarheid; niet deze vraag.
Zet de identiteit en het vertrouwen goed, en een op IP gebaseerde URL is een legitiem ontwerp.
Wat de client werkelijk valideert
De client vergelijkt de referentie-identiteit in de URL met de alternatieve subjectnamen van het certificaat. Voor een IP-adres betekent dat een iPAddress-vermelding die gelijk is aan het adres. Een vriendelijke algemene naam is geen vervanging.
RFC 9525 scheidt identiteiten van IP-adressen van DNS-namen en definieert de overeenkomstenregel. Het adres alleen in het subjectlabel of als vermelding van het type DNS zetten, levert geen overeenkomst op. Daarom is de SAN het veld dat moet worden gecontroleerd wanneer een waarschuwing verschijnt.
Vertrouwen is een tweede, onafhankelijke controle. Een naamovereenkomst lost geen niet-vertrouwde keten, geen verlopen certificaat en geen certificaat dat voor een ander doel is uitgegeven op.
Beslissing één: is het adres stabiel genoeg om een identiteit te zijn
Als het adres vastligt voor de hele levensduur van de uitrol, is een IP SAN-certificaat eenvoudig en eerlijk. Als de dienst kan verhuizen, wordt elke verhuizing een certificaatvervanging en een gecoördineerde clientupdate.
Een stabiele hostnaam vermindert die koppeling. Clients gebruiken de naam, goedgekeurde DNS koppelt die aan het huidige adres, en een adreswijziging is geen identiteitswijziging meer. Het certificaat moet nog steeds worden vernieuwd, maar de URL verandert niet.
Een beheerde hosts-bestandsregel kan de koppeling in een kleine omgeving leveren. Het voegt een distributieverantwoordelijkheid toe; het vervangt de TLS-verificatie niet.
Beslissing twee: hoe de client de uitgever vertrouwt
Voor een particuliere CA distribueert u het vertrouwensanker via een goedgekeurd mechanisme naar de beoogde apparaten. Leer gebruikers niet om waarschuwingen weg te klikken of een certificaat te installeren dat een inlogpagina hun geeft. Als u een publiek vertrouwd certificaat wilt, controleer dan de huidige regels van de uitgever voor particuliere adressen voordat u daarop plant. De meeste publieke uitgevers valideren een privé-IP niet als een publieke identiteit.
Bekijk de werkelijke browser of toepassing. De vertrouwensopslag en het validatiegedrag ervan zijn belangrijker dan de algemene certificaatdocumentatie van het besturingssysteem. Controleer het op het werkelijke apparaat, niet alleen in de console.
De VPN-gateway is mogelijk niet de machine waarop de webtoepassing draait, dus ga er niet vanuit dat het certificaat van de tunnel iets met dit te maken heeft.
Plan de adreswijziging voordat die plaatsvindt
Als 10.60.0.25 10.60.0.40 wordt, beschrijft het oude certificaat de URL niet meer. Plan de vervanging en de clientupdate samen en schakel verificatie tijdens de verhuizing nooit uit.
Kies de identiteit die gebruikers intypen of toepassingen configureren en lijn daarop uitgifte, vertrouwen, uitrol en vernieuwing af. Een bereikbare pagina met een weggeklikte waarschuwing is niet hetzelfde resultaat als een dienst waarvan de client de identiteit valideert.