Problem importing a certificate into an ASA

[baskervi]

I have a customer who is doing something a little different than normal for me, and I'm having a problem getting this to work. He generated a certificate from another system, and has sent me the certificate which also includes the private key and CA and intermediate certs. I have the password for when this was exported. This is a little ASA-5505 running 8.2(5) that is sitting on the DMZ of a Firewall1, and there is no web access permitted to it - this is an IPSec VPN used by some phones and tablets, and they haven't wanted to upgrade to AnyConnect - it's command line only. Can anyone suggest ways I might try to import this certificate? I've exported it to a Base64. Thank you very much.

[jagmeesi]

Hi

Can you enable the following debugs while importing the certificate.

debug crypto ca mess 255

debug crypto ca trans 255

and also please let me know what is the signature algorithm being used in the certificate.

Is it, SHA1,SHA2 or MD5.

Regards

Jagmeet

[baskervi]

I pasted in the debug commands and got nothing. Logging is enabled, and for grins it turned on "deb icmp tra", and that resulted in some lines. I was told the signature algorithm was sha-2. 

[Diego Lopez]

Hello, 

If you have a password for the certificate this is a pkcs12 cert it will include the private keys of the cert you need to import it as it is with the private keys included otherwise the ASA will not accept it since the request was not generated directly from the ASA.

Command line process:

need to create a trustpoint to import the certificate:

crypto ca trustpoint ssl-cert

enrollment terminal 

exit

Authenticate the Trustpoint using the  the intermediate certificate

crypto ca authenticate ssl-cert 

Enter the base 64 encoded CA certificate.

quit

Import the certificate

crypto ca import ssl-cert pkcs12 <passphrase>

<paste in the base64 encoded pkcs12>

quit

that should do it.

Regards, please rate!

[baskervi]

I'm just not having any success, and I've attached the information regarding the certificate below. What I've done was to authenticate the trust point using the intermediate certificate from Verisign's/Symantec's web site for a certificate type "Secure Site", which is given at https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=INFO2108. That works fine, and the ASA responds with "CRYPTO_PKI: Inserted cert into list." Next, I try to import the certificate using "crpto ca import ssl-cert pkcs12 <passphrase>, which results in "-----END CERTIFICATE-----
quit
ERROR: Import PKCS12 operation failed"

I've also tried to copy and past various part of the PKCS12 certificate relating to Symantec/Verisign as the intermediate certificate, but that hasn't helped. I'd be grateful for any more assistance.

===> Certificate information

Bag Attributes

localKeyID: 01 00 00 00
friendlyName: 627d1bd1-c529-11e5-aad8-02573e52107d
Microsoft CSP Name:
Microsoft Enhanced Cryptographic Provider v1.0
Key Attributes
X509v3 Key Usage: 10
-----BEGIN PRIVATE KEY-----
IhpHbu1kwEl7LSFzNfPjI628n1sZQ/UQURmGn7h85RotDcrWPl7fFBaV8M7GREH
-----END PRIVATE KEY-----
Bag
Attributes
localKeyID: 01 00 00 00
1.3.6.1.4.1.311.17.3.92: 00 08 00 00
1.3.6.1.4.1.311.17.3.20: 00 80 1A 05
4A 7C 44 E0 BB 62 52 E8 64 83 1C 54 2C 59 6E A9
subject=/CN=Persona Not Validated -
1453921726457/emailAddress=user@domain.com/OU=S/MIME/OU=Persona Not Validated/OU=Symantec Trust Network
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/OU=Persona Not Validated/CN=Symantec Class 1 Individual
Subscriber CA - G5
-----BEGIN CERTIFICATE-----
/NtKOYTPH8XwOAWFUkdkol921MI318qe1xJ55pL+EDcMfLeFzFOZirAOCWS1H-----END CERTIFICATE-----
Bag
Attributes
1.3.6.1.4.1.311.17.3.92: 00 08 00 00
1.3.6.1.4.1.311.17.3.29: D6 54 F1 11 75 B4 B3 F7 5F AD 34 CF 66
E0 A3 9A
friendlyName: VeriSign
1.3.6.1.4.1.311.17.3.20: 55 19 B2 78 AC B2 81 D7 ED A7 AB C1 83 99 C3 BB 69 04 24
B5
1.3.6.1.4.1.311.17.3.9: 30 14 06 08 2B 06 01 05 05 07 03 02 06 08 2B 06 01 05 05 07 03 04

1.3.6.1.4.1.311.17.3.98: CB B5 AF 18 5E 94 2A 24 02 F9 EA CB C0 ED 5B B8 76 EE A3 C1 22 36 23 D0 04 47 E4 F3 BA 55 4B 65
subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use
only/CN=VeriSign Class 1 Public Primary Certification Authority - G3
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust
Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 1 Public Primary Certification Authority
- G3
-----BEGIN CERTIFICATE-----
MIIEGjCCAwICEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAMI-----END CERTIFICATE-----
Bag Attributes

1.3.6.1.4.1.311.17.3.92: 00 08 00 00
1.3.6.1.4.1.311.17.3.20: 67 19 B6 3D A5 79 BB 33 60 D8 2D 53 D3 8C 09 3D 07 AC
18 70
subject=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/OU=Persona Not Validated/CN=Symantec Class 1
Individual Subscriber CA - G5
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For
authorized use only/CN=VeriSign Class 1 Public Primary Certification Authority - G3
-----BEGIN CERTIFICATE-----
MIIGPDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQs-----END CERTIFICATE-----

[mb0587]

Hi, I had this same issue and after a lot of investigation I've made it work.

The issue is that the ASA expects to have the certificate in pkcs(.p12) format encoded with base64

you just need to take your .pfx file and encode in base64 with the following command

#openssl base64 -in xxxxx.pfx > xxxxx.base64

Then you need to open the file and add the PKCS Header and footer just copy and paste it without leaving any space.

-----BEGIN PKCS12-----
-----END PKCS12-----

The end result would be like this:

-----BEGIN PKCS12-----
yH54bCdLWTlWGhXnPC9pGpL9aXGgsmQV/odoxbEa+fZiDpLL+ZRrN2Up7onCC53l
4Qoh76ju/j9vMlRIE5bAUvMqsCl50CP//C50IuSTvBWyN1/M0RclwK4D7wtwGWfz
.................
.................
m3MylWIXt83bP45nzCqmMKc1aiOVbdQQo8M7MSUwIwYJKoZIhvcNAQkVMRYEFDLo
hsQ3m0hoYwLODqBXBpfpM7mWMDEwITAJBgUrDgMCGgUABBR1pxMEpEZwWkvnJauW
9UvnuP403wQIyRcfzvL8incCAggA
-----END PKCS12-----

Now you have your certificate ready for importing it into the ASA. Execute:

crypto ca certificate [your truspoint name you want] pkcs12 [pkcs12 password]

My example

ASA(config)# crypto ca certificate wildcard.brato.local pkcs12 1234567890
Enter the base 64 encoded pkcs12.
End with the word "quit" on a line by itself:

-----BEGIN PKCS12-----
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
....
....
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
-----END PKCS12-----
quit

INFO: Import PKCS12 operation completed successfully

Verify that the truspoint was created:
ASA(config)# show crypto ca trustpoints BRATO

Trustpoint BRATO:
Not authenticated.


Verify that the key was created:
ASA(config)# show crypto key mypubkey rsa | b BRATO
Key name: BRATO
Usage: General Purpose Key
Modulus Size (bits): 1024
Key Data:

The last step is to add the root and the intermediate certifcates to the chain. That is why you have a NOT AUTHENTICATED truspoint.
You need to encode your certificates chain with base64 again. Remember that on the certificate chain you need to form the chain in the issuing order:

CERT INTERMEDIATE
CERT ROOT1
CERT ROOT2
CERT ETC.

you will end with something like this:

-----BEGIN CERTIFICATE-----
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
....
....
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
....
....
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
-----END CERTIFICATE-----

Execute:

crypto ca truspoint BRATO
enrollment terminal
exit
crypto ca authenticate BRATO
Enter the base 64 encoded CA certificate.
End with the word "quit" on a line by itself

MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
....
....
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB

Certificate has the following attributes:
Fingerprint: xxxxxxx xxxxxxxx xxxxxxx xxxxx
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported

ASA(config)# show crypto ca trustpoint BRATO
Trustpoint BRATO:
Subject Name:
cn=brato-DC-CA
dc=brato
dc=local
Serial Number: gglfshlkahfklsahflkhaslkf
Certificate configured.

[Shakti Kumar]

Hi ,

If the signature algorithm is SHA-2 you cannot have the certificate installed on the ASA on code 8.2(5) and that i because of the below bug

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCti30937/?reffering_site=dumpcr

Once you upgrade the code to the fixed version , it should be good.

Hope that helps

Thanks

Shakti

[Alex Pfeil]

I imported an existing .pem file into Internet Explorer (IE) and made sure that the private key was exportable. I then exported the certificate and key with the DES encryption (not AES), and imported it into the ASA.  I know that you can make changes with OpenSSL as well, but IE was an easy method for me.

[Alex Pfeil]

I recently imported a new certificate and key into IE and made sure the key was set to exportable. I exported the certificate and key as DES and it worked again. I just wanted to post an update that this process still works.

[Aaron OConner]

I thought I would share I ran into the same problem on a FTD. When you go to export the pkcs12 file, the private key has to be set to 3DES-SHA1 as the encryption (from windows box). I did this the first time with AES256-AES256 encryption and the FTP would error out with the original error in the post. Once I changed it to 3DES-SHA1 it worked without any additional problems. Im surprised that the ASA/FTD dosent support higher encryption standards. It might be a version specific thing where the IOS needs to be upgraded, but I didnt look that far into it as changing to 3DES-SHA1 fixed the issue. 

[costaspal]

FYI ~> we had that same issue but in our case, was related to - somehow - "corrupted" Key passphrase.

When it was re-issued with changed passphrase, it worked like a charm !

[RachelGomez161999]

This issue presents itself when an RSA keypair is used with the certificate. On ASA versions from 9.4(1) onwards, all the ECDSA and RSA ciphers are enabled by default and the strongest cipher (usually an ECDSA cipher) will be used for negotiation. If this happens, the ASA presents a Self-Signed certificate instead of the currently configured RSA-based certificate. There is an enhancement in place to change the behaviour when an RSA-based certificate is installed on an interface and is tracked by Cisco bug ID CSCuu02848.

Recommended Action: Disable ECDSA ciphers with these CLI commands:

ssl cipher tlsv1.2 custom "AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:
DES-CBC3-SHA:DES-CBC-SHA:RC4-SHA:RC4-MD5"
Or, with the ASDM, navigate toConfiguration > Remote Access VPN > Advanced, and chooseSSL Settings. Under the Encryption section, select tlsv1.2 Cipher version and edit it with the custom string AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DES-CBC3-SHA:DES-CBC-SHA:RC4-SHA:RC4-MD5

Appendix
Appendix A: ECDSA or RSA
The ECDSA algorithm is a part of the Elliptic curve cryptography (ECC) and uses an equation of an elliptic curve to generate a Public Key whereas the RSA algorithm uses the product of two primes plus a smaller number to generate the Public Key. This means that with ECDSA the same level of security as RSA can be achieved, but with smaller keys. This reduces computation time and increases the connection times for sites that use ECDSA certificates.

The document on Next Generation Cryptography and the ASA provides more in-depth information.

Appendix B: Use OpenSSL to Generate a PKCS12 Certificate from an Identity Certificate, CA Certificate, and Private Key
Verify that the OpenSSL is installed on the system that this process is run on. For Mac OSX and GNU/Linux users, this will be installed by default.
Switch to a working directory.
On Windows: By default, the utilities are installed in C:\Openssl\bin. Open a command prompt in this location.

On Mac OSX/Linux: Open the Terminal window in the directory needed to create the PKCS12 certificate.

In the directory mentioned in the previous step, save the private key (privateKey.key), identity certificate (certificate.crt) and root CA certificate chain (CACert.crt) files.
Combine the private key, identity certificate and the root CA certificate chain into a PKCS12 file. Enter a passphrase to protect your PKCS12 certificate.

strong> openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
Convert the PKCS12 certificate generated to a Base64 encoded certificate:
openssl base64 -in certificate.pfx -out certificate.p12
Next, import the certificate that was generated in the last step for use with SSL.

Regards,

Rachel Gomez

[B1r070]

I experienced this issue as well, but it was due to the encryption of the PFX bundle envelope by the OpenSSL software.

On my PC, I was executing OpenSSL v3.0.2 like this:

---

openssl pkcs12 -export -out <pfx bundle>.pfx -inkey <private key>.pem -in <certificate chain>.pem

and after I read Alex Pfel and Aaron O'Conner's posts, I was running it like this:

openssl pkcs12 -export -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -out <pfx bundle>.pfx -inkey <private key>.pem -in <certificate chain>.pem

Which both generated a PFX file that the ASA v9.4 wasn't able to recognise.

When I used an old version of OpenSSL, v1.0.1 in this instance, the generated PFX with the first command above was accepted.

Probably I was using the wrong algorithms with the keypbe and certbe switches, but didn't have the time to figure it out.
If you do, please let me know.

Regards.

[kms4]

@B1r070, we ran into the same problem and your post helped us figure it out. The answer is actually simpler than your suggestion. Try this instead:

openssl pkcs12 -export -out <pfx bundle>.pfx -inkey <private key>.pem -in <certificate chain>.pem -legacy

The legacy option is for backwards compatibility with the encoding to use 3DES and RC2. Hope that helps!

[fbsdkernel]

Exactly what I was looking for, '-legacy' flag on openssl did the trick, cheers!