3

Say you have two servers with certificates proving their domains (e.g. for use with HTTPS).

Can one of these servers use their certificate as a client certificate when talking to the other, so that both servers can be certain of the other's domain name? E.g. "https://example.com" can get a request that it's certain is coming from "https://elsewhere.com", so can safely send secrets specific to that domain (even if it has never seen that domain before).

(EDIT: I'm aware that client authentication exists in general for TLS, but I'm particularly interested whether the same certificates from the "https" PKI are useable as client certificates. For instance, usage flags would prevent them from "just working" with existing implementations.)

1

Yes. If allowed by EKU.

You can use a cert/key as a client cert if that is allowed within the certificate. Namely if TLS Web Client Authentication is allowed within the Extended Key Usage (EKU) section.

For example: in the example.com cert it is actually allowed. (I didn't know that.)

$ echo -n | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep Authentication -B1
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication

Seems to be wide spread.

Quick off-the-cuff sample of large websites below.

$ echo -n | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -text | grep Authentication -B1
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication

$ echo -n | openssl s_client -connect amazon.com:443 2>/dev/null | openssl x509 -noout -text | grep Authentication -B1
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication

$ echo -n | openssl s_client -connect microsoft.com:443 2>/dev/null | openssl x509 -noout -text | grep Authentication -B1
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication

$ echo -n | openssl s_client -connect apple.com:443 2>/dev/null | openssl x509 -noout -text | grep Authentication -B1
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication

Further reading:

3

Actually, there is an often unused (at least on the web) optional part of SSL/TLS that allows for client authentication. It is generally not used on the web because the server doesn't really care if the client is who they say they are - they just need to have the proper credentials. Additionally, imagine the nightmare of having to verify every client in the world to a certain computer, IP, Domain, etc. I don't even know how it could work. It would be sort of a global internet ID card/cert - a pretty scary idea if you ask me!

Wikipedia has a decent walkthrough here, that explains how the clinet authentication works: http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake

You can compare that to the basic handshake for the more common way we see SSL/TLS handshakes go down.

So, the answer to your question is definitely "yes" with the understanding that one of your servers is still acting as a "client" in this scenario. That last part is just semantics though.

  • Thanks for the answer. I've added an edit to the question - I was mostly interested in whether the "HTTPS certificate" would work as a client certificate and retain the PKI context for identity proof. Since (as you say) client certs aren't generally used on the web, there might be usage flags or somesuch that mean that the same cert can't be used for both, and if it's not a normal use-case then such flags won't be set in most certs. – cloudfeet Mar 31 '15 at 13:05
  • For example, this answer seems to imply that a server cert cannot be repurposed as a client cert. – cloudfeet Mar 31 '15 at 13:13
  • 1
    Whether a cert can be used for TLS client authentication depends on the properties of the certificate: if it has the TLS client authentication extended key usage attribute set (OID: 1.3.6.1.5.5.7.3.2), it can then be used for client auth. In my experience, this extended key usage is present in almost all certificates provided by public CAs. – Stephane Mar 31 '15 at 13:37
  • Oh and, BTW, client certs ARE used on the web. It's actually a pretty nice way to authenticate a client. For instance, StartSSL uses them to let you access your account. The fact that X509 certs are using PKI makes it easier to setup since you can base your ACL rule on the issuer cert instead of having to register all client certs – Stephane Mar 31 '15 at 13:50
  • @Stephane Oh, no doubt. I didn't mean to imply that they are never used, just when you compare it to server authentication, it is pretty rare. – Gray Mar 31 '15 at 13:59
0

Wether or not a given x509 certificate can be used for the client side of a Client authed SSL connection depends on the Key Usage and Extended Key Usage options placed on the certificate by the issuing CA.

You can examine an x509 cert using openssl x509 -in certfile.pem -text

The Key Usage options refer to various operations that the cert is allowed to be used for, such as: Digital Signature, Key Agreement, EncipherOnly etc..

The Extended Key Usage options usually refer to more high level operations such as: Server Authentication (what you would use for a SSL Server), Client Authentication (what you would use for a SSL Client), Code Signing, and a host of others.

If you have an x509 certificate that has both the Server Authentication & Client Authentication Extended Key Usage options, you can be pretty sure that it will work in both roles. If it only has Key Usage options, you may have to experiment.

A more complete list of options can be found in sections 4.2.1.3 & 4.2.1.12 of rfc 5280

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.