strongSwan send_cert: kiam la IKE-atestilo estas sendata

Enirejoj protokolas atestil-rilatajn aŭtentigajn malsukcesojn, kaj la unua instinkto estas aldoni alian CA al la ricevanto. Tio supozas, ke la atestilo alvenis kaj estis rifuzita. La alia ebleco estas, ke ĝi neniam estis sendita, kaj tion decidas la konekta politiko de la sendanto. Determinu, kiu el la du okazis, antaŭ ol ŝanĝi la fidon.

Kion send_cert fakte regas

Atestila aŭtentigo bezonas, ke la fina-entjeta atestilo de la peer atingas la alian flankon per la IKE-interŝanĝo aŭ per antaŭa pretigo. En swanctl la konekta agordo send_cert regas, ĉu ĉi tiu finpunkto inkluzivas sian atestilan ŝarĝon: neniam, ĉiam aŭ ifasked. La defaŭlta ifasked sendas ĝin kiel respondon al atestila peto de la peer. Peti atestilon estas aparta agordo, ĉar peti de la alia flanko ĝian atestilon ne samas kiel proponi la propran.

Pli malnovaj ipsec.conf-aparataroj uzis leftsendcert kaj rightsendcert, kaj tiuj nomoj rilatas al lokaj kaj malproksimaj roloj, ne rekte al swanctl.

Legu unu provon antaŭ ol ŝanĝi la konekton

Diagnozu el unu kontrolita provo, ne el la ĝenerala impreso, ke atestiloj estas implikitaj. Kaj la politiko kaj la aktiva asocio estas inspekteblaj.

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

La konekta listo montras la agorditan valoron de send_cert, kaj la SA-listo montras, kiuj konektoj fakte ekestis. La protokolo aldonas detalojn pri la traktado: ĉu atestila peto estis ricevita kaj ĉu atestila ŝarĝo eliris. Ĝenerala aŭtentiga malsukceso ne indikas liveran problemon, do serĉu la konkretan interŝanĝon antaŭ ol konkludi ion. Notu la tempindikon de la provo, por ke la protokola fenestro kovru la tutan manpremon.

La fido de la ricevanto estas aparta decido

Liverado kaj fido estas malsamaj ecoj, kaj ripari unu ne riparas la alian. Ricevanto devas posedi la celitan fid-Ankron, ricevi uzeblan ĉenon kaj kongrui kun la atendata identeco de la peer. Fina-entjeta atestilo, kiu alvenas sen sia intera atestilo, ankoraŭ malsukcesas ĉe strikta ĉena kontrolo. Male, instali CA tute ne devigas peer-on sendi sian atestilon.

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

La inspektado montras, kiu eldoninto subskribis la atestilon kaj kiam ĝi eksvalidiĝas, kaj al tio devas respondi la ankro de la ricevanto. Fidu la eldonantan CA-on, kiun posedas la aparataro, ne ĉiun interan atestilon en la ĉeno, ĉar promocii ĉiun interan atestilon al radiko vastigas fidon multe preter unu peer. Tenu identecan kontrolon aktiva, ĉar konekto, kiu sukcesas nur kun malŝaltita validado, ne estas riparo. Kie la ĉeno estas nekompleta, riparu la pretigon anstataŭ la politikon de la sendanto.

Ŝanĝu la sendanton nur kun pruvoj

Kiam la protokolo montras, ke la atestilo neniam estis sendita kaj la ricevanto ja petis ĝin, agordi send_cert al always estas pravigita ŝanĝo por tiu konekto. Apliku ĝin en la swanctl-agordo, reŝargu la konektojn kaj starigu novan seancon anstataŭ reuzi la ekzistantan SA. Konfirmu, ke la atestila ŝarĝo nun aperas kaj ke la ricevanto akceptas ĝin kontraŭ la celita ankro. Se nenio ŝanĝiĝas, la misfunkcio estis tamen ĉe la fida flanko kaj la sendanta agordo ne estis la kaŭzo.

Skribu la observitan interŝanĝon, la ankron kaj la rezultan kontrolon en la ŝanĝregistron. Atestila riparo, kiun oni ne povas priskribi per tiuj terminoj, estas koincido.