7

Is there any reason why I shouldn't issue end entity certificate with both TLS Web Server Authentication and TLS Web Client Authentication?

What should happen if the client certificate which should be authenticated on web server contains also TLS Web Server Authentication?

Should I issue instead 2 different certificates? One with TLS Web Client Authentication only and second with TLS Web Server Authentication only?

What is the best practice and your experience?

Improve this question
5
  • 4
    If you use the same cert for client and server, the private key will be accessible on both. That means that anything that compromises your client also compromises the server.
    – crovers
    Oct 25, 2016 at 17:59
  • 2
    What I mean that such certificate and private key would be used on one and the same device. So there is only one keystore with certificate and private key but for both server and client authentication.
    – user1563721
    Oct 25, 2016 at 18:04
  • 1
    Client authentication to what?
    – crovers
    Oct 25, 2016 at 18:09
  • 2
    To different web server for example
    – user1563721
    Oct 25, 2016 at 18:12
  • 1
    Ahh. Ok. @CristianTM seems to have the right answer below - that is, it would work, but would potentially cause you trouble in case of changes in the future, so you might as well split them.
    – crovers
    Oct 25, 2016 at 18:19

3 Answers 3

Reset to default
12

From a normative point of view, RFC5280 does not put any constraint on having both extended key usages set at the same certificate.

From the security point of view, there is also no crypto/protocol problem (as far as I know/could find) on using the same certificate for SSL authentication as client (I guess for connecting to other services) and server (for receiving connections). Since if you use two certificates both would also be stored on the same server, if an attacker can steal one certificates he can steal two, no gain or loss there.

However, it does not hurt to keep them separate too, specially if for any reason later on you need to change one the certificates characteristics in a way that could affect the functionality on one of the usages (ex: change the DN to include something relevant to the client auth that could break the server auth).

I always, in such situatins, keep both separate, and if you are talking about private PKIs, usually I also use different CAs for issuing each of them.

Improve this answer
2
  • 2
    what would be the benefit for using different CA for issuing?
    – kenchew
    Dec 2, 2020 at 12:04
  • "Since if you use two certificates both would also be stored on the same server" that's not true necessarily, especially in 2021 with SPA and containerization. I have a situation where the web client is served from one docker container and the server served from another (fronted by nginx). Both required certificates and are isolated.
    – java-addict301
    Jun 16, 2021 at 20:11
3

first thing is how the other end check whether the certificate other end is giving is client or server as far as know it is from EXTENDED KEY USAGE

Not Critical
TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)

As you can see it is NON Critical extension , so certificate usability hardly depends on this extension

Its the certificate Key Usage extension which imposes restriction

Critical
Signing
Key Encipherment

A certificate without "Signing" field cannot be used for authentication , so Can never be used as server certificate

similarly a certificate without Key Encipherment cannot be used for key exchange purpose ,like wise there are other parameters too

Improve this answer
2
  • 1
    'noncritical' doesn't mean the relier (client) ignores the extension, it means a relier that doesn't implement an extension isn't required to reject the cert. It is up to the CA which extensions are critical, and KU isn't always. Different TLS ciphersuites (and keyexchanges) require different server KU values: some require Signing, some require keyEncipher, none require both. (The 'fixed' DH and ECDH keyexchanges require keyAgreement, but in practice almost no servers use them.) Client certs (when used) always require digSigning.
    – dave_thompson_085
    Oct 28, 2016 at 5:35
  • did i tell any thing different ?
    – Arjun sharma
    Oct 31, 2016 at 2:56
1

To low to comment. I realize this but some situations still required it, for example LDAP/TLS Replication on the popular 389/RH DS. Per the Redhat Directory Server Guide V 11:

Replication configured over TLS with certificate-based authentication fails if the supplier's certificate is only capable of behaving as a server certificate and not also as a client during an TLS handshake. Replication with certificate-based authentication uses the Directory Server's server certificate for authentication to the remote server.

Improve this answer

You must log in to answer this question.

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