Build AD Certificate Authority (CA) using 3rd Party Wildcard SSL Certificate

We are rebuilding our entire Active Directory environment. I've seen many posts on the Internet about building the CA server and that it is best practice keep it separate from the Domain Controller. I also believe there is something about building an offline CA, but in terms of keeping things manageable, I'm not sure if this is a must for us. I always have trouble with certificates and building the CA, and its hard to find instructions applicable to our environment, unless perhaps I'm misunderstanding them.

We have a 3rd Party wildcard certificate issued from GoDaddy (used for network devices, etc). I'd like to build a Windows Server 2016 CA on a separate VM than our DC. I also want utilize certificates for LDAPS and the client machines that are joined to our network.

Can someone advise of the steps in order to accomplish this? I've found these notes on building the CA, however it doesnt say anything about using a 3rd party certificate. Or perhaps I dont need a 3rd party certificate for LDAPS and internal machines?
Ricky HelmerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David FavorLinux/LXD/WordPress/Hosting SavantCommented:
If you have a wildcard cert generated by a public CA based company - GoDaddy, LetsEncrypt, etc... - then the CA already exists, which will be found by following the full cert chain back to it's root.

No requirement to setup an in house CA if you already use a public CA based cert issuer.

Just add the certs where required (HTTPS, MTAs, IMAPS+, etc...) servers + you're done.
you always have an option to get your issuing CA certificate signed by 3rd party CA and use issuing CA to further distribute certificates for your internal purposes, this way your every certificate hierarchy will get back to public CA root


Build your enterprise Root CA (AD Integrated) which always remains online which is totally free of charge, you do need to pay OS license (That you cannot skip in any option)


You can build standalone root CA (Offline) and install sub ordinate CA (AD integrated - online)

Fix one path out of three, for 1st option there is no much documentation available and you must depends upon 3rd party CA for configuration etc

For rest of the options, there are plenty of documentation is available wrt design, deployment, configuration, in fact Microsoft IPD also available for ADCS
How many users / computers / servers do you have?
10K all inclusive or greater than that?
start with standard server config for enterprise CA server, use virtualize environment as far as possible and increase server sizing if required
If you are concerned about security / key compromise, you can use HSM device pair to secure certificate private key
Ricky HelmerAuthor Commented:
Thanks guys. We only have about 150 users, but we have about 500 computers in our environment. (Some machines are used for displays, etc and aren't ever touched by an end-user).

Not fully understanding how it all ties together: In the past, I've gotten our internal CA signed by a 3rd party. Then imported these certificates to our DC's. Is this correct? From your posts, it sounds as if I may not need the internal CA.

Ideally, I'd like to:
- Continue using the 3rd party certificate issuer (at least for network devices)
- Utilize LDAPS in our AD environment

Am I missing any other best practices in regards to certificate use here?
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

your network devices and LDAPS can happily work with internal CA server

U have only 150 users, I would not go for 3rd party CA for issuing certificates for internal purposes
I would simply build internal AD integrated enterprise root CA, back it up periodically and restore it in case it got failed, there won't be any major business impact in that case

If you already have wild card cert, you can use it for your application servers or if you have any major application servers, you an get 3rd party public certs for same
DC won't support wild card certificate for LDAPS, certificate required on DC must have DC FQDN to support LDAPS

Honestly speaking, you are OK with internal CA

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
TLDR: The reason why you don't find anything about 3rd party certificates and you own internal CA is because there is no relationship between the two.

There seems to be some misunderstanding of what 3rd party certificates will and will not do for you. A 3rd party certificate can authenticate a device, such as a web server. A 3rd party will not sign a certificate for your own certificate authority. Think what that would mean if they did. If a CA signed the certificate for your CA, then the certificates issued by your CA would be trusted by all devices that trust the root signing CA, which is basically the entire world. In addition, the certificates that you issued could be valid for any domain. You could mint trusted certificates for,,,, etc. That would be a serious breakdown of the security guarantees of the global PKI infrastructure.

Whatever certificates you have from GoDaddy can only be used for the purposes identified in the certificate(s), which are generally identification of the machine. Since it is a wildcard, it identifies as a machine in your domain. The certificate can not be used to sign code, or to anchor your own certificate authority.

If you want to setup your own internal CA, go ahead. It is useful to secure internal resources. It will only be trusted by devices under your control (done by importing the signature of the root CA public key into each machine, usually via GPO).
Unfortunately, there is no proper documentation available on this topic, but its possible to get your issuing CA signed by 3rd party public CA, the purpose is to automatically build global trust chain and to avoid maintaining offline root CA, certificate authority compromise etc, but option is costlier than putting own internal CA and not suitable only for 150 users, single internal enterprise root CA would suffice requirement
Well yes, you basically need to be able to meet the same requirements of the other publicly trusted certificate authorities.
Ricky HelmerAuthor Commented:
Thanks for the explanation everyone, it makes sense and its a lot easier to comprehend now.

In your opinion(s), is there any real security reason to publish the certificates to client machines? I'm just wondering how many organizations are doing this. I saw it posted here:
Enabling LDAPS for Client Authentication
LDAPS is basically used to encrypt ad query traffic during transit
Normally companies wanted application vendors to comply with LDAPS stanards for regulatory / compliance purpose since those are 3rd party applications
Apart from that you don't need LDAPS with day to day internal operations such as user / Computer logins as it uses kerberos technology where kerberos ticket is already encrypted, ldap transaction between clients and ad server remains unencrypted and this is acceptable for companies within corporate network
David Leon LowesSr. Cloud Integration Eng.Commented:
Just to add a point to the excellent answers. Microsoft allows you setup an internal CA using "Active Directory Certificate Services (AD CS)". As written above certificates work using a "chain of trust" - you issue a certificate for the user and sign it with the root/intermediate certificate. If you don't buy a public certificate (such as from digicert) that allows signing other certificates (these are usually very expensive and not freely issues) then only the people in your organization that are joined to your domain will trust your certificates.

This is perfectly fine for providing secure communication to your internal users.
If you have a website that it is publicly accessed usually easier and cheaper to buy a certificate (one domain/wildcard/multi domain) .

Please note: If you need a certificate for allowing your users to access Exchange from outside then you can only use one domain/multi domain and not a wildcard certificate.

You'd only need a public "signing certificate" if you were to provide a public subscriber email service .
Ricky HelmerAuthor Commented:
Crystal clear. Thank you all
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.