Working with certificates, also known as public key infrastructure (PKI), continues to be an important technology. In Microsoft networking the PKI solution uses a certificate authority (CA) service. In legal terms, a certificate is an official document attesting to the truth of a fact. To the IT pro, a certificate is a small digital document that is used for proving identity.
Certificate uses: SSL websites (encryption) and individual (authentication)
When a web site is encrypted by a certificate, the owner of the certificate proves to the viewer of the content a match between the DNS name, the website name, and the certificate name in a process known as the secure socket layer (SSL). Hopefully most computer users do have some understanding of the meaning of SSL and encryption, i.e., web sites prefixed with https:// are expected when entering a password or credit card number.
Now thinking about authentication, when a user or computer or device entity presents a certificate for authentication, it proves the entity belongs to a trusted group of users, computers, or devices. The use of certificates for authentication replaces or augments traditional username/password credentials, and requires that someone or something possess a unique user, computer, or device certificate instead of, or in addition to, knowledge of a username and password.
Certificates are particularly useful to confirm identify of users and systems across Windows domains, using a federation concept; or in the absence of Windows networking when domain login using Kerberos is unavailable, for example, client computers in “workgroup” mode only. The mutual trust for the “certificate issuing authority” (the CA) replaces a trust for an Active Directory forest or domain.
Private vs. public CAs
If you publish websites to the public, you probably have purchased certificates from a public certificate provider such as VeriSign, GoDaddy, and Thawte. A public cryptographic authority (that issues trusted root authority certificates) is needed when you expect members of the general public, or large numbers of employees, partners, or customers, to trust your certificate.
These SSL certificates cost from $50 to $350 per year or more and are a good value if you have public-facing websites, and for Outlook WebApp (OWA) and Active-Sync. Individual private certificates for user, computers, and devices from public providers go for $10 to $50 per user or more annually. This quickly becomes too expensive for all but very small organizations with very high security requirements.
Most client operating systems already trust the root certificates of the major industry public certificate providers. However if you have internal-only, private websites that need SSL encryption and/or private services like token-based logon that need digital certificates for authentication, you can save a lot of money using private certificates — issued by and trusted by your network.
The trick is to get the private root trust certificate of your CA trusted by the client OS — this is done automatically by Active Directory Group Policy, but the trusted private root certificate must be manually distributed to devices and non-domain computers. It’s an actual digital file that must be stored on, or transferred to, the storage media or memory of the device. This is an administrative burden, but you can consider this an added security layer, because members of the general public don’t have the public key of the PKI solution. A properly designed root (and if appropriate) subordinate CAs can be self-renewing with little administrative work for periods up to twenty years, the maximum recommended lifetime of a root certificate.
Significantly, if you plan to use PKI for encryption of user, computer, and/or device authentication in your enterprise, you need to establish a private certificate authority (CA) or partner with a service provider to establish and maintain one for you. Once you have a private CA properly installed and optionally published to the Internet, you are in a position to be your own certificate provider and issue the same certificates the public providers do.
Certificates you issue can be used for private website SSL encryption, and for all user, computer, and device level authentication in a variety of valuable scenarios. Examples are hardening of routers and switch management such that they require certificates to have their settings changed remotely and centralized certificate-based SSH key issue for managing Linux computers.
Deploying a private CA with Windows Server 2012
There are some great features in Windows Server 2012 that leverage certificates for some useful scenarios like large-scale Direct Access, the VPN-less always-connected wide area networking based on IPv6. (Note: New with Windows Server 2012, small and medium organizations can deploy Direct Access without a full private CA deployment as well.) Most token-based, two-factor login solutions use certificates for their PKI, and Windows Server 2012 natively lets you present credentials on removable tokens.
Microsoft applications like Active Directory, Exchange and SharePoint can be integrated to include encryption and token-based certificates in countless high-security scenarios. You can literally save money deploying on-premise Lync 2010 if you use private certificates on some components. For example, creating trusted subject alternate name (SAN) certificates needed by Lync internal servers can be problematic without a CA. Another scenario is private certificates on domain controllers enabling S-LDAP scenarios, for example, cross-forest address lists between business partners.
You may already have a CA running on an earlier version of Windows, or you may decide now is the time to stand up your own private CA. Windows Server 2012 preserves existing CA technology from Windows Server 2008 and previous releases, and adds some new features as well. There is no lost investment for users of Microsoft’s enterprise PKI solution. Figure A shows a familiar web-based, self-service landing page on the Windows Server 2012 CA, this feature looks unchanged from previous versions of Windows Server.
Windows Server 2012 CA Web Enrollment home page, a self-service portal for certificate actions.
New Windows Server 2012 CA features
The highly integrated and automated installation and configuration features of Windows Server 2012 make this a good time to deploy or redeploy your PKI. There is not much real-world experience yet with migrating existing Windows Server 2003 or 2008 CA databases to Windows Server 2012 CAs. However, depending on the scenario, it can be not too complex to deploy a new, replacement PKI based on Windows Server 2012 in your organization, while continuing to trust the root and client certificates issued by the previous PKI.
A new Windows Server 2012 CA can issue certificates from the same templates you are using now on your Windows 2008 or 2003 CA. In the case of an Enterprise CA, any templates you have in AD remain selectable for issue by Windows Server 2012 CAs. Some reasons to consider a new Windows Server 2012-based CA for your organization include:
- Support for automatic renewal of certificates for non-domain joined computers
- Integrated setup of multiple CA features such as network device enrollment service that would be complex or time-consuming to configure individually
- Assisted configuration with Windows Server 2012 Server Manager including post-installation steps
- Ability to use new V2 and V3 certificates with extended validity lifetimes
- Support for international domain names and for PowerShell to automate CA setup and use
- In-line integration of CA Best Practice Analyzer makes it easier to validate the configuration, see Figure B