O MS Certificate Services pode ser um subordinado à CA criado com o OpenSSL

Quero configurar uma autoridade de certificação corporativa para o meu domínio. Para que eu possa emitir certificados para vários propósitos. Gostaria de seguir as práticas recomendadas de ter uma autoridade de certificação offline como raiz e configurar minha autoridade de certificação corporativa como subordinada. Mas parece tolice licenciar uma cópia completa do Windows para esta tarefa.

O que espero fazer é instalar alguma distribuição ao vivo em um disco flash USB, instalar o openssl e configurar minha CA na unidade flash. Quando estiver pronto para criar a chave raiz / cert, desconectarei o computador da rede e nunca mais utilizarei esse disco USB em um computador conectado à rede novamente.

Poderei assinar e criar corretamente um certificado de autoridade de certificação subordinada para uma autoridade de certificação corporativa do Windows, que será utilizável. Quais opções eu preciso usar com o OpenSSL para criar a autoridade de certificação e assinar o certificado de autoridade de certificação subordinada corretamente.

Tentei pesquisar na web e essa foi a única coisa que pude encontrar sobre o assunto. Mas é anterior a 2008, e não tenho certeza absoluta de que a pessoa foi bem-sucedida.

Sim, funciona muito bem; uma autoridade de certificação do Windows não tem escrúpulos em executar como subordinado a uma raiz que não seja Windows.

Testado com uma raiz OpenSSL e um Windows 2008 R2 subordinado no modo Enterprise.

Algumas coisas a serem boas com o que a CA da Microsoft espera na configuração do OpenSSL:

• Locais válidos de AIA e CDP devem ser aplicados ao certificado raiz, na seção configurada pela x509_extensionspropriedade da [req]seção para a raiz autoassinada. Algo nesse sentido:

  authorityInfoAccess = caIssuers;URI:http://test-rootca.test.local/root.pem
  crlDistributionPoints = URI:http://test-rootca.test.local/root.crl
  

• Uma determinada configuração do OpenSSL provavelmente não permite CAs subordinadas por padrão. Altere isso para solicitações assinadas (verifique se isso não existe para solicitações que não devem ser CAs, é claro). Isso estará na seção configurada pela x509_extensionspropriedade da [ca]seção:

  basicConstraints=CA:TRUE
  certificatePolicies=2.5.29.32.0
  

Então, faremos uma autoridade de certificação para testar.

Faça sua raiz:

openssl req -new -x509 -keyout /etc/ssl/private/root.key -out /etc/ssl/certs/root.pem -nodes -extensions v3_ca

Brinque com sua configuração e crie os arquivos e diretórios necessários na [ca]seção de sua configuração do OpenSSL.

Tudo pronto para dar as caras da Microsoft; crie uma autoridade de certificação subordinada do Windows com assinatura manual.

Faça o upload da solicitação de certificado no servidor OpenSSL. Enquanto você estiver nisso, faça o download do certificado raiz. Importe-o para o armazenamento confiável de raízes - do computador, não do seu usuário!

Emita o certificado subordinado:

openssl ca -in test-subca.req
(you might need to specify a permissive policy manually with -policy, check your config)

Se isso não funcionou, é provável que sua CA tenha um problema com o diretório config - new certs, arquivo de índice, arquivo serial etc. Verifique a mensagem de erro.

Se foi, então é isso. Caso contrário, faça uma CRL e coloque-a no CDP que você configurou acima; Acabei de instalar o Apache e o atolou no webroot:

openssl ca -gencrl -out /var/www/root.crl

E coloque seu certificado no local da AIA, se ainda não estiver:

cp /etc/ssl/certs/root.pem /var/www/root.pem

Baixe o certificado subordinado recém-emitido e instale-o na CA com o snap-in MMC da Autoridade de Certificação. Ele se queixará de quaisquer problemas com confiança ou validação, mas não tem objeção moral em aceitá-lo.

Resultado final; uma CA do Windows em funcionamento, sem reclamar do snap-in Enterprise PKI, com um indicador OpenSSL Generated Certificatenos atributos.

Entendo o que você está dizendo, mas não acho que o OpenSSL seja a ferramenta ideal para o trabalho. Você pode querer olhar para projetos de Autoridade de Certificação de Código Aberto , como EJBCA, que são mais focados nessa funcionalidade do que o OpenSSL e ter documentação específica que você pode usar.

Não vejo uma razão para o conceito não funcionar, pois tudo o que você está fazendo é assinar o certificado da autoridade de certificação subordinada. Se você estivesse pagando uma CA pública para fazer isso por você, não necessariamente saberia ou se importaria com o sabor do servidor que eles estavam usando.

Tudo o que você precisa é se preocupar:

• você pode assinar o certificado do CSR gerado por seu subordinado
• o resultado pode ser instalado no próprio subordinado
• você tem um certificado de assinatura raiz que pode ser instalado como confiável em qualquer cliente que você esteja direcionando
• você pode gerar uma lista de revogação que é veiculada em algum lugar

Não posso dizer que fiz isso, mas tenho certeza que, se você seguir os documentos para gerar um CSR a partir de uma caixa do Windows, siga os documentos da CA para gerar um certificado .p7k a partir de um CSR, então tudo bem.

A propósito - eu recomendaria que você criasse sua CA como uma máquina virtual para um hipervisor popular, como Hyper-V ou VMware, em vez de um disco de inicialização, certifique-se de armazená-lo com muita segurança em algum lugar que seu sucessor possa encontrar e girá-lo fique off-line periodicamente para garantir a execução ou transfira-a para novas mídias / tecnologias. Uma CA raiz pode ter uma vida útil de 10 ou 20 anos ...