qëllim certifikate i pambështetur: pse dështon CA e ndërmjetme

Qëllimi i certifikatës së serverit duket i saktë, çelësi përputhet, datat janë në rregull, dhe lidhja ende dështon me unsupported certificate purpose. Detaji që e zgjidh këtë zakonisht ndodhet në të njëjtin rresht me gabimin: një vlerë thellësie dhe një subject që emërtojnë një certifikatë më lart në zinxhir. Ekzekutohen dy teste të ndryshme, dhe vetëm njëri prej tyre ka të bëjë me gjethen. Krahasimi i tyre shpjegon pse zëvendësimi i certifikatës së serverit nuk ndryshon asgjë.

Cilën certifikatë verifikuesi refuzoi në të vërtetë

Një zinxhir nuk është një objekt i përsëritur tri herë. Gjethja mban emrin dhe çelësin e serverit, të ndërmjetmet e lidhin atë me një rrënjë, dhe secila ka periudhën e vet të vlefshmërisë, kufizimet dhe përdorimet. Kur gabimi emërton një thellësi, ai numër identifikon një pozicion në zinxhirin që ndërtoi verifikuesi, dhe mund të mos jetë pozicioni që prisni nëse serveri dërgon një zinxhir të papritur.

Lexoni fushat e certifikatës në atë thellësi, jo të certifikatës që supozuat fajtore. Kërkoni dy shtesat që kufizojnë lëshimin në vend që të hidhni çdo fushë, sepse përgjigjja është pothuajse gjithmonë në njërën prej tyre. Dalja e shtesave është e sigurt për t'u ndarë; çelësat privatë kurrë.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Nëse certifikata e emërtuar është e ndërmjetme dhe përdorimi i zgjeruar i çelësit të saj përmend diçka të palidhur me vërtetimin e serverit TLS, pjesa tjetër e dështimit vjen në mënyrë mekanike. Zinxhiri nuk mund të përdoret për qëllimin që kërkoi OpenVPN.

Qëllimi i gjethes dhe politika e zinxhirit janë dy teste

Testi i gjethes bën një pyetje të ngushtë: a lejon kjo certifikatë e entitetit përfundimtar vërtetimin e serverit për këtë emër? Testi i zinxhirit bën një më të gjerë: a mund çdo certifikatë në rrugë të shërbejë atë qëllim? Një autoritet certifikimi që lejohet të lëshojë vetëm certifikata klienti do të kalojë kontrollet e veta të nënshkrimit dhe gjithsesi do të dështojë testin e dytë, sepse rruga që autorizon nuk përfshin qëllimin që i nevojitet aplikacionit. Dy testet dështojnë me të njëjtat fjalë dhe kanë riparime krejt të ndryshme.

Prandaj një gjethe e sapolëshuar, e saktë në çdo fushë të dukshme, mund të dështojë menjëherë. Prandaj rregullimi zakonisht i takon profilit të autoritetit lëshues dhe jo konfigurimit të VPN.

Një EKU që mungon nuk është EKU kufizues

RFC 5280 e bën shtesën e përdorimit të zgjeruar të çelësit opsionale dhe, kur është e pranishme, kufizuese. Një certifikatë CA pa shtesën, pra, nuk ka thënë «jo» vërtetimit të serverit, ndërsa një që liston vetëm një qëllim të palidhur ka thënë diçka shumë specifike. Trajtimi i këtyre dy gjendjeve si ekuivalente prodhon diagnozën e gabuar dhe, më keq, riparimin e gabuar. Dallimi shpjegon gjithashtu pse dy autoritete që duken njësoj në një konsol sillen krejt ndryshe në një zinxhir.

Sjellja e bibliotekave gjithashtu nuk është uniforme këtu. dokumenti i OpenSSL për opsionet e verifikimit përshkruan trajtimin e vet të kontrolleve të qëllimit në certifikatat CA, dhe ai trajtim është politikë implementimi, jo një rregull që çdo stiv TLS ndjek identikisht. Përshkruani çfarë bën verifikuesi juaj, pastaj konfirmojeni me versionin që ekzekutoni vërtet.

Riprodhoni dështimin offline përpara se të rilëshoni

Një verifikim offline e nxjerr aplikacionin nga ekuacioni. Nëse zinxhiri dështon në të njëjtën mënyrë nën të njëjtin qëllim, problemi është certifikata dhe asnjë konfigurim serveri nuk e fsheh atë. Nëse zinxhiri kalon offline ndërsa shërbimi ende refuzon, aplikacioni po kërkon një qëllim tjetër ose po përdor një zinxhir tjetër nga ai që testuat.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain ka rëndësi sepse shtyp rrugën që ndërtoi mjeti, dhe ajo shpesh nuk është rendi i skedarëve që dhatë. Ajo dalje është mënyra më e shpejtë për të zbuluar se një e ndërmjetme e dytë po tërhiqet nga një depo besimi, se serveri dërgon një variant të nënshkruar në mënyrë të kryqëzuar që nuk e kishit menduar, ose se flamuri i qëllimit të kopjuar nga një tutorial i takon një roli tjetër nga ai që po shërbehet.

Rregulloni politikën e lëshimit, jo thirrjen e verifikimit

Riparimi i qëndrueshëm është një e ndërmjetme e lëshuar sipas një politike që lejon qëllimet që duhet të shërbejë, me kufizimin e shkruar dhe të rishikuar. Shtimi i çdo qëllimi te çdo autoritet nuk është politikë; ai heq kufizimin që i dha kuptim shtesës dhe zakonisht i mbijeton incidentit që e shkaktoi. Një shënim i shkurtër në profil që përshkruan cilat role autoriteti mund të vërtetojë parandalon që rilëshimi i radhës të përsëritë të njëjtën debat.

Çaktivizimi i verifikimit është shkurtesa tjetër joshëse dhe e kthen një problem certifikate në një problem besimi. Mbani kontrollin e qëllimit, rregulloni zinxhirin dhe ekzekutoni përsëri të njëjtin verifikim offline për të konfirmuar se rruga tani shërben rolin e synuar përpara se të prekni përsëri shërbimin.