É possível confiar em um certificado no Windows, sem confiar na autoridade de certificação raiz?

É possível fazer com que o Windows confie em um certificado, sem que ele confie na CA raiz como uma CA raiz confiável?

digamos que tenho a seguinte cadeia de certificados,

Dept-Root-CA
Dept-Intermediate-1
Server-Certificate

Desejo confiar no certificado do servidor, mas não quero confiar no Dept-Root-CA porque ele poderia assinar qualquer certificado e meus servidores confiariam nele. Só porque estou disposto a confiar no certificado do Server-Certificate para uma operação específica, não significa que estou disposto a confiar que o Dept-Root-CA foi devidamente protegido.

obrigado

windows ssl

— bkr
fonte

Em que exatamente você quer confiar? HTTPS? Ou alguma outra coisa? Não são formas de indicar que deseja aceitar um único certificado sem aceitar qualquer outra coisa da CA raiz, mas isso depende do que você está fazendo. (Você ainda vai ter erros se você tentar validar o certificado embora)

— Mark Henderson

Essencialmente sim. Se fosse um código personalizado, não seria um problema - mas isso é usar o ADFS 2 e a única coisa que posso fazer em relação à forma como trata os certificados é mudar a forma como o servidor confia nesse certificado. Existem outros casos também, mas este é apenas o exemplo atual.

— BKR

Respostas:

Não. Enquanto o certificado indicar "Emitido por: xxx", você também deve confiar em xxx, por toda a cadeia. Se for um certificado autoassinado, você poderá colocá-lo no armazenamento de CAs raiz confiáveis e, como é emitido e emitido pela mesma entidade, ele deve ser confiável.

Mas não, geralmente não é possível ou aconselhável contornar completamente todo o objetivo da segurança baseada em certificado.

— Ryan Ries
fonte

Eu estava com medo daquilo. Eu não chamaria isso de contornar. Só porque quero um canal seguro para conversar com uma máquina em um grupo organizacional diferente não significa que quero confiar na autoridade de certificação deles.

— BKR

Certo ... mas a CA assinou esse certificado e, sem esse certificado, a outra extremidade pode continuar alterando seu certificado.

— precisa

Não sei se entendi o que você está dizendo. Quero confiar explicitamente no certificado deles. Se foi alterado, eu gostaria de confiar explicitamente novamente. Eu basicamente quero o modelo de confiança de certificado como existe no Firefox. No Firefox, se o certificado não for válido sob as CAs confiáveis existentes, você poderá confiar nele de qualquer maneira - se ele mudar, será necessário confiar no novo certificado porque não é explicitamente confiável.

— BKR

just keep changing their certificateSe a extremidade remota alterar seu certificado, não corresponderá ao que você salvou. Se você ignora todos os negócios da CA, não está apenas tratando-o como chaves de host SSH.

— Zoredache

realisticamente, eles só mudam uma vez a cada 2 anos. o produto MS que estou usando requer que a conexão seja protegida por https. por isso tem que ser confiável. como foi assinado com a autoridade de certificação, eu teria que confiar na autoridade de certificação - não quero fazer isso, porque isso permitiria falsificar qualquer certificado para o meu servidor, em vez de permitir interação limitada com um nome de host específico.

— BKR

Bem ... Você pode capturar essas informações de confiança de outra maneira.

Infelizmente, é um pouco complicado.

Crie sua própria autoridade de certificação e, em seguida, crie seu próprio emissor de assinatura cruzada para o Departamento Intermediário-1 (ou Departamento-Raiz-CA) assinando o certificado com a autoridade de certificação, possivelmente adicionando restrições de domínio. Se o Dep-Intermediate-1 "real" estiver desativado (preferencialmente) ou desconhecido, o Windows usará sua cadeia de confiança.

Veja minha outra resposta aqui: Restringir um certificado raiz a um domínio

É assim que os certificados devem funcionar, usando assinaturas digitais para representar uma afirmação de propriedade da chave. Como você deseja afirmar que o certificado e a chave pertencem ao servidor, você mesmo o assina, sob sua autoridade e, em seguida, diz ao sistema para confiar em você.

Ainda há muita utilidade em um certificado sem uma hierarquia de CA, acima do que as chaves SSH fornecem; parte disso são as restrições sobre eles. Uso principal, datas de validade, informações de revogação, restrições de domínio, etc. A outra parte é a informação de identificação; servidor que possui a chave, identidade do emissor, políticas de CA aplicadas, informações de armazenamento de chaves etc.

— davenpcj
fonte

Isto é interessante. Vou ter que encontrar algum tempo para tentar trabalhar com esse processo e ver se consigo fazê-lo funcionar.

— BKR