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

Две щраквания, два много различни артефакта.

Четете диалога за експорт, а не разширението на файла

Експортът на DER или PEM сертификат съдържа публичен ключ и подписаните твърдения за идентичност, което е нужно на сървъра, за да ви се довери, и на клиента, за да провери сървър. Пакетът PKCS#12 е контейнер, който може да съдържа сертификат, неговата верига и съответния частен ключ, защитен с парола, макар да може да бъде създаден и без ключа.

PEM е само текстово кодиране, а не обещание за съдържанието. Едно и също разширение може да описва един сертификат или файл с няколко обозначени блока, а опциите за експорт решават кое.

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

Прегледайте какво действително сте получили

Търсете етикетите, преди да импортирате каквото и да е, после прочетете полетата на сертификата, за да потвърдите коя идентичност държите. Изпълнете проверките върху файла, който действително ще бъде импортиран. Повторете ги след всеки повторен експорт, защото опциите може да се различават.

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

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

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

Ключът може да живее там, откъдето не можете да го копирате

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

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

Регистрирайте нова идентичност вместо да копирате

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

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

Завършете, като потвърдите, че сървърът приема новата идентичност и че старата все още се държи както политиката предвижда. Това завършва разходката с доказателства, а не с файл, който изглежда правилен.

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