Free certificate software

This article is pouring forth into my laptop computer following all the hurricane-induced rains the East Coast has experienced. My best wishes to those in Florida and elsewhere who sustained harm from the storms and wind. This article may be occasionally breezy but hopefully not windy.

The Cisco IOS code now contains a Certificate Authority server. There is a link to the configuration notes page below, along with some other good links. I thought it might be interesting to take a closer look at how this works.

When I was travelling around earlier this year presenting on WLAN security, 1 asked audiences about Certificate Authorities (CAs) and Public Key Infrastructure (PKI). I found that almost nobody had them, or planned to implement them. Admittedly, the Microsoft administrators in their organization might have already implemented or be planning to implement CA/PKI and the network staff not known about it (or cared). So does that mean - there's lack of knowledge about or fear of CA/PKI, or perhaps people aren't interested because they don't see potential value to them? After all, if you're reading this, you're probably a networking person, hence way too busy to inquire into things you don't need to deploy soon.

So it seems useful to talk about what a CA is, what PKI is, and why you and I might care. And that's the topic for this article.

What are CAs and PKI?

If you like reading standards, see ITLJ standard X.509 and the related RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile. see also www.ietf.org/rfc/rfc2459.txt. There are a lot of RFCs and drafts listed on the IETF PKIX Working Group Web page at www.ietf.org/hlml.charters/pkix-charter.html.

Have you ever used a credit card to buy something on the Internet? Then you've probably used both a CA and PKI, without even knowing it. The PKI comes in because you really need somebody to confirm that the site you're on is the site you think it is. That is, say the site claims to be amazon.com. How do you know it really IS the one and only amazon.com? Otherwise you might be on a phishing site typing your card info in for the convenience of somebody who'd like nothing better than spending your hard-earned money. You trust the CA to verify that the site is who it claims to be. Ah, but how do you know to trust the CA? Well, your browser knows to trust it because it has a copy of its public key installed with the browser. How can you trust your browser? Well, you did get it from a reputable source, didn't you? This may seem a bit paranoid, but that's the first rule in thinking about security and trust.

There are links below for Thawte and Verisign, two of the commercial CAs on the Internet. Commercial or government sites pay for managed PKI services, basically a healthy fee for each computer that is authenticated. Thawte and Verisign vouch for the identity of computers within those organizations. The computers in question might just be e-commerce Web servers, or it might be all users (or now, Cisco IP phones) within the organization.

Thawte - Commercial CA www.thawte.com/

Verisign - Commercial CA www.verisign.com/

Under the hood, here's what's going on. Each computer has to be issued a certificate, an electronic file digitally signed by the CA saying in effect "by the authority vested in me, you can believe this is John Doe's computer and its public key." The digital signature ties together identity and a public encryption key. This scheme also uses hash coding of the signature, and encryption to detect alterations. The online CA can then be used to confirm that the digital signature is valid, that it did in fact issue the certificate. If somebody obtains the computer's certificate and puts it on another computer, then they might be able to have another computer pretend to be John Doe's computer. This is somewhat like having your driver's license or ID card copied.

So a Certificate Authority (CA) is just the entity that issues and vouches for digital certificates. Public Key Infrastructure (PKI) is the technology and processes that do the work. You create a public and a private key, and a certificate containing identity info and your public key. You submit it to the PKI. The PKI verifies your identity, stores the identity info and public key (think directory or phone book), digitally signs the certificate, and returns it to you. That CA digital signature confirms that your identity is associated with the public key in the certificate. The certificate gives you a way to digitally sign things by using your private key (proving they really come from you and not someone masquerading as you). The public and private keys also give you a convenient way to automatically and securely negotiate a 3DES or AES key over public networks. But let's not get seduced into the marvels of public/private key crypto right now; see some of my other articles for more on that topic (IKE, IPSec).

You trust the CAs signature since you have the CA's public key from a trusted source, e.g. your browser vendor. Since you also trust the CA, you can then trust the certificates it has signed. Stolen or lost certificates are in essence handled somewhat like stolen credit cards, using a "certificate revocation list." There are lots of intricate protocol details lurking here, but let's not get sidetracked into them either. The Microsoft article referenced below provides a gentle introduction in a little more depth than this article can attempt.

How secure Is the CA?

There are differing degrees for need and security when interacting with a CA. This is like someone who you trust in some matters but not others.

If you want to work in your lab, perhaps to gain familiarity with PKI, you might use the free SimpleCA on Windows or the free software at the "Set up your own" link below. Anybody else using certificates you issue is trusting you, your identity verification process, and the physical and network security controls you have instituted over your lab computer. The certificates probably cannot be verified online (unless you set up a server for that), so Web or e-mail users may have to trust your signing authority or your certificate (say, based on calling to check with you).

Set up your own Certification Authority using free software http://slwww.epfl.ch/ SIC/SL/CA/ or SimpleCA (One of apparently two freeware packages with the same name) http://users.skynet.be/ballet/joris/SimpleCA/

What this lacks is convenient large-scale administration. It's very manual. You have to create certificates. You have to distribute them. You have to confirm that you issued them. It's also not well enough integrated that non-technical people can really be expected to use it.

Microsoft's implementation has more automation and appears adequate for most corporate purposes. It ties into Active Directory, which may well be the corporate repository of employee info. It can use US to digitally sign certificates, if you're willing to trust Microsoft user logins/Web authentication as adequate verification of identity. Probably good enough for most corporate purposes, but how much money would you be willing to pay out based on such a certificate? Convenient, fairly secure. A company might use Microsoft CA to confirm identities within the company. Should outsiders have that need, then external access would be needed for checking certificates. The Microsoft CA would probably be in a server room. Some provision for redundancy and high availability might be made. That would make the CA fairly trustworthy, e.g. for internal e-mail and encryption.

If you're allergic to Microsoft in some fashion, there is ongoing work in the open source and university communities to create open source, free tools for a PKl that scales to a good size. Google turned up the following (and more):

http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm;

http://www.mozilla.org/projects/security/pki/;

So there are alternatives for those who like getting their hands into the software. One can make a case that auditing the code improves ability to trust in the PKI. Web certificate signing based on Web logins (student ID, password) is usually considered good enough for universities, particularly due to the costs of doing identity verification more rigorously.

If you're thinking money and e-commerce, that's where Thawte and Verisign come in. They're well-known and fairly trusted. They claim to have put in a lot of due diligence securing their servers, people, processes, etc. As long as DNS isn't subverted, you can trust that your Web browser is talking to the real Verisign, say, when checking a certificate they issued. Yes, that's a gap: DNS is not yet secured, and there are ways to compromise local DNS.