Via kliento malakceptas atestilon, kies ĉeno valide validiĝas, kaj la eraro diras, ke la nomo ne kongruas. Tiu mesaĝo ne temas pri tio, kiu subskribis la atestilon. Ĝi temas pri la etendaĵo de alternativaj subjektaj nomoj, kiu portas la identecojn, kiujn la atestilo rajtas reprezenti, kaj pri tio, ĉu la identeco, kiun vi agordis, aperas tie en la ĝusta formo. Fido respondas, kiu subskribis ĝin, dum la nomkontrolo respondas, al kiu gastiganto ĝi apartenas.

Kion la kliento efektive komparas

La kliento transformas vian agordon en referencan identecon: gastnomon, adreson aŭ protokol-specifan identigilon. Poste ĝi serĉas tiun identecon en la atestilo, aplikante la kongruigajn regulojn de la uzata protokolo. Nur rikordoj de la sama tipo validas, do DNS-rikordo ne povas kontentigi adreson, kaj la komparo okazas sendepende de tio, ĉu homo iam rigardas la atestilon.

Kiam la referenca identeco mankas en tiu etendaĵo, la kontrolo malsukcesas eĉ se la malnova komuna nomo kongruas. Atestilo povas esti laŭleĝe eldonita al firmao kaj tamen esti la malĝusta por vpn.example.com, se la nomo neniam estis inkluzivita. La malsukceso estas nom-miskongruo, kvankam la atestilo estas aŭtentika.

DNS-nomoj kaj IP-adresoj estas apartaj rikordoj

Profilo, kiu montras al 203.0.113.10 dum la atestilo listigas nur vpn.example.com, estas malakceptita, ĉar la pakaĵoj alvenas sed la identeco ne kongruas. DNS-nomoj kaj laŭvortaj adresoj estas konservataj kiel malsamaj rikordtipoj, kaj unu neniam anstataŭas la alian. Tial servo povas esti atingebla per adreso kaj tamen neuzebla per profilo, kiu uzas tiun adreson.

Ĵokeroj ankaŭ sekvas proprajn regulojn: ĵokero kovras unu etikedon, ne ĉiun nomon sub domajno. DNS-komparo ne distingas usklecon, dum aliaj identigilaj tipoj distingas, do valoro, kiu aspektas identa sur la ekrano, povas malsukcesi en strikta komparo. Kontrolu la kongruigajn regulojn por la uzata identectipo anstataŭ kompari signoĉenojn per okulo. Aldoni nomon al la etendaĵo estas eldona decido, ne io, kion klienta agordo povas provizi.

Ekzamenu la atestilon, kiun la konekto efektive uzis

Legu la materialon prezentatan de la viva finpunkto, ne dosieron kopiitan de administra paĝo. Ŝarĝbalancilo aŭ anstataŭa instanco povas prezenti ion alian ol la atestilo alŝutita antaŭ monatoj, kaj tiu diferenco estas nevidebla en konzolo.

openssl s_client -connect vpn.example.com:443 -showcerts </dev/null | openssl x509 -noout -text

La bloko de alternativaj subjektaj nomoj, la eldonista ĉeno kaj la valideca periodo apartenas al la sama legado, ĉar nom-miskongruo kaj eksvalidiĝo produktas malsamajn erarojn. Komparu ĉiun nomon en tiu bloko kun la identeco agordita en la profilo, signon post signo, kaj notu, kiu tipo ĝi estas. Ripeto de la komando kontraŭ la adresa formo de la finpunkto montras, ĉu la atestilo kovras ambaŭ identecojn aŭ nur unu. Amika subjekta montrado en administra konzolo ne estas validiga rezulto kaj diras nenion pri tio, kiujn nomojn la etendaĵo enhavas.

La komuna nomo ne estas la moderna fonto de vero

Retumiloj kaj plej multaj TLS-bibliotekoj nun ignoras la komunan nomon por gastnoma kongruigo kaj konsultas la etendaĵon anstataŭe. Kelkaj VPN-klientoj ankoraŭ komparas unue la komunan nomon aŭ reiras al ĝi kiam la etendaĵo mankas, kaj tial unu atestilo povas trapasi retumilon kaj malsukcesi en kliento. La sama nomkontrolo povas trapasi sur unu platformo kaj malsukcesi sur alia, sen ke la atestilo entute ŝanĝiĝu.

Eltrovu, kiun kampon via kliento legas, antaŭ ol decidi, ke la atestilo estas malĝusta. Du klientoj ĉe la sama finpunkto povas malkonsenti, kaj la malkonsento estas informo pri la kliento, ne pri la atestilo.

Riparu la eldonon aŭ la profilon, ne la kontrolon

Kiam profilo estis konstruita ĉirkaŭ kaŝnomo, aŭ readresu ĝin al la dokumentita gastnomo, aŭ reeldonu la atestilon por la kaŝnomo kaj lanĉu ĝin en planita fenestro. Silentigi la averton ne estas tria eblo, ĉar la kontrolo estas la sola paŝo, kiu ligas subskribitan atestilon al ĉi tiu konkreta gastiganto. Forigi ĝin signifas, ke iu ajn atestilo de la sama aŭtoritato povas anstataŭi la servilon, kiun vi celis atingi.

Renovigo devus konservi la celitajn nomojn kaj celon anstataŭ nur movi la eksvalidiĝan daton antaŭen. Renovigo, kiu perdas nomon, estas nova misfunkcio planita por la sekva restarto, kaj ĝi kutime venas sen averto, ĉar la malnova atestilo ankoraŭ validis kiam la ŝanĝo estis farita.

Registru la atendatan identecon, la nomojn prezentitajn kaj la ĉenon, kiu subskribis ilin. Tiu registro transformas la sekvan renovigon en komparon anstataŭ en esploron. La difino de la etendaĵo estas en RFC 5280 se vi bezonas kontroli specifan eldonon.

Rilataj artikoloj