---
title: "O que é TLS e como o HTTPS funciona por baixo do cadeado"
description: "Entenda o que o TLS garante, como é o handshake do TLS 1.3, o que são certificado, cadeia e SNI e como inspecionar tudo com openssl s_client e curl."
url: "https://streethosting.com.br/guias/infraestrutura/o-que-e-tls-https-como-funciona"
category: "infraestrutura"
slug: "o-que-e-tls-https-como-funciona"
datePublished: "2026-11-13"
dateModified: "2026-11-13"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "o que e tls https"
  - "como funciona o https"
  - "handshake tls 1.3"
  - "openssl s_client"
  - "cadeia de certificados incompleta"
  - "o que e sni"
---

# TLS e HTTPS na prática: handshake, certificados e como diagnosticar erros

O cadeado do navegador esconde uma conversa de poucos milissegundos entre cliente e servidor. Conhecer cada etapa ajuda a entender por que um certificado é recusado e a achar a causa com duas linhas de comando.

> **Resposta rápida**
>
> **TLS** é o protocolo que protege a conexão do HTTPS. Ele garante três coisas: sigilo, porque ninguém no caminho lê os dados, integridade, porque ninguém altera o conteúdo sem ser notado, e autenticação, porque o servidor prova que é dono do nome do site por meio de um certificado assinado por uma autoridade confiável. Para ver tudo isso em ação, rode `openssl s_client -connect host:443 -servername host` ou `curl -vI https://host`.

## O que o TLS garante

O HTTP puro viaja em texto aberto: quem está no caminho entre você e o servidor, como uma rede sem fio pública ou um provedor, consegue ler e até modificar o conteúdo. O TLS resolve isso com três garantias.

- **Sigilo:** os dados são cifrados com uma chave que só as duas pontas conhecem. Quem captura o tráfego vê bytes sem sentido.
- **Integridade:** cada bloco leva uma verificação. Se alguém muda um bit no caminho, a conexão detecta e é encerrada.
- **Autenticação:** o servidor apresenta um certificado que prova que ele controla aquele nome de domínio. Sem isso, a cifragem seria inútil, porque você poderia estar falando com um impostor muito bem cifrado.

O que o TLS não faz também importa. O cadeado diz que o canal é seguro e que o nome bate com o certificado, não que o site seja honesto. E o TLS protege o trajeto: se o servidor for invadido, os dados estão expostos lá dentro. Sobre ataques à aplicação, o tema é outro, e está em [o que é um WAF](https://streethosting.com.br/guias/infraestrutura/o-que-e-waf-firewall-aplicacao).

## O handshake do TLS 1.3

Antes de trocar qualquer dado da página, cliente e servidor fazem o handshake: uma conversa curta para combinar as regras e criar uma chave secreta. No TLS 1.3, isso leva uma ida e volta.

1. **ClientHello:** o cliente se apresenta. Diz quais versões e cifras aceita, qual nome de site quer acessar (o SNI) e envia a sua metade de uma troca de chaves, em geral feita com curvas elípticas como a X25519.
2. **ServerHello:** o servidor escolhe a cifra e responde com a sua metade da troca de chaves. Nesse ponto, os dois já calculam, cada um por conta própria, a mesma chave secreta, sem que ela tenha viajado pela rede.
3. **Certificado e prova:** daqui em diante tudo já vai cifrado. O servidor envia o certificado e uma assinatura feita com a sua chave privada, que prova que ele é o dono daquele certificado.
4. **Finished:** cada lado confirma que o handshake inteiro chegou intacto. O cliente verifica o certificado e, se estiver tudo certo, a página começa a ser carregada, já cifrada.

As metades da troca de chaves são temporárias e descartadas depois da conexão, e por isso o TLS 1.3 tem sigilo futuro (forward secrecy): mesmo que a chave privada do servidor vaze amanhã, as conexões gravadas ontem continuam ilegíveis. Em comparação, o TLS 1.2 precisava de duas idas e voltas e ainda aceitava cifras antigas. O 1.3 removeu as fracas e encurtou a espera, o que ajuda principalmente quando a [latência até o servidor](https://streethosting.com.br/guias/infraestrutura/o-que-e-latencia-ping-servidor) é alta, já que cada ida e volta custa o tempo do ping.

## Certificado, cadeia e autoridade

Um certificado é um documento digital que liga um nome de domínio a uma chave pública, assinado por uma autoridade certificadora, a CA. Ele traz o nome ou os nomes cobertos, o prazo de validade, a chave pública e a assinatura de quem o emitiu.

O navegador não conhece o seu servidor, mas conhece um grupo pequeno de autoridades raiz, que vêm instaladas no sistema ou no próprio navegador. A confiança chega até o seu certificado por uma cadeia:

| Elo | Quem é | Quem assina | Onde fica |
| --- | --- | --- | --- |
| Certificado raiz | A autoridade, em si | Ela mesma | Instalado no sistema do cliente |
| Certificado intermediário | Emissor delegado pela raiz | A raiz | Enviado pelo servidor |
| Certificado do site | O seu domínio, também chamado de folha | O intermediário | Enviado pelo servidor |

O servidor precisa enviar o certificado do site e os intermediários. A raiz não precisa ir, porque o cliente já tem. É por isso que o arquivo certo para configurar no Nginx é o `fullchain.pem`, que reúne o certificado e os intermediários, e não só o certificado sozinho. A validade é checada em cada conexão, e o certificado também precisa cobrir o nome acessado. O guia de [certificado SSL com Let's Encrypt e Nginx na VPS](https://streethosting.com.br/guias/vps/certificado-ssl-vps-lets-encrypt-nginx) mostra como emitir e renovar de graça, já com o arquivo certo.

## SNI e vários sites em um IP

Um único servidor, com um único IP, costuma hospedar muitos domínios. O problema é que o handshake acontece antes de o navegador dizer qual site quer, o que é feito depois, dentro do HTTP. Como o servidor saberia qual certificado apresentar?

A resposta é o SNI (Server Name Indication): um campo do ClientHello em que o cliente informa o nome desejado. O servidor lê o nome e escolhe o certificado certo, assim como o Nginx faz com os blocos `server` de cada domínio. Quando o SNI falta, o servidor entrega o certificado padrão, que quase nunca é o do site pedido, e o navegador acusa nome errado. O SNI viaja sem cifra no TLS 1.3 comum, então quem observa a rede vê o nome do site, mesmo sem ver o conteúdo. Existe uma extensão que cifra esse campo, a ECH, mas ela depende de suporte nas duas pontas.

Por isso, ao testar um servidor que hospeda vários sites, você sempre precisa informar o nome. É o que a opção `-servername` do openssl faz, na próxima seção. Esse cenário aparece em [Nginx como proxy reverso na VPS](https://streethosting.com.br/guias/vps/configurar-nginx-reverse-proxy-vps), onde cada domínio tem o seu certificado.

## Como inspecionar com openssl e curl

O `openssl s_client` faz o handshake e mostra tudo o que aconteceu. Troque `exemplo.com.br` pelo seu domínio:

```
# conexão completa, com a cadeia que o servidor envia
openssl s_client -connect exemplo.com.br:443 -servername exemplo.com.br -showcerts </dev/null

# só os dados principais do certificado do site
openssl s_client -connect exemplo.com.br:443 -servername exemplo.com.br </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
```

O `</dev/null` fecha a entrada para o comando terminar sozinho em vez de ficar esperando você digitar. No relatório, três pontos merecem atenção:

- **Certificate chain:** lista os certificados enviados. Deve ter o do site e os intermediários. Se aparece só um, a cadeia está incompleta.
- **Verify return code:** no fim da saída. Vale `0 (ok)` quando a verificação passou. Outros códigos explicam o problema, como 20 ou 21 para cadeia incompleta e 10 para certificado expirado.
- **Protocol e Cipher:** a versão negociada, como `TLSv1.3`, e a cifra escolhida.

Já o curl mostra a mesma negociação de um jeito mais curto, junto com a resposta HTTP:

```
curl -vI https://exemplo.com.br
```

Nas linhas que começam com asterisco, o curl informa a versão do TLS, a cifra, o emissor, as datas de validade e o resultado da verificação, e depois vêm os cabeçalhos da resposta. Se o certificado for recusado, o curl termina com uma mensagem de erro clara, e a opção `-k` faz ele ignorar o erro só para você confirmar que o resto funciona. Use apenas para diagnosticar, nunca em um script que lida com dados reais.

> **Dica**
>
> Para testar um servidor antes de o DNS apontar para ele, use `curl -vI --resolve exemplo.com.br:443:IP_DA_VPS https://exemplo.com.br`. O curl faz a conexão no IP que você indicou, mas envia o nome certo no SNI e no cabeçalho Host. O apontamento do domínio está no guia de [como apontar domínio para a VPS](https://streethosting.com.br/guias/vps/apontar-dominio-vps-registro-dns).

## Erros comuns

| Sintoma | Causa provável | Como confirmar | Correção |
| --- | --- | --- | --- |
| unable to get local issuer certificate, ou verify error 20 e 21 | Cadeia incompleta: o servidor não envia o intermediário | Certificate chain mostra um único certificado | Configurar o fullchain.pem em vez do certificado sozinho |
| certificate has expired, ou verify error 10 | O certificado passou da validade, em geral por renovação que falhou | A linha notAfter está no passado | Renovar, e conferir o temporizador ou o cron da renovação |
| no alternative certificate subject name matches | O nome acessado não está no certificado | Comparar o domínio com a lista do subjectAltName | Emitir um certificado que cubra o nome, inclusive o www |
| Certificado de outro site | SNI ausente ou bloco do servidor sem o nome certo | Repetir o teste com e sem o -servername | Criar o bloco do domínio no Nginx com o certificado dele |
| Certificate is not yet valid | Relógio do cliente ou do servidor com data errada | Comparar o resultado do comando date com a hora real | Corrigir o relógio e ativar a sincronização automática |

O erro de relógio engana muito porque aparece como problema de certificado, mas a causa é a data do aparelho. Em um servidor, a sincronização de horário é a correção, e o guia de [NTP e horário correto no servidor Linux](https://streethosting.com.br/guias/infraestrutura/configurar-ntp-horario-correto-servidor-linux) mostra como.

> **Atenção**
>
> Cadeia incompleta é traiçoeira porque o seu navegador pode abrir o site normalmente: ele completa a cadeia sozinho, com intermediários que já viu antes ou que baixa na hora. Já o curl, aplicativos de celular, integrações e outros servidores não fazem isso e falham. Sempre teste também com o openssl ou o curl, e não só no navegador.

## Seu próprio servidor web

Configurar TLS direito significa instalar o certificado, apontar o Nginx para o arquivo certo e cuidar da renovação, tudo com acesso ao servidor. Em uma [VPS da StreetHosting](https://streethosting.com.br/vps) você tem acesso root, então instala o Nginx e o certbot, e usa o openssl e o curl deste guia direto no servidor. Todas ficam em São Paulo, com IPv4 dedicado e AntiDDoS incluso. A VPS Xeon começa em R$ 26,00 por mês, com 2 vCPU, 2 GB de RAM e 20 GB NVMe, o suficiente para um site com HTTPS.

## Perguntas frequentes

### Qual a diferença entre HTTPS, TLS e SSL?

HTTPS é o HTTP rodando dentro de uma conexão TLS. O TLS é o protocolo que cifra e autentica essa conexão. SSL é o nome do protocolo antigo que o TLS substituiu, e hoje todas as versões do SSL são consideradas inseguras. Quando alguém diz certificado SSL, quase sempre quer dizer certificado para TLS.

### O que o cadeado do navegador garante?

Garante que a conexão é cifrada e que o servidor provou controlar o nome do site. Não garante que o site seja honesto: um site de golpe também pode ter certificado válido. O cadeado fala do canal, não da boa fé de quem está do outro lado.

### Para que serve o SNI?

O SNI é o campo em que o cliente informa o nome do site que quer acessar, logo no início do handshake. Com ele, um servidor com um único IP escolhe o certificado certo para cada domínio. Sem SNI, o servidor só conseguiria apresentar um certificado por IP.

### Por que o navegador mostra erro de certificado se o certificado está válido?

As causas mais comuns são cadeia incompleta, em que o servidor não envia o certificado intermediário, o nome do site que não consta no certificado e o relógio do aparelho com data errada. Rodar openssl s_client mostra qual desses é o caso.

### O TLS 1.3 é mais rápido que o TLS 1.2?

Em geral sim. O TLS 1.3 completa o handshake em uma ida e volta, enquanto o 1.2 usa duas, e retoma sessões antigas com ainda menos espera. Também removeu cifras fracas, o que torna a configuração padrão mais segura.

## Guias relacionados

- [Certificado SSL na VPS com Let's Encrypt e Nginx](https://streethosting.com.br/guias/vps/certificado-ssl-vps-lets-encrypt-nginx.md)
- [Como configurar o Nginx como reverse proxy na VPS](https://streethosting.com.br/guias/vps/configurar-nginx-reverse-proxy-vps.md)
- [Como configurar NTP e horário correto no servidor Linux](https://streethosting.com.br/guias/infraestrutura/configurar-ntp-horario-correto-servidor-linux.md)
- [Como apontar domínio para VPS: registros A, AAAA e CNAME](https://streethosting.com.br/guias/vps/apontar-dominio-vps-registro-dns.md)
- [O que é WAF e quando usar em sites e APIs](https://streethosting.com.br/guias/infraestrutura/o-que-e-waf-firewall-aplicacao.md)

## Produtos citados

- https://streethosting.com.br/vps

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "TLS e HTTPS na prática: handshake, certificados e como diagnosticar erros",
    "name": "O que é TLS e como o HTTPS funciona por baixo do cadeado",
    "abstract": "O cadeado do navegador esconde uma conversa de poucos milissegundos entre cliente e servidor. Conhecer cada etapa ajuda a entender por que um certificado é recusado e a achar a causa com duas linhas de comando.",
    "description": "Entenda o que o TLS garante, como é o handshake do TLS 1.3, o que são certificado, cadeia e SNI e como inspecionar tudo com openssl s_client e curl.",
    "datePublished": "2026-11-13",
    "dateModified": "2026-11-13",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/infraestrutura/o-que-e-tls-https-como-funciona"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Qual a diferença entre HTTPS, TLS e SSL?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "HTTPS é o HTTP rodando dentro de uma conexão TLS. O TLS é o protocolo que cifra e autentica essa conexão. SSL é o nome do protocolo antigo que o TLS substituiu, e hoje todas as versões do SSL são consideradas inseguras. Quando alguém diz certificado SSL, quase sempre quer dizer certificado para TLS."
        }
      },
      {
        "@type": "Question",
        "name": "O que o cadeado do navegador garante?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Garante que a conexão é cifrada e que o servidor provou controlar o nome do site. Não garante que o site seja honesto: um site de golpe também pode ter certificado válido. O cadeado fala do canal, não da boa fé de quem está do outro lado."
        }
      },
      {
        "@type": "Question",
        "name": "Para que serve o SNI?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "O SNI é o campo em que o cliente informa o nome do site que quer acessar, logo no início do handshake. Com ele, um servidor com um único IP escolhe o certificado certo para cada domínio. Sem SNI, o servidor só conseguiria apresentar um certificado por IP."
        }
      },
      {
        "@type": "Question",
        "name": "Por que o navegador mostra erro de certificado se o certificado está válido?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "As causas mais comuns são cadeia incompleta, em que o servidor não envia o certificado intermediário, o nome do site que não consta no certificado e o relógio do aparelho com data errada. Rodar openssl s_client mostra qual desses é o caso."
        }
      },
      {
        "@type": "Question",
        "name": "O TLS 1.3 é mais rápido que o TLS 1.2?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Em geral sim. O TLS 1.3 completa o handshake em uma ida e volta, enquanto o 1.2 usa duas, e retoma sessões antigas com ainda menos espera. Também removeu cifras fracas, o que torna a configuração padrão mais segura."
        }
      }
    ]
  }
]
```