Part 1: Cisco IPSCE VPN with Certificate Authentication and MAC OS X Lion Fix

There is very little to no good documentation from Cisco, Microsoft, or Apple when it comes to authenticating a VPN tunnel using SSL certificates. I ran across a customer issue last week where, for compliance reasons, a customer needed to authenticate their VPN tunnel using an SSL certificate, rather than a pre-shared key. No problem, I have set this up several times in the past. The curve ball here was that the end users were using 64 Bit Mac OS X Lion.

After struggling with this for a bit and doing a good deal of research, this seems to be the “great unsolved problem” of Mac OS X. I did get a clue as to what the issue was by finding a patched version of racoon, the Mac OS X vpn daemon here https://github.com/p120ph37/darwin-racoon-cisco-cert-fix.   By reading this smart gentlemen’s write up, I learned what the issue actually was.

As you probably know, the reason we use SSL certificates to identify VPN tunnels is to guarantee the identity of the VPN client and the VPN server. This is done by exchanging SSL certificates issued by a common certificate authority. In general, this works the same way from both from the VPN client side and the VPN server side. The VPN client gets the VPN server’s SSL certificate during the Phase 1 negotiation and vice versa. The VPN client then uses a stored copy of the CA certificate that issued the VPN server’s certificate to verify the authenticity of the certificate. That is, the client essentially verifies “am I really connecting to whom I think I am connecting”?

Here is where the Mac OC X rub comes in. The Cisco VPN client retrieves the SSL certificate and checks the subject name of the certificate. That subject name will usual be the FQDN that the VPN client used to connect to the VPN server or the IP address if a DNS name was not used. In my experience, the Cisco VPN client really does not even care about the subject name, but it seems to blindly accept any SSL certificate. As long as the certificate “checks out” when validated by the CA certificate, the Cisco VPN client says “Good enough” and accepts the identity of the VPN server.

Mac OS X’s built in VPN client, raccoon, is a lot stricter when it comes to SSL identity checks. And, it has a VERY odd behavior, At least it seems odd to me, as I have not read the RFCs for this kind of thing. Rather than look at the subject name, the Mac OSX built-in VPN client looks at the SUBJECT ALTERNATIVE NAME (SAN). If the SAN is missing or does not match the FQDN or IP address used to connect to the VPN server, raccoon will assume this is a forged SSL certificate and fail Phase 1 vpn negotiation. The /var/log/system.log will report a failure on the SSL message 6 of the main-mode Phase 1 negotiation like so:

 

So the key to this whole issue revolves around the SSL certificate that is on the firewall; the firewall’s identity certificate. If you follow most guides for SSL VPN authentication, they will have you generate the SSL certificate signing request (CSR) on the firewall device itself, which normally makes a lot of sense. However, since the Mac OS X native client REQUIRES a SAN certificate, and the firewall does not give you this option when creating a CSR, you will need to create the CSR off of the ASA with the SAN fields properly identified. You can then import this certificate and the private key into the ASA with a few OpenSSL gyrations.

I am going to go over how to set this up using a Microsoft standalone, non-AD integrated certificate authority (CA) and then demonstrate how to configure the Mac OS X VPN client to work properly with the ASA for VPN certificate authentication. This can also be done using free tools in Linux, however, I will be using the Microsoft Server for the demonstration.

Part 1: Install the PKI and tools and generate the needed keys and certificates:

1. Install the Certificate Authority role on Server 2008 (Standard edition or better) by opening Server Manager and clicking ADD ROLES. Select the checkbox “Active Directory Certificate Services”. Note that you do NOT have to have an AD infrastructure setup. This can be used as a stand-alone server, even though the title implies it is AD integrated only. When asked for the subject name of the CA, enter something that makes sense for your organization. In my case, I have used the subject name and common name (CN): ca.networksa.org.

2. Now let’s prepare an MMC to get access to all of the tools that we need on Windows 2K8 to generate a CSR, sign the CSR, and finally export the signed certificate. Click Start –> Run and type MMC to get a MMC framework. Click File–> Add/Remove Snap-in and select the Certificate Authority Server snap in. Then, also select the Certificates Snap-in. When prompted for the types of certificates that you would like to manage, select Computer Account on the local computer.You now have a rudimentary Public Key Infrastructure (PKI) set up with the needed tools to manage the PKI for our purposes.

3. Now we are going to generate a CSR for the ASA firewall. In your MMC, expand the Certificates Tool.

• On the “Personal” folder, right click and go to the Advanced Operations menu and select “Create Custom Request”. Click next.

• Select “Proceed Without Enrollment Policy”, and click next.

• Use the default “(No Template) CNG Key” and leave the format in the selected PKCS#10 and click next.

• Click the DETAILS twirl down on the right hand side of the screen and click Properties
  – Friendly Name: Anything you want really. I am just going to use the FQDN for my firewall here. vpn-dfw.networksa.org
  – Description: “ASA Firewall SSL VPN Certificate”.

• Click on the SUBJECT tab. This is the important information!
  Under SUBJECT NAME:
  • Drop down select “Common Name” and enter the FQDN of your firewall here and click ADD. You will see an entry on the left hand side “CN=vpn-dfw.networksa.org”
  • Drop down select “Organization”. This is a key field. When you connect to your ASA, the Organization determines which tunnel-group configuration is used to process the VPN connection. On pre-shared-key VPN configurations, this would be the “Group Name” field. Honestly for the SSL certificate for the firewall, this is not so important, but we will revisit this when we generate a user certificate. I am going to use my employer’s company name for the organization, “Rackspace”. Don’t forget to click ADD. You will see “O=rackspace” in your right hand window now.
  • Drop down select “State”, enter your 2 letter state abbreviation and click ADD
  • Drop down select “Country”, enter your 2 letter country abbreviation and click ADD

• Next, go to the lower right hand quadrant of the form labeled “Alternative Name”

• Select “DNS” from the drop down menu. Enter the FQDN of your ASA firewall. This is the FQDN that your end users will use to connect to your ASA firewall to establish the VPN connection. Click ADD.– In the form labeled “Alternative Name” select IP Address (v4) and enter the IP address of your ASA firewall. This will allow users to connect using either the FQDN or just the IP address of the firewall. Click ADD.

• Now, Click on the Extensions tab. Twirl down the “Key Usage” menu and uncheck “Makes these key use ages critical”.

• Click the Private Key tab, twirl down key options, and check “Make private key exportable” (Important!!)

• Click OK and then Next. You will be prompted for a file name. I am going to browse to my desktop and use the name “asa-vpn.req” and click FINISH!

4. Now that we have the CSR generated with all of the critical fields, we are ready to sign the request with our CA.

• In the MMC, go to the Certificate Authority node and expand it and select your CA Server.

• Right click your CA server, select All Tasks –> Submit new request, browse to your desktop for the request file that we generated in 3 and click Open. You will be returned to the MMC as if nothing happened, but something DID happen. Click on the “Pending Requests” folder and you will now see your CSR waiting to be signed.Make a note of the “Request ID” and then Right click on the certificate request, All Tasks –> Issue.

• If you were successful, you will now see your signed certificate under the “Issued Certificates” folder! The request ID that you noted previously will help you identify which certificate is the ASA’s.

5. We are now ready to export the certificate and add it to our Personal Certificate Store to match the certificate with the Private Key. .

• Right click on the certificate, All Tasks –> Export Binary Data. Leave the default “Binary Certificate” selected and click the “Save Binary Data to a File” Option and click OK. Browse to the desktop and give the file a name like “asa-cert.crt” and click save.

• We now have 1/2 of what we need to move this into the ASA; the certificate. We will also need the private key that was used to generate the CSR and then we want to wrap both pieces up into a PFX file for easy importing to the ASA. The easiest way that I know to do this in Windows is using the MMC.

• In the MMC,  go back to the Certificates tool and click the Personal Folder.
  Right click the Personal folder, All Tasks –> Import. Browse for the asa-cert.crt file that we exported from the CA and then click next until the certificate is imported.If you imported this certificate into the same personal store where you created the CSR, the certificates tool will automatically match up the certificate with the private key. You will see a little Key icon over the certificate indicating that we now have both pieces, the certificate and the private key.

6. We are almost there. Now, we need to export the certificate and the private key as a PFX file.

• Right click the certificate in the Certificate tool and select All Tasks –> Export. Make sure you click “Yes, export the private key”. If this option is not available, make sure that when you created the CSR in step 3, that you clicked “Make private key exportable”. If you did not, you will need to generate a new CSR and go through the previous steps again.

• Leave the default “Personal Information Exchange” PKCS #12 selected with no checkboxes checked. When prompted for a password, enter a password and make a note of it. You will need this password to import the cert and key to the ASA.

• Give the export a file name and click finish. I am calling mine asa-cert.pfx.

 

7. The last thing we will need from the Windows server at this time is the CA’s public certificate.

• You will need to go to the CLI for this. Start –> Run –> cmd

• Type: certutil  -ca.cert ca.cer

• We are not interested in the file that is generated for us. What we want is the text printed in the terminal window. Copy this text to a text document for use in part 2!

We now have everything we need from the CA to begin configuring our ASA. In part 2. we will cover the ASA configuration using all of the pieces that we have created here in part 1!

One Response to “Part 1: Cisco IPSCE VPN with Certificate Authentication and MAC OS X Lion Fix”

1. Paul Hedderly says:

   August 2, 2012 at 8:18 am

   Using SAN records in certificates is smart for the simple reason that the Subject line can only have one CN – so if your VPN conenctrator can be be addressed my multiple names – you need multiple certificates… but only one can be served.

   By using the SAN records, you can specify multiple names in one certificate (vpn.company.co and company.co for example).

   The bug is that the MacOSX version of Racoon (I’ve not checked other versions) _only_ looks for SAN records – it should merge the Subject CN and the SAN records in my opinion.