Cisco VPN Client: Error 39 when importing Root Certificate

Ok, this was a head scratcher and of course now it makes total sense; in hindsight. Yes, today I "suffered mightily under the iron fist of PKI."

Client was getting this error when trying to import their Root CA certificate into the Cisco VPN client. The following items were not the problem:

• Key length was 2048 bits, so no issue with the key being too long
• Validity period was good
• File wasn't corrupt

The error wasn't much help and calls to Cisco turned out to be somewhat of a red herring as Cisco admitted a bug existed related to certificate imports but had no fix available. We could get other certificates to import fine but were at a loss as to why this particular certificate was somehow "invalid" when everything appeared to the contrary.

The break came when we reproduced the customer's CA configuration in a VPC and started altering the fields that were specific to their implementation:

• Basic Constraints had an error - path length was empty
• CRL DP had the "UnknownConfigDN" present in the LDAP URL
• Issuer/Subject fields on the non-working certificate used CN=RootCA,O=<Org>,C=<Country> format while others did not

As it turned out the Basic Constraints was a non-issue and is typical of renewing the CA certificate using 'certutil -renewcert' instead of going through the GUI. Brian Komar was kind enough to point out that this is due to a bug in Windows Server 2003 where renewing a certificate and changing the key ignores the CAPolicy.inf but I digress.

The CRL DP was also a false start - as it turns out, we're pretty certain the VPN client doesn't even attempt to validate this during import.  That left us with the Issuer and Subject fields...

Let's make one thing very clear, the distinguished name of your CA is not really a DN that should be reachable by any means. It is simply a distinguished name that allows you to infer some sort of organizational or country specific affiliation should you choose to do so. As it turns out, the Cisco client is very particular about RFC5280 to paraphrase Brian Komar.  For instance, the following are all legal distinguished names for your CA:

• CN=My really really long Root CA Name,O=MyCoolOrg,C=US
• CN=MyRootCA,O=Organization
• CN=RootCA
• CN=RootCA,DC=my,DC=activedirectory,DC=domain

None of these need exist but they are all valid syntaxes; however let us say that you have the following AD domain - domain.local and you decide that you would like the following CA DN:

• CN=MyRootCA,O=domain,C=local

Then you would get an Error 39 from your Cisco VPN client when it went to import it. The Microsoft CA doesn't care in the slightest and everything will function properly, until an application attempts to validate the syntax of your CA DN according to the RFC and X.520.

As it turns out, the client saw the "C" and attempted to validate it according to X.520 which says it should be no bigger than 2 characters. To test this further I created the following test CA DN:

• CN=MyRootCA,O=domain,C=xx

"C=xx" is not on the list of approved ISO 3166 codes and guess what...the Cisco client didn't care (would have been pretty impressive and yet self-limiting if it had).

So, the moral of the story is, if you are going to set your CA DN and you want to use the C/Country indicator then you need to stick to strict syntax and a two digit ISO 3166 country code; otherwise you can omit it altogether or use your OU/DC structure that you are most familiar with from Active Directory.

If you're still reading this and you don't already own one of Brian Komar's books, then stop what you are doing and go buy one.

Amazon.com: Windows Server 2008 PKI and Certificate Security (PRO-Other) (PRO-Other)