Republished with permission from WatchGuard Technologies, Inc.


Understanding Certificates and PKI

by David M. Piscitello, President, Core Competence, Inc.

My fellow LSAC member Fred Avolio maintains a list of Security Axioms such as, "A false sense of security is worse than a true sense of insecurity.” My current favorite is, “Your absolute security is only as strong as your weakest link."

Most organizations’ weakest link is password-based authentication. And since authentication is fundamental to applying all subsequent security policy, most security policy is built on quicksand. If I could apply one security remedy ubiquitously, it would be this: eliminate passwords by introducing some combination of stronger authentication methods—biometrics, digital certificates, and tokens—that make impersonation and repudiation much more difficult. This article discusses one such method, digital certificates. What are they? How are they used? What should you look for before you decide to trust them? For the answers, read on.

What is a digital certificate?

A digital certificate helps you verify that a message comes from the person or entity it claims to come from. Digital certificates contain, among other things, the name and the public key of the entity communicating with you. The result is that the certificate binds a public key to a person or a system (for example, a Web server, VPN gateway, host, or individual employee). Digital certificates allow us to associate IP addresses, domain names, and e-mail addresses with the public keys their owners have assigned to them. For example, presents its digital certificate when it wants you to bring up a secure (SSL) Web session to buy Amazon goodies. If you have never viewed a certificate, open your browser, and visit a secure page such as’s checkout. Then click your right mouse button, select Properties, click the Certificate button, and you can see them. But you should demand more than just a certificate before you shop. The certificate must also confirm the identity of the server as (using our example) Why? If you can’t verify that the Amazon secure server is really Amazon and not some server pretending to be, you might not be sending your credit card information to Amazon. (The irony here is that, without proper authentication, you could send your credit card information over a "secure" encrypted channel to a malicious party!) So we must determine whether this certificate is legitimate or bogus. 

Enter the concept of signing. A party who wants you to trust its certificate is valid, and hence that the public key contained therein is also valid, will have some authority you already trust digitally sign the certificate that contains its public key. In Amazon's case, you'll see that Verisign is the third party vouching for the legitimacy of Amazon's certificate.

You may have heard of self-signed certificates. You can self-sign a digital certificate, which is adequate for some communications, but it is like saying, "I'm me, and if you don't believe me, just ask me." Strong security demands that some acknowledged and trusted third party (a Certificate Authority, or CA) issue signed certificates. We need a CA’s signature to feel confident that the certificate contains accurate, complete, and unaltered information about the person or system, including its public key.

Public Key Infrastructure

The use of certificates and the public keys they bear requires that users' and servers’ public keys be widely available. We thus need a public key infrastructure (PKI) to accommodate key and certificate creation, distribution, lookup, backup, recovery, and revocation; essentially, all the administrative measures necessary to make the public key, its associated attributes, and status widely available to others in an automated, reliable, and interoperable manner.

Public Key Infrastructure concepts are often explained by drawing an analogy to a passport authority. A passport authority creates secure, authorized, printed documents, accepted as a means of verifying the identity of a person almost anywhere in the world. Passport authorities throughout the world collect and verify information on a citizen: name, photograph, date of birth, residence address, etc. Once this registration process is completed, the passport authority issues a document (a passport) that is difficult to alter without detection. The authority imposes a lifetime on the passport, then imprints its seal on that document, effectively affixing its unique signature in a way that can't be repudiated. Countries acknowledge passport seals of sovereign states with which they maintain diplomatic relationships. Individuals with passports rely on these documents to prove their identities to merchants and authorities while traveling from country to country.

In the digital world, e-commerce sites contract with independent third parties like Verisign, CommerceLock, and GeoTrust (formerly EquiFax) to verify their merchant credentials and to issue digital certificates. These public CAs are acknowledged as trusted parties responsible and accountable for verifying the authenticity of users or systems to whom they issue certificates, similar to passport authorities. They issue digital certificates using software from EnTrust, Baltimore Technologies, Microsoft, etc. Enterprises and private consortia can also buy CA software from these same companies and operate their own private CAs.

This raises an important, often misunderstood point: there is no single, universal public key "infrastructure" yet. Sovereign states claim exclusive rights to issue passports for their citizens. Loosely speaking, individual CAs exercise authority to issue certificates over some user constituency. So when you hear PKI, understand that many certificate authorities exist, and that cooperation (and the important related concept of asserting trust between CAs) remain two of the more difficult problems to resolve in the Internet today.

Your Digital Passport

CAs issue electronic credentials, a certificate, that serves as proof that a user’s or system’s credentials have been vetted by the CA, that the CA believes the credentials to be accurate, and that from this evidence, the CA believes the user or system has proven he (it) is who he claims to be. Note that when digital certificates are used, it’s commonplace that two parties who have not previously established a trust relationship implicitly trust each other because they each share a relationship with a common third party. That third party vouches for the legitimate identity of both parties. This third-party trust is a fundamental requirement for large scale deployment of any system based on public-key cryptography. 

CA Signing Key

Whether the CA is publicly or privately operated, a CA guarantees the authenticity and integrity of digital certificates it issues by affixing a digital signature created by the CA's signing, or private, key. This private key is the critical piece of digital information that keeps any public key infrastructure trustworthy, because users verify the signature on every certificate by using the issuing CA's verification or public key. So, just as passport authorities protect passport-generating equipment and material to guarantee the authenticity of their passports, CAs must carefully protect their signing private keys against theft or accidental loss.

Certificate Lifetime and Revocation

Passports generally expire after some years, and must be re-issued. Digital certificates have the same property. And just as passport agencies must have a method of revoking a passport if it is reported as stolen, a CA must have a similar process for revoking a digital certificate whose private key has been compromised or that no longer represents a legitimate binding between the holder and certificate (e.g., an employee that leaves a company). Certificate revocation, however, must be accomplished in Internet time. Timely distribution and checking of certification revocation lists can prove difficult to practice, so be certain you understand how this is accomplished by your CA and any system or software that relies on digital certificate authentication.

Client certificates and your SOHO

While you are certain to have used server certificates before, your first encounter with digital certificates on WatchGuard products may be with remote SOHO Configuration via the VPN Manager. You’ll be asked to present your client certificate before the SOHO will permit access to configuration pages (the process of creating a client certificate and using it is documented beginning here). This stronger authentication through client certificates is one example of how we can replace passwords. 


Passwords are lame. Digital certificates are only one of several stronger authentication methods worthy of your consideration.

If you decide to pursue certificate-based authentication further, you may find the additional PKI information at the TISC Resources page worthwhile. If you’d like to learn more about digital certificates and how they apply to VPNs, consider attending a training course like those produced by WatchGuard or presented by my colleagues and I at industry conferences like Networld+Interop, VPNcon, CSI, and the Internet Security Conference. Look into certificates. You'll rest easier the day you can tell passwords, "You are the weakest link. Goodbye!" ##


PKI Basics from Digital Signature Trust

Using PKI with VPNs, as explained by Lisa Phifer

For more helpful articles, see our LiveSecurity Archive

Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.

Copyright © 1996 - 2002 WatchGuard Technologies, Inc. All rights reserved.