0

The question is purely about whether this config is capable of issuing valid intranet SSL certs (i.e. SSL certs for internally facing sites), and not any other implications or concerns.

(The focus of the question isn't security, availability, continuity, disaster recovery or any other implications or concerns other than the ability to issue valid SSL certs.)

Context: inherited an AD setup where the primary DC has a CS/CA role and no templates - which means the CA is "standalone", not "enterprise", confirmed via certutil -getreg ca\catype:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<masked>AD01-CA\CAType:

CAType REG_DWORD = 3 ENUM_STANDALONE_ROOTCA -- 3 CertUtil: -getreg command completed successfully.

There is also a "subordinate" CA running on a secondary DC that is "enterprise" (although its "templates" feature isn't working: "no templates found" errors when using Web Enrollment on it).

The question

Is this configuration ("standalone" root CA + "enterprise" subordinate CA) capable of issuing valid SSL certs for intranet sites like vCenter, SolarWinds, etc.?

Reason I ask:

Having a lot of trouble figuring out how to get a "trusted" SSL setup for internally facing (intranet) sites and could use any help I can get:

Figure this may have something to do with how CAs and DCs are currently set up.

If this is not OK and I need to switch to an "enterprise" CA, what's the easiest way to do so?

P.S. I am OK with it not being configured quite to specs with offline/online CAs and CAs not running on DCs - for now the only goal is to be able to issue good certificates to internally facing sites and apps.

Thanks!

4 Answers4

3

It is NOT OK to run any certificate services on domain controllers. They must be installed on member servers only.

There are two reasons for that:

  1. You won't be able to replace your domain controller if certificate services are installed on DC. As per best practices, DCs are replaced by adding new DC into network and then demoting and decommissioning old DC. You cannot demote DC with CA role. You will have to uninstall CA role first before you can demote DC.
  2. Microsoft Certification Authority is a forest-wide resource. And in multi-domain environments, admins in one domain may affect other domains they don't have permissions in.
Crypt32
  • 7,461
1

As others have said, it's not recommended to run a Certification Authority on a Domain Controller, regardless of it being stand-alone or Enterprise; also, what is even the point of installing a stand-alone CA on a domain computer (even more so on a DC)? The whole point of a stand-alone CA is not being integrated with Active Directory, it should run on a non-domain-joined computer.

Anyway, to answer your original question: while an Enterprise CA is automatically trusted by all domain members, a stand-alone CA is not; in order to make use of its certificates, and/or of certificates issued by a subordinate CA, you need everyone to trust its root certificate.

This can be done either using a GPO or using certutil; you can find more details here: Publish root CA and sub ca certificate to the Trusted root certificate store.

Massimo
  • 72,827
0

According to the Microsoft PKI Design Guide, a standalone CA on a domain controller should be used for lab environments. But it also depends on your organizations security policy.

Regarding trusted SSL, you would need to have the certificate chain available on devices. That could be the root ca certificate and if used the intermediate ca certificate. Using a group policy you can distribute the ca certificates to the clients.

Ace
  • 812
-3

Yes, it can, and is a valid setup for SSL cert issuance even if it doesn't follow best security hardening practices.

  • Note that the question isn't about security or any other implications, or whether this is a valid setup in production environment. The question was raised purely to resolve a problem of CA-issued intranet SSL certs not being trusted by browsers.
  • Any other purposes, concerns and implications - other than SSL cert issuance - such as security, maintenance, configuration changes, etc. - are not in play here..
  • Purely for intranet SSL cert issuance, this config appears to be valid. (Not sure if it bears repeating - yet the existing two answers seem confused about what the question is despite reiterating this in the text of the question.)
  • Yes, it's not the best practice to have a CS/CA (Certificate Services / Certification Authority) role installed on a DC (as mentioned e.g. here) - yet that has nothing to do with the question.

Reason why I believe so:

  • see no indications this is not a valid setup in Microsoft docs or other places (that it's not the best practice or even "strongly advised against" is irrelevant for the purpose of this question)
  • Microsoft's warning, "Never install a certification authority on a domain controller in a production environment" only appears in one place of all Microsoft docs: under "Lab-based PKI" in their "Configure and validate the Public Key Infrastructure - on-premises certificate trust".
    • The fact that it's under "Lab-based PKI" and not under, say, "Deploy an enterprise certification authority", tells me that it may only be relevant to... a "Lab-based PKI", and may not be a strict guideline for every other possible setup.
    • In all other places where it's advised to not install a CA on a DC (e.g. in "Additional Roles on Certification Authorities" - which is a section in "Securing PKI: Technical Controls for Securing PKI") - it's clear that it's not a hard requirement, but a recommendation from security and maintenance aspects.

P.S.

  • I am very far from being an SME on this - this answer is based purely on reading relevant docs and a summary of comments on other answers, with the hope it'll help someone else in a similar situation. If a better answer shows up, I'll mark it as the answer.
  • The whole reason I asked this question was this: could this ("standalone" root CA + "subordinate" enterprise CA) be an invalid config and the reason SSL certs get flagged as invalid in my environment? The answer appears to be a "no": this is not the reason our CA-issued SSL certs aren't trusted by our browsers - regardless of how ill-advised is to run a CA on a DC, it's something else. Onward... :)