2

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?

  • 3
    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 '16 at 17:59
  • 1
    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 '16 at 18:04
  • 1
    Client authentication to what? – crovers Oct 25 '16 at 18:09
  • 2
    To different web server for example – user1563721 Oct 25 '16 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 '16 at 18:19
6

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.

1

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

  • '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 '16 at 5:35
  • did i tell any thing different ? – 8zero2.ops Oct 31 '16 at 2:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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