strongSwan send_cert: wanneer die IKE-sertifikaat gestuur word

Gateways teken sertifikaatverwante verifikasiefoute aan, en die eerste instink is om nog 'n CA by die ontvanger by te voeg. Dit veronderstel dat die sertifikaat aangekom en verwerp is. Die ander moontlikheid is dat dit nooit gestuur is nie, en die sender se verbindingsbeleid besluit daaroor. Bepaal watter van die twee gebeur het voordat jy vertroue wysig.

Wat send_cert werklik beheer

Sertifikaatverifikasie vereis dat die eweknie se entiteitsertifikaat die ander kant bereik deur die IKE-uitruiling of deur vooraf voorsiening. In swanctl bepaal die verbindingsinstelling send_cert of hierdie eindpunt sy sertifikaatvrag insluit: nooit, altyd of ifasked. Die standaard ifasked stuur dit in antwoord op 'n sertifikaatversoek van die eweknie. 'n Sertifikaat aanvra is 'n aparte instelling, want om die ander kant vir sy sertifikaat te vra is nie dieselfde as om jou eie aan te bied nie.

Ouer ipsec.conf-ontplooiings het leftsendcert en rightsendcert gebruik, en daardie name pas by plaaslike en afgeleë rolle eerder as direk by swanctl.

Lees een poging voordat jy die verbinding wysig

Diagnoseer uit een beheerde poging, nie uit die algemene indruk dat sertifikate betrokke is nie. Beide die beleid en die aktiewe assosiasie kan ondersoek word.

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

Die verbindingslys wys die ingestelde waarde van send_cert, en die SA-lys wys watter verbindings werklik opgekom het. Die logboek voeg onderhandelingsbesonderhede by: of 'n sertifikaatversoek ontvang is en of 'n sertifikaatvrag uitgestuur is. 'n Algemene verifikasiefout dui nie op 'n afleweringsprobleem nie, soek dus die spesifieke uitruiling voordat jy enige gevolgtrekking maak. Teken die poging se tydstempel aan sodat die logvenster die hele handdruk dek.

Die ontvanger se vertroue is 'n aparte besluit

Aflewering en vertroue is verskillende eienskappe, en om die een reg te maak maak nie die ander reg nie. 'n Ontvanger moet die beoogde vertrouensanker hou, 'n bruikbare ketting ontvang en by die verwagte eweknie-identiteit pas. 'n Entiteitsertifikaat wat sonder sy tussenliggende sertifikaat aankom, faal steeds 'n streng kettingkontrole. Omgekeerd dwing die installering van 'n CA 'n eweknie geensins om sy sertifikaat hoegenaamd te stuur nie.

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

Die inspeksie wys watter uitreiker die sertifikaat onderteken het en wanneer dit verval, en dit is waarmee die ontvanger se anker moet ooreenstem. Vertrou die uitreikende CA wat die ontplooiing besit, nie elke tussenliggende sertifikaat in die ketting nie, want om elke tussenliggende sertifikaat tot wortel te verhef verbreed vertroue veel verder as een eweknie. Hou identiteitsverifikasie aktief, want 'n verbinding wat net slaag met validering uitgeskakel is nie 'n oplossing nie. Waar die ketting onvolledig is, herstel die voorsiening eerder as die sender se beleid.

Verander die sender net met bewyse

Sodra die logboek wys die sertifikaat is nooit gestuur nie en die ontvanger het wel een versoek, is send_cert op always 'n geregverdigde verandering vir daardie verbinding. Pas dit in die swanctl-konfigurasie toe, herlaai die verbindings en vestig 'n nuwe sessie eerder as om die bestaande SA te hergebruik. Bevestig dat die sertifikaatvrag nou verskyn en dat die ontvanger dit teen die beoogde anker aanvaar. As niks verander nie, was die fout tog aan die vertrouekant en was die senderinstelling nie die oorsaak nie.

Skryf die waargenome uitruiling, die anker en die gevolglike verifikasie in die veranderingsrekord. 'n Sertifikaatherstel wat nie in daardie terme beskryf kan word nie, is 'n toeval.