É possível restringir o uso de um certificado raiz a um domínio


28

Meu cliente usa um certificado autoassinado para que um aplicativo funcione. Para poder trabalhar, tenho que instalar o certificado raiz que eles usaram para assinar o certificado.

É possível configurar um certificado raiz para que valide apenas para um domínio?


Pode ser apenas eu, mas não estou claro o que você está realmente perguntando. Que estado final você está tentando alcançar? Se você importar o seu certificado raiz para a confiança controladores de domínio, em seguida, apenas os sistemas sob esse domínio seria capaz de validar contra ela ...
Gravy

Parece que você está confundindo certificados autoassinados com o uso de uma CA raiz que não é publicamente confiável.Um aplicativo configurado para usar um certificado autoassinado é muito ruim, pois o aplicativo precisaria ser configurado para ignorar erros de validação de certificado. Usar uma autoridade de certificação raiz que não seja confiável publicamente é realmente bastante comum.
Greg Askew

você tem um servidor CA interno?
Crypt32

1
Uma autoridade de certificação pode se restringir a determinados domínios com restrições de nome , mas a aplicação retroativa de restrições à autoridade de certificação de outra pessoa é outra questão.
Matt Nordhoff

3
não há diferença. Você também pode aplicar restrições de nome a uma autoridade de certificação de terceiros. Você acabou de assinar o certificado de CA raiz de terceiros usando sua CA privada e publicar o certificado cruzado gerado. Nesse caso, a cadeia estrangeira terminará na sua cadeia privada por meio de certificado cruzado restrito.
Crypt32

Respostas:


24

Como um princípio básico:

Não , implícita na confiança no certificado de CA do cliente está a confiança em todos os certificados assinados por essa CA.

Não conheço aplicativos / bibliotecas que tenham uma opção fácil que permita ao usuário final selecionar que confiará em seus clientes ou em qualquer outro certificado CA apenas para determinados (sub-) domínios, ou seja, apenas para *. example.com e * .example.org e mais nada.

A Mozilla tem uma preocupação semelhante com as CAs patrocinadas pelo governo atualmente confiáveis ​​como um ponto de atenção aberta e, por exemplo, o Chrome possui verificações extras para acessar sites do Google, e foi assim que o certificado invasor * .google.com e o comprometimento da CA Diginotar se tornaram públicos .

Porém, mesmo se você não confiar na CA, ainda poderá importar / confiar em um certificado de servidor específico assinado por essa CA, o que impedirá avisos de SSL para os nomes de host nesse certificado. Isso deve fazer seu aplicativo funcionar sem erros ou reclamações.

Exceções:

Uma opção muito subutilizada do padrão X.509v3 PKI é a extensão Name Constraints , que permite que um certificado CA contenha listas brancas e negras de padrões de nomes de domínio para os quais está autorizado a emitir certificados.

Você pode ter sorte e seu cliente se restringiu ao configurar sua infraestrutura de PKI e incluiu essa restrição de nome no certificado de CA. Em seguida, você pode importar o certificado da CA diretamente e saber que ele só pode validar um intervalo limitado de nomes de domínio.


2
@CryptoGuy: uma CA interna também pode emitir certificados para domínios externos. Uma vez que você confia no seu CA interna não há nenhuma restrição de tal forma que apenas os certificados para o seu próprio domínio (Active Directory ou DNS) example.comou *.ad.example.com são válidos. Sua CA interna também pode emitir certificados para *.example.bankpermitir um bom ataque intermediário e espionar suas credenciais bancárias online.
21715 HBruijn

1
Bem, "tudo" não é perfeitamente preciso. Existem coisas como listas de revogação de certificados. Mas isso não muda a linha de fundo.
Ben Voigt

1
desculpe, você está incorreto novamente. Você pode restringir a autoridade de certificação de terceiros a confiar nos certificados (dessa autoridade de certificação) emitidos para a lista de nomes desejada. Em relação à sua própria CA interna, assumo a confiança sem dúvida. Se você não confia em sua própria CA, algo está errado com sua TI. Quero dizer que, tendo uma autoridade de certificação privada, o OP pode estabelecer uma confiança parcial para uma autoridade de certificação de terceiros (limitando os nomes em que eles confiam).
Crypt32

3
Para sua postagem editada: mesmo que a CA de terceiros não possua a extensão de restrições de nome, é possível aplicá-las usando seu próprio servidor CA interno por meio de certificação cruzada. Nesse caso, a cadeia de certificados será a seguinte: certificado SSL em folha -> certificado cruzado -> seu certificado CA -> seu certificado raiz interno. O truque é que você assine uma autoridade de certificação de terceiros usando sua autoridade de certificação interna. E o certificado cruzado terá todas as restrições necessárias.
Crypt32

1
A CryptoGuy diz que isso é possível, mas encontrar detalhes de implementação é um desafio. Que tal uma resposta descrevendo como isso pode ser feito? E talvez uma discussão sobre quais plataformas suportam nameConstraints.
jorfus

17

A @CryptoGuy teve uma resposta muito boa aqui, mas eu queria expandir.

Parafrasear:

Você pode restringir a autoridade de certificação de terceiros a confiar nos certificados (dessa autoridade de certificação) emitidos para a lista de nomes desejada. Mesmo que a CA de terceiros não possua a extensão de restrições de nome, é possível aplicá-las usando seu próprio servidor de CA interno por meio de certificação cruzada. O truque é que você assine uma autoridade de certificação de terceiros usando sua autoridade de certificação interna.

certificado SSL leaf -> certificado cruzado -> seu certificado CA -> seu certificado raiz interno.

E aqui está como você faz isso funcionar (usando a linha de comando CA do OpenSSL)

Crie uma CA simples

openssl req -new -x509 -days 3650 -newkey rsa:2048 -sha256 -out root-ca.crt -keyout root-ca.key -subj "/CN=My Root CA"

Você pode pular a criação de uma CA intermediária

Crie uma solicitação CA intermediária, com restrições de nome.

openssl req -new -days 3650 -newkey rsa:2048 -out domain-ca.req -sha256 -keyout domain-ca.key -config ossl_domain_com.cfg

Com isso no ossl_domain_com.cfgarquivo:

[ req ]
prompt=no
distinguished_name=req_distinguished_name
req_extensions=domain_ca

[ req_distinguished_name ]
CN=somedomain.com trust CA

[ domain_ca ]
basicConstraints=critical,CA:true,pathlen:1
nameConstraints=critical,permitted;DNS:.somedomain.com

Em seguida, assine a autoridade de certificação de domínio intermediário com sua autoridade de certificação.

openssl x509 -req -in domain-ca.req -CA root-ca.crt -CAkey root-ca.key -sha256 -set_serial 1 -out domain-ca.crt -extensions domain_ca -extfile ossl_domain_com.cfg

Se você deixou de criar o intermediário, use sua CA raiz para assinar

Agora, assine novamente a CA do domínio original sob sua autoridade, usando o certificado. Você pode adicionar as extensões da CA aqui.

openssl x509 -in third_party_ca.crt -CA domain-ca.crt -CAkey domain-ca.key -set_serial 47 -sha256 -extensions domain_ca -extfile ossl_domain_com.cfg -out domain-cross-ca.crt

Pode ser necessário usar o -x509-to-reqargumento para criar uma solicitação, assinada exatamente da mesma maneira que o intermediário acima.

Agora, adicione sua CA raiz, CA intermediária e o domínio cruzado ao banco de dados confiável do seu navegador.


2
O MacOS não suporta nameConstraints. FIY apenas para quem trabalha em um nome interno restrito CA. security.stackexchange.com/questions/95600/... archive.is/6Clgb
jorfus

P: qual é o status desta solução? Em que sistemas ele funciona atualmente (2018)? // Eu queria isso toda vez que sou obrigado a instalar outro certificado autoassinado pela empresa; e sempre que penso nos Correios de Hong Kong ou na Symantec. // Acho que talvez eu não me importe, pois ninguém implementa o estreitamento descrito, desde que eles não implementem acidentalmente um alargamento.
Krazy Glew

@KrazyGlew Tenho um arquivo em lotes que uso para isso e ainda o uso regularmente. Ocasionalmente, tenho que reemitir os certificados intermediários à medida que expiram ou giram, por isso é um pouco mais manual, mas não tem sido um problema. Ocasionalmente, executo sites gerenciados por autoridade em que meu navegador não confia devido ao uso de uma autoridade intermediária diferente ou por um nome de domínio extra que eles adicionaram, no qual o meu não confia.
Davidpcj

2
Acabei de usá-lo com sucesso, obrigado. Funciona muito bem sem o certificado intermediário. Existe alguma vantagem em usar um? Além disso, a basicConstraintslinha no arquivo de configuração parece fazer com que a extensão de restrições seja incluída no certificado duas vezes, o que faz com que o Firefox rejeite o certificado com uma mensagem de erro enigmática. Eu acho que pode ser removido com segurança.
wrtlprnft

Eu recebo um erro no último passo: error with certificate to be certified - should be self signed. O que significa e como resolver isso? pastebin.ubuntu.com/p/QHhpQh2N6J
mymedia 10/09
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.