Todos os cursos > Tecnologia, Informática e Programação > Servidores Web e Redes de computadores ::

AWS para Iniciantes: Certificados e HTTPS com ACM para navegar com segurança

Capítulo 8

Tempo estimado de leitura: 8 minutos

Por que HTTPS é necessário (e o que o certificado faz)

HTTPS é HTTP “por dentro” de uma conexão criptografada (TLS). Ele é necessário porque protege o tráfego entre o navegador e o seu site contra interceptação e adulteração. Sem HTTPS, alguém na mesma rede (Wi‑Fi público, provedor, roteadores comprometidos) pode capturar dados ou modificar respostas.

O que o certificado digital resolve

Criptografia: o navegador e o servidor negociam chaves para cifrar o tráfego. Isso impede que terceiros leiam o conteúdo (login, formulários, cookies, páginas).
Integridade: garante que o conteúdo não foi alterado no caminho (protege contra “injeção” de scripts e alterações de página em trânsito).
Confiança/identidade: o certificado prova que o site que você acessou é realmente o dono do domínio (ex.: www.seudominio.com). O navegador valida a cadeia de confiança até uma Autoridade Certificadora (CA) reconhecida.

Na prática, um certificado TLS associa um domínio a uma chave pública. O servidor usa a chave privada correspondente para provar que controla aquele certificado durante a negociação TLS.

O que acontece quando não há HTTPS

O navegador pode exibir “Não seguro” (especialmente em páginas com formulário).
Cookies podem ser expostos e sessões podem ser sequestradas.
Conteúdo pode ser alterado em trânsito (ex.: inserir anúncios maliciosos).
APIs modernas e recursos do navegador podem exigir contexto seguro (HTTPS).

ACM (AWS Certificate Manager): visão prática

O AWS Certificate Manager (ACM) emite e gerencia certificados TLS. Para iniciantes, o ponto mais importante é: certificados públicos do ACM são feitos para serem anexados a serviços gerenciados (por exemplo, camada de entrega como CloudFront e balanceadores). Em geral, você não instala um certificado do ACM diretamente dentro de uma instância EC2; em vez disso, você termina o TLS em um serviço gerenciado e encaminha o tráfego para o seu backend.

Benefícios do ACM

Emissão e renovação automática (quando usado com serviços integrados).
Integração com serviços de entrega e balanceamento.
Reduz risco operacional (menos chance de expirar certificado em produção).

Passo a passo: solicitar um certificado no ACM e validar por DNS

O método recomendado é validação por DNS, porque é estável e não depende de e-mail/caixas postais do domínio.

1) Planeje os nomes (domínios) que o certificado deve cobrir

Antes de solicitar, liste exatamente os FQDNs (nomes completos) que serão acessados:

Continue em nosso aplicativo e ...

Ouça o áudio com a tela desligada
Ganhe Certificado após a conclusão
+ de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

seudominio.com (apex/root)
www.seudominio.com
Opcional: subdomínios adicionais (ex.: app.seudominio.com)

Você pode usar um certificado com SANs (Subject Alternative Names) para cobrir vários nomes, ou um wildcard (*.seudominio.com) quando fizer sentido. Para iniciantes, geralmente www + raiz já resolve.

2) Solicite o certificado no ACM

Acesse o console do AWS Certificate Manager (ACM).
Clique em Request a certificate (Solicitar certificado).
Escolha Public certificate.
Em Fully qualified domain name, informe o domínio (ex.: www.seudominio.com).
Em Add another name, inclua o domínio raiz (seudominio.com) se você também for usá-lo.
Em Validation method, selecione DNS validation.
Finalize em Request.

Após solicitar, o certificado ficará como Pending validation até você provar que controla o domínio.

3) Valide por DNS (criando o registro CNAME)

O ACM vai gerar um ou mais registros DNS do tipo CNAME. Você precisa publicá-los na zona DNS do seu domínio (por exemplo, no Route 53 ou no provedor que hospeda seu DNS).

No ACM, abra o certificado recém-criado.
Na seção Domains / Domain validation, localize o(s) CNAME(s) sugeridos.
Crie o registro CNAME no seu DNS exatamente como informado (nome e valor).

Se você usa Route 53, normalmente existe um botão como Create records in Route 53 para automatizar a criação. Se seu DNS está fora da AWS, copie e cole os valores no painel do provedor.

4) Aguarde a emissão

Após o CNAME estar publicado e propagado, o ACM muda o status para Issued. Isso pode levar de poucos minutos até mais tempo dependendo de propagação DNS.

Erros comuns na validação por DNS

CNAME criado na zona errada: o domínio www pode estar em uma zona, e o domínio raiz em outra (ou você pode ter múltiplas zonas similares). Confirme que está editando a zona autoritativa correta.
Registro com nome duplicado/alterado: alguns provedores adicionam automaticamente o sufixo do domínio; verifique como o provedor exibe o “Name/Host”.
Proxy/CDN do provedor de DNS: se o provedor tiver opção de “proxy” (ex.: nuvem laranja), desative para o CNAME de validação (ele deve ser um CNAME DNS puro).
TTL alto e pressa: TTL alto pode atrasar mudanças. Para validação, TTL baixo ajuda.

Como o certificado é usado na camada de entrega (quando aplicável)

Na AWS, o uso mais comum do certificado do ACM é na “borda” (edge) ou na frente do seu site, onde o TLS é encerrado e o tráfego segue para o backend.

Cenário típico: CloudFront na frente do site

O navegador acessa https://www.seudominio.com.
O CloudFront apresenta o certificado do ACM para o domínio.
O CloudFront busca o conteúdo no origin (por exemplo, um endpoint HTTP/HTTPS do seu servidor ou bucket/serviço) e entrega ao usuário.

Nesse cenário, você configura o domínio (CNAME/alias) para apontar para a distribuição do CloudFront e associa o certificado do ACM ao CloudFront em Alternate domain name (CNAME) e Custom SSL certificate.

Cenário típico: Load Balancer (ALB) na frente do backend

O navegador acessa https://seudominio.com.
O ALB termina TLS usando o certificado do ACM em um listener 443.
O ALB encaminha para targets (instâncias/serviços) geralmente via HTTP interno (ou HTTPS, se você quiser criptografia também no trecho interno).

Esse modelo é útil quando você quer tirar a responsabilidade de TLS do servidor e centralizar no balanceador.

Observação importante sobre região (para evitar confusão)

Alguns serviços exigem que o certificado esteja em uma região específica. Um exemplo comum é o CloudFront, que usa certificados do ACM na região us-east-1. Se você solicitar o certificado em outra região, pode não aparecer na lista ao configurar o serviço. Verifique o requisito do serviço antes de solicitar.

Boas práticas essenciais

1) Renovação automática no ACM

Certificados públicos do ACM são renovados automaticamente desde que a validação DNS continue válida (o CNAME de validação deve permanecer publicado) e o certificado esteja associado a um serviço integrado.
Não apague os registros CNAME de validação após emitir o certificado. Eles são usados para renovações futuras.

2) Evite certificados autoassinados em produção

Certificados autoassinados geram alertas no navegador e quebram a confiança do usuário.
Mesmo que criptografem, não fornecem confiança pública (qualquer um pode “assinar” um certificado para qualquer nome).
Use autoassinado apenas para testes internos controlados, nunca para o site público.

3) Mantenha o domínio bem configurado

Garanta que o domínio que você colocou no certificado é exatamente o que o usuário acessa (incluindo www vs raiz).
Configure redirecionamento para um único host canônico (ex.: sempre redirecionar http → https e seudominio.com → www.seudominio.com, ou o inverso).
Evite misturar conteúdo HTTP dentro de páginas HTTPS (mixed content), pois isso causa avisos e pode bloquear recursos.

4) Forçar HTTPS e boas configurações de TLS

Habilite redirecionamento de HTTP para HTTPS na camada de entrega (CloudFront/ALB) quando possível.
Use políticas modernas de TLS (desabilitando versões antigas quando o serviço permitir).
Considere habilitar HSTS após confirmar que tudo funciona em HTTPS (isso força navegadores a usarem HTTPS nas próximas visitas). Use com cuidado, pois pode “travar” o domínio em HTTPS.

Checklist de verificação (antes de considerar “pronto”)

Item	Como verificar	Resultado esperado
Certificado emitido	No ACM, status do certificado	Issued
Domínio validado por DNS	No ACM, domínio(s) com validação OK; no DNS, CNAME(s) presentes	Validação concluída e CNAME mantido
Certificado associado à camada de entrega	No serviço (CloudFront/ALB), conferir certificado selecionado	Domínio alternativo configurado e certificado correto anexado
Navegação sem alertas	Acessar `https://seudominio.com` e `https://www.seudominio.com`	Sem aviso de segurança; cadeado/indicador seguro
HTTP redireciona para HTTPS	Acessar `http://` e observar	Redireciona para `https://`
Sem mixed content	DevTools do navegador (Console/Network)	Nenhum recurso carregado via HTTP
Entendimento do impacto do HTTPS	Revisar: criptografia + integridade + confiança	Você sabe explicar o que o certificado garante e o que não garante

Dica rápida de diagnóstico (quando algo dá errado)

Se o certificado não emite: confira o CNAME de validação, a zona DNS correta e a propagação.
Se o navegador acusa domínio diferente: o certificado anexado não cobre o host acessado (faltou www ou raiz) ou o serviço está usando outro certificado.
Se aparece alerta mesmo com HTTPS: verifique mixed content e se o domínio realmente aponta para a distribuição/balanceador correto.

Agora responda o exercício sobre o conteúdo:

Qual prática ajuda a garantir a renovação automática de um certificado público emitido pelo ACM ao longo do tempo?

Você acertou! Parabéns, agora siga para a próxima página

Você errou! Tente novamente.

O ACM renova certificados públicos automaticamente quando a validação DNS continua válida (CNAME mantido) e o certificado está em uso por um serviço integrado. Remover o CNAME pode impedir renovações futuras.