<div>
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.<br />
<br />
No requirement to setup an in house CA if you already use a public CA based cert issuer.<br />
<br />
Just add the certs where required (HTTPS, MTAs, IMAPS+, etc...) servers + you're done.
</div>


Ricky Helmer

<div>
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<br />
<br />
OR<br />
<br />
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)<br />
<br />
OR<br />
<br />
You can build standalone root CA (Offline) and install sub ordinate CA (AD integrated - online)<br />
<br />
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<br />
<br />
For rest of the options, there are plenty of documentation is available wrt design, deployment, configuration, in fact Microsoft IPD also available for ADCS<br />
How many users / computers / servers do you have?<br />
10K all inclusive or greater than that?<br />
start with standard server config for enterprise CA server, use virtualize environment as far as possible and increase server sizing if required<br />
If you are concerned about security / key compromise, you can use HSM device pair to secure certificate private key
</div>


<div>
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). <br />
<br />
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.<br />
<br />
Ideally, I'd like to:<br />
- Continue using the 3rd party certificate issuer (at least for network devices)<br />
- Utilize LDAPS in our AD environment<br />
<br />
Am I missing any other best practices in regards to certificate use here?
</div>


<div>
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.<br />
<br />
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 facebook.com, apple.com, microsoft.com, bankofamerica.com, etc. That would be a serious breakdown of the security guarantees of the global PKI infrastructure.<br />
<br />
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.<br />
<br />
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).
</div>


<div>
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<br />
<br />
<a href="https://www.globalsign.com/en/certificate-authority-root-signing/" rel="ugc">https://www.globalsign.com/en/certificate-authority-root-signing/</a>
</div>


<div>
Well yes, you basically need to be able to meet the same requirements of the other publicly trusted certificate authorities.
</div>


<div>
Thanks for the explanation everyone, it makes sense and its a lot easier to comprehend now. <br />
<br />
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:<br />
<a href="https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx" rel="ugc nofollow">Enabling LDAPS for Client Authentication</a>
</div>


<div>
LDAPS is basically used to encrypt ad query traffic during transit<br />
Normally companies wanted application vendors to comply with LDAPS stanards for regulatory / compliance purpose since those are 3rd party applications<br />
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
</div>


<div>
Just to add a point to the excellent answers. Microsoft allows you setup an internal CA using &quot;Active Directory Certificate Services (AD CS)&quot;. As written above certificates work using a &quot;chain of trust&quot; - 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.<br />
<br />
<b>This is perfectly fine for providing secure communication to your internal users.<br />
If you have a website that it is publicly accessed usually easier and cheaper to buy a certificate (one domain/wildcard/multi domain) .<br />
</b><br />
<br />
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.<br />
<br />
You'd only need a public &quot;signing certificate&quot; if you were to provide a public subscriber email service .
</div>


<div>
Crystal clear. Thank you all
</div>


<div>
<div class="content wysiwyg-content">
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.<br />
<br />
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.<br />
<br />
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? <a href="https://www.virtuallyboring.com/setup-microsoft-active-directory-certificate-services-ad-cs/" rel="ugc">https://www.virtuallyborin<wbr />g.com/setu<wbr />p-microsof<wbr />t-active-d<wbr />irectory-c<wbr />ertificate<wbr />-services-<wbr />ad-cs/</a>
</div>
</div>


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? https://www.virtuallyboring.com/setup-microsoft-active-directory-certificate-services-ad-cs/ (https://www.virtuallyboring.com/setup-microsoft-active-directory-certificate-services-ad-cs/)

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

LDAPS

PKI CERTIFICATES

Enterprise Certificate Authority

This topic area includes legacy versions of Windows prior to Windows 2000: Windows 3/3.1, Windows 95 and Windows 98, plus any other Windows-related versions including Windows Mobile.

Windows OS

Active Directory (AD) is a Microsoft brand for identity-related capabilities. In the on-premises world, Windows Server AD provides a set of identity capabilities and services, and is hugely popular (88% of Fortune 1000 and 95% of enterprises use AD). This topic includes all things Active Directory including DNS, Group Policy, DFS, troubleshooting, ADFS, and all other topics under the Microsoft AD and identity umbrella.