Old post however:The error comes from the fact that the main configuration file dovecot.conf needs to have a line: "!include conf.d/*.conf"
at the end.
Otherwise it won't load the configuration files that you have inside "conf.d/"
I think this is the reason why you are not getting any difference from changing the settings in the config files within "conf.d/"
Also, why would it say SSL is enabled if it has not been set in 10-ssl.conf or dovecot.conf? Where is it being enabled?
That's because the default configuration is ssl = yes. Not having included the 10-ssl.conf file, where you could either deactivate ssl or set the cert file gives you that result.
Based on the date displayed by your version of OpenSSL, it seems you are seeing the full version displayed there.
Open SSL 1.0.1 was released on March 14th, 2012. 1.0.1a was released on April 19th of 2012.
So, I'm going to go ahead and assert that openssl version -a is the proper, cross-distro way to display the full version of OpenSSL that's installed on the system. It seems to work for all the Linux distros I have access to, and is the method suggested in the help.ubuntu.com OpenSSL documentation, as well. Ubuntu LTS 12.04 shipped with vanilla OpenSSL v1.0.1, which is the version that looks like an abbreviated version, on account of not having a letter following it.
Having said that, it appears that there is a major bug in Ubuntu (or how they package OpenSSL), in that openssl version -a continues to return the original 1.0.1 version from March 14, 2012, regardless of whether or not OpenSSL has been upgraded to any of the newer versions. And, as with most things when it rains, it pours.
Ubuntu is not the only major distro in the habit of backporting updates into OpenSSL (or other packages), rater than relying on the upstream updates and version numbering that everyone recognizes. In the case of OpenSSL, where the letter version numbers represent only bug fix and security updates, this seems nearly incomprehensible, but I have been informed that this may be because of the FIPS-validated plugin major Linux distros ship packaged with OpenSSL. Because of requirements around revalidation that trigger due to any change, even changes that plug security holes, it is version-locked.
For example, on Debian, the fixed version displays a version number of 1.0.1e-2+deb7u5 instead of the upstream version of 1.0.1g.
As a result, at this time, there is no reliable, portable way to check SSL versions across Linux distributions, because they all use their own backported patches and updates with different version numbering schemes. You will have to look up the fixed version number for each different distribution of Linux you run, and check the installed OpenSSL version against that distribution's specific version numbering to determine if your servers are running a vulnerable version or not.
Best Answer
No, you do not need to bother to update them.
It is true that now that heartbleed bug (possibly) has exposed your private key, any third party on network path in between your users and your server ("man in the middle") can see all data as is it was not encrypted.
However, for snakeoil certs, that does not differ much from regular usage case of non-compromised keys, as MITM attack on non-CA certificates is in practice equally trivial. (note that there is a tehnical difference between those two security issues, but in practice they're of the same "weight", so that does not make much difference in real world)
Since you're using snakeoil certs (instead of your own, or some other trusted CA) and so presumably ignore any warnings on such certificates, you should be aware that any data on such SSL connections is really not any more secure than plaintext connection. snakeoild certs are intended only so you technically test the connections before installing real certificate (either signed by your own CA and depending on your PKI - preferable but way more work; or putting trust in some commercial CA, and paying for the less work but lower security)
So in general heartbleed bug has two effects: