Yes, you can have your own Certification Authority (CA), and issue certificates for clients. The bad news is that certificates issued by your internal CA are trusted only by you internal clients, or by clients that have your root certificate imported. For internal applications, sites etc this is gold, because you don’t have to by a commercial certificate, but if you have a public HTTPS site you will need a commercial certificate. Certification authorities can have multiple ramifications or levels, like Root CA, then a Subordinate CA, and the last one is the Issuing CA.Bellow I created a diagram for a better visualization.
Root CA will issue certificates only for Subordinate CA, and the Subordinate CA will issue certificates only for Issuing CA. The Issuing CA is the one that will issue certificates for internal clients. You can, off course create more than three ramifications, but even those commercials Certification Authorities are not going with more than three. Now there are multiple types of Certification Authorities for Windows Domains. The first and the bigger one is Enterprise Root CA, then is Enterprise Subordinate CA. These two types are used only if you have a Windows Domain implemented in your network. The last two are Enterprise Standalone CA, and Subordinate Standalone CA. These are used if you don’t have a Windows Domain implemented. Now the difference between Enterprise and Standalone is that with Enterprise you have certificate templates, and the root certificate will automatically be deployed to all clients. I will end this introduction now, and start working.
For this guide I have a Domain Controller (DC) running Windows Server 2008 R2, and another Windows Server 2008 R2 (named Server-Cert) joined to the domain, which will be our Enterprise Root CA. Yes I’m going with the Enterprise version, because is a Windows Domain, and for small business is more than sufficient a single Enterprise Root CA.
Go to Server-Cert and open Server Manager; right-click Roles and choose Add Roles.
Click Next to skip the Welcome screen. On the Roles screen select the Active Directory Certificate Services and click Next.
Skip the introduction of AD CS. On the Role Services screen we have the option to install more than just the certificate service. For this demonstration I’m going to install the Certification Authority Web Enrollment too. This will give us a web page to request certificates, and it’s great, believe me. As soon as you click the Certification Authority Web Enrollment you will be asked to install some required prerequisites. And off course a web site to function needs a web server. Just click Add Required Roles Services and continue the wizard.
Because this is about installing Enterprise Root CA, just leave the defaults here and click Next.
Again leave the defaults here to install a Root CA.
We need to create a new private key, so click Next to continue.
For Enterprise Root CA I usually choose a length key of 4096 and leave the rest to default.
Give your Root CA a name. I always change the name, because I really hate the default one.
Select a validity period. For Enterprise Root CA I usually type 30 years.
If you have a reason to change the default log and database location, do it using the Browse buttons. Now comes the IIS installation part, just go with the defaults and finish the wizard.
The installation is done. Go to Administrative Tools > Certification Authority to open the Management Console for the Certificate Services. From this console you can revoke certificates and create templates.
To see the root certificate just right-click the server name, choose Properties and hit the button View Certificate
Open a browser and type http://localhost/certsrv, and the Certificates Services Web Enrolment page should open. Using this web page clients can request certificates, if they have the proper permissions.
Want content like this delivered right to your