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

Уверете се, че ключът е RSA, преди да търсите прости числа

Сертификатът доказва, че някакъв ключ съществува и е бил подписан; той не доказва, че ключът е RSA. Системите могат да се строят върху елиптични криви или Ed25519 и същата подредба на директории служи за всички тях. Проверете алгоритъма, преди да започнете да търсите прости множители, които никога не са били там.

Тези три команди само за четене отговарят на въпроса и записват версията на инструмента.

openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text

Версията е важна, защото имената на опциите са се местили между основните издания. В изхода на сертификата намерете реда за алгоритъма на публичния ключ и размера на ключа; в изхода на ключа RSA ключ отпечатва модул и публичен показател. Ключът на елиптична крива отпечатва вместо това именувана крива и никакво търсене няма да извади n или q от него.

Четете структурата вместо base64

PEM е base64, обвит в заглавни редове, и декодирането му дава DER, тоест сериализирана структура, а не едно огромно цяло число. Частните ключове RSA пътуват в два разпространени контейнера, PKCS#1 и PKCS#8, и двата се свеждат до един и същ набор от числа.

При два прости делителя частната структура носи девет полета: версия, модул n, публичен показател e, частен показател d, простите числа p и q, два CRT показателя и CRT коефициент. RFC 8017 раздел A.1 дефинира тези компоненти и оформлението ASN.1, а също допуска повече от две прости числа, поради което общ анализатор може да отпечата допълнителни записи за прости числа. Забележете подредбата, защото тя обяснява честа грешка: публичната половина се съхранява вътре в частния файл, така че наличието на публично поле не прави файла безопасен за споделяне. Всичко след него е материалът, който трябва да остане на хоста.

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

Свържете сертификат с ключ, без да отпечатвате ключа

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

openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH

Еднаквите файлове означават, че сертификатът носи публичната половина на този ключ, а разлика означава, че държите грешната двойка. Това несъответствие е най-честата причина за тунел, който преговаря успешно и после отказва удостоверяване. След това изтрийте двата временни файла; в тях няма нищо тайно, но чистата работна директория е по-лесна за осмисляне по средата на инцидент.

Знайте какво не са съседните файлове

Сертификатът не е криптиран публичен ключ, който партньорът отключва със сертификата на CA; той е подписана връзка между публичен ключ и данни за идентичност. Частният ключ за подпис на CA остава отделен от собствения му сертификат и от всеки клиентски ключ. Заявката също не е сертификат: тя носи поисканата информация и публичния ключ с подпис върху заявката, което я прави вход за записване, а не доказателство за право.

FileAnswersDoes not prove
vpn-client.keyPossession of the private keyThat the identity is enrolled
vpn-client.crtA signed binding of public key to identityThat the client holds the matching key
vpn-client.csrThe requested binding and public keyThat access was granted
dh2048.pemGroup parameters for key exchangeAny RSA component
crl.pemRevocation status for certificatesAnything about a private key

Два от тези записи се бъркат с RSA параметри достатъчно често, за да бъдат назовани два пъти. Файлът с Diffie-Hellman параметри съдържа групови параметри за установяване на ключ и никакви RSA прости числа, въпреки че също се отпечатва като голямо просто число. Списъкът за отмяна публикува статуса на сертификатите и не е място, където частен показател би могъл да се скрие.

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

Запишете двойката, после проверете ръкостискането

Преди да промените нещо, запазете изхода от проверката с датата и версията на OpenSSL. Тогава по-късна ротация може да се сравни с доказателство, а не с памет.

openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -dates

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

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

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