Estou em um cenário estranho onde tenho um servidor com back-end NodeJS e front-end ReactJS que mantém registros onde o cliente deseja usar certificados de usuário para identificar quem visita este site interno. O problema é que eles têm uma rede muito grande, com PKI complicado, e o certificado público que recebi para atribuir ao site não corresponde necessariamente a todos os clientes que podem visitá-lo.
Eu tenho nginx na frente com o ssl_verify_client optional_no_ca;
conjunto, mas notei que os navegadores só darão aos usuários a opção de selecionar seu certificado de cliente se tiverem um certificado devidamente assinado pela mesma CA da chave pública apresentada pelo nginx.
Meu entendimento é que, durante a solicitação do certificado, o servidor pode especificar quais CAs são aceitáveis. Parece que o nginx pode estar fazendo isso, mas não tenho certeza se é esse o caso. Meu plano é começar a dissecar com o wireshark amanhã. Existe uma maneira conhecida de fazer meu site solicitar aos navegadores que sempre solicitem aos usuários um certificado de cliente? Talvez eu tenha entendido mal alguma coisa ao longo do caminho?
Simples: coloque na configuração do nginx quais certificados de autoridade você deseja que o nginx solicite . O Nginx enviará e verificará aqueles dependendo da sua
ssl_verify_client
configuração. É isso ‡ .As duas direções de autenticação por meio de certificados não estão relacionadas. Seu servidor apresenta um certificado e não há nenhuma regra que diga que não pode haver sobreposição, mas, caso contrário, você pode solicitar qualquer autoridade que desejar. O Nginx nem envia a chave pública dos certificados que você configura para serem "enviados" usando o arquivo
ssl_client_certificate
. Ele envia uma lista de algoritmos de assinatura aceitáveis e uma lista dos conjuntos de nomes distintos desses certificados: algo como/C=DK/O=ACME Inc./CN=ACME CA3
.Você pode ter problemas de interoperabilidade se tiver que oferecer suporte a clientes mais antigos (pré-TLSv1.3) juntamente com algoritmos de assinatura mista (mistura entre EC e RSA) e se sua lista de nomes distintos se tornar excessivamente grande. Experimente o que funciona, especificamente usando o software para o qual você precisa de suporte, e certifique-se de que as mensagens de erro sejam autoexplicativas ou devidamente documentadas para quaisquer clientes ou parceiros de negócios que possam encontrá-las.
‡) Isso é tudo para obter um cliente totalmente compatível com TLSv1.3 para apresentar um certificado assinado. Você não terminou, então. Por favor, tenha muito pouca confiança em assumir que tudo assinado por qualquer uma das CAs não gerenciadas por você é o usuário autorizado que o certificado sugere e garanta uma validação muito rigorosa em seu aplicativo por trás do proxy nginx que realmente lida com aqueles apresentados opcionalmente , certificados possivelmente inúteis/irrelevantes .