Confiando em uma CA não confiável - Posso restringir como o sistema confia?

(Publicado no ServerFault em vez do StackOverflow, porque acho que se trata mais da configuração do SO do que do código de programação).

Atualmente, sou responsável por manter um sistema conectado a um serviço da web de terceiros. Esse serviço da web requer certificados de autenticação de cliente, o que é justo o suficiente, mas o próprio serviço da web é protegido por um certificado autoassinado criado por um certificado de autoridade de certificação raiz auto-criado - a mesma raiz que cria os certificados de autenticação do cliente.

Seria suficiente apenas adicionar o certificado de serviço atual à lista confiável conhecida e ignorar o certificado de autoridade criado por si próprio. Infelizmente, o certificado de serviço muda regularmente, portanto, o certificado de autoridade deve ser confiável para garantir que o aplicativo não seja interrompido quando o certificado de serviço é renovado.

No entanto, eu (pessoalmente) não confio no certificado da CA com base na minha experiência com a empresa que administra o serviço da web - não me surpreenderia se vazasse para a web - e, preocupantemente, o certificado da CA não possui restrições de uso de chaves (embora ataques externos ao MITM sejam uma possibilidade, embora remota, estou mais preocupado com um certificado vazado usado para assinatura de código, por exemplo).

É possível dizer ao meu computador (atualmente uma caixa de servidor, mas em futuras caixas de clientes comuns de desktop) confiar em uma autoridade de certificação, mas apenas para um determinado conjunto de usos de chave e um pequeno conjunto de possíveis nomes de assunto (nomes de domínio )?

O servidor atualmente é o Windows Server 2012 R2, mas pode estar em execução em uma caixa Linux - embora as máquinas da área de trabalho sejam todas caixas Windows.

ssl-certificate certificate-authority x509

— Dai
fonte

Pelo menos no Linux, muitos aplicativos têm uma opção para especificar o local dos certificados de autoridade de certificação de mesmo nível, para que você possa limitar o escopo dessa autoridade de certificação apenas ao aplicativo que a utiliza. A resposta da @CryptoGuy também funcionaria no Linux, não há nada específico para o Windows.

— Edheldil 5/05

@ Edheldil: É específico da implementação - por exemplo, o Windows suporta restrições de nome X.509 por muito mais tempo do que, por exemplo, NSS ou GnuTLS.

— grawity

Seu sistema se conecta a este serviço de terceiros; o código do cliente em seu sistema pode ser configurado para confiar na autoridade de certificação desse serviço, de forma que seja feito apenas para esse código de cliente , não para todo o sistema?

— Castaglia 5/05

@ Castaglia Eu posso escrever meu próprio código de verificação de certificado que funciona independentemente do sistema host, mas existem outras partes do software cliente que eu não tenho controle sobre as que usam serviços de certificação em todo o sistema.

— Dai

Sim, é possível. No caso do Windows, existe um recurso chamado Cross-Certification ou Qualified Subordination.

A idéia é que você assine o certificado de CA de emissão de terceiros em seu ambiente. Como resultado, o certificado SSL remoto está acorrentado ao seu próprio certificado CA raiz. Para se proteger de possíveis certificados não autorizados, você implementa uma Name Constraintsextensão de certificado em que especifica uma lista de nomes aceitáveis. Se a CA de terceiros emitir um certificado para qualquer outro nome (não especificado explicitamente na extensão de restrições de nome), ele será automaticamente rejeitado pelo seu provedor de CryptoAPI.

Além das restrições de nome, você pode descrever a restrição de Uso Avançado de Chave, definindo a Application Policiesextensão do certificado no certificado cruzado. Portanto, seu provedor de confiança validará com êxito apenas os usos especificados na Application Policiesextensão.

Mais informações: Planejando e implementando certificação cruzada e subordinação qualificada usando o Windows Server 2003

ps, embora o artigo seja escrito no Windows Server 2003, ele ainda se aplica à versão mais recente do Windows Server.

— Crypt32
fonte