Por que o Windows 2012 R2 não confia no meu certificado autoassinado?

Em um ambiente de teste, atualmente estou impedido de testar algumas coisas que precisam ser implantadas em breve (na verdade já, mas você sabe como vão os prazos ...) porque o Windows se recusa a confiar no certificado autoassinado que temos em nosso ambiente de teste isolado. Embora eu pudesse resolver o problema com o certificado "real" e alguns truques de DNS, por razões de segurança / compartimentação, não tenho o certificado.

Estou tentando me conectar a um servidor de email baseado em Linux chamado Zimbra; está usando um certificado OpenSSL autoassinado gerado automaticamente. Embora as páginas que o Google tenha exibido especificamente se refiram a sites do IIS com certificados autoassinados, não acho que o método de gerá-lo realmente seja importante.

De acordo com as instruções encontradas 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 eu fiz, além de copiar manualmente o certificado e importá-lo diretamente pelo snap-in do MMC. Log-outs e reinicializações não mudam nada.

Aqui está o erro de certificado que recebo sempre:

E aqui está o caminho da certificação (spoiler: é apenas o próprio certificado):

Finalmente, aqui está o certificado guardado com segurança no repositório de certificados do computador local, exatamente como as instruções que encontrei dizem que deveriam ser:

Essas instruções referenciam especificamente o Vista (bem, o segundo não menciona o SO) e o IIS, enquanto estou usando o Server 2012 R2 conectando 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 tenha tentado os dois), então talvez haja algo diferente que eu precise fazer aqui? Uma configuração em algum lugar que não encontrei que precisa ser alterada para que realmente confie no certificado em que eu já disse para confiar?

Qual é a maneira correta de fazer com que o Windows Server 2012 R2 confie em um certificado autoassinado?

O erro que você está recebendo não é que não é um certificado raiz confiável, mas que não é capaz de verificar a cadeia para um certificado confiável. Se alguma parte da cadeia estiver quebrada, não confiável ou ausente, você receberá esse erro. O erro que recebo com uma raiz auto-assinada não confiávelé este: Este certificado raiz da CA não é confiável. Para habilitar a confiança, instale este certificado no armazenamento Autoridades de Certificação Raiz Confiáveis. Mas para você, ele diz que não pode verificar até um certificado raiz confiável. Pode ser que, durante o processo de autoassinatura, você tenha solicitado ao openssl para assinar o certificado com uma raiz diferente (não autoassinada) ou ele não tenha sido definido como uma CA raiz. Se for o primeiro, você deve confiar na raiz com a qual foi assinado. Se for o último, é uma questão de definir algumas propriedades no openssl.conf.

Pelo que pude descobrir, é necessário adicionar o zmaster como uma CA de origem confiável, já que essa é a autoridade emissora, o WS2k12 está tentando verificar o certificado em um host que não conhece 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á enfrentando: que o WS2k12 não está confiando em um certificado apenas porque tem o nome $ Random_issuing_authority, ele precisa poder verificar o certificado.

Eu tive o mesmo problema. Acontece que minha solução foi atualizar os arquivos .crt e .key para o servidor de email, conforme usado pelo dovecot. O Exim4 no correio tinha um conjunto de certificados / chaves atualizado, mas o dovecot ainda estava apontando para o conjunto de certificados / chaves antigo.

O antigo par cert / key funcionou bem na maioria das situações, mas não no outlook.com nem no MS Outlook 2013.

Problemas com o outlook.com me fizeram atualizar o certificado exim4 recentemente - agora o dovecot [e o servidor de webmail] também usa os novos arquivos de certificado (e chave). O próprio servidor de email também foi atualizado recentemente [do antigo Debian squeeze-lts para o wheezy], a configuração antiga estava boa em todo o conjunto de certificados / chaves antigo, mas após a atualização, eu precisei criar o novo conjunto de certificados / chaves antes Os produtos MS funcionariam corretamente com o servidor de email.

Eu acho que o problema é que 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, seu certificado é emitido no nome de domínio completo.

Instale o certificado nas autoridades de certificação raiz confiáveis ​​e nos editores confiáveis.