strongSwan: tipul cheii, încărcătorul și backend-ul greșit

PEM este un container, nu un tip de cheie. Comparați cheia publică a certificatului cu cea privată, apoi încărcați-o prin backend-ul care o citește cu adevărat.

Extensiile fișierelor nu identifică algoritmii cheilor, iar un plic .pem poate conține material RSA sau ECDSA. PEM descrie cum sunt împachetați octeții, în timp ce RSA și ECDSA numesc algoritmi diferiți, iar un fișier PKCS12 este un al treilea lucru. strongSwan încarcă acreditările prin pluginuri și printr-un backend de configurare, așa că un certificat poate apărea într-o listă în timp ce cheia privată nu devine niciodată utilizabilă. Separați acele straturi înainte de a edita orice secret.

Codificarea, algoritmul și împachetarea sunt trei straturi

Un fișier de cheie are o codificare, un algoritm și adesea un container. PEM este plicul base64 cunoscut; DER este omologul său binar; PKCS12 grupează un certificat cu cheia și lanțul său. Un fișier de lanț de certificate este încă un container și de obicei nu conține nicio cheie privată. Niciuna dintre aceste etichete nu spune dacă materialul dinăuntru este RSA sau ECDSA.

Citiți algoritmul din obiectul însuși. Numele de marketing al unui furnizor sau o extensie de fișier nu sunt dovezi, deoarece același emitent poate furniza tipuri diferite de chei.

Comparați cheile publice înainte de a da vina pe încărcător

Un certificat care se încarcă dovedește că certificatul a fost analizat, nu că cheia sa privată este prezentă sau utilizabilă. Derivați cheia publică din certificat și din cheia privată propusă, apoi comparați cele două rezumate. Dacă oricare extracție eșuează, opriți-vă acolo, pentru că rezumatul unei ieșiri goale nu dovedește nimic. Rezumatele identice dovedesc că perechea aparține împreună, și nimic mai mult despre potrivirea certificatului pentru sarcina respectivă.

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

A doua comandă atinge material privat de pe mașina dumneavoastră, dar emite doar jumătatea publică. Păstrați-o așa și nu lipiți niciodată o cheie privată într-un tichet. Dacă cheia este criptată, lăsați instrumentul acceptat să ceară fraza de acces în loc să o puneți pe o linie de comandă unde lista proceselor o poate expune.

ipsec.secrets vechi sau acreditări swanctl

strongSwan are două căi de acreditări folosite frecvent. Stiva starter veche citește intrările specifice tipului din ipsec.secrets, iar fiecare intrare trebuie să numească tipul corect pentru material. Stiva swanctl și vici încarcă chei din propriul director de acreditări prin propria configurație. Editarea fișierului pe care backend-ul aflat în execuție nu îl citește nu schimbă nimic.

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

Aflați care backend rulează de fapt, apoi plasați cheia acolo unde se uită acel backend. manualul vechi strongSwan 5.9 definește intrările de secrete specifice tipului, și nu este documentație swanctl. Amestecarea celor două produce un demon care ignoră un fișier pe care administratorul îl consideră autoritar. O reîncărcare care nu raportează nicio eroare înseamnă doar că configurația a fost analizată.

Citiți evenimentul de încărcare și rezultatul autentificării

După o reîncărcare controlată, citiți ieșirea de încărcare a demonului însuși pentru cheia concretă. Un certificat listat într-un dump de stare nu arată că cheia privată a fost asociată cu el.

Dacă un client tot eșuează, țineți separate evenimentul serverului și eroarea clientului. Validarea lanțului, potrivirea identității și compatibilitatea metodelor sunt întrebări ulterioare cu propriile dovezi. Notați rezultatul cu calea exactă a cheii și rezumatul pe care l-ați comparat, pentru că altfel tura următoare va repeta aceeași reîncărcare. Înlocuirea CA nu este primul răspuns la o nepotrivire a încărcătorului.

Articole similare