APRENDER. PRATICAR. EVOLUIR.Uma variável de cada vez
O laboratório cria duas raízes independentes, um intermédio assinado pela primeira e certificados finais fictícios. Todos os ficheiros vivem numa diretoria temporária e são eliminados no fim. Começa pelo caso que passa: root-a como confiança explícita, intermédio como material auxiliar, propósito sslserver e nome api.fund.test. Depois altera uma variável por teste. Esta sequência permite atribuir a diferença observada ao material ou opção alterada, em vez de trocar simultaneamente raiz, nome e certificado e ficar sem saber o que resolveu a falha.
Construção do caminho não é decisão de confiança
Sem o intermédio, a verificação do leaf falha neste ambiente isolado. Acrescentá-lo com -untrusted permite construir o caminho até root-a. Mudar a âncora para root-b não relacionada volta a falhar, mesmo com o intermédio presente. Assim, a presença de toda a cadeia não obriga qualquer cliente a aceitá-la. Num incidente de batch, confirma qual trust store o processo usa e quem aprova os emissores. Copiar a confiança inteira de um portátil pode alargar o âmbito sem resolver a responsabilidade pelo cliente afetado.
Identidades DNS e IP explícitas
O leaf do ensaio inclui DNS:api.fund.test e IP:192.0.2.40 em SAN. A referência DNS correta passa; wrong.fund.test falha. A referência IP .40 passa e .41 falha. Estes testes não fazem resolução DNS nem contactam esses endereços: comparam a identidade solicitada com o certificado local. A política moderna RFC 9525 exige identidades adequadas em SAN. A documentação OpenSSL também descreve fallback para Common Name; por isso o laboratório usa SAN explícito e não apresenta um sucesso como prova de conformidade integral de todos os clientes com essa política.
Propósito e restrições acima do leaf
Um segundo certificado só permite clientAuth. O ensaio mostra aceitação com sslclient e recusa com sslserver. Noutro caso, o SAN contém api.other.test e corresponde ao nome pedido, mas o intermédio permite apenas DNS sob .fund.test. A falha permitted subtree violation identifica uma restrição no caminho. Reemitir o mesmo nome pela mesma cadeia pode repetir o problema. A recuperação deve confirmar o âmbito autorizado da CA e usar emissão adequada, mantendo os controlos de identidade e de confiança definidos para o serviço.
Ler a evidência e explicar a correção
Executa o runner e lê os grupos chain, identity, purpose e nameConstraint. Para cada falha, identifica a variável alterada, o erro e a correção que respeita a política. Evita dizer apenas certificado inválido: esse resumo pode levar outra equipa a renovar datas quando falta um intermédio, ou a alterar confiança quando o nome está errado. O ticket deve conter a versão OpenSSL, os ficheiros públicos identificados, as opções, o resultado e o âmbito. Nenhuma chave privada precisa de ser anexada para explicar estas verificações.
Passar do ficheiro ao serviço
O comando verify analisa certificados locais. Não envia SNI, não negoceia TLS e não observa o par carregado num processo. Depois de corrigir o material, um plano de mudança ainda precisa de validar ativação, clientes relevantes e operação funcional. As verificações de revogação também dependem de opções e fontes próprias; o runner não usa CRL ou OCSP. Mantém no relatório uma frase precisa sobre o que passou. Um teste offline é uma etapa útil de preparação, não a evidência final de que uma integração foi recuperada.
# From the project root; no network connections
python3 content/labs/tls-paths/run.py
# Runner verification pattern uses disposable local files:
# openssl verify -CAfile root-a.pem -no-CApath -no-CAstore \
# -untrusted intermediate.pem -purpose sslserver \
# -verify_hostname api.fund.test server.pemCaso fictício: api.other.test corresponde ao SAN, mas a CA intermédia permite só .fund.test. A equipa solicita uma cadeia autorizada para o novo nome e mantém o cutover pendente dessa validação.
Armadilhas comuns
Não confundas -untrusted com revogação, cadeia fornecida com confiança aprovada, SAN correspondente com ausência de restrições da CA ou verify com um handshake real.
Tópicos relacionados: Chaves, certificados e confiança · Identidade, nome e tempo · Diagnóstico com critérios explícitos
Uma matriz com uma variável por teste transforma erros genéricos em decisões delimitadas, mantendo separados o material apresentado e a política do cliente.
Referência: OpenSSL verify · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics