CSR para SSL: Desvendando Erros Comuns em SAN e Wildcard
A criação do CSR (Certificate Signing Request) é frequentemente a origem de problemas com certificados SSL, especialmente em configurações complexas com SAN e wildcard. Este artigo explora os erros mais comuns e as melhores práticas para evitá-los.
MundiX News·06 de junho de 2026·9 min de leitura·👁 11 views
A maioria dos problemas com certificados SSL não surge na configuração do TLS, mas sim na etapa de criação do CSR – SANs incorretos, subdomínios esquecidos ou expectativas equivocadas sobre certificados wildcard. O wildcard *.example.com cobre apenas um nível de subdomínios e, por padrão, não inclui o domínio raiz. Grandes Autoridades Certificadoras (CAs) públicas o adicionam ao SAN automaticamente, mas CAs privadas podem não fazê-lo. A partir de março de 2026, o prazo máximo de validade dos certificados SSL começará a ser reduzido (para 47 dias até 2029), tornando a atualização manual de certificados em produção insustentável.
O OpenSSL continua sendo a ferramenta fundamental, mas para configurações multi-domínio/wildcard, é mais seguro utilizar a automação ACME ou um gerador de CSR com geração de chave local. CSR (Certificate Signing Request) é um arquivo de texto codificado com uma solicitação para emissão de um certificado SSL. Ele contém a chave pública, os domínios para os quais o certificado é necessário e informações sobre a organização. O CSR é assinado pela chave privada do proprietário e enviado a uma autoridade certificadora (CA), que emite o certificado após a verificação. Este artigo é destinado a desenvolvedores, engenheiros DevOps e administradores de sistemas que trabalham com infraestrutura HTTPS. Será útil para aqueles que já emitiram certificados SSL, mas desejam entender melhor o funcionamento do CSR, as nuances dos certificados SAN/wildcard e os riscos associados à geração de chaves privadas.
O certificado SSL é frequentemente visto como algo simples, mas na prática, os problemas muitas vezes começam na etapa de geração do CSR. Erros passam despercebidos enquanto a infraestrutura é pequena, mas se manifestam em produção quando a validação do certificado falha e ele precisa ser reemitido. O problema geralmente não está no certificado em si, mas em como o CSR foi criado. A montagem manual via OpenSSL pode se tornar uma fonte de erros pequenos, porém dolorosos. Vamos entender como o CSR funciona, por que as configurações SSL modernas se tornaram mais complexas e por que as equipes estão recorrendo cada vez mais a geradores de CSR.
SSL/TLS é um protocolo de criptografia. CSR é um arquivo de solicitação para emissão de um certificado SSL. Para obter um certificado SSL para o protocolo TLS, você cria um CSR e o envia a uma autoridade certificadora. Importante: a chave privada em si não é transmitida no CSR. Ela deve permanecer com o proprietário do certificado – no servidor, máquina local, armazenamento seguro ou dentro do pipeline de infraestrutura. Se a chave privada for perdida ou comprometida, o certificado precisará ser reemitido. O CSR contém: chave pública; informações do domínio; dados da organização; parâmetros da solicitação. Primeiro, uma chave privada é gerada – um grande número aleatório. A chave pública é derivada dela por uma função matemática unidirecional (para RSA – com base na fatoração do produto de dois grandes números primos; para ECC – com base em operações em pontos de uma curva elíptica). Recuperar a chave privada a partir da chave pública é impossível em tempo razoável com o hardware moderno – é nisso que se baseia toda a PKI. O CSR não contém a chave privada. Ele inclui a chave pública e é assinado pela chave privada para confirmar que a solicitação foi realmente criada pelo proprietário do par de chaves. Portanto, a perda da chave privada após a emissão do certificado significa, na prática, a impossibilidade de usar o certificado e a necessidade de reemissão.
Em configurações simples, o OpenSSL geralmente não causa problemas. No entanto, quanto mais complexa a estrutura do certificado, maior a probabilidade de erro. Do ponto de vista técnico, qualquer certificado SSL é um conjunto de campos assinados por uma autoridade certificadora (CA): Subject (Common Name): contém o domínio principal; Subject Alternative Name (SAN): contém a lista de todos os domínios e subdomínios para os quais o certificado é válido; Issuer: quem emitiu o certificado; Validity: data de início e fim de validade; Public Key: a chave pública associada à privada. O problema não é a quantidade de campos, mas sim a necessidade de preenchê-los corretamente na etapa de criação do CSR. Na prática, a complexidade do preenchimento depende de como e onde o certificado é usado. Os certificados mais complexos geralmente são aqueles que são usados em infraestruturas distribuídas; atendem a um grande número de domínios e subdomínios; combinam diferentes zonas de responsabilidade (serviços internos e externos); são aplicados em ambientes dinamicamente mutáveis.
Um certificado pode conter vários domínios através do mecanismo Subject Alternative Name (SAN). No nível da CA, este é um cenário padrão, mas no nível de operação surgem limitações: é fácil cometer erros ao adicionar domínios; é difícil manter a lista atualizada; alterações exigem a reemissão do certificado; aumenta o risco de erro humano no CSR. Certificados Wildcard cobrem todos os subdomínios de um único nível. IMPORTANTE: De acordo com o padrão RFC 6125, o wildcard NÃO cobre o domínio raiz example.com. Na prática, todas as grandes CAs públicas (Let's Encrypt, DigiCert, Sectigo, GoDaddy) adicionam automaticamente o domínio raiz ao SAN ao emitir um wildcard – esta é uma prática industrial estabelecida. Para CAs privadas e corporativas, a regra pode não se aplicar – sempre verifique o Subject e o SAN do certificado pronto com o comando: openssl x509 -in cert.crt -noout -text | grep -A1 "Subject Alternative". Os riscos de trabalhar com wildcard são especialmente relevantes em infraestruturas onde: serviços criam subdomínios aninhados automaticamente; service discovery é utilizado; parte das rotas é formada dinamicamente; o ingress é montado a partir de vários namespaces. Um cenário típico: a equipe emite *.example.com e acredita que todos os serviços estão cobertos. Um mês depois, a equipe mobile implanta api.v2.staging.example.com – os clientes recebem NET::ERR_CERT_COMMON_NAME_INVALID. O wildcard cobre apenas staging.example.com (um nível), mas não v2.staging.example.com (dois níveis). Soluções: emitir um segundo wildcard *.staging.example.com, usar um certificado SAN com uma lista explícita, ou – se os subdomínios forem criados dinamicamente – migrar para ACME com DNS-01 challenge.
A opção mais complexa é a combinação de wildcard e SAN em um único certificado. Tais configurações frequentemente aparecem em sistemas reais: após o crescimento do projeto; ao consolidar vários serviços; durante a migração de infraestrutura; em ambientes corporativos com diferentes zonas de responsabilidade. É precisamente nesses casos que a probabilidade de erros na formação do CSR aumenta: domínios omitidos; wildcard incorreto; entradas extras ou desatualizadas; inconsistência com a infraestrutura real.
O OpenSSL continua sendo a ferramenta padrão e suficiente para a maioria das tarefas. Um domínio, emissão única, o desenvolvedor conhece a CLI – openssl req faz seu trabalho em um único comando. RSA é a recomendação moderna (3072 bits): openssl req -new -newkey rsa:3072 \ -keyout domain.key \ -out domain.csr. Alternativa – ECC (mais rápido, menor): openssl req -new -newkey ec \ -pkeyopt ec_paramgen_curve:prime256v1 \ -keyout domain.key \ -out domain.csr. Frequentemente, as complexidades surgem em três cenários: Para certificados SAN Multi-domínio com dezenas de domínios e subdomínios. A configuração cresce, sincronizá-la manualmente entre ambientes é um caminho para erros de digitação. Quando a equipe é composta por várias pessoas. Quando cada um tem seu próprio openssl.cnf, com o tempo os padrões se desfazem – um tem RSA 2048, outro 4096, outro não tem SHA-256. Quando a reemissão regular é necessária. Considerando a redução dos prazos de validade dos certificados para 47 dias até 2029, o CSR manual deixa de ser um modelo viável para produção. Como resultado, uma parte significativa dos problemas surge não por causa do TLS ou dos certificados em si, mas devido ao suporte manual das configurações de CSR. Nesses casos, as equipes migram para automação ACME (se a CA suportar) ou para geradores de CSR. Um gerador não substitui o OpenSSL – ele valida os campos antes da emissão: verifica se o SAN está correto, se o wildcard foi escrito sem erros de digitação, se o CN está especificado, se o tamanho da chave atende à política.
O OpenSSL CLI tem alta complexidade (CLI, arquivos de configuração), enquanto um Gerador de CSR Online tem baixa complexidade (formulário no navegador) e um Cliente ACME é de complexidade média (configurar uma vez). A segurança da chave é completa (chave local) com OpenSSL e ACME, mas depende do gerador. Suporte a SAN é possível com todos, mas o wildcard é mais robusto com ACME (DNS-01 challenge). A automação é possível com scripts no OpenSSL, mas não nativamente; é inexistente em geradores online e completa em clientes ACME (renovação via cron).
Existem muitos geradores de CSR gratuitos: DigiCert CSR Tool, CSR Generator HB.BY, SSLShopper CSR Generator, Namecheap CSR Decoder/Generator. Cada um tem suas nuances de interface e conjunto de campos suportados. Siga o checklist de segurança universal abaixo. Como verificar se um gerador de CSR é seguro: HTTPS na página do gerador (sem HTTPS – passe reto). Abrir DevTools → Network antes de clicar em “Gerar”. Após a geração, não deve haver requisições de saída com a chave privada ou CSR no payload. A política de privacidade não deve mencionar o armazenamento ou recuperação de chaves privadas. Preferencialmente – código-fonte aberto ou auditoria independente. Salve a chave localmente imediatamente após a geração; atualize a página – a chave não deve ser recuperável. Se pelo menos um item não for cumprido – o gerador não é adequado para produção, e você deve retornar ao OpenSSL na máquina local.
Em abril de 2025, o CA/B Forum (organização que une autoridades certificadoras e fabricantes de navegadores) aprovou a redução gradual do prazo máximo de validade dos certificados SSL públicos: 200 dias – a partir de 15 de março de 2026; 100 dias – a partir de 15 de março de 2027; 47 dias – a partir de 15 de março de 2029. Na prática, isso significa que a reemissão manual 7-8 vezes por ano se torna impossível. Até 2029, o único modelo viável é a automação. As equipes migram para o protocolo ACME (Let's Encrypt, ZeroSSL, Sectigo ACME) ou integram a geração de CSR ao pipeline de infraestrutura. Para a maioria dos certificados públicos para automação, o CSR é criado pelo próprio cliente ACME: certbot, acme.sh, traefik, cert-manager. A geração manual de CSR é relevante para: certificados comerciais com validação estendida (OV/EV), certificados para CAs internas, configurações multi-domínio para uma única solicitação, situações em que a CA não suporta ACME (por exemplo, GlobalSign para PKI corporativas). Aqueles que planejam emitir certificados comerciais com validação OV/EV e não podem usar ACME, dependem cada vez mais de geradores de CSR com templates e validação SAN.
O elemento mais valioso e vulnerável da cadeia é a chave privada. É ela que é usada para assinar o CSR e confirmar a posse do certificado. Se a chave privada for comprometida, o certificado precisará ser reemitido. Alguns provedores oferecem a emissão do certificado gerando a chave e o CSR em seu lado – geralmente é o painel de um revendedor ou provedor de hospedagem. O CSR ainda é criado, mas a geração da chave não ocorre com você. Isso é conveniente para usuários não técnicos, mas tem uma desvantagem significativa: a chave privada é transmitida a você após a emissão e teoricamente pode ser salva nos logs do provedor. Ao usar um gerador de qualidade, a chave privada nunca sai do seu ambiente confiável. A CA recebe apenas o CSR (chave pública + domínios). Tudo permanece sob seu controle. Se o OpenSSL intimida com o console e os parâmetros, um gerador de CSR se parece com um formulário comum: A maioria dos geradores de CSR seguros funciona de forma semelhante: Insira o domínio (CN); Preencha os dados da empresa (se necessário); Adicione domínios SAN (se necessário); Escolha o tamanho da chave; Clique em “Gerar”; Copie o CSR e a chave privada; Envie o CSR para a CA, e a chave permanece apenas com você ao usar o gerador.
Recursos úteis:
OpenSSL Official Website – biblioteca criptográfica padrão e ferramenta CLI para trabalhar com TLS/SSL, CSR e certificados.
SSL Labs Server Test – análise da configuração TLS no servidor, cadeias de confiança e protocolos suportados.
RFC 2986 - Certificate Signing Request – especificação do formato CSR.
RFC 6125 – Domain-Based Service Identity – regras para wildcard e SAN.
CA/B Forum Baseline Requirements – padrões industriais para CAs.
Certificate Transparency (Google) – logs públicos de todos os certificados emitidos.
OWASP TLS Cheat Sheet – melhores práticas de segurança.
CSR Generator – ajuda na formação de uma nova solicitação para obter um certificado SSL.
ACME RFC 8555 – protocolo de emissão automatizada de certificados.
Censys Search – busca e análise de certificados na internet.
Perguntas Frequentes:
O que é CSR em palavras simples? CSR é uma solicitação para emissão de um certificado SSL. Um arquivo de texto com a chave pública e informações sobre domínios, que você envia a uma autoridade certificadora. A CA o assina e emite o certificado.
Qual a diferença entre CSR e certificado SSL? CSR é uma solicitação de certificado criada pelo proprietário do domínio. Um certificado SSL é um documento já assinado pela CA, que é instalado no servidor. O CSR existe por um curto período – da geração à emissão do certificado.
É possível usar o mesmo CSR para vários certificados? Tecnicamente sim, um CSR pode ser enviado a várias CAs ou reutilizado na reemissão. No entanto, ao trocar a chave privada (key rollover), o CSR deve ser criado novamente – a chave pública dentro do CSR deve corresponder à nova chave privada.
Qual a diferença entre SAN e wildcard? SAN é uma lista explícita de domínios dentro do certificado (DNS.1 = a.com, DNS.2 = b.com). Wildcard é uma máscara *.example.com, cobrindo todos os subdomínios de um único nível. Eles podem ser combinados: um certificado pode ter tanto SAN com uma lista de domínios quanto entradas wildcard no mesmo SAN.
O que fazer se eu perder a chave privada? O certificado se torna inútil – sem a chave privada, o servidor não conseguirá completar o TLS handshake. É necessária uma reemissão completa: nova chave privada → novo CSR → revogação do certificado antigo → emissão do novo. Se a chave foi comprometida, a revogação é obrigatória.
Conclusão:
Trabalhar com certificados SSL raramente causa dificuldades no nível de configuração básica. Os principais problemas surgem depois – quando a infraestrutura cresce, o número de domínios, ambientes e serviços aumenta. Nessas condições, os erros geralmente ocorrem não no nível da criptografia, mas na etapa de preparação do CSR: SANs incorretamente especificados, domínios omitidos ou configurações inconsistentes entre os sistemas. É por isso que o processo de geração de CSR gradualmente deixa de ser uma operação manual e se torna parte do fluxo de trabalho da infraestrutura. Ferramentas que ajudam a estruturar e validar o CSR na etapa de criação permitem reduzir o número de erros antes da emissão do certificado – antes que eles cheguem à produção. No caso de SSL, é mais barato prevenir erros na etapa do CSR do que corrigi-los em produção.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
A maioria dos problemas com certificados SSL não surge na configuração do TLS, mas sim na etapa de criação do CSR – SANs incorretos, subdomínios esquecidos ou expectativas equivocadas sobre certificados wildcard. O wildcard *.example.com cobre apenas um nível de subdomínios e, por padrão, não inclui o domínio raiz. Grandes Autoridades Certificadoras (CAs) públicas o adicionam ao SAN automaticamente, mas CAs privadas podem não fazê-lo. A partir de março de 2026, o prazo máximo de validade dos certificados SSL começará a ser reduzido (para 47 dias até 2029), tornando a atualização manual de certificados em produção insustentável.
O OpenSSL continua sendo a ferramenta fundamental, mas para configurações multi-domínio/wildcard, é mais seguro utilizar a automação ACME ou um gerador de CSR com geração de chave local. CSR (Certificate Signing Request) é um arquivo de texto codificado com uma solicitação para emissão de um certificado SSL. Ele contém a chave pública, os domínios para os quais o certificado é necessário e informações sobre a organização. O CSR é assinado pela chave privada do proprietário e enviado a uma autoridade certificadora (CA), que emite o certificado após a verificação. Este artigo é destinado a desenvolvedores, engenheiros DevOps e administradores de sistemas que trabalham com infraestrutura HTTPS. Será útil para aqueles que já emitiram certificados SSL, mas desejam entender melhor o funcionamento do CSR, as nuances dos certificados SAN/wildcard e os riscos associados à geração de chaves privadas.
O certificado SSL é frequentemente visto como algo simples, mas na prática, os problemas muitas vezes começam na etapa de geração do CSR. Erros passam despercebidos enquanto a infraestrutura é pequena, mas se manifestam em produção quando a validação do certificado falha e ele precisa ser reemitido. O problema geralmente não está no certificado em si, mas em como o CSR foi criado. A montagem manual via OpenSSL pode se tornar uma fonte de erros pequenos, porém dolorosos. Vamos entender como o CSR funciona, por que as configurações SSL modernas se tornaram mais complexas e por que as equipes estão recorrendo cada vez mais a geradores de CSR.
SSL/TLS é um protocolo de criptografia. CSR é um arquivo de solicitação para emissão de um certificado SSL. Para obter um certificado SSL para o protocolo TLS, você cria um CSR e o envia a uma autoridade certificadora. Importante: a chave privada em si não é transmitida no CSR. Ela deve permanecer com o proprietário do certificado – no servidor, máquina local, armazenamento seguro ou dentro do pipeline de infraestrutura. Se a chave privada for perdida ou comprometida, o certificado precisará ser reemitido. O CSR contém: chave pública; informações do domínio; dados da organização; parâmetros da solicitação. Primeiro, uma chave privada é gerada – um grande número aleatório. A chave pública é derivada dela por uma função matemática unidirecional (para RSA – com base na fatoração do produto de dois grandes números primos; para ECC – com base em operações em pontos de uma curva elíptica). Recuperar a chave privada a partir da chave pública é impossível em tempo razoável com o hardware moderno – é nisso que se baseia toda a PKI. O CSR não contém a chave privada. Ele inclui a chave pública e é assinado pela chave privada para confirmar que a solicitação foi realmente criada pelo proprietário do par de chaves. Portanto, a perda da chave privada após a emissão do certificado significa, na prática, a impossibilidade de usar o certificado e a necessidade de reemissão.
Em configurações simples, o OpenSSL geralmente não causa problemas. No entanto, quanto mais complexa a estrutura do certificado, maior a probabilidade de erro. Do ponto de vista técnico, qualquer certificado SSL é um conjunto de campos assinados por uma autoridade certificadora (CA): Subject (Common Name): contém o domínio principal; Subject Alternative Name (SAN): contém a lista de todos os domínios e subdomínios para os quais o certificado é válido; Issuer: quem emitiu o certificado; Validity: data de início e fim de validade; Public Key: a chave pública associada à privada. O problema não é a quantidade de campos, mas sim a necessidade de preenchê-los corretamente na etapa de criação do CSR. Na prática, a complexidade do preenchimento depende de como e onde o certificado é usado. Os certificados mais complexos geralmente são aqueles que são usados em infraestruturas distribuídas; atendem a um grande número de domínios e subdomínios; combinam diferentes zonas de responsabilidade (serviços internos e externos); são aplicados em ambientes dinamicamente mutáveis.
Um certificado pode conter vários domínios através do mecanismo Subject Alternative Name (SAN). No nível da CA, este é um cenário padrão, mas no nível de operação surgem limitações: é fácil cometer erros ao adicionar domínios; é difícil manter a lista atualizada; alterações exigem a reemissão do certificado; aumenta o risco de erro humano no CSR. Certificados Wildcard cobrem todos os subdomínios de um único nível. IMPORTANTE: De acordo com o padrão RFC 6125, o wildcard NÃO cobre o domínio raiz example.com. Na prática, todas as grandes CAs públicas (Let's Encrypt, DigiCert, Sectigo, GoDaddy) adicionam automaticamente o domínio raiz ao SAN ao emitir um wildcard – esta é uma prática industrial estabelecida. Para CAs privadas e corporativas, a regra pode não se aplicar – sempre verifique o Subject e o SAN do certificado pronto com o comando: openssl x509 -in cert.crt -noout -text | grep -A1 "Subject Alternative". Os riscos de trabalhar com wildcard são especialmente relevantes em infraestruturas onde: serviços criam subdomínios aninhados automaticamente; service discovery é utilizado; parte das rotas é formada dinamicamente; o ingress é montado a partir de vários namespaces. Um cenário típico: a equipe emite *.example.com e acredita que todos os serviços estão cobertos. Um mês depois, a equipe mobile implanta api.v2.staging.example.com – os clientes recebem NET::ERR_CERT_COMMON_NAME_INVALID. O wildcard cobre apenas staging.example.com (um nível), mas não v2.staging.example.com (dois níveis). Soluções: emitir um segundo wildcard *.staging.example.com, usar um certificado SAN com uma lista explícita, ou – se os subdomínios forem criados dinamicamente – migrar para ACME com DNS-01 challenge.
A opção mais complexa é a combinação de wildcard e SAN em um único certificado. Tais configurações frequentemente aparecem em sistemas reais: após o crescimento do projeto; ao consolidar vários serviços; durante a migração de infraestrutura; em ambientes corporativos com diferentes zonas de responsabilidade. É precisamente nesses casos que a probabilidade de erros na formação do CSR aumenta: domínios omitidos; wildcard incorreto; entradas extras ou desatualizadas; inconsistência com a infraestrutura real.
O OpenSSL continua sendo a ferramenta padrão e suficiente para a maioria das tarefas. Um domínio, emissão única, o desenvolvedor conhece a CLI – openssl req faz seu trabalho em um único comando. RSA é a recomendação moderna (3072 bits): openssl req -new -newkey rsa:3072 \ -keyout domain.key \ -out domain.csr. Alternativa – ECC (mais rápido, menor): openssl req -new -newkey ec \ -pkeyopt ec_paramgen_curve:prime256v1 \ -keyout domain.key \ -out domain.csr. Frequentemente, as complexidades surgem em três cenários: Para certificados SAN Multi-domínio com dezenas de domínios e subdomínios. A configuração cresce, sincronizá-la manualmente entre ambientes é um caminho para erros de digitação. Quando a equipe é composta por várias pessoas. Quando cada um tem seu próprio openssl.cnf, com o tempo os padrões se desfazem – um tem RSA 2048, outro 4096, outro não tem SHA-256. Quando a reemissão regular é necessária. Considerando a redução dos prazos de validade dos certificados para 47 dias até 2029, o CSR manual deixa de ser um modelo viável para produção. Como resultado, uma parte significativa dos problemas surge não por causa do TLS ou dos certificados em si, mas devido ao suporte manual das configurações de CSR. Nesses casos, as equipes migram para automação ACME (se a CA suportar) ou para geradores de CSR. Um gerador não substitui o OpenSSL – ele valida os campos antes da emissão: verifica se o SAN está correto, se o wildcard foi escrito sem erros de digitação, se o CN está especificado, se o tamanho da chave atende à política.
O OpenSSL CLI tem alta complexidade (CLI, arquivos de configuração), enquanto um Gerador de CSR Online tem baixa complexidade (formulário no navegador) e um Cliente ACME é de complexidade média (configurar uma vez). A segurança da chave é completa (chave local) com OpenSSL e ACME, mas depende do gerador. Suporte a SAN é possível com todos, mas o wildcard é mais robusto com ACME (DNS-01 challenge). A automação é possível com scripts no OpenSSL, mas não nativamente; é inexistente em geradores online e completa em clientes ACME (renovação via cron).
Existem muitos geradores de CSR gratuitos: DigiCert CSR Tool, CSR Generator HB.BY, SSLShopper CSR Generator, Namecheap CSR Decoder/Generator. Cada um tem suas nuances de interface e conjunto de campos suportados. Siga o checklist de segurança universal abaixo. Como verificar se um gerador de CSR é seguro: HTTPS na página do gerador (sem HTTPS – passe reto). Abrir DevTools → Network antes de clicar em “Gerar”. Após a geração, não deve haver requisições de saída com a chave privada ou CSR no payload. A política de privacidade não deve mencionar o armazenamento ou recuperação de chaves privadas. Preferencialmente – código-fonte aberto ou auditoria independente. Salve a chave localmente imediatamente após a geração; atualize a página – a chave não deve ser recuperável. Se pelo menos um item não for cumprido – o gerador não é adequado para produção, e você deve retornar ao OpenSSL na máquina local.
Em abril de 2025, o CA/B Forum (organização que une autoridades certificadoras e fabricantes de navegadores) aprovou a redução gradual do prazo máximo de validade dos certificados SSL públicos: 200 dias – a partir de 15 de março de 2026; 100 dias – a partir de 15 de março de 2027; 47 dias – a partir de 15 de março de 2029. Na prática, isso significa que a reemissão manual 7-8 vezes por ano se torna impossível. Até 2029, o único modelo viável é a automação. As equipes migram para o protocolo ACME (Let's Encrypt, ZeroSSL, Sectigo ACME) ou integram a geração de CSR ao pipeline de infraestrutura. Para a maioria dos certificados públicos para automação, o CSR é criado pelo próprio cliente ACME: certbot, acme.sh, traefik, cert-manager. A geração manual de CSR é relevante para: certificados comerciais com validação estendida (OV/EV), certificados para CAs internas, configurações multi-domínio para uma única solicitação, situações em que a CA não suporta ACME (por exemplo, GlobalSign para PKI corporativas). Aqueles que planejam emitir certificados comerciais com validação OV/EV e não podem usar ACME, dependem cada vez mais de geradores de CSR com templates e validação SAN.
O elemento mais valioso e vulnerável da cadeia é a chave privada. É ela que é usada para assinar o CSR e confirmar a posse do certificado. Se a chave privada for comprometida, o certificado precisará ser reemitido. Alguns provedores oferecem a emissão do certificado gerando a chave e o CSR em seu lado – geralmente é o painel de um revendedor ou provedor de hospedagem. O CSR ainda é criado, mas a geração da chave não ocorre com você. Isso é conveniente para usuários não técnicos, mas tem uma desvantagem significativa: a chave privada é transmitida a você após a emissão e teoricamente pode ser salva nos logs do provedor. Ao usar um gerador de qualidade, a chave privada nunca sai do seu ambiente confiável. A CA recebe apenas o CSR (chave pública + domínios). Tudo permanece sob seu controle. Se o OpenSSL intimida com o console e os parâmetros, um gerador de CSR se parece com um formulário comum: A maioria dos geradores de CSR seguros funciona de forma semelhante: Insira o domínio (CN); Preencha os dados da empresa (se necessário); Adicione domínios SAN (se necessário); Escolha o tamanho da chave; Clique em “Gerar”; Copie o CSR e a chave privada; Envie o CSR para a CA, e a chave permanece apenas com você ao usar o gerador.
Recursos úteis:
OpenSSL Official Website – biblioteca criptográfica padrão e ferramenta CLI para trabalhar com TLS/SSL, CSR e certificados.
SSL Labs Server Test – análise da configuração TLS no servidor, cadeias de confiança e protocolos suportados.
RFC 2986 - Certificate Signing Request – especificação do formato CSR.
RFC 6125 – Domain-Based Service Identity – regras para wildcard e SAN.
CA/B Forum Baseline Requirements – padrões industriais para CAs.
Certificate Transparency (Google) – logs públicos de todos os certificados emitidos.
OWASP TLS Cheat Sheet – melhores práticas de segurança.
CSR Generator – ajuda na formação de uma nova solicitação para obter um certificado SSL.
ACME RFC 8555 – protocolo de emissão automatizada de certificados.
Censys Search – busca e análise de certificados na internet.
Perguntas Frequentes:
O que é CSR em palavras simples? CSR é uma solicitação para emissão de um certificado SSL. Um arquivo de texto com a chave pública e informações sobre domínios, que você envia a uma autoridade certificadora. A CA o assina e emite o certificado.
Qual a diferença entre CSR e certificado SSL? CSR é uma solicitação de certificado criada pelo proprietário do domínio. Um certificado SSL é um documento já assinado pela CA, que é instalado no servidor. O CSR existe por um curto período – da geração à emissão do certificado.
É possível usar o mesmo CSR para vários certificados? Tecnicamente sim, um CSR pode ser enviado a várias CAs ou reutilizado na reemissão. No entanto, ao trocar a chave privada (key rollover), o CSR deve ser criado novamente – a chave pública dentro do CSR deve corresponder à nova chave privada.
Qual a diferença entre SAN e wildcard? SAN é uma lista explícita de domínios dentro do certificado (DNS.1 = a.com, DNS.2 = b.com). Wildcard é uma máscara *.example.com, cobrindo todos os subdomínios de um único nível. Eles podem ser combinados: um certificado pode ter tanto SAN com uma lista de domínios quanto entradas wildcard no mesmo SAN.
O que fazer se eu perder a chave privada? O certificado se torna inútil – sem a chave privada, o servidor não conseguirá completar o TLS handshake. É necessária uma reemissão completa: nova chave privada → novo CSR → revogação do certificado antigo → emissão do novo. Se a chave foi comprometida, a revogação é obrigatória.
Conclusão:
Trabalhar com certificados SSL raramente causa dificuldades no nível de configuração básica. Os principais problemas surgem depois – quando a infraestrutura cresce, o número de domínios, ambientes e serviços aumenta. Nessas condições, os erros geralmente ocorrem não no nível da criptografia, mas na etapa de preparação do CSR: SANs incorretamente especificados, domínios omitidos ou configurações inconsistentes entre os sistemas. É por isso que o processo de geração de CSR gradualmente deixa de ser uma operação manual e se torna parte do fluxo de trabalho da infraestrutura. Ferramentas que ajudam a estruturar e validar o CSR na etapa de criação permitem reduzir o número de erros antes da emissão do certificado – antes que eles cheguem à produção. No caso de SSL, é mais barato prevenir erros na etapa do CSR do que corrigi-los em produção.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
