Certificates and encryption utilizing them play a critical role in modern systems and network security. Even if none of your email users has a client certificate in their email application, and they’re not using PKI for a VPN connection, they’re using certificates in more than a couple of places on a Windows network with Active Directory and Microsoft Exchange. You say, “Clemmer, I know all this, so what?”

Certificate Import Wizard

As I discovered recently, the need to renew certificates only once every year, two years, or more, can make for some hair-pulling troubleshooting with turnover with IT departments often shorter than that time period and likely sparse internal documentation for the many “set it and forget it” configuration components of the CA infrastructure.

Managing certificates can be relatively easy or could be (or become) rather difficult depending on how you go about it and how far you leverage the tools available to assist or automate things. Lack of user understanding for this very technical topic, along with frequent confusion on the part of new administrators as well as complex and dry documentation can all contribute to problems. Another area of confusion is the many places that certificates can be integrated and the different roles of certificates in your infrastructure.

Your Active Directory domain is going to require Microsoft certificate services provided by at least one Microsoft Certification Authority running on a server, often a domain controller. You can configure a Certification Authority (CA) numerous ways, and they can have various roles. Best practices define a number of design specifics that are generally well documented in Microsoft’s training materials and on TechNet. An Enterprise CA requires Active Directory and can be used to “issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS), and logging on to a Windows Server 2003 family domain using a smart card.” CAs can publish certificates to Active Directory (AD) for users and computers as well. A number of CA policy, certificate templates, domain security policy, and AD security settings must be set correctly for certificates to be published automatically.

Email and Microsoft Exchange specifically can leverage certificates in several ways, with internal transport certificates, self-signed certificates, SMTP TLS certificates, and more. Check out this Certificate Use in Exchange Server 2007 on the various uses of certificates in Exchange Server. Certificates are used to encrypt LDAP communication as well, although Exchange normally uses self-signed certificates to encrypt LDAP communication between its ADAM instance (at the Edge Transport) and internal Active Directory servers. Most email admins are aware of the use of certificates in Web SSL traffic, and with Exchange SSL is used to communicate between various Web clients and Client Access servers. Even ActiveSync users that connect to Exchange use SSL certificates to encrypt their sessions.

In almost all cases where the communication traverses an unsecured, partially secure, or untrusted partner network, you will likely want to use a third party, external X.509 CA. When communication is with internal resources, but perhaps ones that are remote, an internal enterprise CA may be preferable due to cost. This leads us back to some points made at the beginning of this post, that an internal CA is a CA that you must manage. Clients and computers will need certificates, and those certificates will expire after a year or two. Servers and applications will also be issued some of these certificates, and they too will need renewal when the time comes. You say “Clemmer, I’ll just increase the key size and set the certificate expiration to five years.” That may delay the renewal effort, certainly–but it won’t eliminate the effort–only delay it. Cracking private keys for certificates with large key sizes isn’t much of a concern today, but with the continuing increase in computing power who it to say that a standard sized private key can’t be cracked four years from now? Consider too that some keys will need to be re-created when new server services appear, and your choice when upgrading services, applications, and operating systems will be to either migrate the certificates you have, or regenerate all of them. Will you really be running the same systems in five years?

I found the solution to my curious problem with certificate renewal in our two-level domain hierarchy in this TechNet article. It’s worth a read if you are expanding your Windows network or designing an improved domain structure.