O que é um certificado SSL/TLS?

Um certificado SSL/TLS é um documento digital que comprova a identidade de um site e permite que seu navegador estabeleça com ele uma conexão HTTPS criptografada. Ele vincula um nome de domínio a uma chave pública e é assinado por uma autoridade certificadora (CA) em que os navegadores já confiam.

Sempre que você vê https:// e um cadeado ou indicador parecido na barra de endereços, um certificado foi verificado uma fração de segundo antes. Os certificados fazem duas coisas ao mesmo tempo: autenticam o servidor, para você saber que está falando com o example.com verdadeiro e não com um impostor, e permitem a criptografia, para que ninguém no caminho da rede possa ler ou alterar o que você envia.

SSL ou TLS: qual é a diferença?

O SSL (Secure Sockets Layer) foi o protocolo original, desenvolvido pela Netscape na década de 1990. Ele foi substituído pelo TLS (Transport Layer Security), e todas as versões do SSL hoje são consideradas inseguras e foram formalmente descontinuadas. O TLS 1.0 e o 1.1 também foram descontinuados, na RFC 8996 (2021), então as conexões modernas usam TLS 1.2 ou TLS 1.3.

Mesmo assim, o nome "certificado SSL" pegou. O certificado em si não está preso a uma versão do protocolo; o mesmo certificado funciona com qualquer versão do TLS. "Certificado SSL", "certificado TLS" e "certificado HTTPS" significam a mesma coisa.

Como funciona o handshake TLS

Antes de qualquer dado de página web ser trocado, o navegador e o servidor realizam um handshake. De forma simplificada, um handshake TLS 1.3 funciona assim:

1. Client hello. O navegador se conecta, normalmente na porta 443, e informa quais versões de TLS e conjuntos de cifras ele aceita. Ele inclui o hostname desejado (pela extensão Server Name Indication, que permite que um mesmo endereço IP hospede vários sites) e a sua parte de uma troca de chaves.
2. Server hello. O servidor escolhe os parâmetros, envia a sua própria parte da chave e apresenta o seu certificado, junto com uma assinatura que comprova que ele possui a chave privada correspondente.
3. Verificação. O navegador confere se o certificado cobre o hostname, se está dentro do prazo de validade e se a cadeia chega até uma CA raiz confiável.
4. Chaves de sessão. Os dois lados derivam as mesmas chaves de sessão simétricas a partir da troca de chaves. Todo o tráfego seguinte é criptografado com elas.

A chave privada nunca sai do servidor. A criptografia de chave pública é usada apenas para autenticar e combinar as chaves; o grosso dos dados é criptografado com cifras simétricas rápidas, como AES-GCM ou ChaCha20-Poly1305. O TLS 1.3 conclui isso em uma única ida e volta, contra duas do TLS 1.2.

O que há dentro de um certificado

Um certificado segue o padrão X.509 e contém, entre outros campos:

• Subject Alternative Names (SANs): os hostnames para os quais o certificado é válido. Os navegadores verificam essa lista, e não o antigo campo Common Name.
• Chave pública: a chave pública RSA ou ECDSA do servidor.
• Emissor: a CA que assinou o certificado.
• Período de validade: as datas "Not Before" e "Not After".
• Número de série e assinatura: um identificador único e a assinatura do emissor sobre tudo o que foi listado acima.

Certificados SAN e wildcard

Um único certificado pode cobrir vários nomes se eles forem listados como SANs, por exemplo example.com, www.example.com e shop.example.com. Um wildcard como *.example.com cobre qualquer rótulo único nesse nível, então vale para www.example.com e api.example.com, mas não para o próprio example.com nem para nomes mais profundos como a.b.example.com. Por isso os certificados wildcard costumam listar o domínio raiz como um SAN adicional.

Certificados DV, OV e EV

Os certificados diferem no rigor com que a CA verificou o solicitante antes de emiti-los:

Os três oferecem exatamente a mesma força de criptografia. A diferença está apenas nas informações de identidade. Os principais navegadores deixaram de exibir o nome da empresa em verde para certificados EV por volta de 2019, então, para a maioria dos sites, um certificado DV é a escolha prática.

A cadeia de confiança

Seu sistema operacional e seu navegador já vêm com um repositório de raízes: uma lista de certificados de CAs raiz em que eles confiam. As CAs raiz raramente assinam certificados de sites diretamente. Em vez disso, assinam certificados intermediários, que assinam o certificado folha (do servidor):

Root CA  (in the browser's trust store)
  └── Intermediate CA  (sent by the server)
        └── www.example.com  (leaf certificate, sent by the server)

O servidor precisa enviar seu certificado folha e os intermediários. O navegador então verifica cada assinatura até chegar a uma raiz em que já confia. Esse arranjo permite que as chaves raiz fiquem offline e bem protegidas. Para evitar emissões indevidas, os certificados publicamente confiáveis também são registrados em logs públicos de Certificate Transparency, e os donos de domínios podem restringir quais CAs podem emitir certificados para eles com um registro DNS CAA, descrito em nosso guia sobre tipos de registros DNS.

Let's Encrypt e a validade dos certificados

O Let's Encrypt, uma CA sem fins lucrativos, popularizou os certificados DV gratuitos. Seus certificados são válidos por 90 dias e foram feitos para ser renovados automaticamente pelo protocolo ACME, com clientes como o Certbot ou recursos embutidos em muitos servidores web e painéis de hospedagem. A maioria dos provedores de hospedagem e CDNs hoje emite e renova certificados sem nenhuma etapa manual.

A validade dos certificados em todo o setor está ficando mais curta. Pela votação SC-081 do CA/Browser Forum, a validade máxima dos certificados TLS publicamente confiáveis está sendo reduzida em etapas, começando em 200 dias a partir de março de 2026 e diminuindo ainda mais nos anos seguintes. O cronograma exato ainda pode mudar, mas a direção é clara: automatize a renovação, porque renovar certificados manualmente será cada vez menos viável.

Erros comuns de certificado e como corrigi-los

Certificado expirado

Os navegadores mostram erros como NET::ERR_CERT_DATE_INVALID. Renove o certificado e recarregue o servidor web. Depois descubra por que a renovação automática falhou, o que muitas vezes é um firewall bloqueando a validação, uma mudança de DNS ou uma tarefa cron quebrada. O relógio incorreto do dispositivo do visitante pode causar o mesmo erro, então confira a data se só um dispositivo reclamar.

Incompatibilidade de nome

Erros como ERR_CERT_COMMON_NAME_INVALID significam que o hostname da barra de endereços não está na lista de SANs do certificado, por exemplo um certificado de www.example.com sendo servido para example.com. Emita o certificado novamente incluindo todos os hostnames que você atende ou redirecione os visitantes para um nome coberto.

Cadeia incompleta

Se o servidor envia apenas o certificado folha, sem os intermediários, alguns navegadores dão um jeito buscando ou guardando em cache a peça que falta, enquanto outros, junto com muitas ferramentas de linha de comando e aplicativos, falham. Configure o servidor com o arquivo de cadeia completa (muitas vezes chamado de fullchain.pem).

Autoassinado ou emissor não confiável

NET::ERR_CERT_AUTHORITY_INVALID significa que a cadeia não leva a uma raiz confiável, normalmente porque o certificado é autoassinado ou vem de uma CA privada. Isso serve para testes internos, mas não para um site público; troque-o por um certificado de uma CA pública. O mesmo erro pode aparecer quando um antivírus ou um proxy corporativo intercepta o HTTPS.

Conteúdo misto

O certificado é válido, mas a página carrega scripts ou imagens por http:// simples. Atualize essas URLs para HTTPS e considere um cabeçalho HSTS para que os navegadores sempre usem HTTPS.

Perguntas frequentes

HTTPS significa que um site é seguro?

Não. HTTPS significa que sua conexão com o site é criptografada e que o site controla o domínio exibido. Sites de phishing podem ter, e têm, certificados DV válidos. Verifique sempre o próprio nome do domínio.

Certificados gratuitos são menos seguros que os pagos?

Não. Um certificado DV gratuito do Let's Encrypt oferece a mesma criptografia que um pago. Certificados pagos podem acrescentar validação de identidade (OV/EV), garantias ou suporte, mas não uma criptografia mais forte.

Quanto tempo dura um certificado SSL?

Os certificados do Let's Encrypt duram 90 dias. As outras CAs públicas seguem o máximo definido pelo CA/Browser Forum, que está sendo reduzido em etapas a partir de 200 dias em 2026. A renovação automática é a abordagem mais segura.

Qual porta o HTTPS usa?

O HTTPS usa a porta TCP 443 por padrão, enquanto o HTTP simples usa a porta 80. Veja nosso guia sobre portas de rede comuns para saber mais.