In a testing environment, I'm currently being held up from testing some things that need to be deployed soon (actually already, but you know how deadlines go...) because Windows refuses to trust the self-signed certificate we have in our isolated testing environment. While I could just side-step the issue with the "real" certificate and some DNS tricks, for security/compartmentalization reasons I don't have said certificate.
I am attempting to connect to a Linux-based email server called Zimbra; it is using an auto-generated self-signed OpenSSL certificate. While the pages Google has turned up specifically refer to IIS websites with IIS self-signed certificates, I don't think the method of generating it actually matters.
According to instructions I found here and here, this should be a simple matter of installing the certificate into the local computer's Trusted Root Certification Authority store. Which I've done, as well as manually copying the certificate and importing it directly via the MMC snap-in. Log-outs and reboots don't change anything.
Here's the certificate error I get every time:
And here's the Certification Path (spoiler: it's just the certificate itself):
Finally, here's the certificate safely tucked away in the local computer's certificate store, exactly as the instructions I've found say they should be:
These instructions specifically reference Vista (well, the second doesn't mention OS) and IIS, while I'm using Server 2012 R2 connecting to a Linux-based server; there are some differences in the import wizard (such as mine has the option to import for current user or local system, although I've tried both), so maybe there's something different that I have to do here? A setting somewhere I've not found that has to be changed to make it really truly trust the certificate I've already told it to trust?
What's the correct way to make Windows Server 2012 R2 trust a self-signed certificate?
from what I can work out you need to add zmaster as a Trusted source CA since that's the issuing authority, WS2k12 is trying to verify the certificate against a host it knows nothing about. You're right in that the generation method isn't important but a verifiable source is. This has the effect you're experiencing: that WS2k12 isn't trusting a certificate just because it has a name of $Random_issuing_authority, it needs to be able to verify the certificate.
The error you are receiving is not that it is not a trusted root certificate, but that it is not able to verify up the chain to a trusted certificate. If any part of the chain is broken, untrusted, or missing, you will receive such an error. The error that I get with an untrusted, self-signed root is this: This CA root certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities store. But for you, it says it cannot verify up to a trusted root certificate. This may be that during the self-signing process, you may have told openssl to sign the certificate with a different root (not self-sign), or it may not have been set as a root CA. If it's the first, you must trust the root it was signed with instead. If it's the latter, it's a matter of setting a few properties in openssl.conf.
I had the same problem, turns out my solution was to update the .crt and .key files for the mail server as used by dovecot. Exim4 on the mail had an updated cert/key set, but dovecot was still pointing to the old cert/key set.
The old cert/key pair worked fine with most situations, but not with outlook.com nor with MS Outlook 2013.
Problems with outlook.com caused me to upgrade the exim4 certificate recently -- now dovecot [and the webmail server] also uses the new cert (and key) files. The mail server itself was also recently upgraded [from old Debian squeeze-lts to wheezy], the old setup was fine all around with the old cert/key set, but after the upgrade, I needed to create the new cert/key set before MS products would work properly with the mail server.
I think the problem is that how did you access the resources. For your local network, you might using the host name instead of full domain name. However, you certificate is issued against the full domain name.
Install certificate to Trusted Root Certification Authorities and Trusted Publishers.