Un P12 antigo falla en OpenSSL 3: contrasinal incorrecto ou cifrado herdado?

O diálogo de importación toma o seu contrasinal, xira un momento e logo di que non pode ler o paquete. Nada nesa mensaxe lle di se escribiu mal a frase de contrasinal ou se o ficheiro se selou cun cifrado que o cliente xa non inclúe. Son fallos distintos con solucións distintas, e escoller mal leva a unha degradación do cliente que só apraza a decisión. Observar a etapa na que se detén o cliente séparaos en aproximadamente un minuto.

Que ocorre entre o diálogo e a lista de certificados

Un ficheiro .p12 é un contedor, non un certificado. Dentro hai unha ou máis bolsas de certificados e unha bolsa de clave privada cifrada cunha clave derivada do seu contrasinal, ademais dunha comprobación de integridade chamada MAC sobre todo o ficheiro. Abrilo significa verificar esa MAC, descifrar a bolsa da clave e emparellar o certificado coa clave que sae dela.

O problema do contrasinal chega no paso da MAC. O problema do cifrado chega máis tarde, cando hai que desenrolar a bolsa da clave e a compilación que o fai non ten implementación do algoritmo indicado no ficheiro.

O segundo caso é habitual nos sistemas actuais porque OpenSSL 3 trasladou un grupo de algoritmos antigos a un provedor legacy opcional. Os paquetes exportados por OpenSSL 1.x adoitan selar os certificados con RC2 de 40 bits e a clave privada con Triple DES de tres claves. Unha compilación predeterminada de OpenSSL 3 aínda verifica a MAC co seu contrasinal correcto e logo falla na bolsa, así que o contrasinal nunca estivo mal e volver escribilo non cambia nada.

Lea o contedor sen escribir ningunha clave

Pida á compilación de OpenSSL da súa propia máquina que analice o ficheiro e lea o punto no que se rende. Unha inspección sen ficheiro de saída deixa a clave cifrada no disco, e esa é a única razón pola que este paso é seguro nun host compartido.

openssl pkcs12 -in vpn-identity.p12 -info -noout

Nun paquete legacy co contrasinal correcto, isto imprime os atributos da bolsa e logo detense con digital envelope routines::unsupported. Cun contrasinal incorrecto obtén Mac verify error: invalid password? antes de que se lea ningunha bolsa. As dúas mensaxes apuntan en direccións opostas, e esa é exactamente a información que o cliente ocultou.

Se o fallo é o do algoritmo non admitido, execute o mesmo comando outra vez con -legacy engadido e nada máis cambiado. Ese indicador carga o provedor legacy só para ese proceso. Non fai que o cliente VPN analice paquetes antigos, non toca a política criptográfica do sistema e é unha medición, non unha reparación, porque o ficheiro segue tendo que substituírse.

Que erro corresponde a que etapa

Unha táboa breve mantén separados os tres resultados, e a redacción importa máis que o lugar onde apareceu o diálogo.

Un texto como not enough data ou header too long non pertence a ningún dos dous primeiros grupos. É un problema de formato: un ficheiro DER renomeado a .pem, unha copia estragada por un editor que reescribiu os finais de liña, ou unha descarga incompleta. Compare a suma de comprobación coa que enviou o emisor antes de comezar a mirar cifrados.

Trate Mac verify error só como evidencia sobre o contrasinal. Significa que a MAC calculada a partir do que escribiu non coincide co valor gardado, o que ocorre cun erro de escritura, cun contrasinal na caché dunha importación anterior ou cun ficheiro reexportado cunha frase de contrasinal distinta. Non di nada sobre se os algoritmos de dentro son antigos.

Construa un paquete que o cliente poida abrir de verdade

Unha vez que o analizador legacy confirma que o ficheiro está correcto, a solución duradeira é unha substitución con algoritmos que o cliente de destino admita: AES-256-CBC para as bolsas de clave e certificados, PBKDF2 con SHA-256 para a derivación e SHA-256 para a MAC. O seu administrador de PKI pode exportalo do mesmo material de clave, e o certificado de dentro segue sendo o que os seus servidores xa confían.

Cando teña que converter localmente, pida á ferramenta pkcs12 que volva selar as bolsas en lugar de volcalas primeiro. Manteña as dúas frases de contrasinal fóra do historial da consola léndoas dun ficheiro.

openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
  -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
  -passin file:old.pass -passout file:new.pass

Unha conversión correcta non di nada sobre a caducidade, o uso da clave, a coincidencia da clave privada nin sobre se o servidor confía na cadea emisora. Reempaquetar é un cambio de transporte, non unha renovación, e cada un deses puntos segue necesitando a súa propia comprobación.

Omita calquera receita que escriba unha clave intermedia sen protección ou un contrasinal de saída baleiro só porque despois o cliente aceptou o ficheiro. Un paquete lexible coa protección eliminada é un resultado peor que o fallo de importación co que comezou.

Confirme que o cliente importou o ficheiro que vostede creou

Unha análise limpa nun terminal demostra que o contedor é válido. Non demostra que o cliente o escollese, porque un perfil sobrante pode seguir apuntando ao ficheiro antigo, e algúns clientes gardan na caché unha identidade importada cun nome que vostede non escolleu.

Imprima a identidade que está a piques de importar e compáraa co que o cliente mostra na súa vista de certificados.

openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
  | openssl x509 -noout -subject -dates -fingerprint -sha256

Quite primeiro a entrada de perfil obsoleta e logo importe. Se o cliente rexistra o suxeito ou a pegada que cargou, compárao coa liña de arriba; se só mostra un nome amigable, comprobe no seu lugar a data de caducidade, xa que é máis difícil confundila con outro certificado do mesmo emisor.

A referencia de PKCS12 enumera as opcións de provedor, frase de contrasinal e saída que se usan aquí. A clave é manter o provedor legacy fóra da contorna do cliente: mida con el, entregue sen el e deixe a clave privada protexida no disco.