I’d be slightly exaggerating if I said that I get questions about public key infrastructure every day, because yesterday no one asked me anything about PKI. Today, I received several questions. I’m sure there are plenty great references on the web. But here’s my response to recent student with questions about IIS, SharePoint, and E2K7 (OWA) web security. I thought I’d share it with you in case it helps you too.
When using a public key infrastructure (PKI) for security, a device such as a phone, workstation, or server needs to be configured to trust the other machines or users it’s communicating with. The trust could be direct or indirect. PKI-based trusts are based upon public key certificates. I’ve written quite a bit about public key cryptosystems, and certainly there are many chapters or whole courses of material which get into the details, but I’ll try to distill down a few basic facets for you.
But first, an analogy. Imagine that you’re driving 100 km/h (62.5 mph) through a school zone in some other province or state. In most jurisdictions, going that fast in a school zone is highly illegal and a really bad idea too. Let’s assume that you have a license in issued the government of Québec and you’re driving in Ontario. The citizen or law enforcement officer who stops/questions you about your driving might ask for your license – how do they know it’s a legitimate license? The government of Ontario trusts the government of Québec, right? So you’re known as an authentic licensed driver, or at least you were before driving so fast in a school zone. So you’re authentic but not necessarily legal (authorized). Enough of that for now, but where you ask is the analogy?
Ah yes, the analogy. A certification authority (CA) is a type of server on a network which can issue certificates to users, computers, or other devices just as a motor vehicle department of a government can issue identity cards and drivers licenses to citizens and residents. With a real-world ID card, the agency certifies that your name and likeness (photo) go together, and that they’ve checked other credentials such as your date of birth, eye color, hair color, and height. There’s typically a validity period with a start date and end date (expiration). Driver’s licenses also add information vouching for your credentials as someone who passed a driver’s test for a certain class of vehicle (e.g. motorcycle, car, truck, bus, etc.) and vision test. Other information may be included. Similarly, a certificate server providing the certification authority (CA) service certifies your identity along with a public key which can be used to encrypt or decrypt information with a corresponding private key. Let’s not get into the details of public/private key relationships. The point is that the certificate associates your name and your digital identity instead of your ability to drive a vehicle. The strange part is that people can get certificates from a CA without proving that they can “drive” a computer, but that’s another story.
There are publicly operated CAs that are hosted by government agencies and by corporations. Just as a public driver’s license would usually be trusted between states or provinces, and perhaps across national boundaries, a public key certificate issued by a public CA is usually trusted across corporate, government agency, and residential boundaries. Most operating systems, including Windows XP and Vista, come with a number of PKI “trusts” built in, and a systems administrator can change those PKI trusts. Normally, just as licenses from New York, California, Sonora, Chihuahua, British Columbia, and Saskatchewan are trusts world-wide, public key certificates from Verisign, Entrust, many national post-telephone-telegrams organizations, and lots of other corporations are already trusted in the default installation of Windows.
Why would you want to use a private CA within your organization (corporation, agency, partnership, etc.)? And what would the limitations be? Imagine that you drive a tractor in a farming community, or a forklift in your corporate warehouse. You might be known in your community or corporation to be a legitimate driver of such vehicles. Does that imply that you can drive those vehicles or other kinds of vehicles in other environments? Certainly, Mac OS X, Linux, Solaris, other UNIXes, and certain editions of Windows Server can be set up to host a certification authority which can issue certificates to users, smartcards, workstations, servers, and other devices. For example, your own internal servers running Windows 2000 Advanced Server, Windows Server 2003 Enterprise Edition, Windows Server 2008 Enterprise Edition (and in some cases Standard Edition), could be set up and configured to run certificate services (called Active Directory Certificate Services in Windows Server 2008) and issue certificates. But just doing that much doesn’t extend trust of these certificates even within the organization, let alone outside.
For example, if you set up your own internal CA, a certificate could be issued to a server running Microsoft Exchange Server 2007 with the Client Access Role installed for the purposes of securing access to Outlook Web Access (OWA), Exchange ActiveSync (EAS), or other services. Normally a web browser or other application would generate a warning message when that client attempts to utilize secure communications using SSL/TLS (e.g. https://myca2.example.com/owa) when the certificate issued to that web server running Exchange OWA is not trusted. How would we get client machines to trust that OWA server’s certificate? Conceptually, we could either install the OWA server’s certificate in the client machine’s trust list, or better yet, we could configure trust of the certificate of the PKI CA which issued the OWA server’s certificate. Be careful: an Exchange Server 2007 Client Access server is often referred to as a CA server or CAS, but a PKI certification authority is also called a CA or CA server, or the plural would be CAs – don’t let those abbreviations confuse you – that’s why we referred to an OWA server (the E2K7 CA server hosting Outlook Web Access).
Why set up an internal private CA? Hosting such a server to issue many certificates to servers or even clients could potentially be less expensive than paying a public CA for each certificate you’d like them to issue on your behalf for your servers, let alone your clients. What are some of the limitations of using an internal CA? First of all, all client machines, either those of employees or external customers who need secure access to your content servers (e.g. Exchange Client Access, SharePoint, or other web servers) would need to be configured to trust your internal CA(s) and the certificates they’ve issued. There are lots of techniques to accomplish this, which are beyond the scope of this article, but for now let’s just note that this does indeed need to be done. Briefly: for Windows clients in workgroup mode, scripts or preconfiguration would be useful approaches, and for Active Directory domain services clients, Group Policy could be utilized to establish the necessary PKI trusts of your internal CA(s).
Users don’t necessarily need user certificates to access OWA when the users are authenticating with OWA’s forms based authentication – the username/password dialog web page. The client machines just need to trust the private public key infrastructure (certificate servers). User certificates are another option for mutual authentication which could be explored as an advanced option. There are a number of methods for obtaining user certificates from a private CA, notably Group Policy and scripting, depending of the relationship between the clients and the domains/realms of the CA servers and Exchange servers.
Yes, SharePoint and other web-based services can certainly use the same configuration method of setting up SSL/TLS for OWA.
In summary, if your OWA users are all internal employees, it’s quite reasonable to establish an internal CA to support the PKI needed for OWA security.