P12 antigo falha no OpenSSL 3: palavra-passe errada ou cifra antiga?

A caixa de importação recebe a palavra-passe, gira por um instante e depois diz que não consegue ler o pacote. Nada nessa mensagem lhe diz se escreveu mal a frase-passe ou se o ficheiro foi selado com uma cifra que o cliente já não inclui. São falhas diferentes com correções diferentes, e uma escolha errada leva a um downgrade do cliente que apenas adia a decisão. Observar em que fase o cliente para separa-os em cerca de um minuto.

O que acontece entre a caixa de diálogo e a lista de certificados

Um ficheiro .p12 é um contentor, não um certificado. Lá dentro há um ou mais sacos de certificados e um saco de chave privada cifrado com uma chave derivada da sua palavra-passe, além de uma verificação de integridade chamada MAC sobre todo o ficheiro. Abrir significa verificar esse MAC, decifrar o saco da chave e emparelhar o certificado com a chave que sai.

O problema da palavra-passe chega na fase MAC. O problema da cifra chega mais tarde, quando o saco da chave tem de ser desempacotado e a compilação que o faz não tem implementação do algoritmo indicado no ficheiro.

O segundo caso é comum nos sistemas atuais porque o OpenSSL 3 mudou um grupo de algoritmos antigos para um legacy provider opcional. Os pacotes exportados pelo OpenSSL 1.x selavam normalmente os certificados com RC2 de 40 bits e a chave privada com Triple DES de três chaves. Uma compilação predefinida do OpenSSL 3 ainda verifica o MAC com a palavra-passe correta e depois falha no saco, pelo que a palavra-passe nunca esteve errada e reescrevê-la não muda nada.

Leia o contentor sem escrever uma chave

Peça à compilação do OpenSSL na sua máquina para analisar o ficheiro e ler o ponto em que desiste. Uma inspeção sem ficheiro de saída deixa a chave cifrada no disco, e é a única razão pela qual este passo é seguro num anfitrião partilhado.

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

Num pacote antigo com a palavra-passe correta, isto imprime os atributos do saco e depois para com digital envelope routines::unsupported. Com uma palavra-passe errada obtém Mac verify error: invalid password? antes de qualquer saco ser lido. As duas mensagens apontam em direções opostas, e é exatamente a informação que o cliente ocultou.

Se a falha for a do algoritmo não suportado, execute o mesmo comando outra vez com -legacy acrescentado e mais nada alterado. Essa opção carrega o legacy provider apenas para esse processo. Não obriga o cliente VPN a analisar pacotes antigos, não toca na política criptográfica do sistema e é uma medição e não uma reparação, porque o ficheiro continua a ter de ser substituído.

Que erro corresponde a que fase

Uma tabela curta mantém os três resultados separados, e o texto importa mais do que o local onde a caixa apareceu.

Texto como not enough data ou header too long não pertence a nenhum dos dois primeiros grupos. É um problema de formato: um ficheiro DER renomeado para .pem, uma cópia estragada por um editor que reescreveu os fins de linha, ou um download incompleto. Compare a soma de verificação com a que o emissor enviou antes de começar a olhar para as cifras.

Trate Mac verify error apenas como prova sobre a palavra-passe. Significa que o MAC calculado a partir do que escreveu não corresponde ao valor guardado, o que acontece com um erro de escrita, com uma palavra-passe em cache de uma importação anterior ou com um ficheiro reexportado com outra frase-passe. Não diz nada sobre se os algoritmos lá dentro são antigos.

Construa um pacote que o cliente consiga mesmo abrir

Assim que o analisador legacy confirmar que o ficheiro está são, a correção duradoura é um substituto cujos algoritmos o cliente de destino suporta: AES-256-CBC para os sacos da chave e dos certificados, PBKDF2 com SHA-256 para a derivação e SHA-256 para o MAC. O seu administrador de PKI pode exportá-lo do mesmo material de chave, e o certificado lá dentro continua a ser aquele em que os seus servidores já confiam.

Quando tiver de converter localmente, peça à ferramenta pkcs12 para voltar a selar os sacos em vez de os despejar primeiro. Mantenha as duas frases-passe fora do histórico da shell lendo-as de um 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

Uma conversão bem-sucedida não diz nada sobre a validade, o uso da chave, o emparelhamento da chave privada ou se o servidor confia na cadeia emissora. Reempacotar é uma alteração de transporte, não uma renovação, e cada um desses pontos continua a precisar da sua própria verificação.

Evite qualquer receita que escreva uma chave intermédia sem proteção ou uma palavra-passe de saída vazia só porque o cliente aceitou o ficheiro depois. Um pacote legível com a proteção retirada é um resultado pior do que a falha de importação com que começou.

Confirme se o cliente importou o ficheiro que criou

Uma análise limpa num terminal prova que o contentor é válido. Não prova que o cliente o escolheu, porque um perfil deixado para trás pode continuar a apontar para o ficheiro antigo, e alguns clientes guardam em cache a identidade importada com um nome que não escolheu.

Imprima a identidade que vai importar e compare-a com o que o cliente mostra na vista de certificados.

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

Remova primeiro a entrada de perfil antiga e só depois importe. Se o cliente registar o sujeito ou a impressão digital que carregou, compare com a linha acima; se mostrar apenas um nome amigável, verifique em vez disso a data de validade, porque é mais difícil de confundir com outro certificado do mesmo emissor.

A referência PKCS12 lista o provider, a frase-passe e as opções de saída usadas aqui. Manter o legacy provider fora do ambiente do cliente é o objetivo: meça com ele, entregue sem ele e deixe a chave privada protegida no disco.