Importação de certificado SSL do WAF: conversão de formato JKS, PFX e PEM

Por que o mesmo certificado se recusa a fazer upload duas vezes

O certificado é real, não expirou, e mesmo assim não entra no WAF — porque o próprio arquivo está no formato errado.

A maioria das plataformas de servidor web não armazena certificados como uma simples chave pública, chave privada e cadeia. Apache e Nginx, construídos sobre OpenSSL, são os que mais se aproximam — já funcionam com arquivos do tipo CRT, KEY e CER. Tomcat, WebLogic e JBoss rodam em Java e armazenam tudo em um único arquivo Java Keystore (JKS) construído com o Keytool do JDK. O IIS da Microsoft usa o repositório de certificados do Windows e exporta como PFX. A configuração HTTPS de um WAF quer diretamente os arquivos estilo OpenSSL, então qualquer coisa que saia de um contêiner JKS ou PFX precisa ser convertida primeiro — e a cadeia precisa viajar junto, ou o site permanece inacessível mesmo com um certificado perfeitamente válido.

A seguir está a relação de conversão entre os três formatos, os comandos exatos para cada etapa, como gerar uma cadeia de certificados quando a do cliente está faltando, como distinguir um arquivo de chave pública de um arquivo de CA antes de fazer upload de qualquer um deles, e algumas respostas de perguntas frequentes tiradas de casos reais de campo.

Como os três formatos realmente se relacionam entre si

JKS, PFX e PEM/KEY/CRT não são três formatos sem relação — eles ficam em uma única cadeia de conversão, e todo upload de certificado de WAF acaba percorrendo-a a partir de uma ou outra extremidade.

Saber de qual extremidade você está partindo indica exatamente quantos saltos existem entre você e um upload que realmente funciona.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Tudo à esquerda de PEM/KEY/CRT precisa fazer o trajeto por este diagrama antes que um WAF o aceite. A cadeia de certificados é uma questão separada que viaja junto com o par de chave pública/privada, não um quarto formato na mesma cadeia — e é a peça mais frequentemente esquecida.

As etapas de conversão reais

Dois saltos, uma etapa de construção de cadeia se necessário, e uma verificação antes de mexer no formulário de upload.

Etapa 1 — De JKS para PFX (Keytool)

Se o certificado veio de um servidor Tomcat, WebLogic ou JBoss, ele está em um único arquivo JKS e precisa primeiro passar pelo Keytool.

1. Localize o utilitário Keytool do JDK na máquina que contém o arquivo JKS — ele vem com qualquer instalação padrão do JDK.
2. Execute o comando importkeystore, apontando-o para o arquivo JKS de origem e nomeando o arquivo PFX de destino, com o tipo de origem definido como JKS e o tipo de destino como PKCS12.
3. O Keytool solicitará a senha do keystore; forneça a que o administrador do servidor do cliente usou quando o arquivo JKS foi criado.

keytool -importkeystore -srckeystore D:\server.jks -destkeystore D:\server.pfx -srcstoretype JKS -deststoretype PKCS12

Etapa 2 — De PFX para PEM / KEY / CRT (OpenSSL)

Seja o PFX vindo da Etapa 1 ou diretamente de um servidor IIS, esta é a etapa que produz os arquivos que o WAF realmente quer.

1. Copie o arquivo PFX para o diretório de instalação do OpenSSL (ou garanta que o OpenSSL esteja acessível a partir de onde o arquivo está).
2. Execute openssl pkcs12 para extrair tudo em um único arquivo PEM não criptografado — ele contém tanto a chave privada quanto o certificado.
3. Execute openssl rsa nesse arquivo PEM para extrair apenas a chave privada como seu próprio arquivo KEY.
4. Execute openssl x509 no mesmo arquivo PEM para extrair apenas o certificado público como seu próprio arquivo CRT.

openssl pkcs12 -in server.pfx -nodes -out server.pem
openssl rsa -in server.pem -out server.key
openssl x509 -in server.pem -out server.crt

Etapa 3 — Construir a cadeia de certificados (se estiver faltando)

Quando o certificado vem de uma CA intermediária em vez de uma autoridade raiz — o caso normal — a cadeia também precisa ser enviada, ou o site permanece inacessível para qualquer um cujo navegador ainda não confie nesse intermediário.

1. Verifique se o cliente já forneceu um arquivo de cadeia junto com o certificado. Se forneceu e está intacto, pule direto para a Etapa 4.
2. Se a cadeia estiver faltando ou tiver sido perdida, importe o certificado de CA do site em uma ferramenta on-line de download de cadeia como a página chain_download do myssl.com.
3. Depois que o certificado de CA for importado, use a ferramenta para gerar a cadeia, depois baixe o arquivo de cadeia resultante para fazer upload junto com a chave pública e privada.

Etapa 4 — Verificar antes de fazer upload

Um arquivo que abre sem erro não é prova de que é o arquivo certo para o campo em que você está prestes a colocá-lo.

1. Clique duas vezes em cada arquivo de certificado para abri-lo e verifique o caminho do certificado. Um nome de domínio no caminho significa que você está vendo a chave pública — o certificado folha realmente emitido para este site.
2. Sem nome de domínio no caminho significa que é um certificado de CA — útil para a cadeia, mas não pertence ao campo de upload de chave pública.
3. Faça upload da chave pública, chave privada e cadeia de certificados em seus campos correspondentes, habilite a descriptografia HTTPS/SSL no site protegido, e confirme que o site está acessível via HTTPS antes de considerar o trabalho concluído.

4 armadilhas que causam a maioria das falhas de upload de certificado

Os próprios comandos de conversão raramente falham — essas quatro coisas ao redor deles é que realmente quebram o upload.

Projetos de soluções relacionadas

Cinco perguntas que surgem constantemente

Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.

Limites honestos desta nota

Leitura relacionada