Como Gerar um Certificado Autoassinado Usando o OpenSSL?

Um certificado autoassinado é aquele que você emite para si mesmo em vez de comprá-lo de uma autoridade certificadora. Os navegadores não confiarão nele automaticamente, então não tem lugar em um site público, mas é a forma mais rápida de colocar HTTPS em uma máquina de desenvolvimento, um servidor de staging, um painel interno ou qualquer serviço que nunca fique exposto à internet aberta.

Este guia mostra como criar um certificado autoassinado com OpenSSL no Windows, Linux e macOS. O comando é o mesmo nos três sistemas. Você também verá como verificar se o certificado gerado é realmente utilizável e como fazer sua própria máquina confiar nele para que os avisos do navegador desapareçam.

O que é um certificado autoassinado

Um certificado autoassinado é um certificado digital assinado com sua própria chave privada, em vez de por uma autoridade certificadora (CA) confiável. Criptograficamente, é um certificado X.509 normal: ele criptografa o tráfego exatamente tão bem quanto um comprado. O que lhe falta é uma cadeia de confiança. Nada fora da sua própria máquina tem motivo para confiar nele, então os navegadores exibem um aviso até que você indique o contrário.

Isso torna os certificados autoassinados uma boa opção para:

• Desenvolvimento local, onde você precisa de HTTPS para que cookies, service workers ou um SDK de pagamento se comportem como se comportarão em produção.
• Serviços internos, como um painel de intranet, um painel de monitoramento ou uma interface de gerenciamento de dispositivos em uma rede privada.
• Testes e staging, onde você quer testar uma configuração TLS sem gastar um certificado com isso.
• Servidores de origem atrás de um proxy que aceita um certificado não confiável no trecho de back-end, como o Cloudflare no modo Full.

São a ferramenta errada para qualquer coisa que um visitante real vá carregar. Detalhamos essa distinção mais adiante, na seção sobre quando não usar um.

Antes de começar: verifique seu OpenSSL

Você precisa da ferramenta de linha de comando OpenSSL. Confirme o que você tem:

openssl version

• Linux: o OpenSSL já vem pré-instalado na maioria das distribuições. Se não estiver, consulte nosso guia sobre como instalar o OpenSSL no Ubuntu.
• Windows: o OpenSSL não vem incluído. Siga nossas instruções sobre como instalar o OpenSSL no Windows e depois execute o comando no Prompt de Comando ou no PowerShell.
• macOS: a Apple distribui o LibreSSL, um fork do OpenSSL, como o comando openssl integrado, então isso retorna algo como LibreSSL 3.3.6 em vez de uma versão do OpenSSL.

O comando principal deste guia funciona tanto no LibreSSL 3.3.6 quanto na versão atual do OpenSSL, então usuários de Mac podem usar a ferramenta integrada. Se preferir ter o OpenSSL genuíno (alguns dos comandos opcionais abaixo precisam dele), instale-o com o gerenciador de pacotes Homebrew e chame-o pelo caminho completo:

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

Em Macs Intel, o caminho é /usr/local/opt/openssl@3/bin/openssl. Para mais detalhes sobre como interpretar a saída, consulte nosso guia sobre como verificar sua versão do OpenSSL.

Como criar um certificado autoassinado com OpenSSL

Etapa 1: Abra um terminal

No Linux, pressione Ctrl + Alt + T ou procure por “Terminal” no menu de aplicativos. No macOS, abra Aplicativos, depois Utilitários, depois Terminal, ou pressione Cmd + Espaço e digite “Terminal”. No Windows, pressione Win + R, digite cmd e pressione Enter.

Etapa 2: Vá até a pasta onde deseja os arquivos

O OpenSSL grava sua saída no diretório em que você está atualmente, não no diretório onde o OpenSSL está instalado. Crie uma pasta para este certificado e entre nela para que a chave e o certificado fiquem em um local que você consiga encontrar:

mkdir my-cert
cd my-cert

No Windows, use os mesmos dois comandos no Prompt de Comando. Não execute os comandos de dentro da pasta do programa OpenSSL: no Windows, esse diretório muitas vezes não é gravável por um usuário comum, e misturar suas chaves com os binários facilita perdê-las.

Etapa 3: Execute o comando do certificado

Este único comando gera a chave privada e o certificado autoassinado juntos. Substitua example.com e www.example.com pelos nomes que seu serviço realmente usará:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Mantenha tudo em uma única linha. O Prompt de Comando e os shells Unix usam caracteres de continuação de linha diferentes, e uma única linha funciona em todos os lugares. Use aspas duplas, não aspas simples, pelo mesmo motivo: o Prompt de Comando não trata aspas simples como delimitadores de citação.

Veja o que cada parte faz:

• req -x509: produz um certificado assinado e finalizado em vez de uma solicitação de assinatura de certificado.
• -newkey rsa:2048: cria uma nova chave privada RSA de 2048 bits como parte do mesmo comando. 2048 bits é o mínimo atual e um padrão sensato. Use rsa:4096 se sua política exigir uma chave maior, ao custo de handshakes mais lentos.
• -keyout private.key: o nome do arquivo para a chave privada.
• -out certificate.crt: o nome do arquivo para o certificado.
• -days 365: por quanto tempo o certificado permanece válido. Veja a seção sobre validade abaixo antes de alterar isso.
• -nodes: deixa a chave privada sem criptografia, para que seu servidor web possa iniciar sem que uma pessoa digite uma senha.
• -addext “subjectAltName=…”: a lista de nomes de host para os quais o certificado é válido. Sem isso, o certificado não corresponde a nada.
• -addext “basicConstraints=critical,CA:FALSE”: marca o certificado como um certificado de entidade final (servidor) em vez de uma autoridade certificadora.
• -addext “extendedKeyUsage=serverAuth”: indica que o certificado é para autenticar um servidor TLS. As plataformas Apple tratam isso como obrigatório.

Por que as três opções -addext são importantes

Essas três flags são a diferença entre um certificado que funciona e um que os clientes recusam totalmente. Vale a pena entendê-las, porque um certificado autoassinado criado sem elas falha de três formas fáceis de diagnosticar erradamente.

O Subject Alternative Name é onde vivem os nomes de host. Os navegadores pararam de ler o campo Common Name há anos e agora comparam o nome de host apenas com a extensão Subject Alternative Name (SAN). Um certificado sem SAN não corresponde a site nenhum, por mais correto que o Common Name pareça. Liste todos os nomes que você usará, separados por vírgulas. Para um serviço local, você também pode incluir um endereço IP:

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

Sem CA:FALSE, o OpenSSL cria um certificado de CA. Quando req -x509 é deixado com seus padrões próprios, ele define basicConstraints como critical, CA:TRUE, o que descreve uma autoridade certificadora, não um servidor web. Chrome e Safari aceitam isso em um certificado de servidor. O Firefox não aceita, e para com MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY. Você ainda pode clicar em Avançado e adicionar uma exceção, mas estaria contornando um certificado que já se sabe malformado, e outros clientes traçam o limite em pontos diferentes. Passar basicConstraints=critical,CA:FALSE evita a situação desde o início.

A versão do LibreSSL que o macOS distribui se comporta de forma diferente aqui: deixada com seus padrões próprios, ela escreve um certificado X.509 versão 1 sem nenhuma extensão, então você não tem o problema de CA:TRUE, mas também não tem o Subject Alternative Name. Fornecer as extensões explicitamente proporciona o mesmo certificado correto em ambas as ferramentas.

Sem serverAuth, as plataformas Apple rejeitam o certificado. Os requisitos publicados pela Apple para certificados confiáveis afirmam que um certificado de servidor TLS deve conter uma extensão ExtendedKeyUsage contendo o OID id-kp-serverAuth. Um certificado sem isso falha na validação de certificado do macOS sob a política TLS com a mensagem “Invalid Extended Key Usage for policy”, mesmo quando o certificado é fornecido como sua própria âncora de confiança. Firefox e Chrome são mais tolerantes e tratam um ExtendedKeyUsage ausente em um certificado de servidor como permitido, então esse detalhe é fácil de passar despercebido até que um Mac ou um iPhone seja o dispositivo que não consegue se conectar. Adicionar extendedKeyUsage=serverAuth não custa nada nas outras plataformas e é exatamente o que uma CA pública emitiria de qualquer forma.

Etapa 4: Preencha os detalhes do certificado

O OpenSSL pede os campos que compõem o Distinguished Name. Pressione Enter para pular qualquer um deles, mas preencha pelo menos um, e que seja o Common Name. A versão do LibreSSL no macOS para com “error, no objects specified in config file” e não grava nada se você deixar todos os campos em branco. Os valores abaixo são exemplos, então use os seus:

• Country Name: o código de duas letras do seu país, por exemplo US.
• State or Province Name: escrito por extenso, por exemplo California.
• Locality Name: sua cidade, por exemplo San Jose.
• Organization Name: o nome da sua empresa ou projeto, por exemplo Example Inc.
• Organizational Unit Name: a equipe responsável, por exemplo IT.
• Common Name: o nome de host principal, por exemplo example.com. Use o mesmo nome que você colocou primeiro na lista de Subject Alternative Name.
• Email Address: um endereço de contato, por exemplo [email protected]. Opcional.

Apenas o Common Name realmente importa aqui, e apenas como um rótulo: a correspondência de nome de host é feita pelo Subject Alternative Name que você já definiu na linha de comando. Todo o resto é descritivo.

Você vai notar que o comando nunca pede uma senha de desafio. Esse prompt pertence às solicitações de assinatura de certificado, e é um campo vestigial que as CAs geralmente ignoram ou rejeitam. Como este comando produz um certificado finalizado em vez de uma solicitação, o prompt simplesmente não aparece.

Etapa 5: Verifique o certificado antes de usá-lo

Não pule esta etapa. Um certificado autoassinado pode ser gerado com sucesso e ainda assim ser inutilizável, e a falha só aparece mais tarde como um erro no navegador. Leia o certificado de volta:

openssl x509 -in certificate.crt -noout -text

No bloco de extensões X509v3, você está procurando exatamente três coisas:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

Se a linha Subject Alternative Name estiver ausente, o certificado não corresponderá a nenhum nome de host. Se Basic Constraints indicar CA:TRUE, o Firefox vai parar nisso. Se a linha Extended Key Usage estiver ausente, as plataformas Apple recusarão o certificado. Em qualquer um desses casos, exclua os dois arquivos e execute o comando novamente com as três opções -addext presentes.

No OpenSSL 3.x, você pode pedir apenas essas extensões em vez de ler todo o certificado:

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

A flag -ext não existe na versão do LibreSSL que o macOS distribui, que reporta “unknown option -ext”. Em um Mac padrão, use a versão com -text acima.

Para confirmar que o certificado e a chave pertencem um ao outro, compare seus módulos. Os dois comandos devem imprimir o mesmo hash:

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

O próprio certificado é um arquivo de texto. Abri-lo em um editor de texto mostra um bloco em base64 entre as linhas BEGIN CERTIFICATE e END CERTIFICATE, que é o que você cola em painéis de controle que pedem o certificado em vez de um upload de arquivo.

Variações do comando

Gere sem nenhum prompt

Para scripts e pipelines de CI, forneça o Distinguished Name com -subj e o comando é executado sem interação:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Use uma chave EC em vez de RSA

Chaves de curva elíptica são menores e mais rápidas do que RSA com resistência equivalente, e todo navegador atual as suporta. P-256 é a escolha padrão:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

O resultado é assinado com ecdsa-with-SHA256. Continue com RSA se você precisar dar suporte a clientes embarcados antigos ou versões legadas do Java, que às vezes não têm suporte a EC.

Use o OpenSSL genuíno para isso. A versão do LibreSSL no macOS aceita o comando, mas escreve a curva no certificado como um conjunto completo de parâmetros explícitos em vez do identificador padrão P-256. A RFC 5480 afirma que a forma explícita não deve ser usada em certificados, e o próprio macOS rejeita um certificado codificado dessa forma.

Verifique o resultado com openssl x509 -in certificate.crt -noout -text: você quer uma linha dizendo “ASN1 OID: prime256v1”, não um bloco listando Prime, A, B e Generator. Em um Mac padrão, use o comando RSA acima ou instale o OpenSSL via Homebrew primeiro.

-nodes ou -noenc?

Ambas as flags fazem a mesma coisa: impedem que o OpenSSL criptografe a chave privada com uma senha. O OpenSSL 3.x adicionou -noenc como o nome mais claro e lista -nodes como obsoleto, embora ainda o aceite. O LibreSSL, distribuído pelo macOS, não reconhece -noenc de forma alguma e gera erro.

Este guia usa -nodes porque é a opção que funciona em qualquer versão que você provavelmente vai encontrar, incluindo um Mac padrão. Se você estiver no OpenSSL 3.x e quiser evitar a grafia obsoleta, substitua por -noenc. Nada mais muda.

Se você omitir a flag completamente, o OpenSSL criptografa a chave com uma senha à sua escolha, e seu servidor web vai então solicitá-la a cada reinicialização. Isso raramente é o que você quer para um certificado de desenvolvimento.

Faça sua máquina confiar no certificado

Um certificado autoassinado correto ainda produz um aviso do navegador, porque nada foi instruído a confiar nele. Adicioná-lo ao seu repositório de confiança local é o que desliga o aviso, e geralmente é esse o objetivo de criar um.

Faça isso apenas em máquinas que você controla, e apenas para certificados que você mesmo gerou. Um certificado confiável é confiável para todos os sites que ele nomeia, então trate a chave privada de acordo e nunca a compartilhe.

Chaveiro do macOS

Adicione o certificado ao chaveiro do sistema e marque-o como confiável para TLS. Você será solicitado a fornecer sua senha de administrador:

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

A parte -p ssl limita a confiança a conexões TLS. Omita-a e o certificado será confiável para todos os propósitos que o macOS conhece, incluindo assinatura de código, o que é muito mais do que um certificado de desenvolvimento precisa.

Para fazer isso pela interface, clique duas vezes no arquivo do certificado para abrir o Acesso ao Chaveiro, encontre a entrada no chaveiro Sistema, abra-a, expanda Confiança, e defina Ao usar este certificado como Sempre Confiar. Para desfazer isso depois, exclua a entrada do Acesso ao Chaveiro.

Repositório de certificados do Windows

Abra o Prompt de Comando como administrador (pressione Win + R, digite cmd, depois pressione Ctrl + Shift + Enter) e adicione o certificado ao repositório de Autoridades de Certificação Raiz Confiáveis:

certutil -addstore -f "Root" certificate.crt

Alternativamente, clique duas vezes no arquivo do certificado, escolha Instalar Certificado, selecione Máquina Local, depois Colocar todos os certificados no repositório a seguir, e navegue até Autoridades de Certificação Raiz Confiáveis. Para removê-lo depois, abra certmgr.msc e exclua a entrada desse repositório.

ca-certificates do Linux

No Debian e Ubuntu, copie o certificado para o diretório de âncoras local e reconstrua o pacote. O arquivo precisa manter a extensão .crt, senão a ferramenta de atualização vai ignorá-lo:

sudo cp certificate.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

No RHEL, CentOS, AlmaLinux, Rocky e Fedora, os caminhos são diferentes:

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

A exceção do Firefox

O Firefox mantém seu próprio repositório de confiança em vez de usar o do sistema operacional. No Windows e no macOS, ele também lê por padrão as raízes adicionadas ao repositório do SO, então os passos acima normalmente cobrem isso. No Linux, não, então o certificado precisa ser importado diretamente no Firefox: abra Configurações, depois Privacidade e Segurança, role até Certificados, clique em Ver Certificados, abra a aba Autoridades, e use Importar.

Reinicie o navegador após qualquer uma dessas alterações. Os navegadores armazenam em cache as decisões sobre certificados, e uma sessão desatualizada é um motivo comum para o aviso parecer persistir após uma importação correta.

Quando não usar um certificado autoassinado

Nunca coloque um em um site que o público vai visitar. Todo visitante recebe um aviso de segurança de tela cheia, e os que prosseguem mesmo assim foram treinados a clicar exatamente no aviso que os protege de um ataque real. Também não há como um visitante distinguir seu certificado autoassinado do de um atacante, que é exatamente o motivo pelo qual os navegadores desconfiam deles. Detalhamos isso em nosso artigo sobre os perigos dos certificados autoassinados.

Os certificados autoassinados também falham em atender a requisitos práticos além do aviso do navegador. Processadores de pagamento, lojas de aplicativos, aplicativos móveis com fixação de certificado (certificate pinning) e a maioria dos regimes de conformidade exigem um certificado de uma CA reconhecida. Para qualquer coisa voltada ao público, use um certificado emitido por uma autoridade certificadora confiável, que você solicita com um CSR e valida antes da emissão. Depois de ativo, confirme a instalação com nosso SSL Checker.