Autenticação SSL Mútua e Requisitos para Certificados

Question

Para nossos testes internos, preciso configurar a autenticação SSL mútua entre o nosso servidor IIS (ele hospeda dois aplicativos: GUI da Web do ASP.NET e um serviço da Web) e clientes (acessando o servidor de duas maneiras possíveis: GUI da Web com um navegador e serviço da web com um cliente criado com WinForms). Quando os testes terminarem e os resultados forem avaliados, terei que dar algumas indicações ao nosso cliente sobre como configurá-lo e configurá-lo em seu ambiente - um ambiente corporativo fechado, acessível por URLs não públicos via VPN.

Estou bastante familiarizado com PKI, chaves e certificados em geral, mas não tenho muita experiência com PKI no contexto de HTTPS. Com algumas ferramentas disponíveis, principalmente o XCA, consegui criar meu certificado de CA raiz, certificado de servidor e vários certificados de clientes; Eu os instalei no IIS e nas lojas do cliente, e as coisas funcionam bem, mas há alguns problemas e perguntas:

• Quais são os valores de uso de chave (estendidos) necessários para um certificado de servidor? No meu certificado de teste, recebi Digital Signature , Non Repudiation , Key Encipherment e estendido TLS Web Server Authentication - estou faltando alguma? São todos necessários?
• A mesma pergunta sobre certificados de clientes: quais usos de chave são necessários? Meus certificados de teste têm Digital Signature , Key Encipherment , Data Encipherment e% estendidoTLS Web Client Authentication - estou faltando algum? São todos necessários?
• Existem outras características especiais que um certificado de cliente deve ter?
• O certificado do servidor deve ter seu nome listado em uma lista de SANs como uma entrada de DNS (ou IP, se acessado por endereço IP, certo?). Mas e o campo CN da Subject do seu Distinguished Name? deve ter alguma forma específica? Deve estar vazio? Endereços não públicos, como, por exemplo, mytestenv.mycompany.lan podem ser usados como SAN? Atualmente, no meu certificado de servidor de teste, tenho apenas um conjunto CN de Assunto e nenhuma entrada de DNS de SAN, e acredito que preciso adicioná-lo, estou certo?
• Há alguma etapa (além de adicionar o certificado da CA a autoridades de certificação confiáveis no navegador ou na loja do Windows) que preciso evitar que os navegadores exibam aviso de segurança de página inteira sobre o site não ser seguro? Eu acho que posso viver sem 'bloqueio verde' ou com algum aviso em uma barra de endereços ou algo assim, mas por exemplo o Chrome exibe erro de segurança de página inteira e não mostra a página da web até configurar uma exceção de segurança para o servidor. Como posso evitar isso? Pode perder SAN ser a causa? IE e Firefox exibem a página.
• Fazer coisas como DV / OV / EV, Transparência de certificado, "HTTPS apocalipse" como entrada para navegadores ou talvez outra coisa, afeta minha configuração (e possivelmente do cliente) de alguma forma? Preciso ter um cuidado especial com isso?

Se possível, eu estaria interessado tanto em observações gerais como em requisitos de servidores específicos (especialmente IIS) e navegadores (na infra-estrutura do cliente, estes serão principalmente IE 11+ e Edge).

    

Answer 1

Uso de chave

Para o TLS, você precisa da codificação de chaves e da assinatura digital, bem como do uso estendido da TLS Web Server / Client Authentication. Non Repudation não é usado. O acordo-chave poderia teoricamente ser usado para o ECDH em oposição ao ECDHE. Consulte o link

Transparência do certificado.

O Google está empurrando isso com sua influência considerável. Uma coisa importante a considerar ao enviar certificados para logs de transparência é que eles são, na verdade, uma publicação de nomes de domínio (ou curinga). Tenho notado consultas para um servidor da web logo após obter um certificado letsencrypt e, em teoria, isso pode ser antes mesmo de seu certificado SSL ser instalado, porque o log de transparência tem uma pré-publicação.

Veja: Blog do Scott Helme

Atualização do Chrome de abril:

De: link

Desde janeiro de 2015, o Chrome exige que os certificados de Validação Estendida (EV) sejam compatíveis com CT para receber o status de EV. Em abril de 2018, esse requisito será estendido a todos os certificados recém-emitidos publicamente confiáveis - DV, OV e EV - e os certificados que não cumprirem essa política não serão reconhecidos como confiáveis quando avaliados pelo Chrome. Os certificados emitidos por CAs localmente confiáveis ou corporativas adicionadas por usuários ou administradores não estão sujeitos a esse requisito.

SAN com nomes locais

Não há problemas que eu conheça. Embora .local seja um TLD especialmente desagradável, porque é usado com DNS multicast.

Outros requisitos

Para qualquer sistema maduro, há a necessidade de servidores CRL e OCSP. Alguns subprocessos podem ser ainda mais exigentes do que o próprio navegador. Tomemos por exemplo o plugin Java no IE11. Se um aplicativo de webstart ou applet tiver um servidor CRL ou OCSP inacessível na hierarquia, o quadro do navegador poderá permanecer completamente em branco por alguns minutos. Além disso, se um servidor web Apache usa grampeamento OCSP, o servidor OCSP deve responder melhor quando o próprio servidor web chama, caso contrário, infelizmente, com o Apache, todos os clientes exibirão erros até que o servidor tenha as respostas grampeadas novamente.

ID da chave de autoridade. Use esse recurso para possibilitar a recuperação da retirada de certificados intermediários por erro ou por comprometimento.

Registros da CAA. As CAs públicas são obrigadas a verificar isso ao emitir certificados. Consulte o link

Outras referências:

• link
• link
• link