Timeline for patching SSL vulnerability (Heartbleed Bug)

Thanks!  That country change fixed it. 

So, just as a confirmation, I am good to go on the other steps where I just went into cert management and refreshed?  The Webadmin piece was the only step that utilizes the command line instructions provided in the latest KB?

I just need 100% confidence I don't need to re-do the SSL VPN certs again.

Thanks!
Jim

No, you do not need to reissue SSL VPN certs. They are signed by the already updated SSL VPN CA. To verify that you can check your actual CA, as shown in the attached screenshot.

Awesome Mino - THANK YOU!  I was about to start to re-deploy the SSL VPN certs. [:)]

-Jim

Lets say I decide to upgrade from V8 to V9 in the coming weeks. I assume hte Heartbleed patches will already be included in the build upgrade files and I wont have to do any special song and dance?

as soon you do the upgrade you will have to regenerate all of the certificates in webadmin.

Lets say I decide to upgrade from V8 to V9 in the coming weeks. I assume hte Heartbleed patches will already be included in the build upgrade files and I wont have to do any special song and dance?

In general, if you apply all the U2Ds at once, you should be safe because they're all downloaded locally and installed one after the other, then the system reboots.

BUT AFAIK there is a gap between v9.004 and 9.005 where you need to update to v9.004 first to be able to see and retrieve the rest of the available U2Ds (until v9.111 which is latest GA). This gap shouldn't be a problem though because v9.0xx is not affected by heartbleed.

So: Update to v9.005 first. Then wait until all U2Ds including v9.111 have been downloaded by the UTM and are available for installation. Then update to v9.111 in one step.

I had no problem with my cluster. 

Only the RED 10 devices were still offline after proceding with the KB Heartbleed: Recommended steps for UTM
Reboot of both (!) UTM's has solved the problem.

Hello everybody,
I updated our active/passive cluster to 9.111 but the RED tunnel doesn't want to come up again... The RED10 is configured in transparent-split mode with fixed IP inthe remote LAN and actually all the clients behind the RED are browsing the web (as configured), but the tunnel with our UTM doesn't work. I try to reboot the UTM as reported by Inter, but without succes-
The RED log is not helpful: 

2014:04:14-15:04:43 fw001-2 red_server[19395]: SELF: RED50 local fw version set to 2031
2014:04:14-15:04:43 fw001-2 red_server[19395]: SELF: IO::Socket::SSL Version: 1.953
2014:04:14-15:04:43 fw001-2 red_server[19395]: SELF: Startup - waiting 15 seconds ...
2014:04:14-15:04:58 fw001-2 red_server[19395]: SELF: Overlay-fw has been updated ...
2014:04:14-15:04:58 fw001-2 red_server[19406]: UPLOAD: Uploader process starting
2014:04:14-15:04:58 fw001-2 red_server[19395]: SELF: (Re-)loading device configurations
2014:04:14-15:04:58 fw001-2 red_server[19395]: A3000*********x: New device
2014:04:14-15:04:58 fw001-2 red_server[19395]: A3000*********x: Staging config for upload
2014:04:14-15:04:58 fw001-2 red_server[19395]: A3000*********xA: device config changed, kicking to force reconfiguration
2014:04:14-15:05:00 fw001-2 red_server[19406]: UPLOAD: [A3000*********x] Uploaded config to registry service
2014:04:14-15:07:46 fw001-2 red_server[19395]: SELF: (Re-)loading device configurations 

The last line is now repeated [:(]

Has anyone any idea?

Thanks Luigi

Hello guys, the openssl vulnerability affects also v8 installations?

Thanks

EDIT: 8.309 seems to be safe, I just tested against some tools such as this one: tif.mcafee.com/heartbleedtest

Hi, 8.x is running a non-vulnerable version of the SSL libs.

Barry