Problems with generaring RSA key pair for SSH and getting certificates from CA
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:
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:
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: ASA2.cisco.com
% 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.cisco.com
ASA2# sh crypto ca cert CA Certificate Status: Available Certificate Serial Number: 01 Certificate Usage: Signature Public Key Type: RSA (1024 bits) Issuer Name: cn=gibsgw.domain.com Subject Name: cn=gibsgw.domain.com 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
ASA2(config)# 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.
Re: Problems with generaring RSA key pair for SSH and getting ce
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.
Re: Problems with generaring RSA key pair for SSH and getting ce
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...