Criei uma Autoridade de Certificação raiz autoassinada para alguns serviços internos em nossa empresa, que eu mesmo configurei (principalmente em HTTPS). Em seguida, criei certificados para esses serviços, assinados com essa CA.
Agora, quero adicionar uma extensão x509 (ponto de distribuição da CRL) à autoridade de certificação raiz sem invalidar os certificados de servidor existentes emitidos por essa autoridade de certificação. Isso é possível?
Minha intuição é "sim" porque, pelo que entendi, o acesso à chave privada correspondente é necessário e suficiente para "autoridade total" sobre a identidade do certificado. Ou seja, a menos que haja algum tipo de nonce incorporado junto com a chave pública no certificado quando ele é gerado (provável).
Ainda sou bastante novo no gerenciamento de certificados SSL, mas acho que entendo o básico da cadeia de confiança padrão. Também me sinto confortável com o uso básico de outras criptografia PKI: gerencio chaves SSH e uso o GPG para assinatura e criptografia. Estudei Ciência da Computação, apesar de ser apenas um praticante autodidata de criptografia.
Eu nunca fiz um CSR para o IIRC original (acho que foi a saída direta de openssl req -new -x509). Ainda tenho a chave privada da CA original, é claro, e usando-a pude "reverter" o certificado original em uma Solicitação de assinatura de certificado:
openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key
Eu esperava que isso "extraísse" efetivamente o nonce mencionado acima e me permitisse recriar o certificado, mas desta vez com um crlDistributionPointscampo e, consequentemente, todos os certificados assinados com a CA original ainda validariam essa nova CA, com exceção que os clientes recuperariam meu arquivo CRL (atualmente vazio) do URL HTTP designado no campo.
Então eu fiz um arquivo de configuração de extensão ext.conf:
[ cert_ext ]
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl
E eu gerei a nova versão da CA raiz a partir do CSR:
openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem
Agora, quando vejo o certificado com openssl x509 -text -in MyNewCA.pem | less
Eu posso ver a parte da extensão da CRL:
X509v3 extensions:
X509v3 Subject Key Identifier:
82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl`
Mas ai! Meus certificados assinados anteriormente não são mais validados com relação a este:
openssl verify -verbose -CAfile MyCA.pem git.pem
git.pem: OK
openssl verify -verbose -CAfile MyNewCA.pem git.pem
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate
Principalmente, estou procurando mais informações sobre como os certificados funcionam e por que. Mas também gostaria de ter uma solução para o problema que leva a este, então aqui estão algumas informações básicas.
Como entrei nessa bagunça: o HTTPS para serviços internos funciona muito bem quando minha CA é instalada por meio do RMB do Explorer → Instalar a GUI do certificado no Windows, ou /usr/local/share/ca-certificatesseguida pelo update-ca-certificatesDebian e Ubuntu. Mas recentemente deparei com uma exceção: Git no Windows, especificamente se instalado para usar o Windows Secure Channel como back-end SSL. Aparentemente, por padrão, insiste que deve haver um campo CRL nos certificados SSL.
Então, acho que é realmente um problema do Windows Secure Channel porque a mensagem de erro em que continuo sendo exibida parece inteiramente específica da Microsoft: fatal: unable to access 'https://angery@git.mycompany.co.za/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
Se eu instalar o Git com OpenSSL e concatenar manualmente minha CA no arquivo apontado por git.http.sslcainfo, ele funcionará, mas temo que meus usuários estejam inclinados a não verificar a identidade SSL se acharem que esse processo é mais trabalhoso do que clicando na GUI "fácil" do instalador de certificados do Windows.
-x509toreqisso recuperasse todas as informações exclusivas da CA raiz existente, mas isso não ocorre ou há algo errado com meu processo a partir daí.
req -new -x509e x509 -req -signkeyambos padronizam a série do certificado autoassinado como um número aleatório (embora isso possa ser substituído) efetivamente um nonce. Se o seu certificado filho (ou qualquer um deles) contiver AuthorityKeyIdentifier usando a opção 'issuer + serial' (em vez de ou além da opção 'keyid'), esse será o caso se você tiver usado cao arquivo de configuração padrão upstream, precisa criar a nova raiz com a mesma serial que a antiga; use -set_serial. ...