Guia de tipos de certificados SSL

Publicado em 26 de junho de 2026

A escolha do certificado geralmente não é o problema. O problema é combiná-lo com o site, a equipe e a quantidade de risco operacional que você quer assumir. Este guia de tipos de certificados SSL vai manter essa parte sob controle, para que você não acabe comprando validação extra de que não precisa ou, pior, implantando um certificado que não cobre o nome de host que sua aplicação realmente usa.

SSL ainda é o nome comum que as pessoas usam, embora certificados modernos protejam o tráfego com TLS. Os navegadores exibem o cadeado na conexão, os usuários veem HTTPS, e seu servidor comprova a identidade por meio de um certificado assinado. O serviço volta a ficar tranquilo quando isso é configurado corretamente. Se não for, você recebe avisos do navegador, chamadas de API com falha, páginas de checkout quebradas e uma fila de suporte que de repente fica muito movimentada.

O que este guia de tipos de certificados SSL realmente cobre

Há duas perguntas diferentes escondidas na compra de certificados. A primeira é o nível de validação — quanto a autoridade certificadora verifica antes de emitir o certificado. A segunda é a cobertura — quantos domínios ou subdomínios o certificado protege. Elas estão relacionadas, mas não são a mesma coisa.

Se você separar essas duas decisões, toda a categoria fica mais fácil. A validação informa aos usuários e sistemas quem você é. A cobertura informa à sua infraestrutura quais nomes estão protegidos.

Níveis de validação: DV, OV e EV

Domain Validation, ou DV

Certificados DV são a opção mais rápida e mais comum. A autoridade certificadora verifica apenas se você controla o domínio. Essa verificação geralmente acontece por e-mail, registro DNS ou por um arquivo colocado no servidor web.

Para muitos sites, isso é suficiente. Blogs, sites institucionais simples, landing pages, ferramentas internas protegidas por login e muitos front ends de SaaS funcionam perfeitamente bem com DV. A criptografia é forte. A compatibilidade com navegadores é boa. A configuração é rápida. Se seu principal requisito é transporte seguro e nenhum aviso do navegador, o DV resolve.

A contrapartida é a identidade. Um certificado DV não informa muito aos visitantes sobre a entidade legal por trás do site. Para uma empresa menor que já tem confiança por meio da marca, sinais do provedor de pagamento ou uma base de clientes estabelecida, isso pode ser aceitável. Para um site em que a confiança pública é frágil, talvez nem tanto.

Organization Validation, ou OV

Certificados OV adicionam verificação empresarial ao controle do domínio. A autoridade certificadora verifica a própria organização, geralmente em registros públicos ou documentação enviada. Isso significa mais trabalho administrativo e emissão mais lenta, mas o certificado contém informações de identidade mais fortes.

OV tende a fazer sentido para sites de empresas, portais, painéis de clientes e serviços B2B em que demonstrar que uma organização real está por trás do endpoint importa. Também é um meio-termo razoável para agências que gerenciam projetos de clientes que precisam de mais do que a validação mínima, sem entrar na opção com maior atrito.

O limite prático é que a maioria dos usuários comuns não vai inspecionar os detalhes do certificado. Eles não vão aplaudir porque você comprou OV. O valor é mais operacional e reputacional do que visual. Equipes de segurança, equipes de compras e clientes atentos à conformidade podem se importar. Compradores aleatórios, geralmente não.

Extended Validation, ou EV

Certificados EV envolvem o processo de validação mais profundo. A autoridade certificadora verifica a existência legal, a presença operacional e o controle do domínio usando verificações mais rigorosas. Historicamente, o EV tinha um efeito mais forte na interface do navegador. Isso é menos dramático hoje do que já foi, então a decisão de compra não deve se basear em antigas lembranças de marketing.

EV é melhor para casos em que a garantia formal de identidade importa — serviços financeiros, empresas regulamentadas, algumas plataformas voltadas a empresas e organizações com requisitos explícitos de conformidade ou confiança. Se seu fluxo jurídico ou de compras espera a validação documentada mais alta, EV ainda pode ser a resposta correta.

Mas EV não é um escudo mágico. Ele não criptografa o tráfego melhor do que DV ou OV. Ele não impede código de aplicação ruim, senhas fracas ou backups expirados. Ele prova mais sobre quem é dono do serviço, não que o serviço em si foi projetado perfeitamente. Nenhum certificado consegue corrigir um servidor de origem mal configurado passando por um dia estranho.

Tipos de cobertura: domínio único, wildcard e SAN

Depois que a validação está clara, a próxima pergunta é a cobertura de nomes de host.

Certificados de domínio único

Um certificado de domínio único protege um nome de domínio totalmente qualificado. Se ele for emitido para www.example.com, isso não cobre automaticamente example.com, a menos que ambos os nomes estejam incluídos. Isso pega as pessoas desprevenidas com mais frequência do que deveria.

Certificados de domínio único funcionam bem quando o ambiente é simples. Um site, um nome de host, um propósito claro. Eles são fáceis de gerenciar e muitas vezes são a opção mais barata. Para um site de pequena empresa ou um endpoint de aplicação focado, esse geralmente é o caminho mais limpo.

Certificados wildcard

Um certificado wildcard protege um nível de subdomínios sob um domínio, como anything.example.com. Isso pode cobrir app.example.com, shop.example.com e api.example.com com um único certificado.

Isso é útil quando você cria subdomínios regularmente ou gerencia muitos serviços sob o mesmo domínio pai. Agências, operadores de SaaS e equipes de plataformas internas muitas vezes preferem certificados wildcard porque eles reduzem o trabalho de emissão repetida.

A contrapartida é o escopo. Um wildcard não cobre o domínio raiz, a menos que ele seja incluído explicitamente, e não cobre níveis mais profundos como test.api.example.com, a menos que essa estrutura exata seja tratada separadamente. Além disso, como um certificado pode cobrir muitos serviços, o manuseio da chave privada se torna mais sensível. Se essa chave for copiada de forma generosa demais, a conveniência começa a se tornar uma responsabilidade.

Certificados SAN ou multidomínio

SAN significa Subject Alternative Name. Esses certificados podem proteger vários nomes de host distintos em um único certificado, até mesmo em domínios diferentes. Por exemplo, um certificado SAN pode cobrir example.com, example.net, shop.example.com e clientportal.org.

Isso costuma ser a melhor opção para empresas que operam várias propriedades de marca, ambientes Microsoft, infraestrutura compartilhada ou conjuntos de domínios gerenciados por agências com previsibilidade. É organizado do ponto de vista de gestão e, em alguns ambientes, simplifica as renovações.

Mas certificados SAN também precisam de planejamento. Se os domínios mudam com frequência, se clientes entram e saem, ou se serviços não relacionados demais dependem de um único certificado, a conveniência de gestão pode se transformar em acoplamento operacional. Uma alteração em um nome de host pode forçar a reemissão e a reimplantação para todos. Isso não é um desastre, apenas algo em que é melhor não entrar no piloto automático.

Qual tipo de certificado SSL se encaixa em qual caso de uso?

Para um site básico, site institucional simples ou pequena loja, DV com cobertura de domínio único geralmente é suficiente. Ele protege o tráfego, é implantado rapidamente e mantém o custo baixo.

Para uma empresa em crescimento com vários subdomínios, DV wildcard costuma ser o ponto ideal prático. Você obtém ampla cobertura sem papelada pesada de validação. Isso funciona especialmente bem para stacks de aplicações com subdomínios separados para web, API, staging e portais de clientes.

Para serviços B2B, portais de parceiros e sistemas empresariais voltados a clientes, OV muitas vezes merece consideração. Não porque os navegadores façam um grande espetáculo disso, mas porque alguns compradores e partes interessadas internas querem uma identidade organizacional mais clara.

Para setores regulamentados, instituições públicas ou contratos corporativos com requisitos formais de confiança, EV ainda pode ser a decisão certa. A validação extra não é apenas uma questão de aparência. Às vezes, é simplesmente o que o ambiente espera.

Para agências e equipes de infraestrutura que lidam com muitos nomes de host, certificados SAN podem reduzir a sobrecarga administrativa. Para equipes que provisionam subdomínios com frequência, wildcard pode ser mais fácil. Se ambos os padrões existem, depende de que tipo de expansão desordenada você tem — muitas marcas ou muitos subdomínios.

Erros comuns ao escolher tipos de certificados

O primeiro erro comum é comprar com base na psicologia de selos, em vez de requisitos reais. Validação mais forte não significa criptografia mais forte. Significa mais verificações de identidade.

O segundo é esquecer o planejamento de nomes de host. As equipes protegem o site principal, mas esquecem www, o subdomínio da API ou o redirecionamento do domínio raiz. Então metade da stack fica criptografada e a outra metade fica causando problemas.

O terceiro é ignorar o fluxo de renovação e implantação. Um certificado não é uma compra única com paz permanente depois. Ele deve ser renovado, instalado e, às vezes, reemitido quando há mudanças de infraestrutura. Se a equipe que gerencia o servidor já está sobrecarregada, escolher um certificado com mais sobrecarga manual pode não ser a ideia mais gentil.

O quarto é compartilhar chaves privadas wildcard de forma ampla demais entre ambientes. A conveniência é boa até que dev, staging e produção tenham todos o mesmo material sensível em lugares que ninguém acompanha totalmente. Isso não é o primo da situação de DNS mais bonita, mas fica sob controle se for tratado cedo.

Uma forma prática de decidir

Comece pelos requisitos de confiança. Se nenhum cliente, regulador ou processo de compras pede validação de identidade empresarial, DV provavelmente é suficiente. Depois, mapeie seus nomes de host. Se você tem um site, escolha domínio único. Se você tem muitos subdomínios sob um único domínio pai, considere wildcard. Se você tem vários domínios não relacionados, avalie SAN.

Depois disso, pense nas operações. Quem renova o certificado? Onde a chave privada é armazenada? Quantos servidores ou contêineres precisam de implantação? Sua arquitetura vai mudar em seis meses? Um certificado um pouco mais caro que se encaixa bem no seu ambiente costuma ser mais barato do que um de baixo custo que causa trabalho manual repetido.

Para empresas que usam infraestrutura gerenciada, é aqui que um provedor como a kodu.cloud pode remover parte do estresse. Não fazendo a lógica de certificados desaparecer, mas impedindo que implantação, renovações e manuseio no lado do servidor se transformem em um hobby das 2 da manhã. passatempo.

Consideração final

O tipo de certificado certo é aquele que cobre seus nomes de host reais, atende às suas necessidades de confiança e não cria ruído operacional extra para sua equipe. Se a configuração do certificado permite que seus usuários se conectem com segurança e permite que você durma um pouco melhor, isso já é uma engenharia muito boa.

Andres Saar Engenheiro de Atendimento ao Cliente