Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Usually the server specifies in the Server Hello message if a client certificate is needed/wanted.

Does anybody know if it is possible to perform an authentication via client cert if the server does not request it?

And if it possible does anybody know a client that allows to force a client certificate authentication?

share|improve this question

Does anybody know if it is possible to perform an authentication via client cert if the server does not request it?

No. If a client certificate is not been requested by the server and the client attempts to send it anyway it's very likely that the server will simply abort the connection attempt since it doesn't match the expected reply.

And if it possible does anybody know a client that allows to force a client certificate authentication?

I would find it more than curious if a client could force a server to accept a certificate if it has not been requested. The answer to that question must hence be a rather qualified no.

For example; section 7.4.7 in RFC5246 states that the client key exchange message MUST be the first message unless a certificate has been requested. Since no certificate has been requested and the client still attempts to send one the server MUST not continue negotiating a connection with the client.

share|improve this answer

The client won't send a certificate unless the server asks for it with a Certificate Request message (see the standard, section 7.4.4). If the server does not ask for a certificate, the sending of a Certificate and a CertificateVerify message from the client is likely to imply an immediate termination from the server (with an unexpected_message alert). The wording of the standard is not overly clear on that subject, but it still includes this paragraph in section 7.4:

The handshake protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order results in a fatal error. Unneeded handshake messages can be omitted, however. Note one exception to the ordering: the Certificate message is used twice in the handshake (from server to client, then from client to server), but described only in its first position. The one message that is not bound by these ordering rules is the HelloRequest message, which can be sent at any time, but which SHOULD be ignored by the client if it arrives in the middle of a handshake.

This rather strongly suggests that an unexpected Certificate message from the client will not be ignored, and instead will "result in a fatal error".

Now you could imagine an active modification by an Man-in-the-Middle entity, who injects an extra Certificate Request message in the flow from the server, and blocks the Certificate and Certificate Verify from the client. This is possible, since the initial handshake is performed, out of necessity, with unprotected records.

However, this will make the handshake fail when the Finished messages are exchanged. These messages are protected (they occur after the switch to the newly negotiated security parameters). The contents of the Finished messages are a hash of all handshake messages sent so far. Since the client and the server did not see the same messages (from the point of view of the client, there were extra Certificate Request, Certificate and Certificate Verify messages), the hash values won't match, and the client and server will drop the connection.

So not only it is unclear what an attacker would gain by forcing a client authentication that the server did not ask for, but it will also not work at all because of the way the Finished messages are computed.

share|improve this answer
Thanks for your detailed answer. In my case I had more a user in mind who uses an web server via port 443 which does not require a client certificate but also exposes the (usually via port 8443 used) admin back-end app which requires a client certificate (checked in-app). Therefore no curruption would occur as the handshake is not manipulated. – Robert May 17 '13 at 14:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.