Resumo

  • A extensão TLS 1.3 certificate_authorities leva uma sequência de Distinguished Names X.501 codificados em DER. O nome ajuda a selecionar uma credencial; não leva o certificado da AC, a chave confiável, o caminho validado ou uma permissão.
  • Em ClientHello, o cliente orienta a escolha de certificado do servidor. Em CertificateRequest, o servidor orienta a escolha do cliente. A estrutura é igual, mas direção, exposição e dono da decisão mudam.
  • Operações auditáveis registram quatro resultados: geração da lista, seleção da credencial, validação do caminho e autorização da identidade pela aplicação.

Uma recusa depois do sucesso criptográfico

Uma cadeia válida pode terminar em acesso negado sem qualquer contradição. O verificador demonstrou que a credencial chega a uma âncora aceita e atende às restrições aplicáveis. Ele não demonstrou que o SAN pertence ao namespace correto, que o sujeito foi cadastrado no tenant ou que seu papel permite executar aquela ação.

Esse é o problema de métricas como ca_allowed=true. O campo não diz se um nome apenas apareceu na rede, se a biblioteca selecionou um certificado, se o servidor aceitou uma âncora ou se a aplicação concedeu uma capacidade. As quatro respostas podem divergir.

Uma investigação precisa manter a ordem: qual política produziu os nomes, quais candidatos existiam, por que um deles foi escolhido, qual caminho foi validado e qual regra de negócio autorizou ou negou o sujeito.

O nome não contém a autoridade

A IANA reserva o valor 47 para certificate_authorities. Segundo a RFC 9846, o conteúdo é um vetor não vazio de DNs em DER; cada item pode designar uma âncora desejada ou uma AC subordinada e deve orientar a seleção do par.

O DN não inclui chave pública, restrições, políticas nem o registro real do trust store. Dois certificados de AC podem ter o mesmo subject e chaves diferentes. Uma rotina pode extrair um subject de um certificado que nem sequer tenha capacidade de AC. Comparar o nome não identifica a chave em que o emissor confia.

A validação da RFC 5280 precisa da âncora concreta, assinaturas, validade, Basic Constraints, Name Constraints, usos de chave e entradas de política. A âncora pode ficar fora da cadeia transmitida porque já foi distribuída por outro canal. A lista não substitui essas avaliações.

Presença prova somente que o remetente anunciou aquele DN no contexto da mensagem. Não prova aceitação de toda cadeia sob o nome. Ausência também não prova desconfiança universal: a lista pode ser limitada por privacidade, tamanho, população de credenciais ou estado local.

A seta do ClientHello e a seta do CertificateRequest

Quando o cliente envia a extensão em ClientHello, oferece informação para a seleção do certificado e da cadeia do servidor. Quando o servidor a envia em CertificateRequest, ajuda o cliente a escolher uma identidade. Misturar as duas setas torna impossível atribuir a geração da lista.

Há também um custo de privacidade. A documentação do OpenSSL observa que nomes de AC enviados pelo cliente chegam em claro ao servidor. Exportar todo o conjunto corporativo pode revelar organizações e hierarquias internas. Uma lista longa do servidor, por outro lado, aumenta bytes e trabalho do handshake.

O antigo trusted_ca_keys não é usado pelo TLS 1.3. Um ClientHello compatível com versões anteriores pode carregar sinais legados, portanto versão negociada, mensagem, sentido e tipo da extensão devem ser registrados juntos.

Seleção é a interseção de vários filtros

O nome da AC é apenas um filtro. signature_algorithms, às vezes signature_algorithms_cert, tipo de chave, disponibilidade da chave privada, assinatura do certificado, Key Usage, EKU, SNI, filtros OID, validade e cadeias locais também eliminam candidatos.

Os motivos de rejeição são essenciais. Um certificado pode casar com o DN e falhar em EKU; outro pode ter a chave adequada e não construir cadeia até a autoridade indicada. Guardar só o leaf escolhido impede explicar o comportamento.

Se o cliente não tiver certificado adequado, TLS 1.3 manda um Certificate vazio. O servidor pode continuar segundo seu perfil ou responder certificate_required. Esse vazio é evidência legítima, não um erro que deve ser escondido com uma identidade qualquer.

Anúncio e verificação são estados separados

No OpenSSL, as APIs que configuram nomes enviados ao par não adicionam confiança. Certificados e âncoras usados na verificação são carregados por outra família de interfaces.

Teste a separação de propósito: anuncie o subject de uma AC sem a chave correspondente no trust store. O cliente pode escolher uma cadeia compatível e o servidor pode rejeitá-la com unknown_ca. Depois mantenha uma âncora confiável fora da lista e observe o comportamento do seletor.

Uma recarga pode alterar só a lista ou só o store. Por isso, ambos precisam de geração, hash, instante de ativação e identificação dos processos que ainda executam o estado anterior.

O carregador de nomes de AC cliente do OpenSSL extrai subjects e não limita a entrada a certificados de AC. Arquivo carregado significa nomes lidos, não autoridades comprovadas.

A aplicação ainda precisa admitir o principal

Após o caminho, regras de identidade interpretam SAN e demais nomes. A aplicação mapeia o principal normalizado para tenant, conta, workload, papel e ação. Pode exigir um formato exato de SAN, um par issuer–subject, OID de política, matrícula ativa ou direito externo.

Logo, negar uma credencial válida pode ser o comportamento correto. O cliente também não sabe, apenas pelo fim do handshake, se o servidor o considerou mutuamente autenticado para uma operação. Uma resposta explícita da aplicação pode ser necessária.

Bibliotecas oferecem pontos distintos para observar isso. OpenSSL, GnuTLS e BoringSSL separam callbacks de seleção de funções de verificação. Callback instalado prova capacidade; somente invocação ligada à conexão prova execução. Algumas vistas do BoringSSL ainda têm vida restrita ao callback, exigindo cópia ou hash imediato dos DERs.

Na retomada com PSK, o handshake principal pode não incluir novo CertificateRequest. Sem troca de certificados, a telemetria não pode declarar uma decisão nova de CA ou de identidade cliente.

Testes negativos que preservam a fronteira

Anuncie um DN sem confiar na chave. Use duas ACs de mesmo subject e confie apenas em uma. Ofereça um certificado cujo nome combina, mas com EKU, validade, política ou chave privada inadequada. Registre cada descarte.

Valide o caminho e negue o sujeito no tenant. Remova todas as credenciais adequadas e observe Certificate vazio e a decisão posterior. Atualize lista e store separadamente para provar que o alerta identifica a geração divergente.

Capture o ClientHello para medir exposição, exercite vetores grandes, retome uma sessão sem contar nova autenticação e diferencie configurado, invocado, selecionado, verificado e autorizado.

A evidência final é uma escada: nome anunciado, conjunto candidato, credencial escolhida, posse de chave, caminho validado, identidade interpretada e ação permitida. Cada degrau pertence a um controle diferente.

Fontes