Overview#Digital Certificates are vessels for Asymmetric Key Cryptography. 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.
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).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).