Introdução
Uma equipe de suporte implantou um site de ajuda, mas os clientes recusam a conexão HTTPS. O HTTPS usa TLS para criptografar o tráfego e provar qual servidor respondeu. Só a criptografia não estabelece identidade: o cliente também precisa reconhecer o nome solicitado e confiar no emissor do certificado.
Você corrigirá certificados sintéticos de treinamento em um servidor Nginx real. Basta familiaridade básica com o terminal; a inspeção de certificados e a configuração do serviço serão apresentadas aqui. Client e Server são sessões e diretórios distintos da mesma VM, não computadores separados. O Nginx executa em um contêiner preparado. O HTTPS Monitor opcional mostra sondagens TLS internas reais; o cadeado do navegador descreve outra conexão externa.
Obter uma referência confiável
Nesta etapa, obtenha um documento de um serviço funcional antes de compará-lo com o site de ajuda com falha. Um nome de host identifica o serviço solicitado. Todos os nomes de treinamento terminam em .lab.test e são locais a este exercício.
Use a aba Client. curl obtém uma URL. --cacert root.crt confia na autoridade certificadora (CA) fornecida, que assina certificados. Essa CA é uma âncora de confiança de treinamento, não uma autoridade pública. --resolve associa um nome e uma porta a um endereço IP, preservando o nome para TLS e HTTP. 127.0.0.1 significa esta VM; a porta 8443 alcança o Nginx preparado. --noproxy '*' envia a solicitação diretamente; as aspas impedem a expansão de * pelo shell. --fail rejeita erros HTTP e --output salva o documento real do serviço para uso posterior.
curl --noproxy '*' --fail --cacert root.crt --resolve status.lab.test:8443:127.0.0.1 --output reference.txt https://status.lab.test:8443/
cat exibe o conteúdo de um arquivo:
cat reference.txt
status service: training content available
O download é um documento de referência real, não um relatório. Agora solicite o nome previsto do site de ajuda. Espera-se que o comando falhe e retorne ao prompt; continue depois.
curl --noproxy '*' --cacert root.crt --resolve help.lab.test:8443:127.0.0.1 https://help.lab.test:8443/
curl: (60) SSL: no alternative certificate subject name matches target host name 'help.lab.test'
...
A referência funcionou com a mesma CA e endereço. Esse erro aponta especificamente para um nome incompatível, não um servidor parado. Mantenha o nome previsto: alterar a URL testaria outra identidade.
Inspecionar e montar a cadeia de certificados
Nesta etapa, compare a identidade servida com um certificado preparado e construa um pacote utilizável pelo servidor. Um certificado contém uma chave pública e informações de identidade. A chave privada correspondente permanece no servidor. Nunca cole uma chave privada em relatórios nem a envie aos clientes.
Em Client, inspecione o certificado realmente servido. openssl s_client abre uma conexão TLS; -connect fornece o endereço e -servername envia o nome solicitado por Server Name Indication (SNI), permitindo vários sites em um listener Nginx. < /dev/null encerra a entrada interativa. 2>/dev/null oculta os diagnósticos apenas nesta inspeção. O pipe | envia o certificado a openssl x509; -noout suprime o certificado codificado e as outras opções mostram campos selecionados. Essa inspeção não prova, sozinha, a confiança.
openssl s_client -connect 127.0.0.1:8443 -servername help.lab.test </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = legacy.lab.test
issuer=CN = LabEx Training Issuing CA
notBefore=...
notAfter=...
X509v3 Subject Alternative Name:
DNS:legacy.lab.test
O nome alternativo do titular (SAN) lista os hosts aceitos. issuer identifica o assinante; as datas delimitam a validade. A preparação gera certificados novos para esta VM: os certificados finais duram 365 dias. Uma data válida não compensa um nome incorreto.
Mude para Server. openssl x509 -in lê um certificado local em vez de uma resposta de rede:
openssl x509 -in certs/help.crt -noout -subject -issuer -dates -ext subjectAltName
Seu SAN é DNS:help.lab.test, correspondente à solicitação. Esta é a relação prevista:
| Item | Função |
|---|---|
help.crt e help.key |
Certificado do site de ajuda e chave privada correspondente |
docs.crt e docs.key |
Certificado da documentação e chave privada correspondente |
issuing.crt |
CA intermediária que assinou ambos os sites |
../client/root.crt |
CA raiz confiável para o cliente |
A cadeia é certificado do site → CA intermediária → CA raiz confiável. O Nginx deve enviar primeiro o certificado final, depois o intermediário. O cliente já confia na raiz, que não precisa ser enviada. Monte o pacote público com cat; > grava a saída em um arquivo, substituindo o conteúdo anterior. A chave privada não faz parte dele.
cat certs/help.crt certs/issuing.crt > certs/help-fullchain.pem
openssl verify verifica o pacote contra a raiz confiável especificada. -untrusted fornece intermediários como possíveis elos, não como raízes adicionais de confiança; -verify_hostname verifica o nome previsto.
openssl verify -CAfile ../client/root.crt -untrusted certs/help-fullchain.pem -verify_hostname help.lab.test certs/help-fullchain.pem
certs/help-fullchain.pem: OK
Se falhar, confira a ordem dos arquivos e a grafia, depois repita cat. Isso valida o pacote preparado; o servidor ativo ainda precisa usá-lo.
Aplicar a identidade do site de ajuda
Nesta etapa, faça o Nginx servir a identidade correta mantendo o site de status funcional. Em Server, exiba a configuração com cat:
cat conf/help.conf
server_name seleciona o site. ssl_certificate indica a cadeia pública; ssl_certificate_key, a chave privada. Caminhos começando com /tls/ são internos ao contêiner Nginx e correspondem a certs/ neste diretório. A linha return 200 fornece o conteúdo real de ajuda do treinamento. Preserve o listener, o nome e a resposta.
Abra o arquivo com o editor de texto nano:
nano conf/help.conf
Use as setas para encontrar as duas diretivas TLS. Substitua somente essas duas linhas por:
ssl_certificate /tls/help-fullchain.pem;
ssl_certificate_key /tls/help.key;
Pontos e vírgulas encerram diretivas Nginx. Salve com Ctrl+O, pressione Enter e saia com Ctrl+X. Se houver um erro no caminho, reabra o mesmo arquivo e corrija-o.
sudo executa um comando com privilégio administrativo. docker exec https-edge executa o comando seguinte no contêiner preparado. nginx -t testa a configuração sem aplicá-la:
sudo docker exec https-edge nginx -t
Procure syntax is ok e test is successful. Se falhar, corrija primeiro o arquivo e a linha indicados. nginx -s reload solicita ao serviço ativo que carregue a configuração testada:
sudo docker exec https-edge nginx -s reload
Mude para Client e repita a solicitação prevista. A recarga pode levar um instante; repita se ainda receber o certificado antigo.
curl --noproxy '*' --fail --cacert root.crt --resolve help.lab.test:8443:127.0.0.1 https://help.lab.test:8443/
help service: training content available
Preserve também o funcionamento normal do site de referência:
curl --noproxy '*' --fail --cacert root.crt --resolve status.lab.test:8443:127.0.0.1 https://status.lab.test:8443/
O sucesso verifica nome, cadeia e datas realmente servidos antes de aceitar a resposta. Editar apenas um certificado não utilizado não produziria esse resultado.
Corrigir um certificado intermediário ausente
Nesta etapa, diferencie uma cadeia incompleta do nome incompatível já corrigido. Em Client, solicite o site de documentação preparado. Esta falha é intencional:
curl --noproxy '*' --cacert root.crt --resolve docs.lab.test:8443:127.0.0.1 https://docs.lab.test:8443/
curl: (60) SSL certificate problem: unable to get local issuer certificate
...
Ambas as falhas usam o código de saída 60; leia a explicação associada. Inspecione o certificado servido com o mesmo formato de comando:
openssl s_client -connect 127.0.0.1:8443 -servername docs.lab.test </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Agora o SAN é DNS:docs.lab.test. O nome está correto, mas o Nginx envia apenas o certificado final, impedindo o cliente de ligar seu emissor à raiz.
Para uma comparação controlada, -k ignora a verificação do certificado. Isso mostra que é possível obter conteúdo mesmo com a confiança quebrada:
curl --noproxy '*' -k --resolve docs.lab.test:8443:127.0.0.1 https://docs.lab.test:8443/
Ver docs service: training content available aqui não é uma correção. Volte a Server, inspecione o arquivo ativo e abra-o:
cat conf/docs.conf
nano conf/docs.conf
O arquivo preparado docs-fullchain.pem já contém o certificado final e o intermediário em ordem. Substitua somente a linha ssl_certificate:
ssl_certificate /tls/docs-fullchain.pem;
Mantenha /tls/docs.key como chave privada. Salve e saia como antes; depois teste e recarregue:
sudo docker exec https-edge nginx -t
sudo docker exec https-edge nginx -s reload
Em Client, solicite os três nomes previstos sem -k. O laço atribui cada valor a host; $host insere esse valor e as aspas duplas mantêm cada argumento resultante unido.
for host in help docs status; do
curl --noproxy '*' --fail --cacert root.crt --resolve "$host.lab.test:8443:127.0.0.1" "https://$host.lab.test:8443/"
done
Espere as três respostas correspondentes. Você pode atualizar HTTPS Monitor para comparar suas sondagens independentes em tempo real. Corrija erros na configuração apropriada, teste e recarregue; não altere a raiz do cliente nem os nomes previstos. Em implantações reais, obtenha certificados aprovados pelo processo da organização; aqui há candidatos sintéticos para você se concentrar no diagnóstico.
Resumo
Você obteve uma referência confiável, inspecionou nomes e emissores reais, montou um pacote final/intermediário e o aplicou por uma recarga testada do Nginx. Corrigiu um nome incompatível e uma cadeia incompleta preservando o serviço normal. O próximo desafio combina essas decisões em outro portal.
