Problems with generaring RSA key pair for SSH and getting certificates from CA

Unanswered Question
Jul 23rd, 2010
User Badges:

Hello security gurus.

My problem is twofold:
I'm experiencing a strange behaviour while generating a pair of RSA keys on the ASA. The plan is to use it both for SSH and enrolling with CA for future site-to-site VPN tunnel. First of all I want to assign a particular label to the RSA key pair and do it the following way:

crypto key gen rsa label RSA-GEN-KEYS mod 1024

The key seems to be generated

ASA2(config)# sh crypto key mypub rsa
Key pair was generated at: 09:40:49 UTC Jul 23 2010
Key name: RSA-GEN-KEYS
Usage: General Purpose Key
Modulus Size (bits): 1024
Key Data:

30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00c5ccc4
a0fdcf31 9c5fb480 cc139fd0 8f15cdbd d82d651f a8015bca 1db4fe24 d81c21a4
a633eecd 2aec2cf1 c33c5d83 e4dc757c 0eb33ac7 80b7367f 594f5c4e 20aa30ca
70068635 6b050d47 e5e50c52 fa3edd2b b5f075cd 73e9d41c 4761b783 e44c3e7b
741fbf63 9a514e6c c35d9c14 e9a76c83 5f2d95d2 eb8ea443 dce32c1a 2f020301 0001

Then I complete SSH configuration and all my attempt to connect to the ASA from SSH client fail. The SSH debug says that I have problems with the key:

SSH: unable to retrieve default host public key.  Please create a defauth RSA key pair before using SSH
SSH0: Session disconnected by SSH server - error 0x00 "Internal error"

This is the first thing that I don't understand. According the Cisco guide I can generate the key with a label. I attached a screen shot of the portion of the guide saying that I can choose the label associated with this key. Why such incongruity ?

Later I want to use the key labeled as above for trustpoint configuration similar to this:

crypto ca trustpoint EXT-CA
enrollment url
  keypair RSA-GEN-KEYS

The process of enrollment seems to go OK except for one thing, I don't get the certificate issued to this particular ASA:

ASA2(config)# crypto ca authen ?

configure mode commands/options:
WORD < 65 char  Trustpoint Name
ASA2(config)# crypto ca authen EXT-CA

INFO: Certificate has the following attributes:
Fingerprint:     9ba0e95d ad1c115b 58b78159 a8eb5bb8
Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
ASA2(config)# crypto ca enrol EXT-CA
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password: 123456
Re-enter password: 123456

% The fully-qualified domain name in the certificate will be:

% Include the device serial number in the subject name? [yes/no]: no

Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority

Here I would expect to see the certificate with a subject name

ASA2# sh crypto ca cert
CA Certificate
Status: Available
Certificate Serial Number: 01
Certificate Usage: Signature
Public Key Type: RSA (1024 bits)
Issuer Name:
Subject Name:
Validity Date:
start date: 18:41:48 UTC Jul 19 2010
end   date: 18:41:48 UTC Jul 19 2011
Associated Trustpoints: EXT-CA

If I do it again and enable debugging on Cisco router that acts as CA I see that the request for the certificate is granted and the certificate is sent to the requestor:

Jul 23 18:09:42.478: CRYPTO_CS: received a SCEP request, 2255 bytes
Jul 23 18:09:42.478: CRYPTO_CS: read SCEP: registered and bound service SCEP_READ_DB_6   
Jul 23 18:09:42.490: CRYPTO_CS: scep msg type - 19
Jul 23 18:09:42.490: CRYPTO_CS: trans id - d7b4df22ff5216b0c8a8aafb6adeeb45
Jul 23 18:09:42.622: CRYPTO_CS: read SCEP: unregistered and unbound service SCEP_READ_DB_6   
Jul 23 18:09:42.622: CRYPTO_CS: received an enrollment request
Jul 23 18:09:42.622: CRYPTO_PKI: creating trustpoint clone LOCAL-CA6
Jul 23 18:09:42.622: CRYPTO_CS: checking policy for enrollment request ID=6
Jul 23 18:09:42.622: CRYPTO_CS: request has been authorized, transaction id=d7b4df22ff5216b0c8a8aafb6adeeb45
Jul 23 18:09:42.622: CRYPTO_CS: locking the CS
Jul 23 18:09:42.626: CRYPTO_CS: added CDP extension
Jul 23 18:09:42.626: CRYPTO_CS: added sub alt name extension
Jul 23 18:09:42.626: CRYPTO_CS: added key usage extension
Jul 23 18:09:42.626: CRYPTO_CS: Generating shorter-duration cert
Jul 23 18:09:42.626: CRYPTO_CS: Validity: 11:09:42 PDT Jul 23 2010-11:41:48 PDT Jul 19 2011

Jul 23 18:09:42.854: CRYPTO_CS: file opened: flash:7.crt
Jul 23 18:09:42.854: CRYPTO_CS: Writing 632 bytes to crt file
Jul 23 18:09:43.266: CRYPTO_CS: file opened: flash:7.cnm
Jul 23 18:09:43.266: CRYPTO_CS: Writing 104 bytes to cnm file
Jul 23 18:09:43.566: CRYPTO_CS: writing serial number 0x7.
Jul 23 18:09:43.566: CRYPTO_CS: file opened: flash:LOCAL-CA.ser
Jul 23 18:09:43.570: CRYPTO_CS: Writing 32 bytes to ser file
Jul 23 18:09:43.870: CRYPTO_CS: reqID=6 granted, fingerprint=E
Jul 23 18:09:43.870: CRYPTO_CS: unlocking the CS
Jul 23 18:09:43.870: CRYPTO_CS: write SCEP: registered and bound service SCEP_WRTE_DB_6   
Jul 23 18:09:44.034: CRYPTO_CS: write SCEP: unregistered and unbound service SCEP_WRTE_DB_6   
Jul 23 18:09:44.090: CRYPTO_CS: Certificate generated and sent to requestor

The ASA finally reports that the request fails

Certificate is not valid yet.
The certificate enrollment request failed!

This is the second stumbling point that prevents me from establishing a site-to-site VPN tunnel based on digital certificates. Anyone has courage to help me with an advice? If you start with asking about the clock settings on the CA and the client then they are synced.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Rahul Govindan Fri, 07/23/2010 - 18:45
User Badges:
  • Silver, 250 points or more

Regarding the ssh issue, I believe only default rsa keys can be used for ssh. Key pair with labels can be created but still a default rsa key-pair has to be present on the ASA. There is an enhancement request to change this but don't think anything has happned in that front for a while.

Bug id: CSCeg00915

And regarding the certificate issue, the only thing that comes to my mind with the corresponding error message is the time. Can you check what is the time on the ASA when you get the cert enroll failed? From the debugs we can see the validity of the cert that the ca server is pushing. So even if there is a small offset you might be getting that error.


zheka_pefti Sat, 07/24/2010 - 13:32
User Badges:

Thanks a lot!!!

It really makes me smiling at the fact there's always a room for something unexpected. And this unexpected is a bug.

Should I refer the proctor at my CCIE Security Lab exam at this particular bug in case of the similar task ?

As for the second problem, you are absolutely right. Even though I thought that the time at two devices in question is identical it turned out there was slight skew in time. Sorry for a false alarm. The certificate was finally received after manually syncing time.



This Discussion