SAN-i i certifikatës IKEv2: pse dështon kontrolli i identitetit

Certifikata juaj zinxhirohet në një CA të besuar, datat janë në rregull dhe pala tjetër refuzon ende të përfundojë fazën 1 me një gabim identiteti. Arritshmëria dhe një nënshkrim i vlefshëm janë vetëm gjysma e asaj që kontrollon një klient IKEv2. Gjysma tjetër është nëse identiteti që pret shfaqet në certifikatë në fushën e duhur, dhe këtë pritshmëri e vendos profili, jo emri i skedarit të certifikatës.

Simptoma ka gjithmonë të njëjtën formë

Një profil lidhjeje ndryshohet nga një emër host në një adresë IP, ose rinovohet nga një certifikatë që mbante një emër DNS në një që mban vetëm adresa, dhetuneli ndalon së negociuari. Asgjë në rrugën e rrjetit nuk ndryshoi. Klienti arrin palën tjetër, merr një certifikatë dhe refuzon identitetin e palës tjetër sepse identifikuesi që iu tha të priste nuk përfaqësohet në një fushë që ai pranon. Rinovimet janë shkaku i zakonshëm, pasi certifikata zëvendësuese shpesh vjen nga një shabllon i ndryshëm nga ajo që zëvendëson.

Të dyja palët regjistrojnë më pas diçka të padobishme, prandaj dështimi raportohet zakonisht si problem certifikate. Regjistri i klientit mund të përmendë identitetin që dëshironte, dhe ai emër është gjurma që ju nevojitet, jo data e skadimit.

Përputhni llojin e identifikuesit, jo vetëm vlerën

Një SAN dNSName dhe një SAN iPAddress janë fusha të ndryshme me rregulla përputhjeje të ndryshme, kështu që një certifikatë që mban 203.0.113.10 si varg DNS nuk kënaq një klient që pret një identitet IP. Validatorët modernë kryesisht injorojnë emrin e përbashkët, prandaj etiketa miqësore në detajet e certifikatës nuk provon asgjë për atë që do të përputhet. Nëse gjatë zgjidhjes së problemeve emri i hostit u zëvendësua me një adresë, supozoni se identiteti i pritur u zhvendos me të derisa ta keni kontrolluar. Krahasoni vargun në profil me vargun në SAN karakter pas karakteri, sepse një pikë në fund ose një hapësirë e tepërt mjaftojnë.

Wildcards janë vetëm një komoditet i DNS dhe ndjekin rregullat e tyre të përputhjes, që është një arsye tjetër pse një profil i bazuar në IP nuk duhet të mbështetet kurrë tek ato.

Gjeni ku e ruan secili klient pritshmërinë

Në strongSwan, vlera që krahasohet me certifikatën vjen nga cilësimi i identitetit të palës tjetër: rightid në konfigurimin klasik, ose id e një seksioni lidhjeje në distancë në swanctl. Dokumentacioni i tij për interoperabilitetin me Apple IKEv2 është i dobishëm këtu sepse shpjegon konventat e identitetit që përdor një klient i drejtuar nga profili, dhe ato konventa shpjegojnë një klasë mospërputhjesh që duken të rastësishme në linjë.

Profilet e konfigurimit Apple mbajnë një fushë identifikuesi në distancë, dhe vlera atje është ajo që kontrollon klienti, jo adresa e serverit në cilësimet e lidhjes. Klientët Windows dhe të pajisjeve kanë secili fushën e vet me vlerën e vet të parazgjedhur, dhe vlera e parazgjedhur shpesh ndjek adresën që keni shtypur. Kur dy fusha nuk pajtohen, fiton ajo që klienti lexon në të vërtetë, dhe rrallë është ajo që keni redaktuar.

Riparoni profilin ose certifikatën, me qëllim

Përpara se të ndryshoni ndonjë gjë, inspektoni certifikatën e palës tjetër me mjete të miratuara dhe renditni hyrjet SAN me llojet e tyre. Ai inspektim nuk kërkon çelës privat dhe as ngarkim, dhe e zgjidh çështjen në sekonda. Nëse vendosja synon një identitet të vetëm DNS, certifikata duhet ta mbajë atë si hyrje dNSName, dhe nëse vendosja synon një adresë, certifikata ka nevojë për një hyrje iPAddress pikërisht për atë adresë.

Kur certifikata është e gabuar, kërkoni nga operatori një të korrigjuar me identifikuesin e pritur specifik. Kur profili është i gabuar, rregulloni profilin dhe lini certifikatën në paqe. Çaktivizimi i validimit të identitetit e bën gabimin të zhduket dhe heq kontrollin që tuneli flet me palën e synuar.

Dokumentoni identitetin e pritur për secilën platformë klienti, sepse një vlerë që një klient e nxjerr automatikisht mund të duhet të jetë e qartë në një tjetër.

Jepini kërkesës për rinovim katër fakte

Shkruani identifikuesin e pritur dhe llojin e tij, hyrjet SAN që certifikata aktuale ka vërtet, klientin dhe versionin që kryejnë kontrollin, dhe tekstin e saktë të gabimit. Një kërkesë rinovimi e ndërtuar nga këto katër rreshta merr certifikatën e duhur herën e parë, në vend të një tjetre me të njëjtin emër skedari të njohur.