Prípony súborov neurčujú algoritmy kľúčov a obálka .pem môže obsahovať materiál RSA alebo ECDSA. PEM opisuje, ako sú bajty zabalené, zatiaľ čo RSA a ECDSA označujú rôzne algoritmy, a súbor PKCS12 je zase tretia vec. strongSwan načítava prihlasovacie údaje cez zásuvné moduly a konfiguračný backend, takže certifikát sa môže objaviť v zozname, no privátny kľúč sa nikdy nestane použiteľným. Oddeľte tieto vrstvy, kým začnete upravovať akékoľvek tajomstvo.

Kódovanie, algoritmus a balenie sú tri vrstvy

Súbor kľúča má kódovanie, algoritmus a často kontajner. PEM je známa obálka base64; DER je jej binárny náprotivok; PKCS12 spája certifikát s jeho kľúčom a reťazou. Súbor reťaze certifikátov je ďalší kontajner a zvyčajne neobsahuje žiadny privátny kľúč. Žiadny z týchto štítkov nehovorí, či je materiál vnútri RSA alebo ECDSA.

Čítajte algoritmus zo samotného objektu. Marketingový názov poskytovateľa ani prípona súboru nie sú dôkazom, pretože ten istý vydavateľ môže vydávať rôzne typy kľúčov.

Porovnajte verejné kľúče, kým obviníte zavádzač

Certifikát, ktorý sa načíta, dokazuje, že certifikát bol spracovaný, nie že jeho privátny kľúč je prítomný alebo použiteľný. Odvoďte verejný kľúč z certifikátu a z navrhovaného privátneho kľúča a potom porovnajte oba odtlačky. Ak niektoré extrahovanie zlyhá, zastavte sa, pretože odtlačok prázdneho výstupu nič nedokazuje. Zhodné odtlačky dokazujú, že pár patrí k sebe, a nič viac o tom, či sa certifikát hodí na danú úlohu.

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ý príkaz sa dotýka privátneho materiálu na vašom počítači, ale vypisuje len verejnú polovicu. Nechajte to tak a nikdy nevkladajte privátny kľúč do tiketu. Ak je kľúč šifrovaný, nechajte podporovaný nástroj vyžiadať heslo, namiesto toho, aby ste ho dávali na príkazový riadok, kde ho zoznam procesov môže odhaliť.

Staršie ipsec.secrets alebo prihlasovacie údaje swanctl

strongSwan má dve bežne používané cesty prihlasovacích údajov. Starý zásobník starter číta položky špecifické pre typ z ipsec.secrets, a každá položka musí uviesť správny typ pre daný materiál. Zásobník swanctl a vici načítava kľúče z vlastného adresára prihlasovacích údajov prostredníctvom vlastnej konfigurácie. Úprava súboru, ktorý bežiaci backend nečíta, nič nezmení.

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

Zistite, ktorý backend skutočne beží, a potom umiestnite kľúč tam, kam sa tento backend pozerá. staršia príručka strongSwan 5.9 definuje položky tajomstiev špecifické pre typ a nie je to dokumentácia swanctl. Miešanie oboch vytvára démona, ktorý ignoruje súbor, ktorý správca považuje za smerodajný. Opätovné načítanie, ktoré neohlási chybu, znamená len to, že konfigurácia bola spracovaná.

Čítajte udalosť načítania a výsledok autentizácie

Po riadenom opätovnom načítaní si prečítajte vlastný výstup načítania démona pre konkrétny kľúč. Certifikát uvedený vo výpise stavu neukazuje, že k nemu bol privátny kľúč priradený.

Ak klient stále zlyháva, držte udalosť servera a chybu klienta oddelene. Overenie reťaze, párovanie identít a kompatibilita metód sú neskoršie otázky s vlastnými dôkazmi. Zapíšte výsledok s presnou cestou kľúča a odtlačkom, ktorý ste porovnali, pretože inak nasledujúca zmena zopakuje to isté načítanie. Nahradenie CA nie je prvou reakciou na nesúlad zavádzača.

Súvisiace články