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?