Developers, engenheiros DevOps, pessoas do Marketing, todos adoram que trabalhemos em bons padrões de segurança, mas pergunte a eles como é que o HTTPS funciona, e eles "ah sei, é só ir aqui no GPTzim, brigado tá?"... depois lêm exatamente o que ChatGPT diz (sem perceber patavina do que acabaram de ler). Eu pergunto "mas você entendeu alguma coisa do que leu?", e a pessoa "sim ué", aí abre novamente o chat, e lê exatamente a mesma frase do início ao fim.

Eu imediatamente:

Neste artigo, vamos dismistificar todo o processo do HTTPS, incluindo o porquê dos certificados TLS (antigamente chamava-se SSL, muitas vezes as pessoas ainda usam esse nome), que é para vocês de uma vez por todas, saberem o que se passa na internet:

---

O que é um Certificado Digital? 📜

É um FICHEIRO. No caso TLS, disponível pra todo mundo ver. Para o HTTPS (HTTP Secure) funcionar, um website precisa de fornecer um certificado digital válido. O browser verifica esse certificado e ambos estabelecem uma session key segura para criptografar conteúdo. No HTTPS, nada de sensitivo é partilhado entre o site e o navegador!

O certificado um ficheiro é um ID digital para um recurso, como um website, mas também é usado em e-mails, etc. O certificado geralmente tem extensão .crt ou .pem. Um certificado pode certificar vários subdomínios, um único certificado pode certificar dionamind.com, e ao mesmo tempo para api.dionamind.com.

Verificar o certificado de um site

A qualquer momento, pode verificar se um certificado é válido clicando no ícone à esquerda da barra de URL do navegador. Veja abaixo:

Os detalhes completos do certificado aparecem na opção "Details". O mais importante é a entidade certificadora (neste caso, chama-se Let's Encrypt), o nome, validade e chave pública.

Analisando o certificado (vamos abrir o ficheiro)

Veja um exemplo de um certificado TLS:

-----BEGIN CERTIFICATE-----
MIIEeTCCAmGgAwIBAgIQBYu72kAv3AdkfWJdJj3qQDANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTUlQgTGFi
ZWxzIElEMSAwHgYDVQQDExdhbWF6b24tdHJ1c3QtY29tLXNydC0xMB4XDTIxMDEy
NjAwMDAwMFoXDTIyMDYwMTIzNTk1OVowSjELMAkGA1UEBhMCVVMxGzAZBgNVBAoM
...
... (Texto em Base64) ...
...
K1B5H5Jy5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5
-----END CERTIFICATE-----

E vocês dizem “Que horror, não entendi nada”.

Os certificados costumam vir encodificados em base64 por compatibilidade, para funcionar em qualquer sistema que entenda texto ASCII. Base64 é apenas uma maneira de tornar o código seguro de ser enviado e interpretado. Não criptografa nada.

---

Muito bem, vamos então descodificar, tornar o Base64 em texto puro, e ver o conteúdo do certificado 🔒:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            10:2a:3d:4c:5e:6f:70:8d:9a:ab:bc:cd:de:ef:01:23:45:67:89:ab
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = PT, O = "AC Portuguesa, SA", CN = AC Portuguesa Root
        Validity
            Not Before: Jan  1 00:00:00 2024 GMT
            Not After : Dec 31 23:59:59 2026 GMT
        Subject: C = PT, ST = Lisboa, L = Lisboa, O = "DIONAMITE LDA", CN = dionamind.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d1:b2:c3:d4:e5:f6:07:18:29:3a:4b:5c:6d:7e:...
                    ... (chave pública muito longa) ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                DNS:dionamind.com, DNS:www.dionamind.com
            X509v3 Subject Key Identifier:
                1A:2B:3C:4D:5E:6F:70:8A:9B:AC:BD:CE:DF:F0:12:34:56:78:9A:BC
            X509v3 Authority Key Identifier:
                keyid:PT:AC:PT:00:CA:FE:BA:BE:CA:FE:BA:BE:CA:FE:BA:BE:CA:FE:BA:BE

    Signature Algorithm: sha256WithRSAEncryption
         a1:b2:c3:d4:e5:f6:07:18:29:3a:4b:5c:6d:7e:8f:90:a1:b2:c3:...
         ... (assinatura digital muito longa) ...

E vocês:

PASITO A PASITO, bora lá! O tal "ficheiro" contém vários elementos essenciais:

• O Domínio ao qual pertence (lógico, por exemplo dionamind.com)
• A Entidade Emissora - uma Autoridade Certificadora reconhecida pelos brwosers, como Google Trust Services, AWS, Let's Encrypt ou DigiCert
• O Período de Validade - importante porque muitos hackers brincam com isto.
• A Chave Pública - SUPER IMPORTANTE - é o que vai ser usado para criptografar comunicações, esta chave é pública e pode ser compartilhada livremente.
• A Assinatura Digital da Autoridade Certificadora - também super importante, vamos ver os detalhes abaixo.
• As Extensões X.509v3, que supostamente são campos opcionais mas adicionam funcionalidades igualmente importantes aos certificados digitais. Reparem como nesta zona vemos que o certificado pemite certificar dionamind.com e www.dionamind.com.

---

A Matemática: Chave Pública & Privada 🔑

Existem dois tipos principais de criptografia no mundo digital: a simétrica e a assimétrica.

• Na criptografia simétrica, a mesma chave é usada para criptografar e descriptografar dados – por exemplo, um arquivo ZIP com senha. São utilizados algoritmos de encriptação como AES (clássico e maravilhoso), ChaCha20 (mais rápido), e TwoFish (ótimo desempenho).
• Na criptografia assimétrica, usamos duas chaves diferentes: uma pública (compartilhada livremente) e uma privada (mantida em segredo). São utilizados algoritmos de encriptação como RSA (mais comum), ECC (mais rápido) e ed25519 (mais rápido).

🔐 O HTTPS usa ambas. As chaves assimétricas são usadas para criar uma chave de sessão temporária simétrica (session key) que, por sua vez, é usada para encriptar/desencriptar dados de maneira muito mais rápida.

---

Nota: é possível criar o nosso par de chave pública-privada utilizando uma ferramenta chamada ssh-keygen:

ssh-keygen -t rsa -b 4096 -C "gandaemail@exemplo.com"

• rsa é apenas o algoritmo de encriptação assimétrica
• 4096 é o tamanho da chave em bits
• -C é um comentário a dizer quem é o dono desta chave (e-mail ou nome)

Normalmente, é criada uma chave privada e logo após, uma pública.

---

Hackear o algoritmo é fácil?

É possível criar uma chave pública através de uma privada. Mas e o contrário? Se eu tiver uma chave pública, posso criar uma privada que dê match? Basicamente... não.

É computacionalmente inviável derivar a chave privada a partir da chave pública. As funções matemáticas usadas (em algoritmos como RSA) funcionam em um sentido único: é fácil gerar a chave pública a partir da privada, mas o processo inverso exigiria um poder computacional tão colossal.

🙋‍♂️ É mais ou menos assim: multiplicar dois números primos grandes (ex: 123456789012345678901127 x 123456789012345678901159) é fácil. Agora, tente fazer o inverso: Fatorar o produto resultante para encontrar os dois primos originais.

• 123456789012345678901127 x 1,
• 123456789012345678901127 x 2,
• 123456789012345678901127 x 3,
• … (nunca mais vamos sair daqui)

Não se esqueçam, no algoritmo AES a chave privada é um número 256 bits. Sabem quanto é o número máximo para 256 bits? Dá:

115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936. (são 78 dígitos)

Agora imaginem a mesma coisa (multiplicar todos os números primos existentes até chegar ao numerozão). Iriamos precisar de testar divisores até a raiz quadrada do número (potencialmente), uma tarefa extremamente morosa para números muito muito muito grandes.

Essa é a essência das keys – fácil para um lado, impossível para o outro. É exatamente essa assimetria matemática que torna o protocolo TLS (Transport Layer Security) confiável e extremamente difícil de ser violado.

---

🤝 Ligação Segura - O Handshake TLS 🤝

(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧ Antes que a comunicação real comece, ocorre um processo chamado Handshake TLS, onde o navegador e o servidor trocam informações para estabelecer um canal seguro.

Existem duas formas principais:

• Autenticação Unilateral: apenas o servidor apresenta o seu certificado. Para a maioria dos casos de uso da Internet pública, o handshake TLS é unilateral. O cliente (navegador) confia no certificado do servidor, o servidor não exige autenticação de cliente com certificado.
• Autenticação Mútua: tanto o navegador quanto o servidor trocam certificados (usado em ambientes de alta segurança). Neste caso, o cliente também tem uma chave pública.

Vamos aprofundar o handshake unilateral passo a passo:

1. O browser liga-se ao servidor e pede o certificado.
2. O certificado contém a chave pública do servidor.
3. O browser valida aquele certificado (verifica CA → cadeia → expirado?).
4. O browser gera uma session key aleatória (o pre-master secret).
5. O browser cifra essa session key com a própria chave pública do servidor.
   • Não esquecer, só a chave privada desencripta coisas encriptadas com a pública!
6. O servidor recebe a session key (encriptada) descifra com a chave privada dele.
7. Agora ambos partilham o mesmo segredo (porque só o servidor conseguia descifrar).
8. A partir desse segredo derivam as chaves simétricas para a ligação.
   • Sim, agora podemos concluir que tanto o servidor como o navegador têm a mesma chave para encriptar e para desencriptar.
9. Comunicação passa a usar AES/ChaCha20, ambas encriptações simétricas!

Reparem, nada de sensitivo foi transmitido em texto legível entre ambos os lados, e apenas o servidor pode desencriptar a session key cifrada enviada pelo navegador.

A Assinatura Digital

Este passo é super importante também.

Nós não podemos nunca saber a chave privada, mas podemos criar um número único que sabemos que pertence obrigatoriamente àquela chave privada. Imagine que diz "este ovo tem exatamente 10 412 521 229 001 099 315 113 242 átomos". Pode assumir que nenhum outro ovo vai ter exatamente esse mesmo número de átomos.

Pronto, os algoritmos de hashing ajudam exatamente nisto, a criar um valor único que pertence a uma chave, a um ficheiro, a um conjunto de coisas.

Neste caso, a assinatura digital (um hash) vai pertencer apenas à chave privada.

Uma assinatura digital é um código criado com a chave privada de alguém. Serve para provar que a pessoa realmente enviou aquilo. O receptor usa a chave pública para confirmar que a assinatura é verdadeira. Se bater certo, também prova que o conteúdo não foi alterado.

Quando um certificado é assinado, não se calcula a assinatura a partir da chave pública mas sim da chave privada (que a CA gera). Assim, qualquer um pode verificar essa assinatura usando a chave pública da CA.

Pasito a pasito:

1. A CA pega no conteúdo do certificado (nome, chave pública do servidor, validade, etc.).
2. Calcula um hash desse conteúdo — um resumo matemático.
3. Usa a sua chave privada para “cifrar” esse hash, produzindo a assinatura digital.
4. A assinatura fica colada ao certificado.

Quando o browser recebe o certificado:

5. Recalcula o hash do conteúdo.
6. Usa a chave pública da CA para “desfazer” a assinatura.
7. Se os dois hashes coincidirem, a assinatura é válida.

---

O DNS, como entra nesta história?

Bom, o certificado precisa de um domínio não é? O domínio utiliza DNS (...fácil).

O DNS (Domain Name System) é o livro de endereços partilhado por vários provedor de serviços da internet. Ao utilizar o serviço "registrar", vários provedores combinam que google.com vai para um IP (endereço) específico.

Como funciona o DNS por si só:

1. O seu navegador pergunta a um DNS Resolver (um servidorzinho de DNS que vem do seu provedor de internet, ou da Google ou do Cloudflare)
2. O resolvedor pergunta a um Root Server: "Onde posso encontrar domínios .games?"
3. O Servidor Raiz responde com o endereço do TLD Server para .games.
4. O TLD Server indica o name server para bullz.games (por exemplo os servidores do Route 53 da AWS).
5. O nameserver do Route 53, finalmente, devolve o endereço IP final do site (18.223.45.67).
   
   Quando compramos um domínio, podemos criar vários tipos de registos DNS para um dado domínio:
   

• A - o clássico. Transforma um domínio dionamind.com num IP 123.123.123.123 para ligações normais na internet.
• AAAA a mesma coisa mas utilizando o protocolo "IPv6".
• MX - funciona para mails. Um mail para maravilhoso@dionamind.com será redirecionado para um IP 234.234.234.234.
• CNAME - Redireciona um domínio para um resultado de outro. Posso apontar dionamind.com para o resultado de google.com. Então, dionamind.com passa a apontar para o IP de google.com. Isto é diferente de um redirecionamento. Redirecionar significa navegar para outra página. Aqui, nós estamos em dionamind.com com o IP de google.com, que vai dar um ganda erro de segurança. O servidor do google vai dizer: TU NÃO ESTÁS A PEDIR GOOGLE, ESTÁS A PEDIR DIONAMIND, QUE RAIOS ESTÁS A FAZER AQUI NO SERVIDOR DA GOOGLE?!
• TXT - Utilizado para fins diversos, nomeadamente para reconhecer a pessoa a querer certificar dionamind.com é sim dona do website.

---

Então, para finalizar, vamos realmente fazer um servidor utilizar todo este protocolo.

Configurar um servidor com um certificado que funciona para um dado domínio. Precisamos de um serviço que fale com uma CA (Entidade Certificadora reconhecida) para gerar um certificado. A entidade faz um teste para perceber que o servidor a pedir o certificado é fidedigno (através de um teste de DNS) e boom!

Para isso, existe uma organização chamada Let's Encrypt, que disponibiliza um programa chamado certbot, que trata de gerar e renovar automaticamente certificados.

---

Vamos criar um certificado num servidor

Depois de compreender o que é o TLS, o próximo passo é aplicá-lo na prática.

• O objetivo é configurar um servidor Nginx num servidor, pode ser um VPS, ou uma instância EC2 (da AWS), ativando HTTPS gratuito através do Let’s Encrypt. O servidor tem de poder receber pedidos da internet nas portas 80 (HTTP) e 443 (HTTPS).

• De seguida, no serviço de DNS (no AWS é o Route 53) aponta o teu domínio para o IP público da instância. Assim que o domínio resolver corretamente (passado umas horas), instala o Certbot, a ferramenta da Let’s Encrypt que gere certificados automaticamente.

• Com o Certbot instalado, executa o comando que configura o certificado para o domínio (por exemplo, bullz.games). Ele valida o domínio, gera o certificado e atualiza automaticamente o ficheiro de configuração do Nginx para redirecionar HTTP → HTTPS.
  Imagens reais do Let's Encrypt a distribuir certificados para os certbot que pedem.

• Por fim, acede a https://teudominio.pt e confirma o cadeado verde 🔒. Parabéns — o teu servidor EC2 está agora protegido com HTTPS e encriptação TLS.

---

Se estivermos a operar na Cloud, temos de saber estes procedimentos para perceber como gerar os nossos próprios certificados. Mas mesmo quem não trabalhe com Cloud, em 2026, é ótimo saber como funciona para gerarmos os nossos próprios certificados. Senão, o SEO do cliente vai pelo cano abaixo.

Para quem não está a utilizar a Cloud e não quer tanta complexidade, serviços de alojamento como a Hostinger tratam de gerar os certificados automaticamente, utilizando certificados de, por exemplo, Let's Encrypt.

Boa, chegamos ao fim da nossa lição! Querem aprender mais?
Sigam-nos no Instagram!