09-14-2016 06:10 AM - edited 03-12-2019 01:16 AM
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
Any ideas?
Solved! Go to Solution.
10-31-2016 06:57 AM
Is there possibly a proxy server between your FirePOWER Management Center and the Internet?
04-07-2017 05:49 AM
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.
09-14-2016 08:10 PM
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)?
09-15-2016 04:47 AM
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.
10-31-2016 06:36 AM
10-31-2016 06:57 AM
Is there possibly a proxy server between your FirePOWER Management Center and the Internet?
04-07-2017 03:39 AM
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.
04-07-2017 05:49 AM
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.
04-07-2017 06:08 AM
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....
04-07-2017 09:14 AM
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.
04-07-2017 10:10 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide