HTTPS drejt një IP private: identiteti i certifikatës apo emri i hostit?
Një IP private mund të jetë identitet TLS i vlefshëm nëse certifikata e thotë këtë. Zgjidhni midis një SAN IP dhe një emri hosti të qëndrueshëm, më pas planifikoni ndryshimin e adresës.
Shërbimi juaj në https://10.60.0.25 mund të ketë TLS të vërtetuar edhe pa një emër DNS. Adresa është identiteti që klienti duhet të verifikojë, dhe certifikata duhet ta përshkruajë atë saktësisht. Vendimi është nëse ajo adresë është mjaft e qëndrueshme për të qenë identitet, apo një emër hosti do të ishte më i lehtë për t'u mirëmbajtur. VPN-ja përgjigjet për aksesueshmërinë; nuk përgjigjet për këtë.
Nëse identiteti dhe besimi janë të saktë, një URL e bazuar në IP është një dizajn i ligjshëm.
Çfarë verifikon në të vërtetë klienti
Klienti krahason identitetin referues në URL me emrat alternativë të subjektit të certifikatës. Për një adresë IP, kjo nënkupton një hyrje iPAddress të barabartë me adresën. Një emër i përbashkët miqësor nuk është zëvendësues.
RFC 9525 i ndan identitetet e adresave IP nga emrat DNS dhe përcakton rregullin e përputhjes. Vendosja e adresës vetëm në etiketën e subjektit, ose si hyrje e tipit DNS, nuk prodhon përputhje. Prandaj SAN është fusha që duhet inspektuar kur shfaqet një paralajmërim.
Besimi është një kontroll i dytë, i pavarur. Përputhja e emrit nuk rregullon një zinxhir jo të besuar, një certifikatë të skaduar ose një certifikatë të lëshuar për një qëllim tjetër.
Vendimi i parë: a është adresa mjaft e qëndrueshme për të qenë identitet
Nëse adresa është fikse për gjithë jetën e vendosjes, një certifikatë SAN IP është e thjeshtë dhe e ndershme. Nëse shërbimi mund të lëvizë, çdo lëvizje bëhet zëvendësim certifikate dhe përditësim i koordinuar i klientëve.
Një emër hosti i qëndrueshëm e zvogëlon atë lidhje. Klientët përdorin emrin, DNS i miratuar e harton atë në adresën aktuale, dhe një ndryshim adrese nuk është më ndryshim identiteti. Certifikata ende ka nevojë për rinovim, por URL-ja nuk ndryshon.
Një hyrje e menaxhuar në skedarin hosts mund të sigurojë hartëzimin në një mjedis të vogël. Shton një përgjegjësi shpërndarjeje; nuk zëvendëson verifikimin TLS.
Vendimi i dytë: si do t'i besojë klienti lëshuesit
Për një CA private, shpërndani ankorën e besimit te pajisjet e synuara përmes një mekanizmi të miratuar. Mos i mësoni përdoruesit të kalojnë paralajmërimet ose të instalojnë një certifikatë që u jep një faqe hyrjeje. Nëse dëshironi një certifikatë të besuar publikisht, kontrolloni rregullat aktuale të lëshuesit për adresat private përpara se të planifikoni mbi to. Shumica e lëshuesve publikë nuk do të verifikojnë një IP private si identitet publik.
Shqyrtoni shfletuesin ose aplikacionin aktual. Depoja e besimit dhe sjellja e verifikimit të tij kanë më shumë rëndësi sesa dokumentacioni i përgjithshëm i certifikatave të sistemit operativ. Verifikojeni në pajisjen aktuale, jo vetëm në konsolë.
Porta VPN mund të mos jetë makina që ekzekuton aplikacionin web, prandaj mos supozoni se certifikata e tunelit ka lidhje me këtë.
Planifikoni ndryshimin e adresës përpara se të ndodhë
Nëse 10.60.0.25 bëhet 10.60.0.40, certifikata e vjetër nuk e përshkruan më URL-në. Planifikoni zëvendësimin dhe përditësimin e klientit së bashku, dhe mos e çaktivizoni kurrë verifikimin gjatë lëvizjes.
Zgjidhni identitetin që përdoruesit do të shkruajnë ose aplikacionet do të konfigurojnë, më pas rreshtoni lëshimin, besimin, vendosjen dhe rinovimin rreth tij. Një faqe e arritshme me një paralajmërim të hedhur poshtë nuk është i njëjti rezultat si një shërbim, identitetin e të cilit klienti e verifikon.