strongSwan: typ klíče, zavaděč a špatný backend

PEM je kontejner, ne typ klíče. Porovnejte veřejný klíč certifikátu s privátním a poté jej načtěte přes backend, který jej skutečně čte.

Přípony souborů neurčují algoritmy klíčů a obálka .pem může obsahovat materiál RSA nebo ECDSA. PEM popisuje, jak jsou bajty zabaleny, zatímco RSA a ECDSA označují různé algoritmy a soubor PKCS12 je zase třetí věc. strongSwan načítá přihlašovací údaje přes zásuvné moduly a konfigurační backend, takže certifikát se může objevit v seznamu, aniž by privátní klíč byl někdy použitelný. Oddělte tyto vrstvy, než začnete upravovat jakékoli tajemství.

Kódování, algoritmus a balení jsou tři vrstvy

Soubor klíče má kódování, algoritmus a často kontejner. PEM je známá obálka base64; DER je její binární protějšek; PKCS12 spojuje certifikát s jeho klíčem a řetězem. Soubor řetězu certifikátů je další kontejner a obvykle neobsahuje žádný privátní klíč. Žádný z těchto popisků neříká, zda je materiál uvnitř RSA, nebo ECDSA.

Čtěte algoritmus ze samotného objektu. Marketingový název poskytovatele ani přípona souboru nejsou důkazem, protože stejný vydavatel může vydávat různé typy klíčů.

Porovnejte veřejné klíče, než obviníte zavaděč

Certifikát, který se načte, dokazuje, že certifikát byl zpracován, ne že jeho privátní klíč je přítomen nebo použitelný. Odvoďte veřejný klíč z certifikátu a z navrhovaného privátního klíče a poté porovnejte oba otisky. Pokud některé extrahování selže, zastavte se, protože otisk prázdného výstupu nic nedokazuje. Shodné otisky dokazují, že dvojice patří k sobě, a nic víc o tom, zda se certifikát hodí pro daný úkol.

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

Druhý příkaz sahá na privátní materiál na vašem počítači, ale vypisuje jen veřejnou polovinu. Nechte to tak a nikdy nevkládejte privátní klíč do tiketu. Je-li klíč šifrovaný, nechte podporovaný nástroj vyžádat heslo, místo abyste jej dávali na příkazový řádek, kde jej seznam procesů může odhalit.

Starší ipsec.secrets nebo přihlašovací údaje swanctl

strongSwan má dvě běžně používané cesty přihlašovacích údajů. Starší zásobník starter čte položky specifické pro typ z ipsec.secrets, a každá položka musí uvádět správný typ pro daný materiál. Zásobník swanctl a vici načítá klíče ze svého vlastního adresáře přihlašovacích údajů prostřednictvím vlastní konfigurace. Úprava souboru, který běžící backend nečte, nic nezmění.

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

Zjistěte, který backend skutečně běží, a poté umístěte klíč tam, kam se tento backend dívá. starší příručka strongSwan 5.9 definuje položky tajemství specifické pro typ a není to dokumentace swanctl. Míchání obojího vytváří démona, který ignoruje soubor, jenž správce považuje za směrodatný. Opětovné načtení, které neohlásí chybu, znamená jen to, že konfigurace byla zpracována.

Čtěte událost načtení a výsledek autentizace

Po řízeném opětovném načtení si přečtěte vlastní výstup načítání démona pro konkrétní klíč. Certifikát uvedený ve výpisu stavu neukazuje, že k němu byl privátní klíč přiřazen.

Pokud klient stále selhává, držte událost serveru a chybu klienta odděleně. Ověření řetězu, párování identit a kompatibilita metod jsou pozdější otázky s vlastními důkazy. Zapište výsledek s přesnou cestou klíče a otiskem, který jste porovnali, protože příští směna jinak zopakuje stejné načtení. Nahrazení CA není první reakcí na nesoulad zavaděče.

Související články