In TLS a non-anonymous server can request a client certificate matching some criteria. However, it is a fatal error for an anonymous server to request a client certificate. Is there a good reason for this?

A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. This message, if sent, will immediately follow the ServerKeyExchange message (if it is sent; otherwise, this message follows the server's Certificate message).

[Further down...]

Note: It is a fatal handshake_failure alert for an anonymous server to request client authentication.

Relevant part of the TLS RFC

  • I have been suggested that I can make a regular TCP connection and then reverse the server-client roles in TLS with the established connection.
    – ReyCharles
    Commented Sep 25, 2016 at 9:14
  • 1
    Why do you want to allow MitM? It is safer to have a certificate for your server too.
    – Tom
    Commented Sep 27, 2016 at 9:03
  • 1
    @Tom it's not that I specifically want MitM, it's just not important. Think of how https-sites don't use client authentication in TLS. The server might get MitM'd by another client!
    – ReyCharles
    Commented Sep 28, 2016 at 5:58

4 Answers 4


In order to answer this I think it is important to look at the definition on what is a client according to the spec. In the Glossary a client is defined as

The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only optionally authenticated.

This means that servers should always be authenticated and hence un-authenticated servers ( or anonymous servers) cannot ask for client authentication. In other words, since the client is initiating the TLS connection, the server should authenticate itself to the client before authenticating the client. I think the language could be clearer so there is no ambiguity.

In your comment you mentioned reversing the roles, so the TCP server becomes the TLS client and the TCP client becomes the TLS server. This is possible using some clever socket level programming. Take a look at STARTTLS which can be used to upgrade a plain connection to a TLS connection in a standard way. Netty is a Java library that provides such an implementation of StartTLS.

  • Good answer. I hadn't thought of STARTTLS. Can you perhaps explain why it's disallowed? Is there a technical reason, or just an "oversight" in the spec? Thanks!
    – ReyCharles
    Commented Oct 4, 2016 at 7:35
  • 1
    I think it is more to do with protocol requirement than a technical reason. The 80% use case for security (at the time the spec was written) was that a client needs to confirm the identity a server before sending any private information to it (think sending Credit Card and passwords etc.). Also making clients use certificates was (and is) very cumbersome so it was made optional.(continued in next comment)
    – ARau
    Commented Oct 4, 2016 at 14:11
  • 1
    There are use cases nowadays where it makes sense for the server to ask for a client that initiated the connection to authenticate first but it is not explicitly stated in the spec since it can be achieved by reversing the roles of client and server once the communication channel has been established. Since this is more prevalent now I would think it may be added in the future. Until then you can use StartTLS or hand code your own.
    – ARau
    Commented Oct 4, 2016 at 14:11

The reason for this is pretty simple. Let me take the example of tor and explain you in detail.

Lets assume that the 2nd hop made by the message from source to destination is the anonymous server. So it can request the client certificate only of its previous server which is not the client.

Path of the packet in TOR, Source => A => B => C => Destination

Here lets assume B is our anonymous server which is requesting the source/client its certificate but if it makes the request it will get the certificate of Server / System A but not of the client.

That's the reason for the fatal error if the anonymous server asks the client for its certificate.

  • Hi, this has nothing to do with TOR.
    – ReyCharles
    Commented Oct 4, 2016 at 7:34
  • @ReyCharles Yes this has nothing to do with TOR, but I just took TOR as an example for anonymous server. I want to make the example clear and simple , thats why I took TOR as an example as there is a concept of client and anonymous server here. And hence I thought its working can be linked to your question and hence I took TOR as an example.You are absolutely right, it has nothing to do with TOR. Its just a simple sample example taken by me. Hope it helped you. Commented Oct 4, 2016 at 8:42
  • OK I think I understand your thinking. In TLS a server (or client) authenticate itself using X.509 certificates. Alternatively, they can choose not to and this is known as an "anonymous server" (or client). I don't see how this explains my question.
    – ReyCharles
    Commented Oct 4, 2016 at 11:58

I think I can answer this for you without any technical details. Would you trust and give someone you have never met the keys to your front door? How about your car? How about your phone password? If your answer was no, then you now understand the logic behind that error.

I assume you are interested in the details however. Check out the "Client Certificate Authentication in SSL/TLS Handshake" section of this MSDN article for that. It's got some good visuals that illustrate that logic.

  • 3
    Public keys are not secrets. Google and many other services give away their public keys billions of times every day.
    – symcbean
    Commented Oct 2, 2016 at 23:22
  • yes, I know that. I am going off of blownie55s definition of a client. Commented Oct 3, 2016 at 7:40
  • 1
    @ReyCharles' question is not about the practical or logical reasoning behind the behavior but more about the TLS specification and what can be concluded by what is written in it to support the behavior.
    – ARau
    Commented Oct 3, 2016 at 20:18


To provide secure communication through the network the server need to provide LDAPS communications protocol over the TLS to form SSL and the Directory Server.

The Directory Server supports TLS/SSL to secure communications between LDAP clients and the Directory Server, between Directory Servers that are bound by a replication agreement.

Before the Directory Server can be set to run in TLS/SSL, server and CA certificates must be properly configured in the Directory Server. If a server certificate has already been generated for the Directory Server instance and the issuing certificate authority (CA) is already trusted by the Directory Server, begin setting up TLS/SSL.

In other words.

You will need to create Directory Server Certificates.

  • 2
    This doesn't make any sense to me.
    – ReyCharles
    Commented Oct 3, 2016 at 7:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .