strongSwan: nøkkeltype, lastar og feil backend

Filendingar identifiserer ikkje nøkkelalgoritmar, og ein .pem-konvolutt kan innehalde RSA- eller ECDSA-materiale. PEM skildrar korleis bytar blir pakka inn, medan RSA og ECDSA nemner ulike algoritmar, og ei PKCS12-fil er ein tredje ting. strongSwan lastar legitimasjon gjennom plugins og ein konfigurasjonsbackend, så eit sertifikat kan visast i ei liste medan den private nøkkelen aldri blir brukbar. Skil desse laga før du redigerer noka hemmelegheit.

Koding, algoritme og emballering er tre lag

Ei nøkkelfil har ei koding, ein algoritme og ofte ein behaldar. PEM er den kjende base64-konvolutten; DER er den binære motparten; PKCS12 samlar eit sertifikat med nøkkelen og kjeda. Ei sertifikatkjede-fil er endå ein behaldar, og ho inneheld vanlegvis ingen privat nøkkel i det heile. Ingen av desse nemningane fortel om materialet inni er RSA eller ECDSA.

Les algoritmen frå objektet sjølv. Eit marknadsføringsnamn frå ein leverandør eller ei filending er ikkje prov, fordi same utferdar kan gje ut ulike nøkkeltypar.

Samanlikn offentlege nøklar før du klandrar lastaren

Eit sertifikat som blir lasta inn, beviser at sertifikatet vart parsa, ikkje at den private nøkkelen finst eller er brukbar. Utleid den offentlege nøkkelen frå sertifikatet og frå den føreslåtte private nøkkelen, og samanlikn deretter dei to hasha. Viss eitt av utdraga mislykkast, stopp der, fordi ein hash av tom utdata beviser ingenting. Samsvarande hashar beviser at paret høyrer saman, og ikkje noko meir om sertifikatet passar til jobben.

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 andre kommandoen rører ved privat materiale på maskinen din, men sender berre ut den offentlege halvdelen. Hald det slik, og lim aldri ein privat nøkkel inn i ei sak. Viss nøkkelen er kryptert, la det støtta verktøyet spørje om passordfrasa i staden for å setje henne på ein kommandolinje der prosesslista kan avsløre henne.

Eldre ipsec.secrets eller swanctl-legitimasjon

strongSwan har to vanlege legitimasjonsstigar. Den eldre starter-stakken les typerelaterte oppføringar frå ipsec.secrets, og kvar oppføring må nemne rett type for materialet. swanctl- og vici-stakken lastar nøklar frå si eiga legitimasjonsmappe gjennom sin eigen konfigurasjon. Å redigere fila som den køyrande backend-en ikkje les, endrar ingenting.

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

Finn ut kva backend som faktisk køyrer, og plasser deretter nøkkelen der den backend-en ser. strongSwan 5.9 eldre handbok definerer dei typerelaterte hemmelegheitsoppføringane, og det er ikkje swanctl-dokumentasjon. Å blande dei to gjev ein daemon som ignorerer ei fil som administratoren meiner er autoritativ. Ei omlasting som ikkje rapporterer feil, tyder berre at konfigurasjonen vart parsa.

Les innlastingshendinga og autentiseringsresultatet

Etter ei kontrollert omlasting, les daemonen sin eigen innlastingsutdata for den aktuelle nøkkelen. Eit sertifikat som er ført opp i ein statusdump, viser ikkje at den private nøkkelen vart matcha til det.

Viss ein klient framleis feilar, hald serverhendinga og klientfeilen skilde. Kjedevalidering, identitetsmatching og metodekompatibilitet er seinare spørsmål med sine eigne bevis. Skriv ned resultatet med den nøyaktige nøkkelstien og hashen du samanlikna, fordi neste skift elles gientar den same omlastinga. Å bytte ut CA-en er ikkje den første reaksjonen på eit misforhold i lastaren.