strongSwan send_cert: kdaj se certifikat IKE pošlje

Prehodi beležijo napake preverjanja, povezane s certifikati, in prvi odziv je dodati prejemniku še en CA. To predpostavlja, da je certifikat prispel in bil zavrnjen. Druga možnost je, da nikoli ni bil poslan, in o tem odloča politika povezave pošiljatelja. Preden spremenite zaupanje, ugotovite, kateri od obeh primerov se je zgodil.

Kaj send_cert v resnici nadzoruje

Preverjanje s certifikatom zahteva, da certifikat končnega subjekta nasprotne strani prispe na drugo stran prek izmenjave IKE ali prek predhodne priprave. V swanctl nastavitev povezave send_cert določa, ali ta končna točka priloži svojo certifikatno vsebino: nikoli, vedno ali ifasked. Privzeto ifasked ga pošlje kot odgovor na zahtevo nasprotne strani po certifikatu. Zahteva za certifikat je ločena nastavitev, ker prositi drugo stran za njen certifikat ni isto kot ponuditi svojega.

Starejše namestitve ipsec.conf so uporabljale leftsendcert in rightsendcert, ta imena pa ustrezajo lokalnim in oddaljenim vlogam, ne pa neposredno swanctl.

Preberite en poskus, preden spremenite povezavo

Diagnosticirajte na podlagi enega nadzorovanega poskusa, ne na podlagi splošnega vtisa, da so vpleteni certifikati. Pregledati je mogoče tako politiko kot aktivno povezavo.

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

Seznam povezav prikazuje nastavljeno vrednost send_cert, seznam SA pa prikazuje, katere povezave so dejansko vzpostavljene. Dnevnik doda podrobnosti pogajanja: ali je prispela zahteva za certifikat in ali je certifikatna vsebina odšla. Splošna napaka preverjanja ne kaže na težavo z dostavo, zato poiščite konkretno izmenjavo, preden karkoli sklepate. Zapišite časovni žig poskusa, da okno dnevnika pokrije celoten rokovanje.

Zaupanje prejemnika je ločena odločitev

Dostava in zaupanje sta različni lastnosti in odprava ene ne odpravi druge. Prejemnik mora imeti predvideno sidro zaupanja, prejeti uporabno verigo in ustrezati pričakovani identiteti nasprotne strani. Certifikat končnega subjekta, ki prispe brez svojega vmesnega certifikata, še vedno ne prestane strogega preverjanja verige. Nasprotno pa namestitev CA nasprotne strani sploh ne sili, da pošlje svoj certifikat.

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

Pregled pokaže, kateri izdajatelj je podpisal certifikat in kdaj poteče, temu pa mora ustrezati sidro prejemnika. Zaupajte izdajatelju CA, ki ga ima namestitev, ne vsakemu vmesnemu certifikatu v verigi, ker povišanje vsakega vmesnega certifikata v korenino razširi zaupanje daleč onkraj ene nasprotne strani. Ohranite preverjanje identitete aktivno, ker povezava, ki uspe le z izklopljenim preverjanjem veljavnosti, ni popravek. Kjer je veriga nepopolna, popravite pripravo, ne politike pošiljatelja.

Pošiljatelja spreminjajte le z dokazi

Ko dnevnik pokaže, da certifikat ni bil nikoli poslan in je prejemnik zanj res zaprosil, je send_cert na always upravičena sprememba za to povezavo. Uporabite jo v konfiguraciji swanctl, znova naložite povezave in vzpostavite novo sejo, namesto da bi znova uporabili obstoječi SA. Potrdite, da se certifikatna vsebina zdaj pojavi in da jo prejemnik sprejme glede na predvideno sidro. Če se nič ne spremeni, je bila napaka vendarle na strani zaupanja in nastavitev pošiljatelja ni bila vzrok.

Zapišite opaženo izmenjavo, sidro in iz tega izhajajoče preverjanje v zapis sprememb. Popravek certifikata, ki ga ni mogoče opisati s temi pojmi, je naključje.