cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
553
Views
0
Helpful
3
Replies

Moving configuration from 8.2 to latest 9.x code

tahscolony
Level 1
Level 1

Upgrading the OS on the core firewall, which of course WILL break the configuration, I know, been there, done that.  My main concern is if I copy the configuration to the new ASA code on another appliance, and repair it, will all my certs be there, or do I need to export all of them and import them?  Once I got the new coe working on the temp ASA, I plan to upgrade the existing ASA to the same code and then move the configuration back.

Here is my main concern, current configuration is in a Context, and will be moved to non Context on the temp ASA, then after upgrading the existing, will be removed from context mode to just single context routed.   Is there anything in particular I should do to make sure the certificates remain intact and functional? Everything else is of little concern to me, my main concern is that the certs work since they are for RSA 2factor.

1 Accepted Solution

Accepted Solutions

James Leinweber
Level 4
Level 4

You are right to worry that you will need extra steps to migrate the certs; the private keys are in hidden storage and not included in the saved configuration.  I move certificate trustpoints between firewalls by doing a pkcs12 export/import.

On the old firewall with the certificate in a trustpoint named XXX do:

enable
configure terminal
crypto ca export XXX pkcs12 P@ssw0rd

Copy the PKCS12 text block and save it.  Escrow the password, which should be a better one than my example.  On the new firewall, to create a trustpoint named YYY using the same escrowed password, do:

enable
configure terminal
crypto ca import YYY pkcs12 P@ssw0rd

It will prompt for the PKCS12 block followed by a single line "quit"; paste the saved text, press enter, and type "quit".  I like to keep the trustpoint names the same across the two firewalls, but you don't actually have to.

I haven't tried moving RSA keys for say, SSH, which aren't included in certificates; those I just regenerate.

If you are moving from 8.2 for the first time, the big things to watch out for are:

  1. NAT was completely redone in 8.3; you will be using less phase I "twice nat" to replace any former "nat 0" needs, and lots of phase 2 "object network" nat for most of your mappings.
  2. NAT translation timing changed to very early/very late; write all the ACL's using the real, on-link addresses, not the mapped ones.
  3. v6 support in access-lists was merged; the "any" keyword is now dual-stack, and there are new "any4" and "any6" keywords for use in mono-protocol rules.  No more parallel access-group statements for the two protocol families.  It helps avoid the ACE element explosion if you use mostly mono-protocol rules.

View solution in original post

3 Replies 3

James Leinweber
Level 4
Level 4

You are right to worry that you will need extra steps to migrate the certs; the private keys are in hidden storage and not included in the saved configuration.  I move certificate trustpoints between firewalls by doing a pkcs12 export/import.

On the old firewall with the certificate in a trustpoint named XXX do:

enable
configure terminal
crypto ca export XXX pkcs12 P@ssw0rd

Copy the PKCS12 text block and save it.  Escrow the password, which should be a better one than my example.  On the new firewall, to create a trustpoint named YYY using the same escrowed password, do:

enable
configure terminal
crypto ca import YYY pkcs12 P@ssw0rd

It will prompt for the PKCS12 block followed by a single line "quit"; paste the saved text, press enter, and type "quit".  I like to keep the trustpoint names the same across the two firewalls, but you don't actually have to.

I haven't tried moving RSA keys for say, SSH, which aren't included in certificates; those I just regenerate.

If you are moving from 8.2 for the first time, the big things to watch out for are:

  1. NAT was completely redone in 8.3; you will be using less phase I "twice nat" to replace any former "nat 0" needs, and lots of phase 2 "object network" nat for most of your mappings.
  2. NAT translation timing changed to very early/very late; write all the ACL's using the real, on-link addresses, not the mapped ones.
  3. v6 support in access-lists was merged; the "any" keyword is now dual-stack, and there are new "any4" and "any6" keywords for use in mono-protocol rules.  No more parallel access-group statements for the two protocol families.  It helps avoid the ACE element explosion if you use mostly mono-protocol rules.

tahscolony
Level 1
Level 1

Thanks, I had a feeling that would be the case. I have migrated at least 100 or more ASA from 8.2 to 8.4+, and most were not pretty, one for example had a 6000 line ACL on the outside due to port translations to an interface, very ugly, and worse, unable to delete it.  I am not even going to attempt to migrate this one, just going to go line by line and recreate all the NAT rules, and just move the ACL's.   The only real consideration I have is RSA, and thats where the certificate question came up, I couldn't remember if the certs were all in the config when you copy it to a server, or if there were hidden keys, and you answered that for me.  I recall having to move a certificate once, but couldn't remember how I did it.

If you are coming off of 8.2 then you probably don't also have to worry about synchronizing a master password, either.  When I was doing my 8.2 to 9.0 migrations a while back (currently on 9.4) I opted for a complete rewrite from scratch too, though I did let my test lab do an in-place 8.2 to 8.6 to 9.0 migration just for giggles and guidance.  I do actually like the new nat style a lot better; it's both more flexible and more concise.

Review Cisco Networking for a $25 gift card