Auditar cadeias de certificados e delegação

Desenha a cadeia que será realmente avaliada

Numa migração fictícia de uma aplicação de fundos, o certificado apresentado pela aplicação é apenas uma peça da evidência. Desenha quatro posições: raiz aprovada R, autoridade emissora I, eventual autoridade subordinada S e certificado terminal E. Identifica quais certificados são fornecidos para construir o caminho e qual entidade o cliente já aceita como referência de confiança. Um certificado fornecido pelo servidor não se torna automaticamente essa referência.

O laboratório gera estes elementos em ficheiros locais. Não os instala no macOS nem contacta serviços. Em P01, o caminho é R → I0 → E. Em P03, é R → I1 → S1 → E. O campo Chain do resultado mostra o caminho construído. Conserva-o com a versão do verificador, os ficheiros usados, a finalidade pedida, o nome esperado e a hora de verificação. Uma captura de “OK” sem estes elementos dificulta a comparação entre o ensaio da equipa e a configuração da aplicação.

Para uma passagem a produção, pede ao responsável técnico que identifique também o processo que carrega o truststore e a cadeia que apresenta ao interlocutor. Se uma instância carrega um ficheiro antigo, o ensaio de outro ficheiro no portátil não descreve essa instância. A decisão de aceitação deve ligar a configuração aprovada à execução observada.

Profundidade de delegação e limite do cliente

O campo pathLenConstraint limita autoridades intermédias não autoemitidas que podem seguir a autoridade em causa. O certificado terminal não entra nessa contagem. No exercício, I0 tem pathLen=0: pode emitir E diretamente, mas o caminho que acrescenta S0 antes de E ultrapassa o limite. Todas as autoridades intermédias do exercício têm nomes de emissor e titular diferentes; não usamos a exceção de certificados autoemitidos.

Antes de executar, prevê P01, P02 e P03. O primeiro passa; o segundo é rejeitado por profundidade; o terceiro passa porque I1 permite uma subordinada. O nome do ficheiro e a quantidade total de certificados no pacote não substituem o desenho do caminho. Um pacote pode conter certificados que não foram usados.

P16 aplica ao mesmo caminho válido de P03 o limite local verify_depth=1. Este cliente aceita no máximo uma autoridade intermédia; o caminho tem duas. A emissão pode respeitar as suas restrições e continuar incompatível com a configuração do consumidor. Numa reunião de mudança, distingue a alteração de arquitetura de certificação da alteração autorizada no cliente. Aumentar um limite local não remove um pathLen=0 assinado no certificado de I0.

O segundo nome também faz parte da decisão

O projeto fictício usa a API api.funds.example. I1 permite nomes em funds.example e exclui restricted.funds.example. O certificado de P04 inclui dois nomes DNS: api.funds.example e archive.restricted.funds.example. O primeiro corresponde à API, mas o segundo entra no espaço excluído. A exclusão impede a aceitação desta cadeia, mesmo que esse segundo nome não seja o destino da ligação ensaiada.

No plano de mudança, confirma se o alias de arquivo é realmente utilizado. Se foi incluído por engano e a sua remoção foi aprovada, uma nova emissão sem esse alias pode resolver esse defeito. Se o arquivo continua necessário, retirar o nome sem tratar a dependência pode interromper outro consumidor. A correção tem de respeitar a utilização aprovada e a autoridade que pode emitir para cada espaço.

P05 mostra uma falha diferente: api.partner.example corresponde ao destino solicitado, mas fica fora do espaço permitido pela emissora. Não basta encontrar a expressão funds.example no texto de um nome; a relação usa os rótulos DNS completos. Os exemplos evitam nomes internacionalizados, curingas e restrições com ponto inicial, para não transformar diferenças de implementação em premissas escondidas.

Corrigir duas causas sem alargar a confiança

Considera um candidato com R → I0 → S0 → E e o alias excluído no certificado terminal. Existem dois problemas independentes: a delegação excede o pathLen de I0 e um nome viola a exclusão. A primeira mensagem do verificador não é um inventário garantido de todas as falhas. Depois de corrigir uma causa, outra pode tornar-se visível. No ensaio adicional de excluded0 pela raiz R, esta versão do OpenSSL apresentou ambas as falhas, 25 e 48; as correções parciais seguintes isolam as causas.

P06 representa a correção apenas do alias: continua a falhar por profundidade. P07 representa uma cadeia com profundidade permitida, mas conserva o alias: continua a falhar por exclusão. P08 reúne as duas correções e passa as verificações pedidas. Estes três registos reutilizam certificados de outros ensaios para comparar hipóteses; não são três mecanismos novos de segurança.

Num comité de mudança, regista a raiz aprovada, a arquitetura de emissão autorizada e os nomes necessários ao serviço. Pede evidência para cada condição alterada e um teste do caminho completo. Uma solução que faz desaparecer o erro através de um novo ponto de confiança altera o âmbito da decisão e deve ser reconhecida como tal. Um resultado positivo só depois de mudar a política não demonstra que o candidato cumpre a política anterior.

A autoridade intermédia promovida a âncora de confiança

P09 é propositadamente enganador se olhares apenas para o estado final. O verificador recebe S0 como entidade de confiança e aceita terminar aí através de partial_chain. O caminho avaliado deixa de incluir I0. Por isso, as restrições colocadas em I0 não fazem parte desse caminho. O certificado terminal com o alias excluído passa esta configuração diferente.

Compara o campo Chain com P01 e P03 e identifica onde termina cada caminho. Este ensaio não mostra que partial_chain é sempre incorreto: pode existir uma política que autorize confiar diretamente numa intermédia. Mostra que uma aprovação baseada apenas em R não foi demonstrada pelo ensaio que passou a confiar em S0. A equipa deve identificar a alteração e obter a decisão adequada, em vez de a descrever como simples reposição do ficheiro em falta.

Para o auditor, a evidência útil inclui o conjunto de confiança efetivo e a justificação da sua seleção. Para o gestor de projeto, inclui o dono da decisão, os consumidores afetados e os testes a repetir quando o âmbito muda. Não instales qualquer certificado gerado pelo laboratório num truststore do sistema.

Restrições acumuladas e causa da rejeição

Em P17 e P18, a autoridade superior permite funds.example e a subordinada permite apenas payments.funds.example. O primeiro certificado usa api.payments.funds.example e passa. O segundo usa api.funds.example e é rejeitado. O espaço mais amplo da autoridade superior não anula a restrição adicional da subordinada. Desenha a parte comum dos espaços permitidos antes de escolher uma nova autoridade emissora.

P10 retira o ficheiro da autoridade emissora do ensaio direto. A raiz permanece fornecida, mas o verificador isolado não consegue construir o caminho. A ação adequada para este defeito é fornecer a intermédia correta como material de construção, mantendo a raiz aprovada. Instalar a intermédia como entidade de confiança responde a outra pergunta.

Usa os códigos de erro como pistas ligadas à versão e aos dados do ensaio. P02 e P16 referem profundidade, mas têm origens diferentes: restrição assinada na cadeia e limite local. P04 e P05 referem espaços de nomes, com exclusão e permissão respetivamente. Conserva stdout, stderr e o código de saída; procurar apenas a palavra “OK” num conjunto concatenado de resultados pode ocultar rejeições de outros certificados.

O que um resultado positivo permite concluir

O guião pede explicitamente a finalidade sslserver e o nome da API na maioria dos ensaios. P11 troca apenas o nome esperado e falha. P12 omite a finalidade e aceita um certificado clientAuth; P13 pede a finalidade de servidor e rejeita o mesmo certificado. P14 altera um bit da assinatura e é rejeitado. Estes controlos ajudam a perceber quais condições foram efetivamente exercitadas.

P15 pede a verificação por CRL sem fornecer uma CRL e falha por falta desse material. O ensaio não consulta OCSP, não obtém uma CRL de uma rede e não demonstra que um certificado está atualmente revogado ou livre de revogação. Também não executa um handshake TLS, não testa autorização da aplicação e não mede disponibilidade ou desempenho.

Escreve a conclusão com o seu âmbito: “Este ficheiro, esta cadeia, esta raiz e estas opções passaram no OpenSSL registado à hora fixada.” Para aceitar uma mudança WebSphere ou Kubernetes, acrescenta evidência produzida pelo consumidor relevante, com o material carregado e os requisitos do serviço. A etapa local ajuda a isolar o problema; o contrato de aceitação determina os ensaios adicionais.

Exercício: preparar a decisão de mudança

Descarrega o exercício, confirma que tens Python 3 e OpenSSL 3 e escolhe um diretório novo para os resultados. Executa python3 run_lab.py --output tentativa-01. O guião recusa um diretório já existente, gera chaves descartáveis e regista os comandos e resultados. Cada repetição gera novos certificados; compara os resultados e as relações entre certificados, não hashes iguais entre execuções.

Antes de abrir report.json, prevê os resultados de P01 a P10 numa tabela com quatro colunas: caminho, autoridade de confiança, causa esperada e correção possível. Depois compara com os resultados reais. Explica porque P09 passa e porque esse resultado não satisfaz uma política limitada à raiz R. Para P06 e P07, indica a causa que sobrevive à correção parcial.

Entrega uma nota de mudança de seis linhas: serviço e nomes necessários; raiz autorizada; cadeia proposta; defeitos observados; alteração e responsável pela decisão; evidência ainda necessária no consumidor. Termina com o limite da conclusão. A validação automática verifica resultados literais deste conjunto sintético; a qualidade da tua nota depende de reconhecer as dependências e os limites de confiança.

Ligar certificados à autorização da aplicação

A aceitação de um certificado para autenticação de cliente não define quais os processos de negócio que essa identidade pode consultar. Várias organizações podem ter certificados válidos emitidos pela mesma CA. A aplicação precisa de um mapeamento aprovado entre identidade autenticada e organização, seguido de autorização sobre o recurso.

Não uses o emissor como identificador único de organização sem que o modelo de confiança o justifique. Um prazo de certificado mais curto ou consulta de revogação mais frequente não corrige uma associação errada entre identidades válidas. Exercício: usa duas identidades autorizadas de organizações diferentes e verifica acesso próprio e recusa cruzada.

Resumo: cadeia, finalidade, identidade e autorização de recurso respondem a perguntas diferentes. Relaciona com federação de identidades e isolamento entre clientes.

Armadilhas comuns

Contar o certificado terminal como intermédia; ignorar um segundo SAN; confundir limite do cliente com pathLen; promover uma intermédia sem reconhecer a mudança de confiança.