strongSwan send_cert: wannear't it IKE-sertifikaat ferstjoerd wurdt

Gateways lochje sertifikaat-relatearre autentikaasjeflaters, en de earste ympuls is om noch in CA oan de ûntfanger ta te foegjen. Dat ferûnderstelt dat it sertifikaat oankaam en wegere waard. De oare mooglikheid is dat it nea ferstjoerd waard, en it ferbiningsbelied fan de stjoerder beslút dat. Bepaal hokker fan de beide bard is foardat jo it fertrouwen oanpasse.

Wat send_cert eins regelet

Sertifikaatautentikaasje freget dat it ein-entiteitssertifikaat fan de peer de oare kant berikt fia de IKE-útwikseling of fia eardere foarsjenning. Yn swanctl regelet de ferbiningsynstelling send_cert oft dit einpunt syn sertifikaatlading meistjoerdt: nea, altyd of ifasked. De standert ifasked stjoert it as antwurd op in sertifikaatfersyk fan de peer. In sertifikaat oanfreegje is in aparte ynstelling, want de oare kant om har sertifikaat freegje is net itselde as dyn eigen oanbiede.

Aldere ipsec.conf-ymplemintaasjes brûkten leftsendcert en rightsendcert, en dy nammen ferwize nei lokale en ôfstâne rollen yn stee fan direkt nei swanctl.

Lês ien poging foardat jo de ferbining feroarje

Diagnostisearje fanút ien kontrolearre poging, net fanút de algemiene yndruk dat sertifikaten derby belutsen binne. Sawol it belied as de aktive assosjaasje binne te besjen.

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

De ferbiningslist toant de konfigurearre wearde fan send_cert, en de SA-list toant hokker ferbiningen wier ta stân kamen. It logboek foeget ûnderhannelingsdetails ta: oft in sertifikaatfersyk binnenkaam en oft in sertifikaatlading útgie. In algemiene autentikaasjeflater wiist gjin oerleveringsprobleem oan, sykje dus de spesifike útwikseling foardat jo eat konkludearje. Skriuw de tiidstimpel fan de poging op, sadat it logfinster de hiele handshake dekt.

It fertrouwen fan de ûntfanger is in aparte beslissing

Oerlevering en fertrouwen binne ferskillende eigenskippen, en it iene oplosse lost it oare net op. In ûntfanger moat it bedoelde fertrouwensanker hâlde, in brûkbere keatling ûntfange en by de ferwachte identiteit fan de peer passe. In ein-entiteitssertifikaat dat sûnder syn tuskenlizzende sertifikaat oankomt, falt noch altyd by in strang keatlingkontrôle. Oarsom twingt it ynstallearjen fan in CA in peer hielendal net om syn sertifikaat te ferstjoeren.

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

De ynspeksje toant hokker útjouwer it sertifikaat ûndertekene hat en wannear't it ferrint, en dêr moat it anker fan de ûntfanger mei oerienkomme. Fertrou de útjouwende CA dy't de ymplemintaasje besit, net elk tuskenlizzend sertifikaat yn 'e keatling, want elk tuskenlizzend sertifikaat ta root ferheffe ferbredelet fertrouwen folle fierder as ien peer. Hâld identiteitsferifikaasje aktyf, want in ferbining dy't allinnich slagget mei falidaasje útskeakele is gjin oplossing. Wêr't de keatling ûnfolslein is, reparearje de foarsjenning yn stee fan it belied fan de stjoerder.

Feroarje de stjoerder allinnich mei bewiis

Sadree't it logboek toant dat it sertifikaat nea ferstjoerd waard en de ûntfanger wol ien frege hat, is send_cert op always in rjochtfeardige feroaring foar dy ferbining. Pas it ta yn de swanctl-konfiguraasje, herlaad de ferbiningen en set in nije sesje op yn stee fan de besteande SA te werbrûken. Befêstigje dat de sertifikaatlading no ferskynt en dat de ûntfanger dy tsjin it bedoelde anker akseptearret. Feroaret der neat, dan lei de flater dochs oan de fertrouwenskant en wie de stjoerderynstelling net de oarsaak.

Skriuw de waarnommen útwikseling, it anker en de dêrút folgjende ferifikaasje yn it feroaringsrekord. In sertifikaatoplossing dy't net yn dy termen beskreaun wurde kin, is in tafal.