HTTPS nei in privee IP: sertifikaatidentiteit of hostnamme?
In privee IP kin in jildige TLS-identiteit wêze as it sertifikaat dat seit. Kies tusken in IP SAN en in stabile hostnamme, en plan dan de adreswiziging.
Jo tsjinst op https://10.60.0.25 kin autentisearre TLS hawwe sels sûnder DNS-namme. It adres is de identiteit dy't de klant kontrolearje moat, en it sertifikaat moat it presys beskriuwe. De beslissing is oft dat adres stabyl genôch is om in identiteit te wêzen, of oft in hostnamme makliker te ûnderhâlden wêze soe. De VPN antwurdet berikberens; it antwurdet dit net.
Krij de identiteit en it fertrouwen goed, en in IP-basearre URL is in legitim ûntwerp.
Wat de klant eins kontrolearret
De klant fergeliket de referinsje-identiteit yn 'e URL mei de alternative ûnderwerpnammen fan it sertifikaat. Foar in IP-adres betsjut dat in iPAddress-ynfier gelyk oan it adres. In freonlike algemiene namme is gjin ferfanging.
RFC 9525 skiedt IP-adresidentiteiten fan DNS-nammen en definiearret de oerienkomstiisregel. It adres allinnich yn it ûnderwerplabel pleatse, of as in ynfier fan it DNS-type, liedt net ta in oerienkomst. Dêrom is de SAN it fjild dat besjoen wurde moat as in warskôging ferskynt.
Fertrouwen is in twadde, ûnôfhinklike kontrôle. In namme-oerienkomst reparearret gjin net-fertraud keatling, in ferrûn sertifikaat of in sertifikaat dat foar in oar doel ôfjûn is.
Beslissing ien: is it adres stabyl genôch om in identiteit te wêzen
As it adres fêst is foar de hiele libbensdoer fan 'e ynset, is in IP SAN-sertifikaat ienfâldich en earlik. As de tsjinst ferpleatse kin, wurdt elke ferpleatsing in sertifikaatferfanging en in koördinearre klantfernijing.
In stabile hostnamme ferminderet dy keppeling. Klanten brûke de namme, goedkarde DNS mapt it nei it hjoeddeistige adres, en in adreswiziging hâldt op in identiteitswiziging te wêzen. It sertifikaat moat noch fernijd wurde, mar de URL feroaret net.
In beheard hosts-triemynfier kin de mapping yn in lytse omjouwing leverje. It foeget in distribúsjeferantwurdlikheid ta; it ferfangt TLS-ferifikaasje net.
Beslissing twa: hoe't de klant de útjouwer fertrouwe sil
Foar in privee CA, ferspriede it fertrouwensanker nei de bedoelde apparaten fia in goedkard meganisme. Lear brûkers net om warskôgingen troch te klikken of in sertifikaat te ynstallearjen dat in oanmeldside harren jout. As jo in publyk fertroud sertifikaat wolle, kontrolearje dan de hjoeddeistige regels fan 'e útjouwer foar privee adressen foardat jo dêromhinne planje. De measte publyke útjouwers sille in privee IP net as publyke identiteit validearje.
Besjoch de werklike browser of applikaasje. Syn fertrouwensopslach en falidaasjegedrach binne wichtiger as de algemiene sertifikaatdokumintaasje fan it bestjoeringssysteem. Kontrolearje it op it werklike apparaat, net allinnich yn 'e konsole.
De VPN-gateway is miskien net de masine dy't de webapplikaasje draait, dus nim net oan dat it sertifikaat fan 'e tunnel hjirmei wat te krijen hat.
Plan de adreswiziging foardat it bart
As 10.60.0.25 10.60.0.40 wurdt, beskriuwt it âlde sertifikaat de URL net mear. Plan de ferfanging en de klantfernijing tegearre, en skeakelje nea ferifikaasje út tidens de ferpleatsing.
Kies de identiteit dy't brûkers yntype of applikaasjes konfigurearje, en lynje dan útjefte, fertrouwen, ynset en fernijing dêromhinne. In berikbere side mei in fuortklikte warskôging is net itselde resultaat as in tsjinst waans identiteit de klant ferifiearret.