strongSwan send_cert: când este trimis certificatul IKE

Gateway-urile înregistrează eșecuri de autentificare legate de certificate, iar primul impuls este să adauge încă o CA la receptor. Aceasta presupune că certificatul a ajuns și a fost respins. Cealaltă posibilitate este că nu a fost trimis niciodată, iar acest lucru este decis de politica de conexiune a expeditorului. Stabiliți care dintre cele două cazuri s-a întâmplat înainte de a modifica încrederea.

Ce controlează de fapt send_cert

Autentificarea prin certificat necesită ca certificatul de entitate finală al peer-ului să ajungă la cealaltă parte prin schimbul IKE sau printr-o pregătire prealabilă. În swanctl, setarea conexiunii send_cert stabilește dacă acest punct final își include încărcătura de certificat: niciodată, întotdeauna sau ifasked. Valoarea implicită ifasked îl trimite ca răspuns la o cerere de certificat din partea peer-ului. Cererea unui certificat este o setare separată, deoarece a cere celeilalte părți certificatul ei nu este același lucru cu a-l oferi pe al tău.

Implementările mai vechi de ipsec.conf foloseau leftsendcert și rightsendcert, iar aceste nume corespund rolurilor local și la distanță, nu direct swanctl.

Citiți o încercare înainte de a modifica conexiunea

Diagnosticați pe baza unei singure încercări controlate, nu pe baza impresiei generale că sunt implicate certificate. Atât politica, cât și asocierea activă pot fi inspectate.

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

Lista conexiunilor arată valoarea configurată a send_cert, iar lista SA arată ce conexiuni au fost într-adevăr stabilite. Jurnalul adaugă detalii despre negociere: dacă a fost primită o cerere de certificat și dacă a ieșit o încărcătură de certificat. Un eșec de autentificare generic nu identifică o problemă de livrare, așa că găsiți schimbul concret înainte de a trage vreo concluzie. Notați marca temporală a încercării, astfel încât fereastra jurnalului să acopere întreaga strângere de mână.

Încrederea receptorului este o decizie separată

Livrarea și încrederea sunt proprietăți diferite, iar rezolvarea uneia nu o rezolvă pe cealaltă. Un receptor trebuie să dețină ancora de încredere dorită, să primească un lanț utilizabil și să corespundă identității așteptate a peer-ului. Un certificat de entitate finală care sosește fără certificatul său intermediar eșuează în continuare la o verificare strictă a lanțului. Dimpotrivă, instalarea unei CA nu obligă deloc un peer să își trimită certificatul.

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

Inspecția arată ce emitent a semnat certificatul și când expiră, iar ancora receptorului trebuie să corespundă acestui lucru. Aveți încredere în CA emitentă deținută de implementare, nu în fiecare intermediar din lanț, deoarece promovarea fiecărui intermediar la rădăcină lărgește încrederea mult dincolo de un singur peer. Mențineți activă verificarea identității, deoarece o conexiune care reușește doar cu validarea dezactivată nu este o remediere. Acolo unde lanțul este incomplet, reparați pregătirea, nu politica expeditorului.

Schimbați expeditorul numai cu dovezi

Când jurnalul arată că certificatul nu a fost trimis niciodată, iar receptorul l-a cerut într-adevăr, setarea send_cert pe always este o schimbare justificată pentru acea conexiune. Aplicați-o în configurația swanctl, reîncărcați conexiunile și stabiliți o sesiune nouă în loc să reutilizați SA-ul existent. Confirmați că încărcătura de certificat apare acum și că receptorul o acceptă față de ancora dorită. Dacă nimic nu se schimbă, defecțiunea era totuși de partea încrederii, iar setarea expeditorului nu a fost cauza.

Notați schimbul observat, ancora și verificarea rezultată în registrul de modificări. O remediere de certificat care nu poate fi descrisă în acești termeni este o coincidență.