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!

Improve this question
7
  • It takes less than five minutes to use certreq and an inf file to create a certificate. Doesn't get much easier than that. Usually if someone needs help they include what they are doing that isn't working.
    – Greg Askew
    Sep 28 at 11:35
  • 2
    "Never install a certification authority on a domain controller in a production environment." learn.microsoft.com/en-us/windows/security/identity-protection/…
    – Greg Askew
    Sep 28 at 11:36
  • create a certificate - maybe. Installing it properly and getting it trusted across the network - or even on a single machine? Haha. (I am a week into this, and not getting much closer: Can AD CA certificates for internally facing sites be inherently trusted?, lot more screenshots and what I tried here: "Can Orion use an AD CA issued SSL cert?"
    – kindzmarauli
    Sep 28 at 19:53
  • "Never install a certification authority on a domain controller in a production environment." is not applicable to the question. There is fairly specific context that it does apply to, in that article ("Hello for Business", security hardening, Lab-based PKI), none of which are in play here. I have not found this to be a requirement in any other MS docs, only a security hardening recommendation and best practice.
    – kindzmarauli
    Sep 29 at 14:58
  • The vendor PKI Design Guide describes Certificate Services on a Domain Controller as "not recommended" and a "worst case scenario". You probably aren't reachable, however anyone else should be aware this is not a good practice and should be avoided. social.technet.microsoft.com/wiki/contents/articles/…
    – Greg Askew
    Sep 30 at 12:55

4 Answers 4

Reset to default
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.
Improve this answer
6
  • Thank you, @Crypt32! Does having a "subordinate" CA on a secondary DC change any of that? (Ability to replace or demote a DC running CA...)
    – kindzmarauli
    Sep 28 at 20:01
  • P.S. The focus of the question wasn't security, availability, continuity, disaster recovery or any other implications or concerns other than this one: ability to issue valid SSL certs. If you were answering a question, "Primary DC runs a Standalone CA - is that OK purely for the purpose of valid CA-issued SSL certs?", with the focus on "standalone" - how would you answer that? (I didn't want the question to be too long and was hoping the added context was clear enough - looks like it wasn't. Both of the current answers are focussing on other aspects of the config and not cert issuance.
    – kindzmarauli
    Sep 28 at 20:07
  • 1
    You are asking wrong question. You can't eliminate security and maintainability aspects, so your rephrased question makes little sense. So the answer remains unchanged, i.e. it is not ok to have CA on DC.
    – Crypt32
    Sep 28 at 20:57
  • Yes you can (eliminate security and maintainability aspects) for testing purposes - or when inheriting someone else's setup and the primary goal is to fix a specific issue, and worry about the rest later. If you can't answer it or think it's wrong - please don't. Delete it. I made that context crystal clear from the get go in several places in the text. The question was only rephrased to make that context appear in four places (rather than just two) and in the title.
    – kindzmarauli
    Sep 28 at 21:43
  • P.S. I don't dispute that I don't know how to ask the right question - and that's because I indeed don't (know what's relevant and what isn't) - which is very common when venturing into a relatively new territory. Getting pummelled for asking "wrong" questions and getting the question closed because of it - is quite unhelpful, mildly put. Instead, please read the question in full (or walk away if you have no time), and help craft the right question. Thanks!
    – kindzmarauli
    Sep 28 at 22:17
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.

Improve this answer
4
  • Thanks Massimo! The questions isn't asking how to get those SSL certs to be trusted (there's a linked question in the text, or perhaps we could ask a separate question which your answer would then be applicable to - I'll be happy to do so. The question is only asking whether this setup is capable of issuing valid SSL certs. (For which there's already an answer.)
    – kindzmarauli
    Sep 29 at 15:32
  • Separately, the 1st paragraph of your answer ("not recommended", etc.) is stated and restated in the question itself, as well as in other answers that seem to miss that context. Please do no repeat it in the answer. Thanks!
    – kindzmarauli
    Sep 29 at 15:35
  • Finally, the core of your answer, that this setup's (standalone root CA + subordinate enterprise CA) certs aren't automatically trusted by domain members - should probably be well supported? Would you have a link to the appropriate docs and a quote from them?
    – kindzmarauli
    Sep 29 at 15:38
  • @kindzmarauli I wrote this answer exactly to say "although it's not recommended, it should work if you do it right". The core of the answer is, you have to make your root cert trusted. This is true regardless of where your stand-alone CA is running.
    – Massimo
    Sep 29 at 21:53
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.

Improve this answer
11
  • Did you mean, "a standalone CA on a domain controller should be used for lab environments" only, i.e. should not be used in production environments? Would you know why, i.e. what are the adverse effects - not in terms of overall security but purely for the purpose of issuing valid and trusted SSL certs for intranet sites? (That's the gist of my question and I'd really rather not get into any other implications.)
    – kindzmarauli
    Sep 27 at 20:32
  • 1
    That depends how business critical those intranet sites are, let's imagine you need to renew the certificate of those certificates, and for some reason your CA is down, is that acceptable or not? From a security point of view i wouldn't recommend it either. When a threat actor is able to land on that server he has access to your CA and your AD. So he is able to create fake websites with your cerficates and he is able to compromise identities. This is really a PKI Design question where you need to set your requirements.
    – Ace
    Sep 28 at 0:54
  • 1
    social.technet.microsoft.com/wiki/contents/articles/… (PKI Design Guide)
    – Ace
    Sep 28 at 0:59
  • thanks but you are still not answering the question :)
    – kindzmarauli
    Sep 28 at 20:18
  • Ok, i think a standalone CA should not be used in production environments.
    – Ace
    Sep 28 at 21:37
-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... :)
Improve this answer
6
  • 1
    Downvoted. The reason is that this answer may be harmful to other users who come to this web site. They may get a wrong impression that it is ok and good option to setup CA on DC only because it works. Technically, this setup will work, but it was never recommended. Answers provided on this board are intended to help other people too, thus we answer by considering potential negative implications. PKI is not an easy topic and you always should follow best practices and recommendation to avoid headaches in future.
    – Crypt32
    Sep 29 at 9:53
  • oh that's OK - of course you prefer your own answer even if it betrays not reading the question in full and/or not understanding the context, as well as providing factually incorrect information :)
    – kindzmarauli
    Sep 29 at 14:31
  • The Microsoft PKI Design Guide describes Certificate Services on a Domain Controller as "not recommended" and the "worst case scenario". Your self answer reeks of confirmation bias. There's a lot of reasons this is 180 degrees wrong. Just because it doesn't have a signed, numbered list from the vendor doesn't mean unorthodox configurations are "valid". social.technet.microsoft.com/wiki/contents/articles/… en.m.wikipedia.org/wiki/Confirmation_bias
    – Greg Askew
    Sep 30 at 12:49
  • 1
    "The question was raised purely to resolve a problem of CA-issued intranet SSL certs not being trusted by browsers" - If that were the case, then your question should have focused on that instead of all the discussion of a DC running CA services. Sorry, but it's a down vote from me, too.
    – twconnell
    Sep 30 at 16:11
  • Oh that's OK - thanks for at least letting me know. As to the downvote reason: the focus comes from knowing what's relevant. (But you already know that, right?) I don't - as people asking questions often don't. (It's all described and mentioned in the question - it's really strange seeing people who appear to be experts paying no attention to it and then downvoting - because they missed that context. Just super strange. But oh well.)
    – kindzmarauli
    Sep 30 at 17:45

You must log in to answer this question.

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