strongSwan: nøgletype, indlæser og den forkerte backend

PEM er en beholder, ikke en nøgletype. Sammenlign certifikatets offentlige nøgle med den private, og indlæs den derefter gennem den backend, der faktisk læser den.

Filendelser identificerer ikke nøglealgoritmer, og en .pem-konvolut kan indeholde RSA- eller ECDSA-materiale. PEM beskriver, hvordan bytes pakkes ind, mens RSA og ECDSA navngiver forskellige algoritmer, og en PKCS12-fil er en tredje ting. strongSwan indlæser legitimationsoplysninger gennem plugins og en konfigurationsbackend, så et certifikat kan optræde på en liste, uden at den private nøgle nogensinde bliver brugbar. Adskil de lag, før du redigerer nogen hemmelighed.

Kodning, algoritme og emballering er tre lag

En nøglefil har en kodning, en algoritme og ofte en beholder. PEM er den velkendte base64-konvolut; DER er dens binære modstykke; PKCS12 samler et certifikat med dets nøgle og kæde. En certifikatkædefil er endnu en beholder, og den indeholder normalt slet ingen privat nøgle. Ingen af disse betegnelser fortæller, om materialet indeni er RSA eller ECDSA.

Læs algoritmen fra objektet selv. En udbyders marketingnavn eller en filendelse er ikke bevis, fordi den samme udsteder kan levere forskellige nøgletyper.

Sammenlign offentlige nøgler, før du bebrejder indlæseren

Et certifikat, der indlæses, beviser, at certifikatet blev parset, ikke at dets private nøgle er til stede eller brugbar. Udled den offentlige nøgle fra certifikatet og fra den foreslåede private nøgle, og sammenlign derefter de to hashes. Hvis en af udtrækningerne mislykkes, så stop der, fordi en hash af tomt output ikke beviser noget. Matchende hashes beviser, at parret hører sammen, og intet mere om, hvorvidt certifikatet passer til opgaven.

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

Den anden kommando rører ved privat materiale på din maskine, men udskriver kun den offentlige halvdel. Hold det sådan, og indsæt aldrig en privat nøgle i en ticket. Hvis nøglen er krypteret, så lad det understøttede værktøj spørge om adgangsfrasen i stedet for at sætte den på en kommandolinje, hvor proceslisten kan afsløre den.

Ældre ipsec.secrets eller swanctl-legitimationsoplysninger

strongSwan har to almindeligt anvendte legitimationsstier. Den ældre starter-stak læser typerelaterede poster fra ipsec.secrets, og hver post skal angive den korrekte type for materialet. swanctl- og vici-stakken indlæser nøgler fra sin egen legitimationsmappe gennem sin egen konfiguration. At redigere den fil, som den kørende backend ikke læser, ændrer intet.

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

Find ud af, hvilken backend der faktisk kører, og placer derefter nøglen, hvor den backend kigger. strongSwan 5.9 ældre manual definerer de typerelaterede hemmelighedsposter, og det er ikke swanctl-dokumentation. At blande de to giver en daemon, der ignorerer en fil, som administratoren tror er autoritativ. En genindlæsning, der ikke rapporterer nogen fejl, betyder kun, at konfigurationen blev parset.

Læs indlæsningshændelsen og autentificeringsresultatet

Efter en kontrolleret genindlæsning skal du læse daemonens eget indlæsningsoutput for den specifikke nøgle. Et certifikat, der er nævnt i en statusdump, viser ikke, at den private nøgle blev matchet til det.

Hvis en klient stadig fejler, så hold serverhændelsen og klientfejlen adskilt. Kædevalidering, identitetsmatchning og metodekompatibilitet er senere spørgsmål med deres egen evidens. Skriv resultatet ned med den nøjagtige nøglesti og det hash, du sammenlignede, fordi det næste skift ellers gentager den samme genindlæsning. At udskifte CA'en er ikke den første reaktion på en indlæsermisforhold.

Relaterede artikler