Tutorial de Ubuntu 26.04 / Emita HTTPS e verifique renovação e validade

Configure o HTTPS apenas após preparar um domínio que você controla e sua rota de validação. Emissão do certificado, certificado realmente fornecido externamente, renovação programada e monitoramento de expiração são verificações separadas.

Verifique os pré-requisitos de domínio e HTTP público

O site .test em loopback na porta 8080 da lição de Nginx (em inglês) não é elegível para emissão de certificado público. Prepare um site real cujo DNS, server_name do Nginx, raiz do documento e resposta na porta 80 estejam corretos. Se existir um registro AAAA, a rota IPv6 também deve funcionar.

Insira o domínio real para as consultas a seguir. Instale o pacote dnsutils do Ubuntu se o dig não estiver presente. Verifique DNS e HTTP a partir de uma rede separada e revise juntos as regras de host, roteador e nuvem.

read -r -p "Domain you control: " domain
dig +short A "$domain"
dig +short AAAA "$domain"
curl -I "http://$domain/"

Complete primeiro o site HTTP do domínio real

Esta seção tem como alvo um servidor web Ubuntu separado, acessado em um endereço público através de um domínio que você controla. A VM da rede exclusiva de host no laboratório de IP estático não é diretamente acessível pela internet. Sem hospedagem/DNS pública, adie a emissão ou escolha separadamente um plugin oficial DNS-01 e um armazenamento de credenciais adequado.

Prepare o Nginx/curl e aponte o registro A do domínio para o endereço IPv4 público. Um AAAA divulgado também precisa de uma rota IPv6 funcionando. Salve o script completo como ~/prepare-public-http.sh, escolhendo um nome ainda não ocupado, e execute bash ~/prepare-public-http.sh SEU_DOMINIO. Ele aceita nomes de host ASCII comuns; use punycode verificado para um domínio internacionalizado. Ele para nos caminhos de laboratório existentes. Sua verificação sintática é básica e não comprova a propriedade nem a validade completa do domínio; confirme ambas antes de executá-lo e não faça alterações simultâneas no servidor.

set -eu
if [ "$#" -ne 1 ]; then
    printf 'Usage: bash prepare-public-http.sh YOUR_DOMAIN\n' >&2; exit 2
fi
domain=$(printf '%s' "$1" | tr '[:upper:]' '[:lower:]')
if [[ ! "$domain" =~ ^([a-z0-9]([a-z0-9-]*[a-z0-9])?\.)+[a-z]([a-z0-9-]*[a-z0-9])?$ ]]; then
    printf 'Use a valid ASCII hostname you control.\n' >&2; exit 2
fi
case "$domain" in
    *.test|*.invalid|*.localhost|*.example|example.com|*.example.com)
        printf 'Use your real domain, not an example name.\n' >&2; exit 2 ;;
esac
site=/etc/nginx/sites-available/ubuntu-course-public
enabled=/etc/nginx/sites-enabled/ubuntu-course-public
root_dir=/srv/ubuntu-course-public
for path in "$site" "$enabled" "$root_dir"; do
    if sudo test -e "$path" || sudo test -L "$path"; then
        printf 'Existing lab path: %s; stop and inspect.\n' "$path" >&2; exit 1
    fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-public.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
sudo install -d -m 0755 "$root_dir"
printf 'public-http-lab\n' | sudo sh -c 'set -C; cat > "$1/index.html"' sh "$root_dir"
sudo chmod 0644 "$root_dir/index.html"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<EOF
server {
    listen 80;
    listen [::]:80;
    server_name $domain;
    root /srv/ubuntu-course-public;
    index index.html;
    location / {
        try_files \$uri \$uri/ =404;
    }
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
printf 'HTTP site prepared; backup: %s\n' "$backup_dir"

Se a escuta IPv6 não estiver disponível, ajuste essa linha de escuta para a política real e não anuncie registros AAAA inutilizáveis. Continue apenas após a criação, validação e recarga terem sucesso. Em caso de falha, compare apenas essa alteração com o backup e preserve outros sites.

No novo servidor público, se a política permitir HTTP/HTTPS público e UFW já estiver gerenciado, adicione essas permissões. Preserve o SSH e prepare caminhos correspondentes no firewall/grupo de segurança do provedor. Isso não habilita o UFW. Permitir apenas o cliente do laboratório .10 é insuficiente para a validação HTTP-01 externa.

sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw status verbose

A variável de domínio do script autônomo não persiste no shell pai. Digite novamente o hostname real na sessão atual do Bash e verifique o public-http-lab a partir de outra conexão de internet também. Compare nome, conteúdo e caminhos A/AAAA antes de prosseguir para o Certbot.

read -r -p "Domain you control: " domain
dig +short A "$domain"
dig +short AAAA "$domain"
curl --fail --show-error "http://$domain/"

Escolha uma rota de instalação do Certbot

Se o Certbot já existir, inspecione sua origem e o trabalho de renovação antes de misturar instalações via APT, Snap ou pip. Este exemplo escolhe a rota oficial Snap em um novo servidor dedicado. Revise seu requisito de acesso clássico e use o caminho de comando completo para evitar invocar outra instalação.

sudo snap install --classic certbot
/snap/bin/certbot --version

As instruções oficiais do Certbot para Nginx/Snap cobrem instalação, emissão e teste de renovação.

Faça backup e valide antes da emissão

(
set -eu
backup=$(sudo mktemp -d /root/nginx-before-tls.XXXXXX)
sudo cp -a /etc/nginx "$backup/"
sudo nginx -t
sudo /snap/bin/certbot --nginx -d "$domain"
)

Confirme que o domínio contém o hostname real na mesma sessão do Bash e execute o Certbot apenas após uma verificação de sintaxe bem-sucedida. Revise o e-mail, os termos e as escolhas de redirecionamento. A instalação automática edita arquivos do Nginx, então compare as alterações com o backup.

HTTP-01 precisa de uma rota acessível pelo validador externo. Para outros ambientes, selecione uma alternativa documentada, como um plugin oficial de DNS, e proteja credenciais de DNS com escopo mínimo. Investigue DNS, portas e logs de validação antes de repetir solicitações de emissão que falharam.

Verifique o HTTPS externo e o certificado fornecido

curl --fail --show-error "https://$domain/"
openssl s_client -connect "$domain:443" -servername "$domain" -verify_return_error -verify_hostname "$domain" </dev/null

Verifique o nome do host, a verificação da cadeia e a resposta web esperada. Não simule sucesso usando curl -k. Um arquivo de certificado local pode estar atualizado enquanto um proxy, balanceador de carga ou outro servidor IPv6 fornece um certificado antigo; teste a rota voltada para o usuário.

Teste a renovação e monitore a expiração

sudo /snap/bin/certbot certificates
sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all | grep certbot

Uma execução de teste verifica a rota atual de validação/renovação; não garante sucesso em execuções futuras agendadas. Inspecione os temporizadores e logs e organize alertas de falha e expiração externa. Leia a data notAfter real em vez de assumir um prazo fixo. certbot certificates mostra certificados locais; para inspecionar a data apresentada pela rota externa, após validar nome e cadeia como acima, use openssl s_client -connect "$domain:443" -servername "$domain" </dev/null 2>/dev/null | openssl x509 -noout -enddate. A extração da data, sozinha, não valida a cadeia nem garante que todos os servidores atendam com o mesmo certificado.

Para reverter, revise apenas esta alteração do Certbot/Nginx e preserve os certificados e as configurações de renovação dos outros domínios. Verifique o certificado servido atualizado e a resposta do serviço após a renovação para completar a verificação operacional.