Een wachtwoordzin voor een sleutel verwijderen of bewaren? De kopie die u maakt

Een versleutelde privésleutel en een onversleutelde bevatten hetzelfde sleutelmateriaal. Converteren maakt geen nieuwe identiteit, reset geen VPN-account en maakt het oude bestand niet ongeldig. Het schrijft een tweede kopie, en die kopie draagt een ander risico in rust.

Of de ruil de moeite waard is, hangt af van waar het bestand komt te staan en wie het kan lezen.

Wat conversie werkelijk verandert

Vóór conversie wordt de sleutel beschermd door een wachtwoordzin die de operator aanlevert. Na conversie wordt hij beschermd door bestandssysteemrechten en door welke toegangscontrole het bestand ook omringt. De cryptografie is niet veranderd; het aantal dingen tussen een aanvaller en de sleutel wel. Dat is de hele vergelijking.

Een tabel maakt het verschil concreet.

Geen van beide vormen is automatisch veiliger. Ze falen op verschillende manieren, en slechts één van die manieren laat een logregel achter.

Wanneer de wachtwoordzin bewaren beter is

Als een ondersteunde client om de wachtwoordzin kan vragen of hem uit een goedgekeurde geheimenkluis kan halen, levert converteren niets op. U houdt één kopie, één beschermingsgrens en één bestand minder om bij te houden. De meeste VPN-clients die PEM-sleutels accepteren, kunnen dit.

Converteren is ook de verkeerde zet wanneer een team de sleutel deelt. Een onversleuteld bestand op een gedeelde host wordt een inloggegeven dat iedereen met shell-toegang kan kopiëren.

Wanneer een onversleutelde kopie gerechtvaardigd is

Sommige diensten kunnen niet vragen, sommige containers koppelen geheimen alleen-lezen en sommige apparaten lezen een sleutelbestand bij het opstarten zonder interactief pad. In die gevallen kan een onversleutelde sleutel in een goed beperkte map het ondersteunde ontwerp zijn. De rechtvaardiging is de omgeving, niet het gemak.

Als u niet kunt zeggen wie het bestand kan lezen en waarom, is het antwoord nee.

De opdracht en zijn scherpe randen

Voor een bestandsgebaseerde sleutel die door OpenSSL 3.5 wordt ondersteund, de pkey-referentie documenteert het verwijderen van de wachtwoordzin en een interactieve prompt wanneer de invoer versleuteld is en er geen wachtwoordbron is opgegeven. De minimale vorm is kort, en hij is gemakkelijk onzorgvuldig uit te voeren.

umask 077
openssl pkey -in protected-key.pem -out new-private-key.pem

Drie scherpe randen. De I/O van het uitvoerbestand is niet atomair, dus een bestaand uitvoerpad kan midden in het schrijven worden afgekapt. Gebruik het invoerpad niet als uitvoer, en experimenteer niet op de enige beschermde kopie. Voer de wachtwoordzin bij de prompt in en niet op de opdrachtregel, waar hij in de shellgeschiedenis belandt.

Controleer het resultaat voordat u een VPN-configuratie wijzigt: openssl pkey -in new-private-key.pem -pubout zou dezelfde openbare sleutel moeten afdrukken die u eerder had.

Wat conversie niet doet

Hij trekt de versleutelde kopie niet in, die nog steeds bestaat waar u hem ook hebt achtergelaten. Hij wijzigt niet het wachtwoord van het VPN-account of het certificaat. En hij herstelt geen blootstelling die al heeft plaatsgevonden. Als een sleutel is uitgelekt, is de oplossing vervanging en intrekking aan de serverzijde, geen lokale formaatwijziging.

Verwijder het tussenbestand bewust, en bevestig dat het pad dat u verwijdert het pad is dat u hebt aangemaakt.