Algum certificado SSL pode ser usado para fins de autenticação de certificado de cliente?

Question

Estou tentando conectar-me a uma API de terceiros que tenha uma configuração de autenticação TLS mútua ativada. Portanto, devo instalar meus certificados de cliente em meu armazenamento de chaves e enviá-los no processo de handshake TLS.

Para esse processo, estou usando agora o SSL positivo para commodo como certificado do lado do cliente. Quando faço chamadas TLS, Evnthough servidor está solicitando um certificado, o cliente não está enviando um. E quando eu verifiquei SChannel Log, eu posso ver um aviso como este

The remote server has requested TLS client authentication, but no suitable client certificate could be found. An anonymous connection will be attempted. This TLS connection request may succeed or fail, depending on the server's policy settings.

SO minha dúvida é assim, estou usando o tipo correto de certificado X509 para fins de autenticação do lado do cliente? Preciso usar algum outro tipo específico? Como meu certificado atual não está recebendo envio.

    

Answer 1

Depende. Os certificados X.509v3 geralmente vêm com um campo de extensão "Extended Key Usage", que contém uma lista de usos permitidos (EKUs).

• Certificados servidor regulares da web contêm o uso de "Autenticação do servidor TLS" (às vezes exibido como "TLS Web Server", mas na verdade não é específico da Web).

• Para atuar como um cliente, você precisa de um certificado com "TLS Client Authentication" (mais uma vez mostrado como "TLS Web Client", apesar de não ter nada específico da Web).

É bastante comum que os certificados SSL "web server" regulares contenham ambos usos - por exemplo, eu estou olhando para certificados emitidos por Let's Encrypt e DigiCert, e todos eles contêm ambos os usos , portanto, pode ser usado para autenticação de cliente / mútua.

No entanto, é possível que em algumas outras CAs, especialmente CAs de organizações privadas, a maioria dos certificados tenha um uso ou o outro, mas raramente ambos.

Por exemplo, o OpenVPN costumava exigir estritamente " somente TLS Client" (em vez de " pelo menos TLS Client" como outros programas fazem), portanto, seu easy-rsa o script emite apenas os certificados do servidor e do cliente, mas não o tipo misto.

Portanto, você deve examinar seus certificados e certificar-se de que eles contenham o EKU necessário. Praticamente qualquer ferramenta de certificado fará o trabalho - por exemplo, o diálogo Propriedades do certificado no Windows mostrará isso em "Extensões V3", assim como os navegadores da Web, openssl x509 , certtool , certutil , etc.

Também vale a pena lembrar se você executar sua própria autoridade de certificação interna: se você usar um certificado CA intermediário , preste atenção a ela também. Intermediários não são obrigados a ter uma extensão EKU, mas se eles fizerem , então todos os certificados emitidos por aquele intermediário são restringidos por ela. (Se você obtiver os certificados comercialmente, não precisará se preocupar com isso.)

Além disso, o certificado terá um campo básico "Uso da chave", que contém algumas restrições muito gerais: por exemplo, "Assinatura digital" significa que o certificado pode assinar dados (e, portanto, permite o handshake do EDH / EECDH no TLS); "Acordo-chave" parece ser para estática-DH / ECDH; "Key Encrypting" permite handshakes RSA estáticos.

A documentação oficial do X.509v3 é muito confusa em quais usos são necessários quando ... As CAs comerciais geralmente acertam este campo. Mas para CAs particulares vale a pena verificar novamente.