Копирање VPN сертификата не копира кључ

Преглед почиње на листи сертификата клијента, где ставка приказује само назив, издаваоца и датум истека и ништа више. Извезите га, увезите на другом уређају и веза се одбија јер клијент не може да докаже поседовање приватног кључа. Датотека је копирана у целости; грешка је очекивати да сертификат носи сопствени кључ. Прочитајте дијалог за извоз пре него што одаберете формат, затим прегледајте датотеку коју сте заиста добили.

Два клика, два сасвим различита артефакта.

Читајте дијалог за извоз, не наставак датотеке

Извоз сертификата 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 такође извештава да ли је кључ присутан, што решава питање за тај формат. Наводи и алгоритам и величину кључа, и потпуно отказује када кључа нема.

Никада не лепите датотеку која садржи приватни кључ у тему подршке, праћење проблема или разговор, чак и када изгледа као сертификат који сте већ делили. Снимци екрана табле са кључем заслужују исту пажњу.

Кључ може да живи тамо одакле не можете да га копирате

На управљаним уређајима приватни кључ може да стоји у привеску за кључеве оперативног система, хардверском токену или сигурној енклави, уз правило које га означава неизвозним. Управник сертификата тада приказује јавни објекат док тајна остаје на месту, и ниједна наредба за извоз неће створити преносиву копију. Упис путем управљања мобилним уређајима често по дизајну функционише управо тако.

То је контрола, а не препрека коју треба заобићи. Реконструкција приватног кључа из јавног сертификата није могућа, и сваки алат који то тврди чини нешто друго.

Упишите нови идентитет уместо да копирате

Подржани пут обично је да упишете посебан идентитет за нови уређај и опозовете стари када оде у пензију, тако да сваки уређај може да се повуче независно. Где је извоз са кључем заиста одобрен, третирајте добијену датотеку и њену лозинку као акредитиве: шифроване у мировању, пренесене преко поузданог канала и избрисане када упис заврши.

Проверите аутентификацијом са увезеним идентитетом, а не гледањем да ли је увоз успео. Клијент који прихвати јавни сертификат у своје складиште није доказао ништа о кључу.

Завршите потврдом да сервер прихвата нови идентитет и да се стари и даље понаша како правило предвиђа. Тиме је преглед заокружен доказом, а не датотеком која изгледа исправно.