Sol·licitud de clau d’OpenVPN després d’OpenSSL 3: comproveu el proveïdor

Ningú no ha tocat el perfil, i tot i així el mateix client ara demana una frase de pas per a la clau privada cada cop que s’inicia. Quan aquest canvi arriba pocs dies després d’una actualització de la distribució, la causa probable és l’actualització: OpenSSL 3 va reorganitzar el suport d’algoritmes, i una clau que la biblioteca antiga llegia sense problemes pot esdevenir il·legible sense que canviï ni un byte. Feu les comprovacions en ordre, perquè dues d’elles semblen idèntiques si només mireu la sol·licitud.

La primera pregunta és si la clau està xifrada, i la segona és si aquesta compilació la pot desxifrar. Els canvis de configuració només tenen sentit quan se’n coneixen totes dues respostes.

Comproveu si la clau està xifrada

Llegiu la primera línia del fitxer i després deixeu que la biblioteca l’analitzi, perquè un nom de fitxer no demostra res. Un bloc PEM etiquetat ENCRYPTED PRIVATE KEY és PKCS#8 xifrat, i un bloc RSA PRIVATE KEY més antic que porta Proc-Type: 4,ENCRYPTED és la forma tradicional, i tots dos esperen una frase de pas. Un bloc PRIVATE KEY sense xifrar no hauria de demanar-ne cap. Executeu l’anàlisi amb el compte que posseeix el fitxer, perquè un problema de permisos produeix un error diferent i molt menys interessant.

Si la clau realment no està xifrada i el client encara pregunta, deixeu de mirar la criptografia i comproveu si el perfil indica un fitxer askpass que el servei encara pugui llegir.

Comproveu si aquesta compilació la pot desxifrar

OpenSSL 3 va dividir el suport d’algoritmes en proveïdors, i un conjunt de xifradors antics ara és al proveïdor legacy en lloc del predeterminat. Una clau xifrada amb un d’aquests xifradors continua sent vàlida, però una biblioteca carregada sense el proveïdor legacy no la pot descodificar. En alguns clients això es veu com una sol·licitud que es repeteix, en d’altres com un error contundent just després de la frase de pas.

Analitzeu la mateixa clau dues vegades amb el mateix binari: primer només amb el proveïdor predeterminat, després amb legacy i predeterminat sol·licitats tots dos a la línia d’ordres. Si el segon intent té èxit on el primer va fallar, el diagnòstic es basa en proves i no en el moment de l’actualització. Si tots dos fallen igual, la frase de pas és incorrecta o el fitxer està malmès, i cap paràmetre de proveïdor no arregla cap de les dues coses.

Comproveu la solució més estreta disponible

Preferiu un canvi limitat al client abans que un d’abast sistèmic. Algunes compilacions 2.6 accepten una opció de perfil que carrega tots dos proveïdors per al procés d’aquell dimoni, així que confirmeu la directiva al manual de la vostra versió exacta abans de confiar-hi; editar el openssl.cnf del sistema afecta en canvi tots els programes OpenSSL de l’amfitrió. El paràmetre més estret també és molt més fàcil de revertir un cop la clau s’hagi tornat a codificar.

No suprimiu la frase de pas per fer desaparèixer la sol·licitud. Això converteix una credencial protegida en un fitxer de text pla i canvia silenciosament el risc de cada còpia de seguretat, còpia i paquet d’assistència on aparegui. La distinció que importa és entre una clau que necessita la seva frase de pas i una clau que aquesta biblioteca no pot descodificar.

Comproveu el context del servei i torneu a codificar

Un cop la clau es pot desbloquejar, torneu a xifrar-la amb un algoritme actual perquè la dependència desaparegui. Escriviu el fitxer nou amb un xifrador modern, verifiqueu que s’analitza, actualitzeu el perfil i conserveu la còpia antiga només fins que una connexió tingui èxit. No poseu mai la frase de pas en una línia d’ordres, on qualsevol usuari local la pot llegir de la llista de processos. Suprimiu el fitxer antic només després que el nou s’hagi connectat des del compte de servei, no només des del vostre shell.

Després comproveu la unitat que realment executa el client. Una clau llegible al vostre shell pot ser il·legible per a un servei que s’executa amb un altre compte o amb un paràmetre de directori personal endurit.

Anoteu el paràmetre del proveïdor al costat del perfil i conserveu-hi la prova de dues ordres. Quan una actualització posterior elimini el proveïdor legacy, torneu a executar aquella prova per veure si la clau encara el necessita o si el perfil es pot retirar de la solució temporal.

Una sol·licitud és un símptoma amb almenys tres causes, i només una d’elles és una frase de pas absent.