strongSwan: nyckeltyp, laddare och fel backend

PEM är en behållare, inte en nyckeltyp. Jämför certifikatets offentliga nyckel med den privata och ladda den sedan via den backend som faktiskt läser den.

Filändelser identifierar inte nyckelalgoritmer, och ett .pem-hölje kan innehålla RSA- eller ECDSA-material. PEM beskriver hur bytes packas, medan RSA och ECDSA namnger olika algoritmer, och en PKCS12-fil är en tredje sak. strongSwan laddar in uppgifter via plugins och en konfigurationsbackend, så ett certifikat kan visas i en lista medan den privata nyckeln aldrig blir användbar. Skilj på de lagren innan du redigerar någon hemlighet.

Kodning, algoritm och packning är tre lager

En nyckelfil har en kodning, en algoritm och ofta en behållare. PEM är det välkända base64-höljet; DER är dess binära motsvarighet; PKCS12 samlar ett certifikat med dess nyckel och kedja. En certifikatkedjefil är ännu en behållare och innehåller oftast ingen privat nyckel alls. Ingen av dessa beteckningar säger om materialet inuti är RSA eller ECDSA.

Läs algoritmen från objektet självt. En leverantörs marknadsföringsnamn eller en filändelse är inte bevis, eftersom samma utfärdare kan ge ut olika nyckeltyper.

Jämför offentliga nycklar innan du skyller på laddaren

Ett certifikat som laddas bevisar att certifikatet parsades, inte att dess privata nyckel finns eller är användbar. Härled den offentliga nyckeln från certifikatet och från den föreslagna privata nyckeln och jämför sedan de två hasharna. Om någon av uttagen misslyckas, stanna där, för en hash av tom utdata bevisar ingenting. Matchande hashar bevisar att paret hör ihop, och inget mer om certifikatet passar för uppgiften.

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

Det andra kommandot rör privat material på din maskin men skriver bara ut den offentliga halvan. Håll det så, och klistra aldrig in en privat nyckel i en biljett. Om nyckeln är krypterad, låt det stödda verktyget fråga efter lösenfrasen i stället för att sätta den på en kommandorad där processlistan kan avslöja den.

Äldre ipsec.secrets eller swanctl-uppgifter

strongSwan har två vanliga vägar för inloggningsuppgifter. Den äldre starter-stacken läser typspecifika poster från ipsec.secrets, och varje post måste ange rätt typ för materialet. swanctl- och vici-stacken laddar nycklar från sin egen katalog för uppgifter via sin egen konfiguration. Att redigera filen som den körande backend inte läser ändrar ingenting.

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

Ta reda på vilken backend som faktiskt körs och placera sedan nyckeln där den backend tittar. äldre strongSwan 5.9-handbok definierar de typspecifika hemlighetsposterna, och det är inte swanctl-dokumentation. Att blanda de två ger en daemon som ignorerar en fil som administratören anser vara auktoritativ. En omladdning som inte rapporterar något fel betyder bara att konfigurationen parsades.

Läs inläsningshändelsen och autentiseringsresultatet

Efter en kontrollerad omladdning, läs daemonens egen inläsningsutdata för den specifika nyckeln. Ett certifikat som listas i en statusdump visar inte att den privata nyckeln matchades mot det.

Om en klient fortfarande misslyckas, håll serverhändelsen och klientfelet åtskilda. Kedjevalidering, identitetsmatchning och metodkompatibilitet är senare frågor med sina egna bevis. Skriv ner resultatet med den exakta nyckelsökvägen och hashen du jämförde, för annars upprepar nästa skift samma omladdning. Att byta ut CA:n är inte den första reaktionen på en laddarmissmatchning.

Relaterade artiklar