topic Ah that makes sense. in Network Security

Cisco FirewPOWER Update fails after 6.1

EckoForce_1 — Tue, 12 Mar 2019 08:16:20 GMT

I have Cisco ASA 5516X with FirePOWER services. I received the FirePOWER running SFR 5.4.1-211.

Via CLI - I performed a reimage of the device to upgrade the boot image and the software to 6.0.0-1005.

Via ASDM - I was able to use the update feature to go to 6.0.1.XX

Via ASDM - I upgraded to 6.1

Now I am not longer able to update via the update feature in ASDM.

I get this error: Download updates failed: Peer certificate cannot be authenticated with known CA certificates.

Some Info:

show module sfr

Mod MAC Address Range Hw Version Fw Version Sw Version
---- --------------------------------- ------------ ------------ ---------------
sfr 002a.1025.7adb to 002a.1025.7adb N/A N/A 6.1.0-330

Mod SSM Application Name Status SSM Application Version
---- ------------------------------ ---------------- --------------------------
sfr ASA FirePOWER Up 6.1.0-330

Mod Status Data Plane Status Compatibility
---- ------------------ --------------------- -------------
sfr Up Up

Any ideas?

Well at Release 6.1.0-330 you

Marvin Rhoads — Thu, 15 Sep 2016 03:10:04 GMT

Well at Release 6.1.0-330 you are at the latest release.

Still - the ASDM update feature should confirm that and not throw the error.

Are you running ASDM 7.6(2)?

Marvin,

EckoForce_1 — Thu, 15 Sep 2016 11:47:06 GMT

Marvin,

Yes I am running IOS 9.6(2), ASDM 7.6(2), and FirePOWER 6.1.0-330.

The issue is I cant update anything via the "update"

Actually this issue probably started before as I upgraded to 6.1 by downloading from Cisco and uploading. I had to that with Snort, VDB and other updates as well.

When I try to:Download

EckoForce_1 — Mon, 31 Oct 2016 13:36:26 GMT

When I try to:
Download Rules
Error Peer certificate cannot be authenticated with known CA certificates

Download Updates
Error Download updates failed: Peer certificate cannot be authenticated with known CA certificates

Update URL Filtering
Error Failed URL Filtering Update: 2016-10-31 09:30:03

Not sure whats wrong

Is there possibly a proxy

Marvin Rhoads — Mon, 31 Oct 2016 13:57:22 GMT

Is there possibly a proxy server between your FirePOWER Management Center and the Internet?

Just getting back to this....

EckoForce_1 — Fri, 07 Apr 2017 10:39:08 GMT

Just getting back to this.....

This issue was caused by the SSL inspection configuration. It was set to "Decrypt - Resign" all SSL traffic. I added a "Do not decrypt" rule at the very top of the SSL Policy for the ASA and SFR module. Once deployed works again.

Ah that makes sense.

Marvin Rhoads — Fri, 07 Apr 2017 12:49:24 GMT

Ah that makes sense.

In effect there is a proxy server - the FirePOWER module itself. As it inspects (decrypts / resigns) traffic in the data plane it caused its own traffic from the management plane to fail to connect.

yeah you would think the ASA

EckoForce_1 — Fri, 07 Apr 2017 13:08:23 GMT

yeah you would think the ASA/SFR would be aware but oh well. It appears support.sourcefire.com is similar to google.com in chrome. Another issue we are having where resigning google certs fails to load the page. All the workarounds (from cisco and google) are to whitelist the domains....

I believe that may be due to

Marvin Rhoads — Fri, 07 Apr 2017 16:14:21 GMT

I believe that may be due to what's known as "certificate pinning". It's becoming a greater and greater issue. Apps like iTunes and Dropbox have it too.

The preferred approach in the long term is to put security on the endpoints using solutions like Cisco Umbrella (former OpenDNS product) and AMP for Enpdpoints.

Correct, but this is past

EckoForce_1 — Fri, 07 Apr 2017 17:10:59 GMT

Correct, but this is past cert pinning and HSTS. This is specific only to Chrome and google domains. For example google.com works on IE, Edge, Firefox and Opera. Even though they are pinning the cert we resign and they accept it but Google Chrome can check it further down in the application - I suppose since they had some cert forgery in the past the decided to implement this. Oh well, just added a do not decrypt for DN=*.google for the application chrome and the it works fine.