strongSwan send_cert: wanneer het IKE-certificaat wordt verzonden

Gateways loggen certificaatgerelateerde authenticatiefouten, en de eerste reflex is om nog een CA aan de ontvanger toe te voegen. Dat veronderstelt dat het certificaat is aangekomen en geweigerd. De andere mogelijkheid is dat het nooit is verzonden, en het verbindingsbeleid van de afzender bepaalt dat. Bepaal welke van de twee zich heeft voorgedaan voordat u het vertrouwen aanpast.

Wat send_cert feitelijk regelt

Certificaatauthenticatie vereist dat het eindentiteitscertificaat van de peer de andere kant bereikt via de IKE-uitwisseling of via eerdere provisioning. In swanctl bepaalt de verbindingsinstelling send_cert of dit eindpunt zijn certificaatlading meestuurt: nooit, altijd of ifasked. De standaard ifasked stuurt het als antwoord op een certificaatverzoek van de peer. Een certificaat aanvragen is een aparte instelling, want de andere kant om haar certificaat vragen is niet hetzelfde als het eigene aanbieden.

Oudere ipsec.conf-implementaties gebruikten leftsendcert en rightsendcert, en die namen verwijzen naar lokale en externe rollen in plaats van rechtstreeks naar swanctl.

Lees één poging voordat u de verbinding aanpast

Diagnosticeer op basis van één gecontroleerde poging, niet op basis van de algemene indruk dat certificaten in het spel zijn. Zowel het beleid als de actieve associatie zijn in te zien.

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

De verbindingslijst toont de geconfigureerde waarde van send_cert, en de SA-lijst toont welke verbindingen daadwerkelijk tot stand kwamen. Het logboek voegt onderhandelingsdetails toe: of er een certificaatverzoek binnenkwam en of er een certificaatlading uitging. Een algemene authenticatiefout wijst geen afleverprobleem aan, zoek dus de specifieke uitwisseling voordat u iets concludeert. Noteer de tijdstempel van de poging, zodat het logvenster de hele handshake dekt.

Het vertrouwen van de ontvanger is een aparte beslissing

Aflevering en vertrouwen zijn verschillende eigenschappen, en het ene oplossen lost het andere niet op. Een ontvanger moet het bedoelde vertrouwensanker bezitten, een bruikbare keten ontvangen en overeenkomen met de verwachte identiteit van de peer. Een eindentiteitscertificaat dat zonder zijn tussenliggende certificaat aankomt, faalt nog steeds bij een strikte ketencontrole. Omgekeerd dwingt het installeren van een CA een peer geenszins om zijn certificaat überhaupt te verzenden.

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

De inspectie toont welke uitgever het certificaat heeft ondertekend en wanneer het verloopt, en daarmee moet het anker van de ontvanger overeenkomen. Vertrouw de uitgevende CA die de implementatie bezit, niet elk tussenliggend certificaat in de keten, want elk tussenliggend certificaat tot root promoveren verbreedt het vertrouwen veel verder dan één peer. Houd identiteitsverificatie actief, want een verbinding die alleen slaagt met uitgeschakelde validatie is geen oplossing. Waar de keten onvolledig is, repareer de provisioning in plaats van het beleid van de afzender.

Wijzig de afzender alleen met bewijs

Zodra het logboek laat zien dat het certificaat nooit is verzonden en de ontvanger er wel om heeft gevraagd, is send_cert op always een gerechtvaardigde wijziging voor die verbinding. Pas die toe in de swanctl-configuratie, herlaad de verbindingen en zet een nieuwe sessie op in plaats van de bestaande SA te hergebruiken. Bevestig dat de certificaatlading nu verschijnt en dat de ontvanger die tegen het bedoelde anker accepteert. Verandert er niets, dan lag de fout toch aan de vertrouwenszijde en was de afzenderinstelling niet de oorzaak.

Schrijf de waargenomen uitwisseling, het anker en de daaruit volgende verificatie in het wijzigingsrecord. Een certificaatoplossing die niet in die termen te beschrijven is, berust op toeval.