Como gerar um CSR no NGINX

Este tutorial mostra como gerar um CSR no NGINX. O NGINX não gera Pedidos de Assinatura de Certificado (CSR) por si só: você cria a chave privada e o CSR com o OpenSSL no mesmo servidor que hospedará o certificado e, em seguida, envia o CSR à sua Autoridade Certificadora. Quando o certificado emitido retornar, você aponta o NGINX para ele com as diretivas ssl_certificate e ssl_certificate_key.

Os passos abaixo funcionam em todas as distribuições Linux suportadas que incluem o NGINX (Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Amazon Linux), pois cada uma delas inclui o OpenSSL 1.1.1 ou 3.x. O OpenSSL moderno assina os pedidos com SHA-256 por padrão, portanto você não precisa adicionar uma flag de digest.

Passo 1: Conecte-se ao seu servidor NGINX

Conecte-se ao servidor que executa o NGINX via SSH a partir da sua máquina local (Terminal no macOS ou Linux, PowerShell ou Windows Terminal no Windows). Substitua o nome de usuário e o host pelos seus próprios:

ssh your-user@your-nginx-server

Gere o CSR no servidor que vai servir o certificado. A chave privada é criada junto com o CSR e deve permanecer nesse servidor. Executar esses comandos localmente e depois copiar a chave para outro lugar anula o propósito de se ter uma chave privada.

Passo 2: Gere a chave privada e o CSR

Execute o seguinte comando. Ele cria uma chave privada RSA de 2048 bits e um CSR correspondente em uma única etapa, com o assunto e os Nomes Alternativos do Assunto (SANs) fornecidos diretamente para que o OpenSSL não pare para fazer perguntas:

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

O que cada parte faz:

• -newkey rsa:2048 gera uma nova chave RSA de 2048 bits. 2048 bits é o mínimo atual aceito pelas CAs públicas; você pode usar rsa:4096 para uma chave maior, ou mudar para ECDSA (veja abaixo).
• -nodes deixa a chave privada sem criptografia para que o NGINX possa lê-la na inicialização sem pedir uma senha. Se preferir criptografar a chave, remova -nodes e use a diretiva ssl_password_file do NGINX para fornecer a senha ao iniciar e recarregar.
• -keyout e -out nomeiam os arquivos da chave privada e do CSR.
• -subj fornece o assunto do certificado. Coloque aqui o nome real da sua empresa, estado e cidade, não os valores de exemplo. CN (Common Name) é o seu domínio principal.
• -addext “subjectAltName=…” lista todos os nomes de host que o certificado deve cobrir. As CAs públicas validam com base na lista de SAN, portanto inclua também o Common Name aqui. A flag -addext requer OpenSSL 1.1.1 ou mais recente; toda distribuição Linux suportada inclui pelo menos essa versão.

Substitua yourdomain.com pelo seu domínio real em todo o comando. Para cobrir nomes de host adicionais, adicione-os à lista de SAN separados por vírgulas, por exemplo DNS:api.yourdomain.com. Para um wildcard, inclua tanto o wildcard quanto o domínio simples: DNS:*.yourdomain.com,DNS:yourdomain.com.

Se preferir uma chave ECDSA (menor e mais rápida, com P-256 amplamente suportado), gere a chave e o CSR desta forma:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Se o seu OpenSSL não suportar -addext

Em sistemas muito antigos com OpenSSL anterior à versão 1.1.1, a flag -addext não está disponível. Crie um pequeno arquivo de configuração chamado san.cnf com este conteúdo:

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
C  = US
ST = YourState
L  = YourCity
O  = YourCompany
CN = yourdomain.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = yourdomain.com
DNS.2 = www.yourdomain.com

Depois execute:

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key -out yourdomain.csr -config san.cnf

Passo 3: Localize seus arquivos

Liste o diretório atual para confirmar que ambos os arquivos foram criados:

ls

Você deverá ver dois novos arquivos:

• yourdomain.key: sua chave privada. Mantenha-a no servidor, faça backup com segurança e nunca a envie a ninguém, incluindo a Autoridade Certificadora. Quem possuir a chave pode se passar pelo seu site.
• yourdomain.csr: seu Pedido de Assinatura de Certificado. Este é o arquivo que você envia ao provedor de SSL.

Defina permissões restritas na chave privada imediatamente para que apenas o root possa lê-la:

sudo chmod 600 yourdomain.key
sudo chown root:root yourdomain.key

Passo 4: Verifique o CSR (opcional, mas recomendado)

Antes de enviá-lo, verifique se o CSR contém o assunto e os SANs corretos e se sua assinatura é válida. Isso decodifica o pedido localmente com o OpenSSL:

openssl req -noout -text -verify -in yourdomain.csr

Confirme que a linha Subject mostra seus dados, que X509v3 Subject Alternative Name lista todos os nomes de host esperados, e que a verificação da assinatura exibe verify OK. O algoritmo de assinatura deve mostrar sha256WithRSAEncryption (ou ecdsa-with-SHA256 para uma chave ECDSA). Se preferir não usar a linha de comando, cole o CSR em nosso decodificador de CSR online para ler os mesmos campos em um navegador.

Passo 5: Envie seu CSR

Para copiar o CSR para o seu pedido, imprima seu conteúdo:

cat yourdomain.csr

Você verá um bloco de texto como este:

-----BEGIN CERTIFICATE REQUEST-----
MIIBozCB... (a long string of characters)
-----END CERTIFICATE REQUEST-----

Copie o bloco inteiro, incluindo as linhas —–BEGIN CERTIFICATE REQUEST—– e —–END CERTIFICATE REQUEST—– (cada marcador tem cinco hífens de cada lado). Todo esse bloco é o seu CSR. Cole-o no formulário de pedido durante sua compra e mantenha a chave privada correspondente no servidor.

Se preferir não usar a linha de comando, você também pode criar o pedido com nosso Gerador de CSR online. Observe que ele gera a chave privada no seu navegador, então salve essa chave você mesmo e a transfira para o servidor.

O que acontece depois que a CA emite o certificado

Assim que a CA validar o CSR e emitir o certificado, você normalmente receberá seu certificado de servidor (um arquivo .crt nomeado de acordo com seu domínio) mais um ou mais certificados intermediários, às vezes agrupados em um arquivo .ca-bundle. O NGINX espera que o certificado do servidor e a cadeia intermediária estejam combinados em um único arquivo (a “fullchain”) e apontados pela diretiva ssl_certificate; a chave privada que você gerou anteriormente é apontada separadamente pela diretiva ssl_certificate_key. O procedimento completo (montagem da fullchain, edição do bloco do servidor, testes e recarregamento) é abordado em nosso tutorial de instalação de SSL no NGINX.