Да премахнете ли паролата за ключ или да я запазите? Копието, което създавате
Нешифрован файл с ключ пази същата тайна при по-слаба защита. Сравнете риска в покой, преди да конвертирате, и знайте какво то не отменя.
Шифрован частен ключ и нешифрован такъв съдържат един и същ ключов материал. Конвертирането не създава нова идентичност, не нулира VPN акаунт и не обезсилва стария файл. То записва второ копие и това копие носи различен риск в покой.
Дали разменянето си заслужава зависи от това къде ще живее файлът и кой може да го чете.
Какво всъщност променя конвертирането
Преди конвертирането ключът е защитен с парола, която операторът предоставя. След конвертирането той е защитен с права на файловата система и какъвто и контрол на достъпа да заобикаля файла. Криптографията не се е променила; променил се е броят на нещата между нападателя и ключа. Това е цялото сравнение.
Таблицата прави разликата конкретна.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
Нито една форма не е автоматично по-безопасна. Те се провалят по различни начини и само един от тези начини оставя запис в журнала.
Кога запазването на паролата е по-добре
Ако поддържан клиент може да запита паролата или да я вземе от одобрено хранилище за тайни, конвертирането не купува нищо. Запазвате едно копие, една граница на защита и един файл по-малко за проследяване. Повечето VPN клиенти, които приемат PEM ключове, могат да го направят.
Конвертирането е грешен ход и когато екип споделя ключа. Нешифрован файл на споделен хост става идентификационни данни, които всеки с достъп до shell може да копира.
Кога нешифровано копие е оправдано
Някои услуги не могат да питат, някои контейнери монтират тайни само за четене, а някои устройства четат файл с ключ при зареждане без интерактивен път. В тези случаи нешифрован ключ в правилно ограничена директория може да е поддържаният дизайн. Оправданието е средата, не удобството.
Ако не можете да кажете кой може да чете файла и защо, отговорът е не.
Командата и нейните остри ръбове
За ключ във файл, поддържан от OpenSSL 3.5, справката pkey описва премахването на парола и интерактивна подкана, когато входът е шифрован и не е зададен източник на парола. Минималната форма е кратка и лесно се изпълнява небрежно.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemТри остри ръба. Входно-изходните операции на изходния файл не са атомарни, така че съществуващ изходен път може да бъде отрязан по средата на записа. Не използвайте входния път като изход и не експериментирайте върху единственото защитено копие. Въведете паролата при подканата, а не на командния ред, където тя попада в историята на shell.
Проверете резултата, преди да промените каквато и да е VPN конфигурация: openssl pkey -in new-private-key.pem -pubout трябва да отпечата същия публичен ключ, който имахте преди.
Какво конвертирането не прави
То не отменя шифрованото копие, което все още съществува там, където сте го оставили. То не променя паролата на VPN акаунта или сертификата. И не поправя вече случило се излагане. Ако ключ е изтекъл, решението е замяна и оттегляне от страна на сървъра, а не локална промяна на формата.
Изтрийте междинния файл нарочно и потвърдете, че пътят, който изтривате, е този, който сте създали.