Diffie-Hellman certificates are certificates which contain a Diffie-Hellman public key (such beasts are exceedingly rare; nobody does that in practice). Such certificates can work for client authentication only if:
- the server's certificate also is a DH certificate;
- both DH key pairs use the same parameters (they work in the same group);
- and a static DH (not DHE) cipher suite is used.
In such a situation, the server shows its DH public key as part of its Certificate
message, the client shows its DH public key as part of its own Certificate
message, and both DH key pairs are used for the actual key exchange (that is, the client uses its private key and the public key from the server, and the server uses its private key and the public key from the client). Client and server are mutually authenticated by virtue of the client (respectively the server) using the DH public key of the server (respectively the client) as found in a certificate duly signed by a trusted CA.
Conceptually, the signature by the CA suffices, which is why there is no need for an actual Certificate Verify
message (or, for that matter, a Server Key Exchange
message). In fact, we can consider that when a DHE (ephemeral DH) cipher suite is used, then both the client and server play the role of a subordinate CA, with the resulting "certificates" being the Certificate Verify
and Server Key Exchange
messages...
Diffie-Hellman certificates (and DSA signatures) were promoted by the US Federal government in the late 20th century because RSA was patented at that time. But the DH standard (ANSI X9.42) has never been freely available, so open-source software did not follow, and DH support in deployed systems is poor. Which is why DH certificates are a rarity. A museum piece, even.