Tipos de certificados SSL: escolha a opção certa

Publicado em 30 de setembro de 2026

O certificado SSL certo desempenha duas funções ao mesmo tempo: criptografa o tráfego entre um visitante e seu servidor e apresenta a identidade que seus visitantes precisam considerar confiável. Os tipos de certificados SSL diferem principalmente na forma como essa identidade é validada e na quantidade de nomes de host que abrangem. Para a maioria dos sites, escolher corretamente tem menos a ver com criptografia e mais com alinhar a cobertura e a validação do certificado à forma como o serviço realmente funciona.

Um pequeno site institucional, uma página de checkout, uma plataforma SaaS multi-tenant e uma agência que gerencia 40 domínios de clientes podem usar os mesmos padrões de criptografia TLS. Eles não devem usar automaticamente o mesmo certificado. O serviço funciona melhor quando o plano do certificado corresponde ao plano da infraestrutura.

Tipos de certificados SSL por nível de validação

O nível de validação determina o que a autoridade certificadora verifica antes de emitir o certificado. Todo certificado válido criptografa a conexão. A diferença está no nível de verificação de identidade por trás dele e, em alguns casos, nas informações exibidas nos detalhes do certificado.

Certificados validados pelo domínio

Um certificado validado pelo domínio, ou DV, confirma o controle sobre um nome de domínio. A autoridade certificadora geralmente solicita que você insira um registro DNS, carregue um arquivo de verificação ou aprove um e-mail enviado para um endereço autorizado. Depois que essa verificação é aprovada, a emissão pode ser muito rápida.

O DV é a escolha prática para blogs, landing pages, ambientes de desenvolvimento, APIs, ferramentas internas expostas por meio de um domínio e muitos sites comerciais comuns. Ele oferece aos visitantes o cadeado HTTPS e criptografa credenciais, formulários, sessões e outros tráfegos em trânsito.

A desvantagem é simples: o DV não verifica a empresa legal por trás do site. Um visitante pode ver que sua conexão está criptografada e que o site controla o domínio, mas não recebe da autoridade certificadora uma identidade organizacional verificada separadamente. Para muitas empresas, isso é perfeitamente adequado.

Certificados validados pela organização

Os certificados validados pela organização, ou OV, exigem que a autoridade certificadora verifique tanto o controle do domínio quanto a organização que solicita o certificado. Isso normalmente envolve verificar dados de registro comercial, informações de endereço e um método de contato confirmado.

Os certificados OV são adequados para empresas estabelecidas, portais B2B, sites de agências, plataformas de compras e áreas de clientes nas quais a identidade organizacional tem importância. As informações da organização verificada ficam disponíveis nos detalhes do certificado, o que pode apoiar conversas de due diligence com clientes corporativos ou equipes de segurança.

A criptografia não é mais forte do que a do DV simplesmente porque o certificado é OV. A proteção TLS moderna depende da configuração do servidor, das versões de protocolo compatíveis, dos conjuntos de cifras e do tipo de chave do certificado. O OV acrescenta um processo mais rigoroso de garantia de identidade, não uma criptografia extra mágica. Ainda é útil, apenas não é feitiçaria.

Certificados com validação estendida

Os certificados com validação estendida, ou EV, envolvem o processo de validação mais detalhado. A autoridade certificadora verifica a existência legal da organização, seu status operacional, endereço físico e o solicitante autorizado de acordo com regras definidas.

O EV pode fazer sentido para organizações regulamentadas, serviços financeiros, marcas de comércio eletrônico de alto valor e empresas com requisitos formais de compras ou conformidade. Ele também pode ser solicitado por um parceiro que tenha sua própria lista de verificação de segurança de fornecedores.

Para um site de uma pequena empresa típica, o EV não é automaticamente o melhor investimento. Os navegadores modernos já não exibem a barra de endereço verde altamente visível que antes fazia o EV se destacar para os usuários comuns. Escolha-o quando o processo de validação atender a uma necessidade real de confiança, contrato ou política — não porque você espera um aumento significativo e visível na conversão.

Tipos de certificados SSL por cobertura de domínios

Depois da validação, a cobertura é a próxima decisão. É nessa etapa que as compras de certificados mais costumam dar errado. Um certificado pode ser válido, estar instalado corretamente e ainda assim falhar para um nome de host para o qual nunca foi emitido para proteger.

Certificados de domínio único

Um certificado de domínio único protege um nome de domínio totalmente qualificado, como `www.example.com` ou `app.example.com`. Dependendo da configuração do certificado, o domínio raiz e a versão `www` podem exigir coberturas separadas. Nunca presuma que ambos estão incluídos sem verificar os Nomes alternativos do assunto do certificado, geralmente chamados de SANs.

Os certificados de domínio único são simples e fáceis de gerenciar para um serviço. Eles são adequados quando um aplicativo tem um nome de host dedicado e um ciclo de renovação independente.

Certificados curinga

Um certificado curinga protege um domínio e seus subdomínios de primeiro nível, como `shop.example.com`, `api.example.com` e `status.example.com`, usando um nome como `*.example.com`. Ele é útil para plataformas nas quais subdomínios são adicionados regularmente, incluindo implantações de agências, portais de clientes e ambientes SaaS em expansão.

Há um limite que pega muita gente de surpresa: `*.example.com` não protege `example.com` a menos que o domínio raiz seja incluído separadamente, e não cobre `east.api.example.com`. Os curingas cobrem apenas um nível de subdomínio. Essa não é a situação de DNS mais agradável de descobrir durante um lançamento; por isso, mapeie os nomes de host antes de fazer o pedido.

Os certificados curinga normalmente exigem validação baseada em DNS, pois provar o controle sobre um domínio curinga requer um desafio de DNS. Isso geralmente é simples quando o acesso ao DNS está organizado, mas deve ser considerado antes de selecionar um fluxo de trabalho de renovação automatizada.

Certificados multidomínio ou SAN

Um certificado multidomínio, também chamado de certificado SAN, protege vários nomes de host específicos em um único certificado. Por exemplo, um certificado pode abranger `example.com`, `www.example.com`, `app.example.net` e `customer.example.org`.

Isso é útil para empresas que operam várias marcas, agências que hospedam serviços relacionados de clientes ou equipes que precisam de um certificado controlado para um grupo definido de endpoints. Isso pode reduzir a proliferação de certificados, mas também cria uma dependência compartilhada. Se você substituir ou revogar esse certificado, todos os nomes de host cobertos poderão ser afetados.

Em ambientes grandes, certificados separados por aplicativo, unidade de negócio ou responsável pela renovação podem ser operacionalmente mais seguros. Menos certificados nem sempre significam menos trabalho quando uma alteração tem um amplo raio de impacto.

Como escolher o certificado certo

Comece pelos nomes de host, não pelo nome do produto. Liste todos os domínios públicos, o nome `www`, endpoints de API, portais de administração, endpoints relacionados a e-mail e subdomínios planejados que precisam de TLS. Depois, decida se esses nomes são fixos, se crescem de forma imprevisível ou se são gerenciados por equipes diferentes.

Um certificado DV de domínio único geralmente é suficiente para um site ou endpoint de aplicativo. Um certificado DV curinga costuma ser a resposta mais sensata para um conjunto crescente de subdomínios de primeiro nível. Um certificado SAN funciona bem para uma coleção fixa de nomes em vários domínios. A validação OV ou EV deve fazer parte da decisão quando a verificação de identidade for exigida por clientes, políticas, práticas do setor ou termos contratuais.

Considere também o ambiente por trás do certificado. Se o tráfego terminar em um balanceador de carga, proxy reverso, CDN ou servidor web gerenciado, o certificado deverá ser instalado e renovado no ponto em que o TLS termina. Instalá-lo em um servidor de back-end não ajudará se os visitantes se conectarem primeiro a um proxy com um certificado expirado.

Renovação, automação e risco operacional

Um certificado expirado pode interromper logins, fluxos de checkout, chamadas de API e a confiança do navegador, dando aos clientes pouquíssimo aviso. A renovação do certificado deve ser tratada como uma tarefa operacional, não como um lembrete no calendário que alguém espera notar durante uma sexta-feira movimentada.

Use a renovação automatizada quando o tipo de certificado e o método de validação permitirem. A validação DNS é especialmente útil para certificados curinga, mas a automação precisa de acesso seguro aos registros DNS. Restrinja cuidadosamente essas credenciais e documente quem é responsável por elas. Para a validação baseada em arquivo, confirme que redirecionamentos, regras de cache, firewalls de aplicativos web e pipelines de implantação não bloqueiam o caminho de verificação.

Após a instalação ou renovação, verifique mais do que o cadeado. Verifique a cadeia de certificados, os nomes cobertos, a data de expiração, o comportamento dos redirecionamentos e o endpoint TLS que realmente atende ao tráfego público. O monitoramento deve alertar bem antes da expiração e testar o nome de host usado pelos clientes, não apenas um endereço de servidor interno.

Para equipes que preferem não assumir sozinhas essa carga operacional, o suporte de hospedagem gerenciada pode ajudar com a instalação de certificados, verificações de renovação, validação DNS e monitoramento de serviços. Na kodu.cloud, o objetivo prático não é tornar os certificados empolgantes. É manter os serviços criptografados disponíveis enquanto você cuida do trabalho que paga as contas.

Escolha o menor escopo de certificado que cubra com confiabilidade seus serviços reais, automatize as renovações que puder e mantenha visibilidade suficiente para que uma pessoa identifique as exceções. A segurança funciona melhor quando é entediante da melhor maneira possível.

Andres Saar Engenheiro de Suporte ao Cliente