- Turn the tables on your organization with Adaxes 2018.1’s Web Interface and reporting capabilities - Thu, Sep 20 2018
- Review: Softerra Adaxes – Automating Active Directory management - Thu, Jun 4 2015
- Azure Multi-Factor Authentication – Part 8: Delegating Administration - Tue, Apr 28 2015
The Active Directory Certificate Services (AD CS) technology makes Windows Server-based Certification Authorities possible. With them, you can provision users and computers with digital certificates to secure their communications through a Public Key Infrastructure (PKI) scheme.
History of the Certificate Server Role in Server Core
Microsoft introduced the Certification Authority Server Role in its early forms in Windows NT 4.0. In Windows 2000 Server, Certificate Services emerged with an Active Directory-integrated Certification Authority model. Adoption of Windows Server-based Certification Authorities rose from this point onward. At one point, Microsoft decided to rename the Certificate Services to Active Directory Certificate Services (AD CS).
Active Directory Certificate Services, themselves, evolved to become a multi-role technology next to the all-important Certification Authority (the server component issuing certificates to users, computers, and services and managing certificate validity), including:
- Enrollment Web Services
Web enrollment allows users to connect to a Certification Authority with their web browser to request certificates and retrieve certificate revocation lists (CRLs). - Online Responder Service (OCSP)
The Online Responder Service decodes revocation status requests for specific certificates, evaluates the status of these certificates, and returns a signed response containing the requested certificate status information. - Network Device Enrollment Service (NDES)
The Network Device Enrollment Service allows routers and other network devices that do not have domain accounts to obtain certificates.
All these extra services, however, were only available on Full installations of Windows Server and some even only in the Enterprise and Datacenter Editions of Windows Server. Server Core installations of Windows Server 2008 and Windows Server 2008 R2 featured Certification Authorities, but Windows Server 2012 is the first Server Core installation with all the Active Directory Certificate Services. Also, all Certificate Services role services and features can be installed and used on both the Standard Edition and the Datacenter Edition of Windows Server 2012.
Overview of Certificate Services in Server Core
The following Active Directory Certificate Services (AD CS) Role Services are available in Server Core installations of Windows Server 2012:
Role Name | Role Name |
Active Directory Certificate Services | AD-Certificate |
Certification Authority | ADCS-Cert-Authority |
Certificate Enrollment Policy Web Service | ADCS-Enroll-Web-Pol |
Certificate Enrollment Web Service | ADCS-Enroll-Web-Svc |
Certification Authority Web Enrollment | ADCS-Web-Enrollment |
Network Device Enrollment Service | ADCS-Device-Enrollment |
Online Responder | ADCS-Online-Cert |
Installing Certificate Services in Server Core
You can install the Active Directory Certificate Services role by running the following PowerShell one-liner (start off by typing PowerShell first, to get the PowerShell prompt):
Install-WindowsFeature AD-Certificate
This way, the Active Directory Certificate Services Role will automatically be installed with the Certification Authority Role Service. Optionally, you can install one of the other five Server Role Services.
Configuring Certification Authorities on Server Core
Managing Certification Authorities (CAs) in Windows Server 2008 and Windows Server 2008 R2-based Server Core installations wasn’t a lot of fun. Luckily, you no longer have to rely on clunky old certutil.exe to configure settings—you can now use the new PowerShell-based Active Directory Certificate Services cmdlets.
In my opinion, two scenarios stand out for Server Core CAs:
- Stand-alone Root Certification Authority (CA)
In a multi-tier Certificate Authority Chain, you would configure a non-domain joined Windows Server as a stand-alone Root CA to issue (and hopefully never revoke) certificates to lower-tier Issuing CAs. For security purposes, this server would be turned off most of the time. - Enterprise Certification Authority (CA)
In smaller environments, a dedicated Active Directory-integrated Enterprise (Root) CA on Server Core would offer the best of both worlds with a hardened operating system and its high availability.
Creating a stand-alone Root CA
The default secure stand-alone Root CA on Server Core would take up the least number of resources and would be less susceptible to attacks, compared to Full installations of Windows Server. After the initial installation of the Active Directory Certificate Services Role, use the Install-AdcsCertificationAuthority cmdlet in PowerShell to configure the CA.
By default, when you run the Install-AdcsCertificationAuthority cmdlet, it will configure an Enterprise Root CA with a Common Name based on the Domain and Hostname of your Server Core installation and appended with -CA. It will issue certificates with a key length of 2048 bits, based on SHA1 from the RSA#Microsoft Software Key Storage Provider. Its certificates, by default, would be valid for 5 years, and your default CA would store its database and logs in C:\Windows\System32\CertLog.
This might not be completely suitable for your stand-alone Root CA, so we’re changing at least some of the settings in the following command:
Install-AdcsCertificationAuthority -CAType StandaloneRootCa -ValidityPeriod Years
-ValidityPeriodUnits 10 -DatabaseDirectory "D:\ADCS" -LogDirectory "D:\ADCS"
With a validity of 10 years, your Issuing CAs will have a long enough certificate life time period to issue certificates with more common certificate validity periods. By placing the database and logs on a different drive, an additional layer of security and high availability is added to the system.
The Issuing CAs, then, can be configured using the following PowerShell command:
code>Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCa -ParentCA SC2.servercore.net\SERVERCORE-SC2-CA
Of course, you would replace the DNS name and CA with your previously created stand-alone Root CA. After you’ve configured the Issuing CAs with their parent relationships to the stand-alone Root CA, you can turn off the latter.
Enterprise Certification Authority
To configure a CA for a smaller environment, you might simply use the following PowerShell command:
Install-AdcsCertificationAuthority
Since most of the settings for a default CA look to be well-suited for small- to medium-sized businesses, I consider it a best practice to use them in this case. Answer y to accept them.
Managing Certificate Templates on Server Core
With your CAs configured and handing out certificates, you might feel the need to configure Certificate Templates. Sure, you can manage your Server Core CA from a Full installation of Windows Server 2012 and Windows 8 with the Remote Server Administration Tools (RSAT) installed. But you can also add Certificate Templates on the console of your Server Core installation, like a boss. To this purpose, the Add-CATemplate cmdlet was added to Windows Server 2012.
Install-ADCSCertificationAuthority
Concluding
Certification Authorities on Server Core installations of Windows Server 2012 Standard Edition offer all the benefits of a highly available certificate infrastructure, and with all the benefits of a centrally manageable networking environment based on highly secure operating system installations. If that’s not secure enough, you can always throw in a couple of Hardware Security Modules (HSMs).
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
What are the step by step procedure of renewing a certificate from a windows 2008 Server core and it’s offline. I have a surbodinate that’s online?
Under Enterprise Certification Authority, you basically advise to accept the defaults. I advise against this until everyone is clear on what those defaults actually are. If you accept the defaults, you may for instance end up with an undesirable name, and you’ll be unable to rename your CA. Going back isn’t really an option either because it’s an AD integrated CA. In other words, risky.