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 не з’яўляецца першай рэакцыяй на неадпаведнасць загрузчыка.

Падобныя артыкулы