APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
O cliente precisa de confirmar que a identidade apresentada corresponde ao serviço pretendido. Na orientação RFC 9525, nomes DNS são verificados em subjectAltName e Common Name não é usado para identificar o serviço. Um CNAME ou endereço partilhado não acrescenta identidades ao certificado. Para um wildcard como *.example.test, só um label à esquerda é abrangido: api.example.test pode corresponder, mas example.test e a.api.example.test não. Estas são regras de identidade TLS, distintas de expansão wildcard no DNS. Implementações antigas podem ter comportamento diferente; o curso torna explícita a referência moderna usada nos exercícios, sem presumir que todos os clientes a implementam integralmente.
Aplicação guiada
SNI ajuda o servidor a selecionar o contexto TLS; não é a própria validação de nome. Em OpenSSL, -servername e -verify_hostname servem essas funções distintas. Compara também notBefore, notAfter e o relógio efetivo. Um erro de certificado ainda não válido pode refletir relógio errado ou emissão que ainda não entrou no intervalo; confirma antes de corrigir. A opção x509 -checkend 86400 responde a uma pergunta limitada sobre expiração nas próximas 24 horas. Não verifica por si cadeia, identidade ou certificado carregado no endpoint. Num exercício de mudança de alias, a cadeia continua válida, mas o novo nome exige emissão e ativação de material que o cubra.
Certificado de legacy.example.test não cobre automaticamente api.example.test por existir um CNAME.
Armadilhas comuns
SNI como validação; CN como fallback moderno; wildcard como todos os subdomínios; checkend como auditoria completa.
Tópicos relacionados: Chaves, certificados e confiança · Negociação, mTLS e aplicação · Renovação e certificado servido
Confirma o nome que o cliente espera e a validade no instante observado.
Referência: Service Identity in TLS · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics