Overview#

Certificate-based Authentication is an Authentication Method which is used with Certificates within a Public Key Infrastructure

Digital Certificates are vessels for Asymmetric Key Cryptography.

Certificates are intended to solve Key-Exchange. Namely, the user-agent wants to use the server's Public Key.

An attacker will try to make the client use the attacker's Public Key. So the client must have a way to make sure that it is using the right Public Key.

In SSL-TLS, the most common use of Certificate-based Authentication, is supposed to use X.509 which is a standard for Certificates. Each Certificate is signed by a Certificate Authority.

Typically the user-agent inherently knows the Public Keys of a handful of Certificate Authority (these are the "Trust Anchors" or "Root Certificates"). With these Public Keys, the client can verify the Digital Signature computed by a Certificate Authority over a certificate which has been issued to the server.

Authentication By Certificate#

With these known Public Keys, the Protocol Client can verify the Digital Signature computed by a Certificate Authority over a Certificate which has been issued to the Protocol Server.

So the user-agent is supposed to do the following:

• Get a Certificate Chain ending with the server's Certificate. The Certificate message from the server is supposed to contain, precisely, such a chain.
• Perform Certificate Validation of all the Certificates in the Certificate Chain, which is complex and heavy (Web browsers now do it, more or less, but it is a recent development).
• Verify that the intended server name is indeed written in the server's Certificate. Because the client does not only want to use a validated Public Key, it also wants to use the Public Key of a specific server. See RFC 2818 for details on how this is done in a HTTPS context.

If a Protocol Client performs these processes properly, there is a High Level Of Assurance that the Protocol Server is who-he-said-he-was and is considered Authenticated.

This process can be extended recursively: a Certificate Authority can issue a Certificate for another Certificate Authority (i.e. sign the certificate structure which contains the other Certificate Authority name and key).

Public Key Infrastructure Weaknesses#

The certification model for X.509 Certificates has often been criticized, not really on technical grounds, but rather for politico-economic reasons. The certification model for X.509 concentrates validation power into the hands of a few players, who are not necessarily well-intentioned, or at least not always competent. Now and again, proposals for other systems are published (e.g. Convergence or DNSSEC) but none has gained wide acceptance (yet).

For certificate-based user-agent authentication, it is entirely up to the server to decide what to do with a user-agent certificate (and also what to do with a user-agent who declined to send a certificate).

More Information#

There might be more information for this subject on one of the following:

• Certificate Chain
• How SSL-TLS Works
• Non-Repudiation