Cisco ASA: How To Remove/Delete The Default-RSA-Key .server Certificate

Have you ever seen on a penetration test, where you get a weak key on an ASA?  And they want you to take care of it?  I have recently, and I found that the weak key was the <Default-RSA-Key>.server certificate that is created by default on the Cisco ASA.  So here is what I did to remove this and get it taken care of:

ASA(config)# sh cryp key mypubkey rsa
Key pair was generated at: 18:34:10 UTC Sep 23 2014
Key name: <Default-RSA-Key>
Usage: General Purpose Key
Modulus Size (bits): 2048
Key Data:

  XXXX
Key pair was generated at: 01:37:31 UTC Sep 30 2014
Key name: <Default-RSA-Key>.server
Usage: Encryption Key
Modulus Size (bits): 768
Key Data:

XXXX

See that 768 bit key?  We dont want that, so lets get rid of it.

ASA(config)# cryp key zer rsa label <Default-RSA-Key>.server
WARNING: Keys to be removed are named '<Default-RSA-Key>.server'.
WARNING: All device certs issued using these keys will also be removed and
the associated trustpoints may not function correctly.

Do you really want to remove these keys? [yes/no]: yes

ASA(config)# show cryp key mypubkey RSA
Key pair was generated at: 18:34:10 UTC Sep 23 2014
Key name: <Default-RSA-Key>
Usage: General Purpose Key
Modulus Size (bits): 2048
Key Data: xxxxx

ASA(config)#

Now, for whatever reason, it will create that <Default-RSA-Key>.server certificate again.  So we better make sure its 2048 instead of 768.

ASA(config)#  cryp key gen rsa label <Default-RSA-Key>.server mod 2048
INFO: The name for the keys will be: <Default-RSA-Key>.server
Keypair generation process begin. Please wait...
ASA(config)# sho cryp key mypubkey rsa
Key pair was generated at: 18:34:10 UTC Sep 23 2014
Key name: <Default-RSA-Key>
Usage: General Purpose Key
Modulus Size (bits): 2048
Key Data:

  XXXXX
Key pair was generated at: 02:01:28 UTC Sep 30 2014
Key name: <Default-RSA-Key>.server
Usage: General Purpose Key
Modulus Size (bits): 2048
Key Data:

XXXXX
ASA(config)#

So, what I have found is that the next day I did this, the 768 bit key was back again, as a third certificate. After contacting Cisco TAC, this is what they responded back with:

"Thank you for the information. I found a bug that was filed for this behavior. Unfortunately it is not publically visible bug. Here are some details from that bug:

PIX software may generate a self-signed RSA key on bootup that is 768 bits, even if a user-generated key already exists. Vulnerability scanners can identify this as a security risk.

When the default RSA key is deleted, the ASA will regenerate a 768-bit RSA key on a subsequent bootup even if a user-created RSA key exists.  This causes the ASA to fail a vulnerability scan because the 768-bit key is visible to a client that is trying to connect via SSH.  The Qualys scanner specifically identifies this as 38477.

The ASA will retain all keys over a reboot as long as a "write mem" is done after the keys are created.  This applies to the "<Default-RSA-Key>" that is created by "crypto key generate rsa" and the "<Default-RSA-Key>.server" key that is created upon the first ssh connection to the ASA. Tested this behavior on 8.0(4.33) and the key is not automatically generated.

Basically what this means is, to fix the issue, an upgrade to a newer code is required. The best code to upgrade to without major config modifications would be 8.2.5"

UPDATE:

So, just FYI.  Even after the upgrade, the problem of the cert and the weak key came back. No resolution at this point and Cisco TAC says there is no answer.