Temos um domínio do Microsoft Active Directory com um grande pool de controladores de domínio (DC) que são configurados com o LDAP. Eles são todos configurados com LDAPS e usam os Serviços de certificados por meio de um modelo para configurar um certificado com o nome de domínio (por exemplo, test.corp) no SAN (Subject Alternate Name) para o servidor LDAPS servir.
Como esses são DCs, o DNS é configurado em um pool para cada um desses sistemas para responder a solicitações para testar.corp de maneira round robin.
Cada um desses DCs tem vários modelos e vários certificados no Local Computer \ Personal Certificate Store.
Após testar, usando um módulo nodejs, ldapjs ao fazer uma solicitação LDAPS usando o nome de domínio, test.corp, notamos que um punhado de servidores falha com a seguinte mensagem:
Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: test.corp. is not in the cert's altnames: othername:, DNS:.test.corp
Conforme investigamos, descobrimos que esses poucos servidores LDAPS estão atendendo ao certificado incorreto. Nós determinamos isso usando o seguinte comando
openssl s_client -connect .test.corp:636
Se você pegar a seção de certificado da saída e colocá-la em um arquivo e usar uma ferramenta como o Gerenciador de certificados ou o certutil para ler o arquivo, poderá ver que o certificado não é o correto. (Não possui o domínio "test.corp" SAN). Também verificamos isso comparando os números de série
Conforme investigamos, já que temos DCs com vários certificados no armazenamento Local Computer \ Personal Certificate, nos deparamos com o seguinte artigo:
Ele sugere colocar o certificado do computador local \ Armazenamento de certificados pessoais no armazenamento do Serviço de Domínio do Active Directory \ Pessoal. Seguimos os passos descritos, mas encontramos os mesmos resultados.
Após investigação adicional, sugeriu-se usar uma ferramenta chamada ldp ou adsiedit. Em seguida, passamos a usar essas ferramentas e falsificamos o arquivo host da máquina local do qual estávamos fazendo o teste, para apontar o domínio (test.corp) para o ip de um dos DCs que está nos causando problemas. Depois de um reinício para limpar qualquer cache, testamos as ferramentas "ldp" e "adsiedit" para conectar ao test.corp. Esses sistemas não relataram erros.
Achamos isso estranho. Em seguida, executamos o comando openssl para ver qual certificado estava sendo exibido desse mesmo sistema e descobrimos que ele ainda estava exibindo o certificado incorreto.
Após uma pesquisa adicional, parece que o "ldp" ao selecionar a caixa de seleção SSL e as ferramentas "adsiedit" não eram compatíveis com o RFC6125, especificamente B.3, que basicamente afirma que a identidade do certificado deve corresponder à identidade da solicitação, caso contrário, o handshake falharia. Essa verificação de identidade é feita usando o nome comum do certificado (CN) ou a SAN.
Com base nisso, as ferramentas "ldp" e "adsiedit" não estão em conformidade com o padrão RFC6125.
Tudo isso para dizer que precisamos primeiro corrigir os poucos controladores de domínio que estão atendendo o certificado correto. Estamos abertos a sugestões, uma vez que temos trabalhado neste problema nos últimos meses. Em segundo lugar, há uma maneira de fazer com que as ferramentas de MS em questão funcionem no padrão RFC6125?
Nota: Se eu tiver postado isso no quadro incorreto (por exemplo, estouro de pilha), por favor me avise e eu removerei e repostarei para o local correto.