0

I am trying to setup an IPv6-only Exchange Server 2013, running on Server 2012 R2 Datacenter. This is a 1-machine-setup in a VirtualBox for testing purposes.

Everything is running ok so far. I.e. I can access the Exchange-OWA and send and receive emails to IPv6-enabled mail-providers.

However, I still cannot seem to get Outlook 2016 to connect. This seems to be related to my certificates. Also Chrome/IE accessing the OWA complain about the certificate, but this can be skipped, while for Outlook 2016 it's a stop.

Therefor, I installed the Certification Authority role on the server, configured it (Enterprise-CA, Root-CA), created a certificate in Exchange 2013, signed it by my CA (web enrollment) and enabled it in Exchange. So, if I access the OWA from the server, certificate is fine. Then I copied the certificate to the machine running my Outlook-client and imported it there (Windows 10 Home Premium x64). However, Chrome/IE still complain about a non-trusted issuer. My certificate shows up looking at the windows-certificate-store, but if I check Internet Options in Control Panel, I don't see my certificate. When I try to add it there, it says it worked, but it doesn't appear in the list.

Is it somehow necessary that the Root-CA (or a subordinate CA) is accessible by the client-machine to somehow verify that the certificate hasn't been revoked? Or am I missing something else? If it needs to be online, is there a way to do it without? This is not a production environment (and never supposed to become one) but just testing for IPv6-readyness.

TJJ
  • 130
  • 10
  • For what it's worth MS recommended that it should be 'considered good practice' to shutdown your root CA when not signing certificates. – Sum1sAdmin Apr 13 '16 at 13:41
  • I think they even recommend that the root CA shouldn't be reachable by any machine except for subordinate CA. This is to prevent it getting compromised (and subsequently all certificates signed by the root CA would become untrustworthy). – TJJ Apr 14 '16 at 10:57

2 Answers2

1

Well, I have to say I am sorry. But this whole topic is quite new to me. However, I've managed to find the solution to my problem on my own:

Of course it couldn't work because I only imported the Exchange-server's certificate in my client. This references my private root-CA as issuer. Since I didn't import my root-CA's certificate, my client could never trust the exchange certificate because it couldn't verify it with the root-CA's certificate. So, after I exported my root-CA's cert and imported it on my client to the "Trusted Root Certification Authorities"-store, the Exchange-cert became trusted as well. And subsequently Outlook 2016 connects perfectly.

While this solved my original problem, it doesn't answer my question, that came up: How can a certificate be revoked without connectivity to the issuer? I do have quite a lot of root-certificates in my store that don't seem to have any kind of URL or IP to check for their revocation status.

TJJ
  • 130
  • 10
1

As for your original question, the issue lies in the fact that your client had no way of identifying & validating the leaf certificate. For any machine to do the same, it must have the Public Cert of Root CA in its trust-store. Also, You did not need to copy the leaf certificate to the client.

As for the question you have placed in your answer, please look at Wikipedia:Revocation List TL;DR - You will need to manually propagate the CRL as you are the Root CA and its your responsibility

Shreekar Shetty
  • 26
  • 2