strongSwan send_cert: millal IKE-sertifikaat saadetakse

send_cert määrab, kas peer saadab oma sertifikaadi, samas kui send_certreq palub teisel poolel seda teha. Enne vastuvõtja usalduse muutmist kontrolli logisid.

Gateway'd logivad sertifikaadiga seotud autentimisvigu ja esimene mõte on lisada vastuvõtjale veel üks CA. See eeldab, et sertifikaat saabus ja lükati tagasi. Teine võimalus on, et seda ei saadetudki, ja selle otsustab saatja ühendusepoliitika. Tehke kindlaks, kumb kahest juhtus, enne kui usaldust muudate.

Mida send_cert tegelikult juhib

Sertifikaatautentimine nõuab, et peeri lõpp-üksuse sertifikaat jõuaks teisele poolele IKE-vahetuse või varasema juurutamise kaudu. swanctl-is määrab ühenduse säte send_cert, kas see otspunkt lisab oma sertifikaadi kandevõime: mitte kunagi, alati või ifasked. Vaikeväärtus ifasked saadab selle vastuseks peeri sertifikaadipäringule. Sertifikaadi küsimine on eraldi säte, sest teiselt poolelt tema sertifikaadi küsimine ei ole sama, mis oma sertifikaadi pakkumine.

Vanemad ipsec.conf-paigaldused kasutasid leftsendcert ja rightsendcert ning need nimed vastavad kohalikele ja kaugrollidele, mitte otse swanctl-ile.

Lugege üks katse enne ühenduse muutmist

Diagnoosige ühe kontrollitud katse põhjal, mitte üldise mulje põhjal, et sertifikaadid on mängus. Nii poliitikat kui ka aktiivset assotsiatsiooni saab uurida.

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

Ühenduste loend näitab konfigureeritud send_cert väärtust ja SA-de loend näitab, millised ühendused tegelikult üles tulid. Logi lisab läbirääkimise üksikasju: kas sertifikaadipäring võeti vastu ja kas sertifikaadi kandevõime läks välja. Üldine autentimisviga ei viita tarneveale, seega otsige konkreetset vahetust, enne kui midagi järeldate. Märkige katse ajatempel, et logiakna kataks kogu kätluse.

Vastuvõtja usaldus on eraldi otsus

Tarne ja usaldus on erinevad omadused ning ühe parandamine ei paranda teist. Vastuvõtjal peab olema kavandatud usaldusankur, ta peab saama kasutatava ahela ja vastama oodatud peeri identiteedile. Lõpp-üksuse sertifikaat, mis saabub ilma oma vahesertifikaadita, ebaõnnestub ikkagi range ahelakontrolli korral. Vastupidi, CA paigaldamine ei kohusta peeri oma sertifikaati üldse saatma.

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

Kontroll näitab, milline väljaandja sertifikaadi allkirjastas ja millal see aegub, ja sellele peab vastama vastuvõtja ankur. Usalda väljaandvat CA-d, mis kuulub juurutusele, mitte iga vahesertifikaati ahelas, sest iga vahesertifikaadi juureks tõstmine laiendab usaldust palju kaugemale kui üks peer. Hoidke identiteedi kontrollimine aktiivne, sest ühendus, mis õnnestub ainult keelatud valideerimisega, ei ole lahendus. Kus ahel on puudulik, parandage juurutamist, mitte saatja poliitikat.

Muutke saatjat ainult tõenditega

Kui logi näitab, et sertifikaati ei saadetudki, ja vastuvõtja seda siiski küsis, on send_cert väärtus always selle ühenduse jaoks põhjendatud muudatus. Rakendage seda swanctl-konfiguratsioonis, laadige ühendused uuesti ja looge uus sessioon, selle asemel et olemasolevat SA-d uuesti kasutada. Kinnitage, et sertifikaadi kandevõime nüüd ilmub ja et vastuvõtja aktsepteerib seda kavandatud ankru vastu. Kui miski ei muutu, oli viga ikkagi usalduse poolel ja saatja säte ei olnud põhjus.

Kirjutage täheldatud vahetus, ankur ja sellest tulenev verifitseerimine muudatuste registrisse. Sertifikaadiparandus, mida ei saa nendes termintes kirjeldada, on juhus.

Seotud artiklid