Heartbleed and Bitnami

Is there an ETA for when the Bitnami images will be patched for the Heartbleed OpenSSL vulnerability?



+1 to this.

Does anyone have any suggestions for updating OpenSSL outside of the Bitnami process? I’ve built the latest stable OpenSSL on my development LAMP Stack and it appears to work. Is there any way to test this?

We will be sending an email momentarily. More details here



Daniel, could you please elaborate on how I install the update mentioned in the wiki please (where I put the file) Thank you.
This all sounds very alarming to someone who is not a developer so a step by step, idiots guide, all the way to the end would be HUGELY appreciated.

Hi Simon, the step by step is provided in the wiki. You need to download and run the provided patch installer and follow the instructions. If you are running a server just for local development, or if you have not enabled SSL in your site, you should not be affected (it is still a good idea to upgrade)

Thank you Daniel
I’m sure it looks like a step by step to people who understand this stuff but I’m just a guy who is running a moodle site on EC2. I’m not a software developer. So I’m not sure from the wiki where I am supposed to put the downloaded file. In the root directory? And then there is the question of revoking and redistributing private keys??? Process for doing that? Implications to user of the site if any?
Thank you for taking the time to respond and for everyone at Bitnami for endeavoring to help people with Bitnami stacks to overcome this issue.
… OK! I think I answered my own question. I have successfully updated openssl. Clearly I was just over complicating things in the panic of the “Take immediate action” message from the vulnerability test :wink:
Now the only thing remaining is the private keys. Is that referring to the keys required for integrations such as moodle to mahara and joomdle? Or are there other layers to that step?
And thank you again. I really do appreciate your patience. It can’t be easy dealing with people like me :smile:

Hi @simon

This is only necessary if you already configured HTTPS with your own certificate. In this case you should regenerate new certificates and configure them again in your server. If you did not configured that you do not need to regenerate them.

Hi - Thanks for the email detailing the issues with existing installations.

I’m currently running the Bitnami Redmine Installation on a windows platform. You’ve provided links for openssl updates for various platforms, but not Windows.

Do you have a link for this?

In the Windows case it is not necessary to update the library. Apache for Windows was compiled with OpenSSL 0.9.8 and that version is not affected by this issue.


I can see that there are multiple versions of openssl installed in the Bitnami Redmine Stack:

Apache2\bin: OpenSSL 0.9.8y 5 Feb 2013
Subversion\bin: OpenSSL 1.0.1c 10 May 2012

Currently (due to PATH settings) it’s the latter that’s reporting back by default when I open a cmd prompt.

Are you saying that it’s the version that Apache itself is using that’s pertinent here? and when there are multiple versions installed like this, how can you tell? Does it use the PATH in preference? Or will it pick up the version in the Apache folder every time?

Is there any test which you can return from Apache itself on the server to confirm the version in use? The site itself ‘looks clean’ on your test link http://filippo.io/Heartbleed, which is a positive - but the test on the machine itself using the openssl version -a gives conflicting information… (because of the PATH settings)

When does the version in the subversion folder get used - if ever? Is there any scenario where that could still cause an issue?

Great. Thank you Beltran.

Hi I’m getting some,

The selected Bitnami installation architecture (osx) does not match the one bundled in this patch (osx-x86_64)

Please help me.

Why isn’t it necessary to generate new certificates when I use Bitnami’s? A Bitnami Redmine installation which I host is accessible from the internet. I do not use my own certificate, only the one which is generated by Bitnami’s Redmine stack.

Our version is OpenSSL 0.9.8r and system is mac. But issue is there.



I’m running the TracStack on Windows. The test at http://filippo.io/Heartbleed is telling me that it is vulnerable, but your post suggests that it is not. Not sure how to proceed without a Windows patch from Bitnami. Any advise?


Hi all!
I have ubuntu x64 machine and I’ve tried to go through instructions mentioned here
but when I download and start opensslfix I see no output (I’ve downloaded it with wget and checked md5), it just runs
a couple of seconds and exits; /opt/bitnami/opensslfix folder doesn’t exist.
apt-get update - works
apt-get upgrade - works
when I try to do sudo apt-get install -y libssl1.0.0 openssl, I see

libssl1.0.0 is already the newest version. openssl is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
if I do
$ openssl version -a OpenSSL 1.0.1e 11 Feb 2013 built on: Fri Jul 12 11:34:28 CEST 2013 platform: linux-x86_64
but if I do
$ /usr/bin/openssl version -a OpenSSL 1.0.1 14 Mar 2012 built on: Mon Apr  7 20:33:29 UTC 2014 platform: debian-amd64

Does it mean the problem is solved? but I still see compromised version there. What should I do?
I did sudo reboot after installation

I should add that the installed version is:


No success using patch at 2014-04 Heartbleed Bug

I downloaded the patch for Linux 64bit, then:

root@trac:/home/bitnami/heartbreak# uname -a
Linux trac.home.local 3.2.0-31-virtual #50-Ubuntu SMP Fri Sep 7 16:36:36 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
root@trac:/home/bitnami/heartbreak# md5sum bitnami-opensslfixer-1.0.1g-0-linux-x64-installer.run 
30e4e4199b5f0d41dced11c2db2f8d5c  bitnami-opensslfixer-1.0.1g-0-linux-x64-installer.run
root@trac:/home/bitnami/heartbreak# ./bitnami-opensslfixer-1.0.1g-0-linux-x64-installer.run 
Segmentation fault

Apologies if I goofed up, but I wanted to get the feedback to you quickly.


Apache uses the 0.9.8y OpenSSL library so it is not currently vulnerable. This issue only affects to sites that you already configured a custom HTTPS certificate. The other library only used by Subversion.

You probably are using an old version of a stack in OS X Intel 32 bit. You are currently using 0.9.8 version so this version is not vulnerable. It is not necessary to fix your installation.