Explaining Certificate Authentication - 101 style

Less people know that one of my pet technologies I’ve worked with in the last years was everything around certificates. I’m not talking about SSL for websites only, more about using certificate-based technology in general.

The reasons why I started with certificates was the incorporation of this piece of technology within different areas of our companies products. That has extended by time into other areas. Projects I’ve worked in and with involved for example:

• automatic certificate creation and validation (including the handling of the corresponding directories like Domino Directory or Active Directory)
• certificate authentication on systems and protocols like ActiveSync, VPN, Wifi
• incorporated certificate based client authentication into mobile apps
• definition and setup of high-available systems for certificate issuance and managing
• etc.

One thing that I’m seeing often is that the concept of certificates isn’t clear to everybody. Most people know why they want to use certificates - but the way they work isn’t known. I just experienced that again in a recent project where we deployed certificates for two-factor authentication of SAP using a F5 BIG-IP.

That’s why I’ve decided to create this blog post. I don’t want to describe the different OIDs or what TLS is. The purpose of this post is to describe how certificate authentication in general works.

It’s all about trust

Certificate authentication can happen on two sides: verification of a server/host or verification of a client.

At least it’s dead simple:

• if you want to verify a server the server needs to have a certificate named on his hostname and issued by a certificate authority which the client trusts
• if you want to verify a client the client needs to have a certificate issued by a certificate authority which the server trusts.

That sounds easy, doesn’t it? The basics are always the same: a trusted authority issues a certificate. And this gets verified.

I think it’s important to have examples. That helps to create a coherent and visual view on things. Using real-world scenarios helps a lot to explain technology. So let’s do it.

Receiving a parcel - or how to authenticate a server

The door bell rings. You open the door. A guy from the parcel delivery service is in front of your home’s door. He asks you for your ID card which you’re going to show him. After he has validated your photo on your government issued ID card and the address he’s giving you the parcel.

What does that mean technically? Someone wants to connect to a server URI (you). He’s connecting based on DNS (your address). The delivery guy is checking if you’re the one who you’re saying you are (validating hostname with requested URI). And if your ID is issued by the government (a trusted certification authority) he’ll handoff the parcel.

There maybe some exceptions:

• Your spouse opens the door. The delivery guy accepts him/her to receive the parcel instead of you. That’s an exception the delivery guy (the client) may do based on his known rules (it may lead to a Man-In-The-Middle-Attack and should be avoided if the parcel contains the anniversary gift for your spouse).
• If you or your spouse uses a self-created ID (aka self-signed server certificate) or the ID of your gym (unknown certification authority) the delivery guy won’t hand out the parcel as he can’t validate it against an authority (a certification authority).

Entering a bar - or how to authenticate a client

You want to enter a licensed bar in Boston, MA. The guy at the front door requests to validate your identity. You’re showing him your European ID card. He denies it as he only accepts European passports. So you get your passport and present it to the frontman. After he has validated your identity you’re allowed to enter the bar.

The description in technology would be: A client connects to a trusted server (bar with a government issued license). The server requests to validate the identity of the client (you). The client presents a client certificate (European ID card) which isn’t trusted by the server (only accepts specific issuers). The client selects manually another client certificate (European passport) which is trusted. After the server has validated the client certificate the request may proceed (enter the bar).

Again, more things may come into the game:

• You would have selected the passport directly if the bar would display a list of accepted IDs at the front door. That’s known as certificate advertising (a server tells the client which issuers he accepts so that the client may choose the correct certificate directly).
• You can add a bunch of more details like verifying the expiry date of the ID/passport (the certificate), if the ID/passport hasn’t been revoked by the government (is in a CRL), if certain details of the ID/passport are valid (verifying certificate OIDs against LDAP) and so forth.

Conclusion

Certificate authentication in general is like everyday tasks. That’s it. More layers of complexity may (and will) be added in real life - but the basics remain the same.