CA de Rede Interna: “Nome Comum Inválido” ou Certificado Inválido em tudo (exceto no Internet Explorer e no Windows 'Certificates mmc snapin)

Question

Nós executamos uma Autoridade de Certificação interna alimentada por um servidor Ubuntu 16.04 e um back-end OpenSSL para recursos internos, em um ambiente misto Windows / Linux.

Esta AC é usada com alguns sites internos na tentativa de fornecer certificados de site confiáveis e válidos para sites internos, implantações de software etc. Temos um problema.

O certificado da CA Root é enviado para todos os nossos sistemas Windows pelo GPO ou foi instalado manualmente. No entanto, todos os certificados assinados por essa AC acabam dando alguns problemas - Chrome e Firefox indicam que o certificado tem um nome comum inválido, enquanto outros utilitários, como um servidor XMPP aqui, não podem validar o certificado, mesmo se o certificado da CA estiver em os armazenamentos de confiança.

Somente o Internet Explorer respeita o certificado. Infelizmente, somos uma casa do Chrome e do Firefox, portanto, usar o IE para tudo será um problema.

Alguém descobriu uma solução para fazer um certificado OpenSSL CA e seus certificados assinados para certificados emitidos não terem um erro "Nome comum inválido" no Chrome e no Firefox e, assim, permitir que certificados internos sejam visto como 'válido'?

    

Answer 1

Eu realmente descobri o problema central, e foi preciso muita pesquisa. Finalmente encontrei uma resposta no StackOverflow , que combinou com a minha investigação sobre os dados reais no próprio certificado com openssl req -text -noout -verify -in CSR.csr para leia os dados no CSR, e openssl x509 -in certificate.crt -text -noout para dissecar o certificado gerado e comparar esses dois, apontou para o problema central.

Aparentemente , o OpenSSL estava ignorando a seção do nosso arquivo de configuração relacionado às extensões V3, e não faz as extensões v3, a menos que você diga para ele corretamente no etapa de assinatura da CA real ...

Estes foram os dados do arquivo de configuração que foram passados para o comando openssl req :

[ req ]
default_bits = 4096
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = v3_req

[ dn ]
C=US
ST=Pennsylvania
L=Somewhere
O=No Man's Land
OU=Internal
CN = chat.foo.bar.baz

[ v3_req ]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage=serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1   = chat.foo.bar.baz
DNS.2   = chat
DNS.3   = 10.1.2.151

Uma chamada padrão dos seguintes itens não respeita as extensões v3 de alguma forma:

openssl req -new -sha256 -out cert.csr -key cert.key -config csrgen.cnf

... no entanto, este funcionou:

openssl req -new -sha256 -out cert.csr -key cert.key -config csrgen.cnf -extensions v3_req

... e quando assina o certificado com o CA, nós tivemos que usar algo assim, executando isso de onde todos os certificados foram armazenados (incluindo o CSR e a chave, para gerar o certificado em primeiro lugar - os certificados e chaves da CA estão em uma seção /certauthority/... separada em nosso sistema):

openssl x509 -req -days 3650 -in ./cert.csr -CA /certauthority/certs/cacert.pem -CAkey /certauthority/private/cakey.pem -CAserial /certauthority/CA/serial -CAcreateserial -out certificate.crt -extfile csrgen.cnf -extensions v3_req

Este comando colocou corretamente as extensões v3 no certificado e, de alguma forma, ignorou as extensões reais do arquivo. Isso, por sua vez, solucionou os problemas de CN e SAN, e agora o sistema retorna o certificado como "válido" para sites internos e (mais) serviços internos.