strongSwan send_cert: kur dërgohet certifikata IKE

Portat regjistrojnë dështime vërtetimi që lidhen me certifikatat, dhe impulsi i parë është të shtohet një CA tjetër te marrësi. Kjo supozon se certifikata mbërriti dhe u refuzua. Mundësia tjetër është që të mos jetë dërguar kurrë, dhe këtë e vendos politika e lidhjes së dërguesit. Përcaktoni cila nga të dyja ndodhi përpara se të ndryshoni besimin.

Çfarë kontrollon në të vërtetë send_cert

Vërtetimi me certifikatë kërkon që certifikata e entitetit përfundimtar të peer-it të arrijë palën tjetër përmes shkëmbimit IKE ose përmes një përgatitjeje të mëparshme. Në swanctl cilësimi i lidhjes send_cert përcakton nëse kjo pikë fundore përfshin ngarkesën e certifikatës së vet: kurrë, gjithmonë ose ifasked. Vlera e parazgjedhur ifasked e dërgon si përgjigje ndaj një kërkese certifikate nga peer-i. Kërkimi i një certifikate është cilësim i veçantë, sepse t'i kërkosh palës tjetër certifikatën e saj nuk është e njëjta gjë me ofrimin e asaj tënde.

Vendosjet më të vjetra ipsec.conf përdornin leftsendcert dhe rightsendcert, dhe këto emra korrespondojnë me rolet lokale dhe të largëta, jo drejtpërdrejt me swanctl.

Lexoni një provë përpara se të ndryshoni lidhjen

Diagnostikoni nga një provë e vetme e kontrolluar, jo nga përshtypja e përgjithshme se janë të përfshira certifikata. Si politika ashtu edhe asocimi aktiv mund të inspektohen.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Lista e lidhjeve tregon vlerën e konfiguruar të send_cert, dhe lista e SA tregon cilat lidhje u ngritën vërtet. Regjistri shton detaje të negocimit: nëse u prit një kërkesë certifikate dhe nëse doli një ngarkesë certifikate. Një dështim i përgjithshëm vërtetimi nuk identifikon një problem shpërndarjeje, prandaj kërkoni shkëmbimin konkret përpara se të konkludoni diçka. Shënoni vulën kohore të provës që dritarja e regjistrit të mbulojë gjithë shtrëngimin e duarve.

Besimi i marrësit është vendim i veçantë

Shpërndarja dhe besimi janë veti të ndryshme, dhe rregullimi i njërës nuk rregullon tjetrën. Marrësi duhet të ketë ankorën e synuar të besimit, të marrë një zinxhir të përdorshëm dhe të përputhet me identitetin e pritur të peer-it. Një certifikatë e entitetit përfundimtar që mbërrin pa certifikatën e saj të ndërmjetme vazhdon të dështojë në një kontroll të rreptë zinxhiri. Në të kundërt, instalimi i një CA nuk e detyron aspak një peer të dërgojë certifikatën e vet.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Inspektimi tregon cili lëshues nënshkroi certifikatën dhe kur skadon, dhe ankorës së marrësit duhet t'i përgjigjet kjo. Besoni CA-së lëshuese që zotëron vendosja, jo çdo certifikate të ndërmjetme në zinxhir, sepse ngritja e çdo të ndërmjetmeje në rrënjë e zgjeron besimin shumë përtej një peer-i. Mbajeni aktiv verifikimin e identitetit, pasi një lidhje që ka sukses vetëm me validim të çaktivizuar nuk është rregullim. Aty ku zinxhiri është i paplotë, rregulloni përgatitjen dhe jo politikën e dërguesit.

Ndryshoni dërguesin vetëm me prova

Kur regjistri tregon se certifikata nuk u dërgua kurrë dhe marrësi vërtet e kërkoi, vendosja e send_cert në always është ndryshim i justifikuar për atë lidhje. Zbatojeni në konfigurimin swanctl, ringarkoni lidhjet dhe vendosni një sesion të re në vend që të ripërdorni SA-në ekzistuese. Konfirmoni se ngarkesa e certifikatës shfaqet tani dhe se marrësi e pranon kundrejt ankorës së synuar. Nëse asgjë nuk ndryshon, defekti ishte prapë në anën e besimit dhe cilësimi i dërguesit nuk ishte shkaku.

Shkruani shkëmbimin e vëzhguar, ankorën dhe verifikimin që rezulton në regjistrin e ndryshimeve. Një rregullim certifikate që nuk mund të përshkruhet me këto terma është rastësi.