-1

Is AD CA (AD Certificate Services properly configured) all that's needed for (SSL certs on) internally facing sites to be trusted w/o any additional configuration on domain-joined clients?

Say:

  1. Active Directory Certification Authority is properly installed
  2. Certificates to internally facing sites are properly issued and are valid
  3. No other certificates (e.g. "retail" SSL certificates from Digicert or others) are used

Will browsers such as current versions of Chrome, Edge, Safari, etc. on AD-joined computers "trust" SSL certs on those internally facing sites? (E.g. vCenter or SolarWinds web UIs.)

If not, what are the steps to get them trusted?

If yes, and the certificates still show as invalid, what are the steps to troubleshoot the issue? (Which logs to look at, how to isolate the issue to a specific part in the cert chain and how to remedy it from there, etc.)

Reason I ask: the AD CA seems to be functioning well as domain-joining new computers is smooth with no issues, and existing domain services seem to be working OK. However any internally facing sites we have are flagged as not secure despite seemingly having valid AD CA certificates.

connection not secure, certificate not valid

certificate details

(Windows Server 2016 with AD DS, CS roles installed, CS configured.)

P.S.:

  • I anticipate the above info may not be enough to determine what's wrong and will be happy to supply more information and amend this question.
  • I am on my 3rd day in this rabbit hole and saw in several places that the answer to the title question might be a "yes" - but have yet to find it stated authoritatively in MS AD docs, or demonstrated somewhere, and have yet to find guidance on how to troubleshoot common issues.

What I am looking for is something like this:

  1. What are the steps (if any) for an SSL cert for https://dc01.mydomain.com to be trusted by Chrome running on a domain-joined computer, and where:
  • mydomain.com is the AD domain,
  • dc01.mydomain.com is the default IIS site on an AD DC with CS/CA (Certificate Services / Certification Authority role) installed,
  • this is a freshly deployed simplest-possible AD setup using default installation choices where possible?
  1. If something breaks in the above setup, and Chrome now flags https://dc01.mydomain.com as having an invalid SSL cert despite the cert not showing any issues (like being expired), what are the common root causes, and how does one go about troubleshooting them?
4
  • 1
    The certificates are only trusted if the trust-anchor (the topmost CA) is trusted by the relying parties (the clients). You need to distribute this trust-anchor to all. Within AD, group policy or AD can distribute them. Outside of the AD forest, you will need to distribute them manually (somehow). Commented Sep 25, 2023 at 21:03
  • 1
    I just noticed that your screenshot shows only the root CA certificate; it is not showing the server certificate (the one that's actually supposed to have Subject: CN=dc01.mydomain.com). Do you actually have that issued or not yet? Commented Sep 26, 2023 at 16:05
  • this looks to have hit the nail on the head - I may have issued it but imported / assigned the wrong one - let me poke around Commented Sep 26, 2023 at 16:06
  • Getting somewhere - thank you! When using the server cert in IIS bindings for the site (instead of the root one), the site (https://dc01.mydomain.com/certsrv) is now "secure" in Chrome and Edge - both when accessed from the local server (dc01.mydomain.com) (but not https://localhost/, interestingly), and from several other computers I tried - all without a GPO pushing any of these certs out (that I know of). Now I need to retrace my steps as I can't yet replicate this for another internally facing site... :) Commented Sep 26, 2023 at 20:23

1 Answer 1

2

What are the steps (if any) for an SSL cert for https://dc01.mydomain.com to be trusted by Chrome running on a domain-joined computer, and where:

As far as I know, a private CA root certificate must be deployed via Group Policy, even if it's an AD CS managed CA. (There's no implicit assumption of what audience the AD CS managed CA is meant for – if it's for your machines, you need to deploy it there.)

So the first step would be to create a GPO with your CA certificate added to "Computer → Windows Settings → Security Settings → Public Key Policies → Trusted Root CAs".

(Many tutorials omit this step because they show usage of AD CS to issue client auth certificates, where the root is only needed either on the server (verifying) side, or in a special AD store for DCs – but that's not your situation here.)

If something breaks in the above setup, and Chrome now flags https://dc01.mydomain.com as having an invalid SSL cert despite the cert not showing any issues (like being expired), what are the common root causes, and how does one go about troubleshooting them?

Same procedures as with any other CA. If it shows up as "expired", literally check the dates. (Of both the server certificate and the CA certificate!) If it shows up as "unknown issuer", go to certmgr.msc and check whether the issuer CA has been deployed there or not.

Firefox traditionally uses its separate root database as part of its NSS TLS library; in recent versions it can read Windows roots, but you may need to enable security.enterprise_roots.enabled (I believe there's a Firefox GPO for that).

5
  • Thank you. The cert in question shows no issues (that I can see), just says "invalid". Commented Sep 26, 2023 at 15:25
  • I think you're answering question 1 without the additional context of it (that I just need to demonstrate the concept of Chrome or Edge on a single machine, trusting something like dc01.localdomain.com w/o involving an external cert facility, and the minimum steps to get there.) Do I, for instance, need a GPO in this case? Can I install the cert manually? Could I use the web enrollment feature of CS/CA to issue a cert - if it is needed at all? I'll go spin up an air gapped Win Server and experiment to get an answer. (Thanks!) Commented Sep 26, 2023 at 15:37
  • 1
    It doesn't matter how you install the CA certs (GPO or manually), as long as they're installed into the right store (Trusted Root Certificate Authorities). I'm not sure about web enrollment; so far I've only used the built-in enrollment ("Request Certificate") in certmgr.msc. Commented Sep 26, 2023 at 16:02
  • Can you think of where I can see detailed steps for a 10-year old (i.e. easy to follow, missing nothing) on how to do this? (built-in enrollment ("Request Certificate") in certmgr.msc)? E.g.: do I run this from the CA machine? From the machine running an intranet IIS site where I need the SSL cert? Is it "All tasks" -> "Request New Certificate..."? Does it matter which folder? What should the choices be while requesting a cert? (I don't see a "server" option - only "Administrator", "Basic EFS", "EFS Recovery Agent", and "User".) Thanks! Commented Sep 27, 2023 at 21:23
  • P.S. Would you mind updating your answer if a GPO is not a must? (It wasn't a must, it seems, for https://dc01.mydomain.com/certsrv to be trusted on all AD computers in the network. It's probably not a must for a single client machine POC I described in my question.) Commented Sep 27, 2023 at 21:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .