strongSwan: тип на ключа, зареждащ модул и грешен backend

PEM е контейнер, а не тип на ключ. Сравнете публичния ключ на сертификата с частния и след това го заредете през backend, който действително го чете.

Разширенията на файловете не определят алгоритмите на ключовете и обвивка .pem може да съдържа материал RSA или ECDSA. PEM описва как са опаковани байтовете, докато RSA и ECDSA назовават различни алгоритми, а файлът PKCS12 е трето нещо. strongSwan зарежда идентификационни данни чрез плъгини и конфигурационен backend, така че сертификат може да се появи в списък, докато частният ключ така и не стане използваем. Разделете тези слоеве, преди да редактирате каквато и да е тайна.

Кодиране, алгоритъм и опаковане са три слоя

Файлът с ключ има кодиране, алгоритъм и често контейнер. PEM е познатата обвивка base64; DER е неговият двоичен аналог; PKCS12 обединява сертификат с неговия ключ и верига. Файлът с верига от сертификати е още един контейнер и обикновено не съдържа никакъв частен ключ. Нито един от тези етикети не ви казва дали материалът вътре е RSA или ECDSA.

Четете алгоритъма от самия обект. Маркетинговото име на доставчик или разширението на файла не е доказателство, защото един и същ издател може да издава различни типове ключове.

Сравнете публичните ключове, преди да обвинявате зареждащия модул

Сертификат, който се зарежда, доказва, че сертификатът е анализиран, а не че частният му ключ е наличен или използваем. Изведете публичния ключ от сертификата и от предложения частен ключ, след което сравнете двата хеша. Ако някое извличане се провали, спрете дотам, защото хеш на празен резултат не доказва нищо. Съвпадащите хешове доказват, че двойката принадлежи заедно, и нищо повече за това дали сертификатът е подходящ за задачата.

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

Втората команда докосва частен материал на вашата машина, но извежда само публичната половина. Оставете го така и никога не поставяйте частен ключ в тикет. Ако ключът е криптиран, оставете поддържания инструмент да поиска паролата, вместо да я слагате на команден ред, където списъкът с процеси може да я разкрие.

Стари ipsec.secrets или идентификационни данни на swanctl

strongSwan има два често използвани пътя за идентификационни данни. Старият стек starter чете записи, специфични за типа, от ipsec.secrets, и всеки запис трябва да посочва правилния тип за материала. Стекът swanctl и vici зарежда ключове от своята директория с идентификационни данни чрез своята конфигурация. Редактирането на файла, който работещият backend не чете, не променя нищо.

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

Открийте кой backend действително работи, след което поставете ключа там, където този backend гледа. старото ръководство на strongSwan 5.9 определя записите на тайни, специфични за типа, и това не е документация на swanctl. Смесването на двете създава демон, който игнорира файл, който администраторът смята за авторитетен. Презареждане, което не съобщава грешка, означава само, че конфигурацията е анализирана.

Четете събитието на зареждане и резултата от удостоверяването

След контролирано презареждане прочетете собствения изход на демона за зареждане за конкретния ключ. Сертификат, посочен в дъмп на състоянието, не показва, че частният ключ е съпоставен с него.

Ако клиентът все още се проваля, дръжте събитието на сървъра и грешката на клиента отделно. Проверката на веригата, съпоставянето на идентичност и съвместимостта на методите са следващи въпроси със собствени доказателства. Запишете резултата с точния път на ключа и хеша, който сте сравнили, защото следващата смяна иначе ще повтори същото презареждане. Подмяната на CA не е първата реакция при несъответствие на зареждащия модул.

Подобни статии