strongSwan send_cert: kad tiek IKE sertifikāts

Vārtejas reģistrē ar sertifikātiem saistītas autentifikācijas kļūdas, un pirmā doma ir pievienot saņēmējam vēl vienu CA. Tas pieņem, ka sertifikāts ieradās un tika noraidīts. Otra iespēja ir tāda, ka tas nekad netika nosūtīts, un to nosaka sūtītāja savienojuma politika. Noskaidrojiet, kurš no abiem notika, pirms maināt uzticību.

Ko send_cert patiešām nosaka

Sertifikātu autentifikācijai ir vajadzīgs, lai peera gala vienības sertifikāts sasniegtu otru pusi caur IKE apmaiņu vai iepriekšēju nodrošināšanu. swanctl savienojuma iestatījums send_cert nosaka, vai šis galapunkts iekļauj savu sertifikāta kravu: nekad, vienmēr vai ifasked. Noklusējuma ifasked nosūta to atbildot uz peera sertifikāta pieprasījumu. Sertifikāta pieprasīšana ir atsevišķs iestatījums, jo lūgt otrai pusei tās sertifikātu nav tas pats, kas piedāvāt savu.

Vecāki ipsec.conf izvietojumi izmantoja leftsendcert un rightsendcert, un šie nosaukumi attiecas uz lokālajām un attālinātajām lomām, nevis tieši uz swanctl.

Izlasi vienu mēģinājumu pirms savienojuma maiņas

Diagnosticē pēc viena kontrolēta mēģinājuma, nevis pēc vispārēja iespaida, ka tajā iesaistīti sertifikāti. Apskatāma ir gan politika, gan aktīvā asociācija.

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

Savienojumu saraksts rāda konfigurēto send_cert vērtību, un SA saraksts rāda, kuri savienojumi faktiski tika izveidoti. Žurnāls pievieno sarunu detaļas: vai tika saņemts sertifikāta pieprasījums un vai izgāja sertifikāta krava. Vispārīga autentifikācijas kļūda nenorāda uz piegādes problēmu, tāpēc meklē konkrēto apmaiņu, pirms izdari secinājumu. Pieraksti mēģinājuma laika zīmi, lai žurnāla logs aptvertu visu rokasspiedienu.

Saņēmēja uzticība ir atsevišķs lēmums

Piegāde un uzticība ir dažādas īpašības, un vienas labošana nelabo otru. Saņēmējam jābūt paredzētajam uzticības enkuram, jāsaņem lietojama ķēde un jāatbilst gaidītajai peera identitātei. Gala vienības sertifikāts, kas ierodas bez sava starpposma sertifikāta, joprojām neiztur stingru ķēdes pārbaudi. Un otrādi, CA instalēšana nepiespiež peeru vispār nosūtīt savu sertifikātu.

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

Pārbaude rāda, kurš izdevējs parakstīja sertifikātu un kad tas beidzas, un tam jāatbilst saņēmēja enkuram. Uzticies izvietojumam piederošajai izdevējai CA, ne katram starpposma sertifikātam ķēdē, jo katra starpposma sertifikāta paaugstināšana par sakni paplašina uzticību daudz tālāk par vienu peeru. Turpini identitātes pārbaudi, jo savienojums, kas izdodas tikai ar izslēgtu validāciju, nav risinājums. Kur ķēde ir nepilnīga, labo nodrošināšanu, nevis sūtītāja politiku.

Maini sūtītāju tikai ar pierādījumiem

Kad žurnāls rāda, ka sertifikāts nekad netika nosūtīts un saņēmējs to tiešām pieprasīja, send_cert vērtība always ir pamatota izmaiņa šim savienojumam. Piemēro to swanctl konfigurācijā, pārlādē savienojumus un izveido jaunu sesiju, nevis izmanto esošo SA. Apstiprini, ka sertifikāta krava tagad parādās un ka saņēmējs to pieņem pret paredzēto enkuru. Ja nekas nemainās, kļūda tomēr bija uzticības pusē un sūtītāja iestatījums nebija cēlonis.

Ieraksti novēroto apmaiņu, enkuru un no tā izrietošo verifikāciju izmaiņu reģistrā. Sertifikāta labojums, ko nevar aprakstīt šādos terminos, ir nejaušība.