strongSwan: sleuteltype, loader en de verkeerde backend

Bestandsextensies identificeren geen sleutelalgoritmen, en een .pem-envelop kan RSA- of ECDSA-materiaal bevatten. PEM beschrijft hoe bytes worden ingepakt, terwijl RSA en ECDSA verschillende algoritmen benoemen, en een PKCS12-bestand is weer iets anders. strongSwan laadt inloggegevens via plugins en een configuratie-backend, zodat een certificaat in een lijst kan verschijnen terwijl de persoonlijke sleutel nooit bruikbaar wordt. Scheid die lagen voordat u een geheim bewerkt.

Codering, algoritme en verpakking zijn drie lagen

Een sleutelbestand heeft een codering, een algoritme en vaak een container. PEM is de bekende base64-envelop; DER is de binaire tegenhanger; PKCS12 bundelt een certificaat met zijn sleutel en keten. Een certificaatketenbestand is weer een andere container, en bevat meestal helemaal geen persoonlijke sleutel. Geen van die labels zegt of het materiaal binnenin RSA of ECDSA is.

Lees het algoritme uit het object zelf. De marketingnaam van een leverancier of een bestandsextensie is geen bewijs, want dezelfde uitgever kan verschillende sleuteltypen uitgeven.

Vergelijk openbare sleutels voordat u de loader de schuld geeft

Een certificaat dat laadt, bewijst dat het certificaat is geparseerd, niet dat de persoonlijke sleutel aanwezig of bruikbaar is. Leid de openbare sleutel af uit het certificaat en uit de voorgestelde persoonlijke sleutel, en vergelijk dan de twee hashes. Als een van beide extracties mislukt, stop daar, want een hash van lege uitvoer bewijst niets. Overeenkomende hashes bewijzen dat het paar bij elkaar hoort, en niets meer over of het certificaat bij de taak past.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

De tweede opdracht raakt persoonlijk materiaal op uw machine maar geeft alleen de openbare helft vrij. Houd dat zo, en plak nooit een persoonlijke sleutel in een ticket. Als de sleutel versleuteld is, laat de ondersteunde tool dan om de wachtwoordzin vragen in plaats van die op een opdrachtregel te zetten waar de proceslijst hem kan blootleggen.

Oude ipsec.secrets of swanctl-inloggegevens

strongSwan heeft twee veelgebruikte paden voor inloggegevens. De oude starter-stack leest typespecifieke vermeldingen uit ipsec.secrets, en elke vermelding moet het juiste type voor het materiaal noemen. De swanctl- en vici-stack laadt sleutels uit zijn eigen inloggegevensmap via zijn eigen configuratie. Het bestand bewerken dat de draaiende backend niet leest, verandert niets.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Zoek uit welke backend echt draait, en plaats de sleutel dan waar die backend kijkt. oude strongSwan 5.9-handleiding definieert de typespecifieke geheime vermeldingen, en het is geen swanctl-documentatie. Beide door elkaar halen levert een daemon op die een bestand negeert waarvan de beheerder denkt dat het gezaghebbend is. Een herladen dat geen fout meldt, betekent alleen dat de configuratie is geparseerd.

Lees de laadgebeurtenis en het authenticatieresultaat

Lees na een gecontroleerd herladen de eigen laaduitvoer van de daemon voor de specifieke sleutel. Een certificaat dat in een statusdump staat, toont niet dat de persoonlijke sleutel eraan is gekoppeld.

Als een client nog steeds faalt, houd de servergebeurtenis en de clientfout gescheiden. Ketenvalidatie, identiteitsafstemming en methodecompatibiliteit zijn latere vragen met hun eigen bewijs. Schrijf de uitkomst op met het exacte sleutelpad en de hash die u hebt vergeleken, want anders herhaalt de volgende dienst hetzelfde herladen. De CA vervangen is niet de eerste reactie op een loader-misverstand.