HTTPS till en privat IP: certifikatidentitet eller värdnamn?
En privat IP kan vara en giltig TLS-identitet om certifikatet säger det. Välj mellan en IP SAN och ett stabilt värdnamn och planera sedan adressändringen.
Din tjänst på https://10.60.0.25 kan ha autentiserad TLS även utan ett DNS-namn. Adressen är den identitet som klienten måste validera, och certifikatet måste beskriva den exakt. Beslutet är om adressen är stabil nog att vara en identitet, eller om ett värdnamn skulle vara lättare att underhålla. VPN:en svarar på nåbarhet; den svarar inte på detta.
Få identiteten och tilliten rätt, och en IP-baserad URL är en legitim design.
Vad klienten faktiskt validerar
Klienten jämför referensidentiteten i URL:en med certifikatets alternativa namn. För en IP-adress betyder det en iPAddress-post som är lika med adressen. Ett vänligt vanligt namn är ingen ersättning.
RFC 9525 skiljer IP-adressidentiteter från DNS-namn och definierar matchningsregeln. Att bara sätta adressen i subjektetiketten, eller som en post av DNS-typ, ger ingen matchning. Därför är SAN det fält som ska granskas när en varning visas.
Tillit är en andra, oberoende kontroll. En namnmatchning reparerar inte en ej betrodd kedja, ett utgånget certifikat eller ett certifikat som utfärdats för ett annat syfte.
Beslut ett: är adressen stabil nog att vara en identitet
Om adressen är fast under hela driftsättningens livstid är ett IP SAN-certifikat enkelt och ärligt. Om tjänsten kan flytta blir varje flytt ett certifikatbyte och en samordnad klientuppdatering.
Ett stabilt värdnamn minskar den kopplingen. Klienter använder namnet, godkänd DNS mappar det till den aktuella adressen, och en adressändring upphör att vara en identitetsändring. Certifikatet behöver fortfarande förnyas, men URL:en ändras inte.
En hanterad hosts-filpost kan ge mappningen i en liten miljö. Det lägger till ett distributionsansvar; det ersätter inte TLS-verifieringen.
Beslut två: hur klienten ska lita på utfärdaren
För en privat CA distribuerar du förtroendeankaret till de avsedda enheterna via en godkänd mekanism. Lär inte användare att klicka sig förbi varningar eller installera ett certifikat som en inloggningssida ger dem. Om du vill ha ett offentligt betrott certifikat, kontrollera utfärdarens aktuella regler för privata adresser innan du planerar kring det. De flesta offentliga utfärdare validerar inte en privat IP som en offentlig identitet.
Granska den faktiska webbläsaren eller applikationen. Dess förtroendelager och valideringsbeteende är viktigare än operativsystemets allmänna certifikatdokumentation. Kontrollera det på den faktiska enheten, inte bara i konsolen.
VPN-gatewayen är kanske inte maskinen som kör webbapplikationen, så anta inte att tunnelns certifikat har något med detta att göra.
Planera adressändringen innan den sker
Om 10.60.0.25 blir 10.60.0.40 beskriver det gamla certifikatet inte längre URL:en. Planera bytet och klientuppdateringen tillsammans och inaktivera aldrig verifieringen under flytten.
Välj den identitet som användare kommer att skriva eller applikationer konfigurera, och anpassa sedan utfärdande, tillit, driftsättning och förnyelse kring den. En nåbar sida med en avvisad varning är inte samma resultat som en tjänst vars identitet klienten validerar.