HTTPS til en privat IP: certifikatidentitet eller værtsnavn?
En privat IP kan være en gyldig TLS-identitet, hvis certifikatet siger det. Vælg mellem et IP-SAN og et stabilt værtsnavn, og planlæg derefter adresseændringen.
Din tjeneste på https://10.60.0.25 kan have autentificeret TLS selv uden et DNS-navn. Adressen er den identitet, klienten skal validere, og certifikatet skal beskrive den præcist. Beslutningen er, om adressen er stabil nok til at være en identitet, eller om et værtsnavn ville være lettere at vedligeholde. VPN'en svarer på tilgængelighed; den svarer ikke på dette.
Få identiteten og tilliden rigtigt, og en IP-baseret URL er et legitimt design.
Hvad klienten faktisk validerer
Klienten sammenligner referenceidentiteten i URL'en med certifikatets alternative navne. For en IP-adresse betyder det en iPAddress-post, der svarer til adressen. Et venligt fællesnavn er ingen erstatning.
RFC 9525 adskiller IP-adresseidentiteter fra DNS-navne og definerer matchreglen. At sætte adressen kun i emnefeltet eller som en post af DNS-typen giver ikke et match. Derfor er SAN det felt, der skal undersøges, når en advarsel vises.
Tillid er en anden, uafhængig kontrol. Et navnematch retter ikke en ubetroet kæde, et udløbet certifikat eller et certifikat udstedt til et andet formål.
Beslutning et: er adressen stabil nok til at være en identitet
Hvis adressen er fast i hele implementeringens levetid, er et IP-SAN-certifikat enkelt og ærligt. Hvis tjenesten kan flytte sig, bliver hver flytning en certifikatudskiftning og en koordineret klientopdatering.
Et stabilt værtsnavn reducerer den kobling. Klienter bruger navnet, godkendt DNS mapper det til den aktuelle adresse, og en adresseændring holder op med at være en identitetsændring. Certifikatet skal stadig fornyes, men URL'en ændrer sig ikke.
En administreret hosts-filpost kan levere mappingen i et lille miljø. Det tilføjer et distributionsansvar; det erstatter ikke TLS-verifikation.
Beslutning to: hvordan klienten vil stole på udstederen
For en privat CA distribueres tillidsankeret til de tilsigtede enheder via en godkendt mekanisme. Lær ikke brugerne at klikke gennem advarsler eller installere et certifikat, som de får af en login-side. Hvis du vil have et offentligt betroet certifikat, skal du kontrollere udstederens aktuelle regler for private adresser, før du planlægger ud fra det. De fleste offentlige udstedere validerer ikke en privat IP som en offentlig identitet.
Gennemgå den faktiske browser eller applikation. Dens tillidslager og valideringsadfærd betyder mere end operativsystemets generelle certifikatdokumentation. Kontroller det på den faktiske enhed, ikke kun i konsollen.
VPN-gatewayen er måske ikke den maskine, der kører webapplikationen, så antag ikke, at tunnelens certifikat har noget med dette at gøre.
Planlæg adresseændringen, før den sker
Hvis 10.60.0.25 bliver 10.60.0.40, beskriver det gamle certifikat ikke længere URL'en. Planlæg udskiftningen og klientopdateringen sammen, og deaktiver aldrig verifikation under flytningen.
Vælg den identitet, brugerne vil skrive, eller applikationerne vil konfigurere, og tilpas derefter udstedelse, tillid, implementering og fornyelse omkring den. En tilgængelig side med en afvist advarsel er ikke det samme resultat som en tjeneste, hvis identitet klienten validerer.