strongSwan send_cert: noiz bidaltzen den IKE ziurtagiria

Atebideek ziurtagiriekin lotutako autentifikazio hutsegiteak erregistratzen dituzte, eta lehen erreakzioa hartzaileari beste CA bat gehitzea da. Horrek suposatzen du ziurtagiria iritsi eta baztertu egin zela. Beste aukera da inoiz bidali ez izana, eta bidaltzailearen konexio-politikak erabakitzen du hori. Konfiantza aldatu aurretik zehaztu bietatik zein gertatu zen.

Zer kontrolatzen du benetan send_cert-ek

Ziurtagiri bidezko autentifikazioak peer-aren amaierako entitate ziurtagiria beste aldera iristea eskatzen du, IKE trukearen edo aldez aurreko prestaketaren bidez. swanctl-en konexio-ezarpenak send_cert erabakitzen du mutur honek bere ziurtagiri-karga sartzen duen: inoiz ez, beti edo ifasked. ifasked lehenetsiak peer-ak egindako ziurtagiri eskaerari erantzunez bidaltzen du. Ziurtagiri bat eskatzea beste ezarpen bat da, beste alderdiari bere ziurtagiria eskatzea ez baita berdina norberarena eskaintzearekin.

ipsec.conf inplementazio zaharrek leftsendcert eta rightsendcert erabiltzen zituzten, eta izen horiek rol lokal eta urrunekoei dagozkie, ez zuzenean swanctl-i.

Irakurri saiakera bat konexioa aldatu aurretik

Saiakera kontrolatu batetik diagnostikatu, ez ziurtagiriak tartean daudelako inpresio orokorretik. Politika zein asoziazio aktiboa ikus daitezke.

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

Konexioen zerrendak send_cert-ren konfiguratutako balioa erakusten du, eta SA zerrendak zein konexio benetan sortu ziren erakusten du. Erregistroak negoziazioaren xehetasunak gehitzen ditu: ziurtagiri eskaera bat jaso zen eta ziurtagiri karga bat atera zen. Autentifikazio hutsegite orokorrak ez du bidalketa-arazorik adierazten, beraz bilatu truke zehatza ondorio bat atera aurretik. Idatzi saiakeraren denbora-marka, erregistro-leihoak esku-ukaldi osoa estal dezan.

Hartzailearen konfiantza erabaki bereizia da

Bidalketa eta konfiantza propietate desberdinak dira, eta bat konpontzeak ez du bestea konpontzen. Hartzaileak nahi den konfiantza-ankra izan behar du, erabilgarria den katea jaso behar du eta espero den peer identitatearekin bat etorri behar du. Bere tarteko ziurtagiririk gabe iristen den amaierako entitate ziurtagiriak kate-egiaztapen zorrotzean huts egiten du oraindik. Alderantziz, CA bat instalatzeak ez du peer bat bere ziurtagiria bidaltzera behartzen.

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

Egiaztapenak erakusten du zein igorlek sinatu zuen ziurtagiria eta noiz iraungitzen den, eta hartzailearen ankrak horri erantzun behar dio. Konfiantza ezazu inplementazioak duen igorle CAan, ez kateko tarteko ziurtagiri guztietan, tarteko bakoitza erro bihurtzeak konfiantza peer batetik askoz harago zabaltzen baitu. Eduki identitatearen egiaztapena aktibo, baliozkotzea itzalita soilik lortzen den konexioa ez baita konponketa bat. Kateak osatugabea duenean, konpondu prestaketa, ez bidaltzailearen politika.

Aldatu bidaltzailea froga daukazunean soilik

Erregistroak erakusten duenean ziurtagiria inoiz ez zela bidali eta hartzaileak benetan eskatu zuela, send_cert always-era ezartzea aldaketa justifikatua da konexio horretarako. Aplikatu swanctl konfigurazioan, birkargatu konexioak eta ezarri saio berri bat lehendik dagoen SA berrerabili ordez. Egiaztatu ziurtagiri-karga orain agertzen dela eta hartzaileak nahi den ankraren aurka onartzen duela. Ezer aldatzen ez bada, hutsegitea konfiantza aldean zegoen eta bidaltzailearen ezarpena ez zen arrazoia.

Idatzi behatutako trukea, ankra eta hortik datorren egiaztapena aldaketa-erregistroan. Termino horietan deskribatu ezin den ziurtagiri konponketa bat kasualitatea da.