Autenticação do Apache: navegador não enviando certificado quando o nome da AC não corresponde por maiúsculas e minúsculas?

Question

Usando o Apache 2.4.

Temos dois certificados CA válidos cujos nomes diferenciados diferem apenas pelo caso de um caractere (digamos CA1 com dn: cn = MyCA, O = myOrg e CA2 com dn: cn = MyCA, O = MyOrg).

Esses dois certificados estão no arquivo referido pela diretiva Apache SSLCACertificateFile , como precisamos autenticar certificados de clientes assinados por ambas as CAs. Isso não acontece: somente navegadores com certificados de cliente assinados por CA1 ou CA2 podem acessar, dependendo da ordem dos certificados de CA no arquivo. Portanto, se apenas os clientes da CA1 puderem se autenticar, depois de alternar o pedido em SSLCACertificateFile e recarregar o Apache, somente os clientes da CA2 poderão se autenticar.

Se executarmos um handshake SSL em openssl s_client -connect <server>:<port> -prexit , notamos que apenas um dos nomes distintos de CA é enviado na lista de CAs aceitas, e o dn que é enviado depende da ordem em que o certificado de CAs está o SSLCACertificateFile. Isso faz sentido, pois o hash computado Openssl para os dois nomes distintos é o mesmo, pois os nomes distintos não devem diferenciar maiúsculas e minúsculas.

No entanto, parece que o navegador realiza uma correspondência com distinção entre maiúsculas e minúsculas, como nos registros do Apache. O certificado instalado no navegador não é enviado quando a "CA anunciada" é CA1 e o certificado do cliente é assinado pelo CA2. vice-versa. Tentamos com o Firefox no Windows e no Linux, e o Internet Explorer e o Chrome no Windows.

Caso contrário, o navegador de linha de comando curl não tem esse problema, quando invocamos a URL https com o certificado do cliente e a chave no formato PEM.

    

Answer 1

Sem realmente cavar, eu diria que você não pode convencer os navegadores a fazer uma pesquisa que não diferencia maiúsculas de minúsculas aqui. No caso de um serviço web simples, você poderia criar outro VirtualHost onde todos os clientes são distribuídos (digamos link ).

Isso significaria que o cliente negocia o TLS uma vez, depois ele tem um redirecionamento e, em seguida, outra negociação de TLS.

VirtualHost detect-cert.example.com:

• certifique-se de aceitar optional_no_ca certificados dos navegadores
• não SSLCACertificateFile
• veja a variável de ambiente SSL_CLIENT_I_DN ou SSL_CLIENT_CERT_CHAIN_<n>
• redirecionar (HTTP 302) um navegador para ca1clients.example.com ou ca2clients.example.com

VirtualHost ca1clients.example.com:

• certifique-se de que require certificados dos navegadores
• SSLCACertificateFile CA_lowercase.pem

VirtualHost ca2clients.example.com:

• certifique-se de que você require
• SSLCACertificateFile CA_uppercase.pem

Mas seu aplicativo da Web precisa suportar dois nomes de domínio ao mesmo tempo (por exemplo, por meio do X-Forwarded-Host header). Ele nunca deve informar a um navegador que entrou por ca2clients.example.com para reinserir em ca1clients.example.com . Outra dificuldade seria os usuários trocarem links entre si (por exemplo, enviando links para algum conteúdo).