cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Wildcard certificate export issues on ASA

7512
Views
0
Helpful
3
Comments
Cisco Employee

Of late I have seen quiet a few instances wherein Netwok adminstrators are facing issues with exporting wildcard certificates in pkcs 12 format from an ASA and use it on other network devices (mostly for SSL ). In this blog post lets disucss about the reasons for the same and workarounds to overcome this issue.

Scenario:

ASA, any model, running post 8.2.x software version

Assume you have obtained a wildcard certificate from a third party CA (Certificate Authority) by generating a CSR (Certificate Signing Request) at one ASA, and successfully installed this wildcard certificate on this ASA. After this, to leverage the basic use of wildcard certificate, when you try to export this wildcard certificate in PKCS 12 format (which contains Identity certificate + RSA key pair + certificates in the chain), you might get the following error:

"a required certificate or keypair was not found export certificate"

(same error on CLI or ASDM)

This could because for the following reasons, lets discuss them in detail:

     1. The identity certificate or the certificates in the chain itself could be missing. Or the RSA key pair that you would have used to create the CSR originally could have been zeroized and thereby not present on the ASA anymore. In this case you could solve the problem by regenerating the CSR and enrolling the trustpoint again.

     2. The other possibe reason is that, the Certificate Authority could be using "printable string" encoding type for generating the wild card certificate. But the "printable string" encoding type does not contain * in its set. As you might be aware, you would have the CN with a wildcard character * in your wildcard certificate to recognize multiple devices that fall in the same domain.

Ex:

Issued to:

CN = *.example.com.au

     The CA must use the encoding type like "TeletexString" to generate wildcard certificates so that the * character is supported in the CN field. As mentioned in the RFC (Appendix C.  ASN.1 Notes in RFC 2459) we should not be supporting the character ( * ) with the"printable string" encoding type in the wildcard certificates. Now in the earlier ASA releases (pre 8.2.x versions) the ASA was allowing the use of * with printable string encoding, and you would have installed the wildcard certificate, and later exported these wildcard certificates just fine, Post 8.2.x releases, although it supports installation of the wiilcard cerficiate on one ASA on which the CSR was generated, it shows the following warning at time u actually import the certificate:

WARNING: Invalid string: *.examplepki.com       Encoding: Printable String 
Printable String character set is { A-Z a-z 0-9 (space) ' ( ) + , - . / : =
? }
WARNING: Invalid string: *.examplepki.com       Encoding: Printable String
Printable String character set is { A-Z a-z 0-9 (space) ' ( ) + , - . / : =
? }
Certificate associated with trustpoint TrustPoint_W-05-16-2011 does not comply with ASN.1 encoding
rules.It should be reissued to make it compliant and avoid interoperability issues.

INFO: Certificate successfully imported


Here is the bug filed that addressed the issue with incorrect encoding type for wildcard certificates post 8.2.x:

CSCsl92337 :  ASA should check the validity of certificate during importing

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsl92337

  Although the wildcard certificate is allowed to be installed on the ASA, it will not be allowed to be exported since the certificate actually doesn't have a valid encoding type (if "printable string" is used) and thereby it cannot be used as a wildcard certificate. The reason for allowing the installation of certificate on the first ASA in the first place, is to avoid downtime for customers, considering the business impacts it could have when an adminstrator tries to reinstall a certificate few days before his old certificate expires.

Meanwhile here are the other types of encoding available:

 DirectoryString ::= CHOICE {
         teletexString           TeletexString (SIZE (1..MAX)),
         printableString         PrintableString (SIZE (1..MAX)),
         universalString         UniversalString (SIZE (1..MAX)),
         utf8String              UTF8String (SIZE (1.. MAX)),
         bmpString               BMPString (SIZE (1..MAX)) }

   " The character string type PrintableString supports a very basic Latin character set:  the lower case
   letters 'a' through 'z', upper case letters 'A' through 'Z', the digits '0' through '9', eleven special
   characters ' " ( ) + , - . / : ? and space. "

http://www.faqs.orgrfcs/rfc2459.html

So here are the options you have if you are facing the above mentioned scenario with being unable to export wildcard certificates due to wrong
encoding type used:

     1. So you can downgrade the ASA to a pre 8.2.x version (i tested it in 8.0.3) and u'll be able to export the wildcard certificate fine.

     2. Other option is request your CA to generate a new certificate with proper encoding type (like "TeletexString") which will support * character
          in the DN of the certificate.

     3. Instead of generating a key pair on the ASA and then a CSR (the certificate from which will you will not be export because of the encoding
         issue), you can generate RSA key pair and then the CSR from a Windows Server 2003/2008 (or any such server capable of generating CSRs)
         and then once the server has thecertificate on it, you can export it with .pfx (i.e pkcs12 ) format.
         http://www.serverintellect.com/support/windowsserver2003/create-certificate-request.aspx
    
         Once you have the certificate in the Windows 2003/2008 server, you can export it in .pfx or pkcs12 format, and then you can import it on any
         ASA, since from the Windows server it is exportable without any issue.

The options 1 and 3 are just the workarounds, and ideally from a security perspective and a long term solution you should be choosing option 2 wherein
you have the right encoding for the wildcard certificates.


Please feel free to share your thoughts and let me know if you have any questions.

Cheers,
Rudresh

3 Comments

Hi Rudresh,

In your post you said:

Assume you have obtained a wildcard certificate from a third party CA (Certificate Authority) by generating a CSR (Certificate Signing Request) at one ASA, and successfully installed this wildcard certificate on this ASA.

It is possible to import a wildcard certificate from third party CA but the ASA did not generate the CSR?

Thanks,

Daniel

Cisco Employee

Hi Daniel,

Yes we can. We can generate a generate CSR from another device (like windows 2003 server: http://www.serverintellect.com/support/windowsserver2003/create-certificate-request.aspx) and obtain a wildcard certificate from the third party CA for this CSR. After this you can export the wildcard certificate in pkcs 12 format from the windows server and then import it to the ASA.

Cheers,

Rudresh

Beginner

Hello,
Recently we have purchased a wildcard certificate from GeoTrust and we have managed to install this certificate to some of our infrastructure servers. Unfortunately I am unable to install the same certificate to ASA for use in AnyConnect SSL VPN.
I have successfully installed the CA interim certificate and created the Geotrust trustpoint on the ASA but when I try to import the identity certificate from ASDM I receive the following error:
Import PKCS12 operation failed.
I have tried to import from .p12/.pfx and from .pem file with the same result.
Any advice will be much appreciated!
Regards, Kliment