9

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: enter image description here

And here's the Certification Path (spoiler: it's just the certificate itself): enter image description here

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: enter image description here

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?

Kromey
  • 3,641
  • 4
  • 25
  • 30
  • Unable to reproduce your issue. If you use IIS's "Create a Self-Signed Certificate" and select to install it in the Personal store (also tried Web Hosting store), there is no issue at all. How did you create the certificate? From IIS or from Certification Authority MMC snapin ? –  Jun 14 '14 at 05:51
  • Have you tried selecting the destination store explicitly (importing from within the mmc console)? – JoaoCC Jun 15 '14 at 01:27
  • @SujaySarma It's not for an IIS website, but for a Linux application called Zimbra. It's an OpenSSL self-signed certificate. – Kromey Jun 15 '14 at 18:18
  • @user1703840 Yes, I've explicitly specified the destination store, as well as allowed Windows to select it automatically, via both the MMC and the certificate import wizard in IE. Same results either way, which is none. – Kromey Jun 15 '14 at 18:19
  • Huh? Where did Linux come from? Your entire question and the links you have posted (including your screenshots) deal with Windows Server 2012 R2 and IIS. Please clarify. –  Jun 17 '14 at 12:44
  • @SujaySarma Sorry for the confusion, I didn't think the source of the certificate or the nature of the server I was connecting to was relevant. The sources dealing with IIS were simply all I could find when Googling. The screenshots though don't have anything to do with IIS -- that's IE and MMC. I'll edit my question to clarify what I'm connecting to. – Kromey Jun 17 '14 at 14:21

5 Answers5

1

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.

James Gugelstuphukenmuch Moore
  • 11
  • 1
  • It's a self-signed cert - by placing the cert in the Trusted Root CA store you are by definition trusting the issuer. – Chris McKeown Jun 24 '14 at 23:39
  • Unless I'm missing something, that's exactly what I've done -- see the third screenshot showing zmaster's certificate within the Trusted Root CA store. – Kromey Jun 24 '14 at 23:43
1

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.

flashbang
  • 135
  • 1
  • 1
  • 11
  • The screenshots show that the certificate is installed in Trusted Root CA, and also show that the entire chain is the certificate itself -- it is the root, and therefore being in the Trusted Root CA should suffice. The question is why isn't it? – Kromey Jun 27 '14 at 14:45
  • I'm saying it might not be the root, not that it isn't added to the trusted roots store. The error is what's weird about it - it shouldn't say it can't verify it up to a trusted CA, if it's *supposed to be* a CA - which is why I'm suggesting that it's not actually a root, but signed with another certificate. – flashbang Jun 27 '14 at 15:21
  • try running this command on the box you're trying to get the certificate for: `openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30 -sha256 -nodes` and importing that certificate into the trusted root CA store. (as well as configuring it to be the cert and key used by Zimbra, of course). – flashbang Jun 27 '14 at 15:24
  • Oh, I see what you mean. Sorry, I misunderstood. But if it isn't the root, shouldn't that show up in the Certification Path window? In any case, unfortunately, I can't actually test this any further -- I managed to get hold of our legit certificate, and along with a bit of hacking in the `hosts` file got it working that way. – Kromey Jun 27 '14 at 16:24
  • Your certificate is from a root CA, based on the screen shot. If you look at the certificate details for https://idp.godaddy.com/ the whole path is presented and you can use that as a comparison. If you look at the properties of the certificate in MMC, does it include server authentication in the certificate purposes? (Right click over the cert in second screen shot and select properties). – John Auld Jun 27 '14 at 17:18
  • @Kromey If it chains to a root/subordinate certificate that your OS does not have in its stores then it won't show up in the certification path, because your computer doesn't know what the certificate above it is (or where to find it). – flashbang Jun 27 '14 at 22:55
  • @JohnAuld Yes it does; while I didn't know there were "purposes" going into this, I did find those and make sure they were set for what I needed (actually for "Everything"!) while trying to troubleshoot. – Kromey Jun 27 '14 at 23:02
  • @user3131004 Hm, that's not how I understood certificates to work, but that does make sense. I've gone ahead and accepted your answer, because you do make a lot of sense here -- I just wish you'd come in a little sooner so I could have found if it actually worked for my problem! – Kromey Jun 27 '14 at 23:03
  • Thank you! Yes, certificates all chain to a certificate above them (or a root, which does not, obviously). If any part of this chain is broken, missing, revoked, or invalid, all certificates below that fail authenticity checks. When a server sends certificates, it must send the entire chain (sans root - this is the client's job to possess). Each certificate sent by the server must "validate" the certificate sent before/below it. If your computer does not possess the root, but a certificate is issued with that root, it can't verify its authenticity, and you get the error that you were getting. – flashbang Jun 27 '14 at 23:11
0

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.

Andrew McGlashan
  • 101
  • 1
  • 2
0

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.

puffel
  • 1
-1

Install certificate to Trusted Root Certification Authorities and Trusted Publishers.

Dimaf
  • 181
  • 1
  • 7