HTTPS til en privat IP: sertifikatidentitet eller vertsnavn?
En privat IP kan være en gyldig TLS-identitet hvis sertifikatet sier det. Velg mellom en IP SAN og et stabilt vertsnavn, og planlegg deretter adresseendringen.
Tjenesten din på https://10.60.0.25 kan ha autentisert TLS selv uten et DNS-navn. Adressen er identiteten klienten må validere, og sertifikatet må beskrive den nøyaktig. Beslutningen er om adressen er stabil nok til å være en identitet, eller om et vertsnavn ville være lettere å vedlikeholde. VPN-en svarer på tilgjengelighet; den svarer ikke på dette.
Få identiteten og tilliten riktig, og en IP-basert URL er et legitimt design.
Hva klienten faktisk validerer
Klienten sammenligner referanseidentiteten i URL-en med sertifikatets alternative navn. For en IP-adresse betyr det en iPAddress-oppføring lik adressen. Et vennlig vanlig navn er ingen erstatning.
RFC 9525 skiller IP-adresseidentiteter fra DNS-navn og definerer samsvarsregelen. Å sette adressen bare i emneetiketten, eller som en oppføring av DNS-typen, gir ingen samsvaring. Derfor er SAN feltet som må undersøkes når en advarsel vises.
Tillit er en andre, uavhengig kontroll. Et navnesamsvar retter ikke en ikke-klarert kjede, et utløpt sertifikat eller et sertifikat utstedt for et annet formål.
Beslutning én: er adressen stabil nok til å være en identitet
Hvis adressen er fast for hele levetiden til utrullingen, er et IP SAN-sertifikat enkelt og ærlig. Hvis tjenesten kan flytte seg, blir hver flytting en sertifikatutskifting og en koordinert klientoppdatering.
Et stabilt vertsnavn reduserer den koblingen. Klienter bruker navnet, godkjent DNS mapper det til gjeldende adresse, og en adresseendring slutter å være en identitetsendring. Sertifikatet må fortsatt fornyes, men URL-en endres ikke.
En administrert hosts-filoppføring kan gi mappingen i et lite miljø. Det legger til et distribusjonsansvar; det erstatter ikke TLS-verifisering.
Beslutning to: hvordan klienten vil stole på utstederen
For en privat CA distribuerer du tillitsankeret til de tiltenkte enhetene gjennom en godkjent mekanisme. Ikke lær brukere å klikke seg gjennom advarsler eller installere et sertifikat de får av en innloggingsside. Hvis du vil ha et offentlig klarert sertifikat, sjekk utstederens gjeldende regler for private adresser før du planlegger rundt det. De fleste offentlige utstedere vil ikke validere en privat IP som en offentlig identitet.
Gå gjennom den faktiske nettleseren eller applikasjonen. Tillitslageret og valideringsatferden dens betyr mer enn operativsystemets generelle sertifikatdokumentasjon. Kontroller det på den faktiske enheten, ikke bare i konsollen.
VPN-gatewayen er kanskje ikke maskinen som kjører webapplikasjonen, så ikke anta at tunnelens sertifikat har noe med dette å gjøre.
Planlegg adresseendringen før den skjer
Hvis 10.60.0.25 blir 10.60.0.40, beskriver ikke det gamle sertifikatet URL-en lenger. Planlegg utskiftingen og klientoppdateringen sammen, og deaktiver aldri verifisering under flyttingen.
Velg identiteten brukerne vil skrive, eller applikasjonene vil konfigurere, og juster deretter utstedelse, tillit, utrulling og fornyelse rundt den. En tilgjengelig side med en avvist advarsel er ikke det samme resultatet som en tjeneste hvis identitet klienten validerer.