O erro que você está recebendo não é que ele não seja um certificado raiz confiável, mas que não é possível verificar a cadeia para um certificado confiável. Se alguma parte da cadeia estiver quebrada, não confiável ou ausente, você receberá tal erro. O erro que recebo com uma raiz auto-assinada não confiável é: Este certificado raiz da CA não é confiável. Para habilitar a confiança, instale esse certificado no armazenamento das Autoridades de Certificação Raiz Confiáveis. Mas para você, ele diz que não pode verificar até um certificado raiz confiável. Isso pode acontecer porque, durante o processo de auto-assinatura, você pode ter dito ao openssl para assinar o certificado com uma raiz diferente (que não é auto-assinatura) ou pode não ter sido definida como uma CA raiz. Se for o primeiro, você deve confiar na raiz com a qual ele foi assinado. Se é o último, é uma questão de configurar algumas propriedades em openssl.conf.
Por que o Windows 2012 R2 não confia em meu certificado autoassinado?
Em um ambiente de teste, estou atualmente sendo impedido de testar algumas coisas que precisam ser implantadas em breve (na verdade, mas você sabe como os prazos terminam ...) porque o Windows se recusa a confiar no certificado autoassinado tem em nosso ambiente de teste isolado. Embora eu possa apenas evitar o problema com o certificado "real" e alguns truques de DNS, por razões de segurança / compartimentalização, eu não disse o certificado.
Estou tentando conectar-me a um servidor de e-mail baseado em Linux chamado Zimbra; ele está usando um certificado OpenSSL autoassinado gerado automaticamente. Embora as páginas que o Google criou se refiram especificamente a sites do IIS com certificados auto-assinados do IIS, não acho que o método de geração realmente importe.
De acordo com as instruções, encontrei aqui e aqui , isso deve ser uma simples questão de instalar o certificado no armazenamento da Autoridade de Certificação Raiz Confiável do computador local. O que fiz, além de copiar manualmente o certificado e importá-lo diretamente pelo snap-in do MMC. Logout e reinicializações não alteram nada.
Aqui está o erro de certificado que recebo sempre:
Eaquiestáocaminhodecertificação(spoiler:éapenasoprópriocertificado):
Por fim, aqui está o certificado guardado com segurança no armazenamento de certificados do computador local, exatamente como as instruções que eu encontrei dizem que devem ser:
Essas instruções fazem referência especificamente ao Vista (bem, a segunda não menciona o SO) e ao IIS, enquanto eu estou usando o Server 2012 R2 conectando-me a um servidor baseado em Linux; Existem algumas diferenças no assistente de importação (como o meu tem a opção de importar para o usuário atual ou sistema local, embora eu tentei os dois), então talvez haja algo diferente que eu tenho que fazer aqui? Uma configuração em algum lugar que eu não encontrei que tem que ser alterada para realmente confiar no certificado em que eu já disse para confiar?
Qual é a maneira correta de tornar o Windows Server 2012 R2 confiável em um certificado autoassinado?
5 respostas
pelo que posso descobrir, você precisa adicionar o zmaster como uma CA de origem confiável, pois essa é a autoridade de emissão, o WS2k12 está tentando verificar o certificado em relação a um host sobre o qual não sabe nada. Você está certo em que o método de geração não é importante, mas é uma fonte verificável. Isso tem o efeito que você está experimentando: que o WS2k12 não está confiando em um certificado apenas porque ele tem um nome de $ Random_issuing_authority, ele precisa ser capaz de verificar o certificado.
Eu tive o mesmo problema, no final das contas, minha solução era atualizar os arquivos .crt e .key para o servidor de email como usado pelo dovecot. O Exim4 no correio tinha um conjunto de cert / key atualizado, mas o dovecot ainda estava apontando para o conjunto de cert / key antigo.
O antigo par de certificados / chaves funcionou bem na maioria das situações, mas não no outlook.com nem no MS Outlook 2013.
Problemas com outlook.com fizeram com que eu atualizasse o certificado exim4 recentemente - agora o dovecot [e o servidor de webmail] também usa os novos arquivos de certificados (e chaves). O servidor de e-mail em si também foi recentemente atualizado [do antigo squeeze-lts para o wheezy], a configuração antiga estava bem ao redor com o antigo conjunto cert / key, mas após o upgrade, eu precisava criar o novo conjunto de cert / key antes Produtos MS funcionariam corretamente com o servidor de email.
Eu acho que o problema é como você acessou os recursos. Para sua rede local, você pode usar o nome do host em vez do nome completo do domínio. No entanto, o certificado é emitido contra o nome de domínio completo.
Instale o certificado para autoridades de certificação raiz confiáveis e editores confiáveis.