cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9107
Views
0
Helpful
3
Comments
Rudresh Veerappaji
Cisco Employee
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
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: