extendedKeyUsage "TLS Client Authentication" in TLS server certificates



I just read the current version (2.2) of the ISRG Certification Practice Statement which says that the extendedKeyUsage extension of DV-SSL End Entity Certificates contains the OIDs for “TLS Server Authentication” and “TLS Client Authentication”. It seems pretty obvious that a TLS server certificate has to contain the “TLS Server Authentication” OID but I wonder why the “TLS Client Authentication” OID is also included.

Of course I can imagine situations where a server uses a backend service which requires TLS client authentication. Using your already issued server certificate for this purpose could come in very handy but allowing any Let’s Encrypt issued certificate to access a sensitive backend service hardly makes sense. One could of course restrict the allowed clients further by for instance checking the client certificate’s thumbprint but with a validity period of just 90 days for any Let’s encrypt issued certificate this is not an ideal solution.

I am aware that not only Let’s Encrypt but a lot (all?) of the major CAs issue their server certificates with an EKU that includes “TLS Client Authentication” but I simply do not understand why. is the scenario described above the reason for that or am I missing something?



Are you asking for the option to exclude either?


There is no option to exclude either. But I think @nitram42 is wondering what the rationale for including the OID in the certificate is and what purposes it’s used for.


The rationale could be as simple as…
It is because it has always been.
Which of course means that the first guy got to decide for us all and forever.

As for the purpose…
Certs are designed to ensure/prove (to others) that we are who we say we are.
Which includes us as servers and also as clients.

My question to him is: Would he like to see the option to request only server certs (or only client certs)?

What is he really after…
or Change???


@rg305, why don’t we just wait for someone who was actually involved in this decision to answer the question as it was posed?


If the “question” would be made clear(er)…


I think the question is, from an issuing CA’s point of view,


Which is unclear to me…
I can see how that could be read to ask “Can I please get a cert without including the TLS Client Auth OID?”
Because he also goes on to point out a possible use case; which appears to be irrelevant to him.


Nonetheless. I think I would like to hear the answer to both questions:
Can I get one without the other?


TLS server certificates virtually always also include the TLS Client Authentication eku because…

Not all TLS server certificates are exclusively used for https.

There are many other common use cases which make active use of the TLS Client Authentication role:

The most prevalent by far would be mail servers.

A modern mail server configured with a TLS certificate will offer up a STARTTLS (587) mode both for the client submission port and the MTA transfer port (25).

Additionally, when same said mail server is representing itself to another TLS enabled mail server, it will use the same certificate it is using in the server role to present as a client TLS certificate to the other email server.

The server-to-server confederation functions in XMPP/JABBER servers also utilize the TLS Client Authentication property.

In a majority of cases the software which have dual connection role use cases do not support having different client role and server role certificates. In that software which does, it’s still an uncommon feature to configure it that way.

I don’t believe Let’s Encrypt offers a way to request a certificate without the TLS Client Authentication eku, nor do I believe that they should, unless someone comes up with a really compelling argument for why it creates a risk for people. Having both Server and Client Authentication EKUs is appropriate for TLS endpoints which engage both as clients and servers.

Oh, certain types of VoIP TLS endpoints also make use of these roles.


There is a larger use case for TLS Client Authentication without Server than there is for Server without Client.

There are lots of enterprise PKI certificates out there with TLS Client Authentication only used for single-sign-on, smart-card login, etc.

Many of those are also often tied to the S/MIME Email EKU, but as I understand it Let’s Encrypt is not interested in those kinds of use cases…

It makes sense (the EKUs as practiced today) when you think about it. It’s rather common for a server to also be a client. It’s rather less common for a client to be a server.


Thanks for all the replies. My original question was what the reason is for including the “TLS Client Authentication” OID in the EKU of server certificates because the typical web server scenario works fine without that OID. I do not want Let’s Encrypt to issue certificates without “TLS Client Authentication”. I simply want to understand why this OID is there and what application scenarios it is intended to enable.

As said in the original posting I am aware of the fact that a TLS server A can act as a client of an another service B but in my experience it is pretty rare to require TLS client authentication between A and B in such scenarios. If it is rare that begs the question why all major CAs nonetheless include the “TLS Client Authentication” OID as a default. On the other hand I could be misjudging how often TLS client authentication between services based on a certificate issued by a publicly trusted CA is utilized.

I also want to mention that a naive implementation of TLS client authentication where the server allows access to anyone who uses a certificate issued by a certain root or intermediate is fairly useless when the root is publicly trusted.



But I can restrict the hostnames allowed to connect and trust the public CA, that the hostnames in certificates are validated.


But I can restrict the hostnames allowed to connect and trust the public CA, that the hostnames in certificates are validated.

Yes, that is the non-naive implementation :wink:


It’s a common thing in XMPP/Jabber server to server communication. And those generally validate against trusted roots, for purposes of determining whether the server which has attached may properly use the domain label that it has just represented itself as having.

If you mean naive implementation as in any certificate which chains to this root or set of roots is an authorized user, then yes, that would be silly. But it can be used to authenticate certain aspects about the client. For example, if a trusted root has signed a certificate that has TLS Client Authentication EKU and the client has represented that they are a.example.com and their client certificate has been validated with that SAN dnsName means that they’ve demonstrated that a publicly trusted root CA has given the client-speaker a certificate for that label. The question of what that party is authorized to do, and the weight of that authentication is left to the application and its configuration to determine.


My recollection of the overall reason that CAs started adding the TLS Client Authentication parameter was for SMTP server to SMTP server use cases such that one SMTP server transiting an email message or messages to another SMTP server could use the server’s TLS certificate as a client certificate rather than just being an anonymous TLS client.

XMPP servers took it further by making their use of the role more explicit.

Ultimately, there are/were no downsides to making all TLS Server certificates allowable as TLS Client certificates. I just did a quick survey of recent issuances from all the major CAs and they all seem to include TLS Client on their server certificates.

@nitram42 is correct about WebServer <-> WebServer communications (say, for example, one web server accessing a web service API of another server). In those instances, TLS client authentication is rare. It’s not non-existent though, at least in terms of private PKI certificates being used to authenticate the API caller – at least one of the payment gateway networks does that. There’s generally some other authentication mechanism (usually defined within the API in question) for most server to server http api calls.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.