IKEv2, RHEL 7 VPN Server, WIN 7 VPN Client and Public Keys

Latest response

I have project where employees and customers will need to login remotely to the company network. Most will be using windows 7/8 systems.
I decided to use VPN/IKEv2. The end users will login to the company network which consist of a RHEL 7 Firewall/Authentication Server, a RHEL 7 File Server, and 30 windows 7
workstations.
The problem I'm having is that my test windows 7 workstations keep issuing an error code 13806 (windows cannot find a valid certificate)
However after reviewing the windows network trace log, what happens after the ISAKMP "hand-shake" between the rhel 7 server and the win7 client. is that windows
starts searching it's certificate stores for a certificate with the appropriate "private" key. It never finds one. That's because I used certutil to generate a self-signed CA cert.
I then generated a client cert for the win7 system and a server cert for the rhel7 server. Now I exported the client cert and associated CA cert with ONLY the public key.
My understanding about SSL , certificates, and asymmetric keys is that the public key is issued to "The World" i.e. to my win7 client, while the rhel7 server "holds" the private key.
So my question is: MUST I export an certificate to the win7 system that has a private key?? Does IKE actually exchange public & private keys??

Best Regards

Guy

2U
Log in to join the conversation

Responses

SW Red Hat Guru 4022 points
25 May 2015 7:33 AM

Hello

You should not copy, move, or export private keys (EDIT: and no, IKE does not exchange private keys).

The client needs a certificate signed by the CA.

Was the client certificate made be generating a key on the client, sending it to the server that functions as your CA, signing it with the CA's key used for client certs and then sending the certificate to the client?

I have not done this on the platform you mention, but I have been working on SSH keys using ssh-keygen. The process should be similar, and is as follows:

1) Generate host CA key on server that functions as your CA
2) Sign CA host key
3) Publish CA public key (or manually copy it to other hosts (servers and clients)

On other hosts that users need to log into:
1) Download CA public key
2) Setup cert-authority in known_hosts file
3) Generate and upload host key to CA, have it signed and download back to host
4) Add pub key /etc/ssh/ssh_known_hosts file using the cert-authority directive (maybe Set up ~/.ssh/authorized_keys per user?)

On users client machines:
1) Download CA public key
2) Setup cert-authority in known_hosts
3) Generate and upload user public key to CA, have it signed and download
back to user machine
4) Set up ssh_config (IdentityFile, ssh-agent, etc. )

HTH

2U Active Contributor 265 points
25 May 2015 1:16 PM

Hi Stephen, thanks for your response.
I ran some traces on both systems, my rh7 server (Pluto debug trace) and a netsh WFP IPsec trace on the win7 client.
What I determined is the VPN connection process fails in phase 1 of the ISAKMP procedure.
(If I'm understanding this correctly)
The pluto trace shows the win7 client initiating the session, the ISAKMP protocol negotiation where the
protocol parms sent by the win7 system are "matched" by the rh7 system.
The ISAKMP process then responds to the win7 system by sending a generated DH public/private key pair
to the win7 system.
As I understand it, this is the ISAKMP phase 1 process which establishes the Security Association.
Once the response is sent to the win7 system, win7 is unable to "find" the private key.
My understanding is that this Diffie-Helman key pair is generated and exchanged during phase 1 and has nothing at all to do with the certificates I generated using certutil on my rh7 system, and I imported the
client cert and the associated CA cert into the win7 system using their certificate import tool.
To sum it up the VPN connection fails in phase 1 because an SA is never established.
Would you like to see the traces?

Best Regards
Guy

SW Red Hat Guru 4022 points
25 May 2015 2:14 PM

Yes, please post them. You can xxx out the IP addresses.

2U Active Contributor 265 points
25 May 2015 2:57 PM

The win7 client initiates the session
From my Linux "Pluto" logs I can see where the ISAKMP negotiation takes place matching the security policy parameters sent by the
win7 client: (offered is from the win7 client)
proposal 1 succeeded encr= (policy:3DES(-1) vs offered:3DES(-1))
considering Transform Type TRANS_TYPE_INTEG, TransID 2
succeeded integ=(policy:AUTH_HMAC_SHA1_96(-1) vs offered:AUTH_HMAC_SHA1_96(-1))
considering Transform Type TRANS_TYPE_PRF, TransID 2
succeeded prf= (policy:PRF_HMAC_SHA1(-1) vs offered:PRF_HMAC_SHA1(-1))
considering Transform Type TRANS_TYPE_DH, TransID 2
succeeded dh= (policy:OAKLEY_GROUP_MODP1024 vs offered:OAKLEY_GROUP_MODP1024)

Once the security policy has been established the next step is the Internet Key Exchange(IKE)

DH public value received: <--- From the win7 client (my comment)
86 8a 19 17 28 ba 08 59 08 db 60 ac f1 61 bf d1
32 2e a2 93 4c 1a 1f 8c 3d 39 c5 2d f0 70 60 0c
f9 d2 09 4b 5f b3 8c c8 8d c7 3a 32 8a 0c b0 47
84 3b b7 27 81 ea de c6 f7 e5 1a 52 44 30 0c 2b
8b e0 7c e0 32 94 fe a4 7c ab 3c 94 4a 58 2e 21
e3 7d fa 38 54 88 50 16 9d c9 82 ee b4 ee fa 34
2d 46 10 11 0f ca 73 69 4d a9 b7 71 c8 17 80 f0
74 a0 55 77 48 1e 9e 4b b5 97 51 b5 a4 42 01 93
saving DH priv (local secret) and pub key into state struct
***emit IKEv2 Key Exchange Payload:
IKEv2 next payload type: ISAKMP_NEXT_v2Ni
flags: none

DH group: OAKLEY_GROUP_MODP1024
emitting 128 raw bytes of ikev2 g^x into IKEv2 Key Exchange Payload
ikev2 g^x 96 0a a9 d0 d7 83 6f 04 ef f8 92 ae e1 37 ad 8d
ikev2 g^x e4 f1 a0 90 69 14 32 77 ac 71 7f a1 22 2a 7b a1
ikev2 g^x 2b 95 65 2b cd b4 28 86 d7 d9 26 16 e9 d1 68 52
ikev2 g^x ed f9 aa b0 3f 47 72 dd aa 50 d3 8d 84 b3 4a ff
ikev2 g^x 63 e3 9e 99 b6 48 f3 3d d3 7f 0d 2e d9 b0 5f 59
ikev2 g^x c1 0a 82 33 e4 8c 38 72 8d 7c 24 bb 2f 35 c7 b3
ikev2 g^x 87 ca c1 e8 e5 0f 69 bc 2d b0 d3 37 e8 fa 9c b6
ikev2 g^x 3e cf 5e e0 ac f4 9f fe 78 0a c3 6a cb f0 3d 00
emitting length of IKEv2 Key Exchange Payload: 136
***emit IKEv2 Nonce Payload:
next payload type: ISAKMP_NEXT_v2N
flags: none

                                    no IKE message padding required for IKEv2
                                    emitting length of ISAKMP Message: 284
                complete v2 state transition from STATE_PARENT_R1 with STF_OK

"remote-x509"[4] 107.223.51.98 #4: transition from state STATE_IKEv2_START to state STATE_PARENT_R1
"remote-x509"[4] 107.223.51.98 #4: STATE_PARENT_R1: received v2I1,

                                   sent v2R1 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=sha group=MODP1024}
                                   sending reply packet to 107.223.51.98:500 (from port 500)
                                   sending 284 bytes for STATE_IKEv2_START through enp3s0:500 to 107.223.51.98:500 (using #4)
                                   de ea 92 2d  80 d9 33 36  d1 da 58 04  51 7f 52 96
                                   21 20 22 20  00 00 00 00  00 00 01 1c  22 00 00 2c
                                   00 00 00 28  01 01 00 04  03 00 00 08  01 00 00 03
                                   03 00 00 08  03 00 00 02  03 00 00 08  02 00 00 02
                                   00 00 00 08  04 00 00 02  28 00 00 88  00 02 00 00
                                   96 0a a9 d0  d7 83 6f 04  ef f8 92 ae  e1 37 ad 8d
                                   e4 f1 a0 90  69 14 32 77  ac 71 7f a1  22 2a 7b a1
                                   2b 95 65 2b  cd b4 28 86  d7 d9 26 16  e9 d1 68 52
                                   ed f9 aa b0  3f 47 72 dd  aa 50 d3 8d  84 b3 4a ff
                                   63 e3 9e 99  b6 48 f3 3d  d3 7f 0d 2e  d9 b0 5f 59
                                   c1 0a 82 33  e4 8c 38 72  8d 7c 24 bb  2f 35 c7 b3
                                   87 ca c1 e8  e5 0f 69 bc  2d b0 d3 37  e8 fa 9c b6
                                   3e cf 5e e0  ac f4 9f fe  78 0a c3 6a  cb f0 3d 00
                                   29 00 00 14  aa f7 15 96  9a fa 41 22  bd 6b b5 e0
                                   50 52 e0 6f  29 00 00 1c  00 00 40 04  ba ba 97 d5
                                   d5 b4 e8 79  01 4c ad 6e  65 10 7d 70  27 15 d3 2e
                                   00 00 00 1c  00 00 40 05  33 21 4c 2d  01 ef ab 32
                                   c7 99 65 0d  49 99 e6 ad  1d 01 2e 40
SW Red Hat Guru 4022 points
25 May 2015 2:22 PM

BTW I found this How do I configure an IPSec tunnel from RHEL to Windows 2003 SP2?.

It has some tips at the end for debugging.

Paul Wouters's picture Red Hat Community Member 55 points
25 May 2015 5:21 PM

Note that Windows is extremely picky with its certificates and Extended Key Usage (EKU)

Note that you should use "Machine Certificates" and not EAP. This will authenticate the Windows machines based on only their X.509 certificate.

Your gateway certificate must have extendedKeyUsage = serverAuth (sometimes called "TLS Web server authentication")
You should also set the "IP Security IKE Intermediate" EKU with OID 1.3.6.1.5.5.8.2.2.

In openssl.cnf terms, you can set both by using:

     extendedKeyUsage = serverAuth, 1.3.6.1.5.5.8.2.2

Next, you SHOULD put the VPN server DNS name in the Common Name (CN=vpn.example.com) and MUST put it in the SubjectAltName (SAN)

in openssl.cnf that is:

subjectAltName = DNS:vpn.example.com

For client certificates, be sure to set the clientAuth EKU. If doing this on a Windows Mobile phone, ensure that a SIM card is present when importing and using the VPN. When removing the SIM, the certificate will become unavailable (but importing it won't give an error!)

When adding a certificate to a Win7+ machine, use the MMC and add the Certificate snap-in. You MUST change the type to "Computer Account". Go to Certificates (Local Computer) -> Personal -> Certificates folder and select Import. Import the PKCS#12 (.p12 file) into the personal certificate store. Then move the Root CA that came with the PKCS#12 file into "Trusted Root Certification Authorities -> Certificates. Never use double clicking of a .p12 file to import the certificate, as it will end up in the wrong place.

See also : Microsoft KB926182

2U Active Contributor 265 points
25 May 2015 6:25 PM

Hi Stephen, thanks for your response.
I have done everything that you have suggested.
I've generated the Public self-signed CA, client, and server certificates using certutil.
I have all the certs set to EKU clientAuth & serverAuth.
However I use my email address as the SAN in all of the certificates.
So are you suggesting that I use the server's FQDN as the SAN in ALL the certificates?
I don't export the .p12 files since they contain the private key.
I use the pkcs12 utility to parse the certs that I will export to windows.
I parse a .p12 file using the parameters "nokeys" & "certonly", into a .crt file.
I import the .crt files (client & Trusted Public CA) using mmc into the win7 "Local Computer" Personal
(client) and Trusted CA stores.

Cheers
Guy

SW Red Hat Guru 4022 points
25 May 2015 7:55 PM

Hello Guy

That response was from Paul. I have asked Paul to help as he has extensive IPSec knowledge.

2U Active Contributor 265 points
25 May 2015 8:02 PM

Oh! okay
Many Thanks to you and Paul.

Guy

Paul Wouters's picture Red Hat Community Member 55 points
25 May 2015 11:34 PM

I meant to say the server certificates need their DNS name in their certificate. A client certificate can have an email address based ID. If you do not use PKCS12 with private key, then how does the private key of your user's certificates get onto the Windows machines?

You should have a unique private key + certificate and the CAcert together in the PKCS#12 bundle

2U Active Contributor 265 points
26 May 2015 2:29 AM

Hello Paul Thanks for the clarification regarding the server certificates.
As to the private key, My understanding must be "skewed".
I thought the private key was NOT to be distributed.
I'm under the impression that the client uses the public key to to encrypt a "message" then
send it to it's destination via the established tunnel. where the "holder" of the private key is able to decrypt
the message.
So should I generate a public/private key pair, and import the client's public key into the server's database?
However it's the clients who must authenticate themselves to the server. Therefore it seems to me that some sort of asymmetric authentication must occur.

SW Red Hat Guru 4022 points
26 May 2015 6:49 AM

Speaking generally, one purpose of certificates is to avoid having to copy all clients public keys to the server host. The certificates are signed by the CA, and the server should have the CA's public key in order to authenticate a certificate presented by a client.

What you have suggested in your last paragraph would be public key, a.k.a asymmetric, authentication, which is not what you are trying to achieve it seems.

2U Active Contributor 265 points
26 May 2015 11:34 AM

Hi Stephen, we may be talking at cross purposes.
What I have to achieve is to authenticate clients signing in to the network.
I want to establish a VPN in order to do this.
This is a two step process.
1) Authenticate the machine to the server by establishing a VPN, using x.509
certificates.
2) once the VPN is established then have the user of the client system
login w/userID & pw.
On my rhel 7 server, I do have the CA's public key.
The CA certificate is self-signed, I used certutil to generate all of the certificates.
They're contained in the NSS database which has been defined to Pluto.
I exported a client public key certificate and a Trusted CA certificate to my
win7 test client.
In the "real" world, a client would logon to a "public" ftp server, and download
a client cert and associated CA and run a script that will install the certs on their system.
Next they would establish the VPN session and then signon to the network as I mentioned earlier.
I thought this was asymmetric authentication.

Guy

Paul Wouters's picture Red Hat Community Member 55 points
26 May 2015 2:37 PM

Both the server needs to authenticate the client, and the client needs to authenticate the server. So both have an identity that is signed by the CA. So both need their own private keys and their own certificate to cryptographically prove their identity.

During IKE(v2), both server and client send their certificate across to each other, along with a signed proof that they are the legitimate owner of that certificate identity - so they sign it with their private key.

Each certificate has its own private key. When creating a PKCS#12 file, this file contains a bundle of public certificate, private key, CA certificate. Each node installs their own bundle. During IKE, no private keys are exchanged, only certificates and signatures made by the respective private keys.

2U Active Contributor 265 points
26 May 2015 5:24 PM

Hi Paul, So each client will have it's private/public key pair, and the VPN server has it's private/public key.
So BOTH the client and the server must have a pub/priv key pair that are signed by the same CA ?

Guy

SW Red Hat Guru 4022 points
26 May 2015 7:10 PM

All hosts involved, client or server, have their public and private key pairs (hence the term asymmetric).

It is a hosts public key that is signed by the CA's private key. A certificate is essentially a public key, generated on the client, sent to the CA, combined with some identity details and signed by the CA, then given back to the host.

Certificates do not have to be signed by the same CA although in your application that may be the case. Provided the hosts have the certificate of the CA, they can authenticate a certificate signed by the CA. Think of a browser which has certificates, signed public keys, for many CA's.

It seems to me that in your case the device that is self-signing your CA certificate is your CA, and it should sign the public keys of all hosts involved, and all the hosts need a copy of the CA's certificate.

2U Active Contributor 265 points
26 May 2015 9:18 PM

Hi Stephen, that's exactly what I have done.
It's that windows gets "lost" looking for a private key.
Now my point of confusion is How do I get the private key into indows
without distributing the private key which is not recommended.

SW Red Hat Guru 4022 points
27 May 2015 7:20 AM

The private and public key are generated simultaneously on the system and you should only ever give out or copy the public key.

The PKCS #12 file can store the private key, which implies to me that you need to create it on the system where it is wanted and where the private key is.

Searching for articles on how to create the PKCS #12 file on your client's OS version, together with Paul's tips above, should help.

Paul Wouters's picture Red Hat Community Member 55 points
27 May 2015 2:28 PM

The PKCS#12 export containing the private key is encrypted to a password you issue. So you can distribute it securely. It is the only way to get the private key securely to the Windows client.

2U Active Contributor 265 points
27 May 2015 4:40 PM

Hi Paul, that's correct. I tried that. However when I import the pkcs#12 package into the win7 client
the mmc import process asks for that password in order to import the .p12 file.
You see; I'm trying to keep the client side "seamless and transparent" as possible.
I'm dealing with end users whose knowledge of certificates & keys is slim to none.
Windows 7 provides a GUI to generate a private/public key pair, but as usual you have to use
their list of CA's (all microsoft) OR obtain a CA from an AD server in your domain.
Microsoft does provide a version of certutil, perhaps the batch (command line) mode will give me some
more flexibility.
Thanks for your help, more will be revealed...

Cheers
Guy

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.