4

I'm building a network that will allow employees and customers to access the company systems. To that end I'm using a Red Hat Enterprise Linux (RHEL) 7.0 server as a firewall/authentication server. Initially for test purposes I'm going to use self-signed certificates. The operational scenario is the client system (Windows 7/8) establishing a VPN/IKEv2 session with the server.

I have to distribute a public-key client certificate to the windows systems. Do I also have to define a server certificate, which holds the private key? Here's where I get a bit confused, because I've seen so many variants: I've seen the Extended keyUsage field set to both clientAuth and serverAuth; to just clientAuth; or to just serverAuth.

My assumption is that the client in trying to establish a VPN/IKEv2 session with the server, should be "authorized" by the server if the client sends the "correct" public key. So should I set the EKU on the server cert to clientAuth? or serverAuth? or both? (which doesn't make any sense to me)

|improve this question
  • For clarification: what do you mean by "Linux 7". Do you mean RedHat 7, Oracle Linux 7, something else? – Mike Ounsworth May 1 '15 at 14:56
  • @Mike Quinsworth RHEL 7.0 – Guy May 2 '15 at 15:56
3

Theory
This is the usual process in theory:

Your client establishes a connection to the server. The server presents its certificate. The client then makes sure that:
(1) the cert is valid,
(2) the server is in possession of the matching private key via a challenge and response mechanism,
(3) that "serverAuth" is set in the certificate.

Then the server may or may not ask the client for a certificate of its own. And it's pretty much the same in this direction again. The client presents its certificate. The server then makes sure that:
(1) the cert is valid,
(2) the client is in possession of the matching private key via a challenge and response mechanism,
(3) that "clientAuth" is set in the certificate. Otherwise the server drops the connection.

Practice
Now whether your software actually enforces step 3 is a different matter altogether.
So, how do you find out what works?

(1) Thorough way: Read the manual, do some experimentation, contact software support.
(2) Lazy way: Just set each and every usage flag on the certificates.

Standard RFC 5280
Now RFC 5280 describes the EKUs in section 4.2.1.12 but is not very verbose.

|improve this answer
  • Thanks for your response.. This has got me wondering now. – Guy Mar 30 '15 at 17:10
  • Thanks for your response.. This has got me wondering now. I would have thought the client, by initiating the connection request would send it's client certificate with it's public key to the server. The server in turn would authorize the connection based on the client's public key. I thought private keys were to be held securely on the server system. I don't want the client to have a private key. – Guy Mar 30 '15 at 17:19
  • 1
    These things only work in pairs. You can't say "Okay, I like the idea of doorkeys, but I don't want doorlocks." You have to have both. And you pass one of them out into the public. And you make the claim, that you have the other half of it, the private key, as well. And then somebody can encrypt something using the pubkey which you can then decrypt using the privkey. That way you can exchange secrets. And prove to the outside world the possession of the privkey/pubkey pair. (And without actually revealing the privkey.) – StackzOfZtuff Apr 9 '15 at 14:58
0

The "auth" in question is authentication, not authorization. serverAuth indicates that the certificate can be used to authenticate the server (that is, the certificate allows a server to prove its identity to the client); clientAuth certificates are intended to allow a client to prove its identity (that is, authenticate itself) to the server.

|improve this answer

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.