See bug# 163851. Opening separate bug, as per uberlord's suggestion. With USE ssl, the ebuild silently installs an invalid ssl cert/key pair /etc/ssl/dovecot/{server.pem, server.key}. The dovecot tarball does supply doc/mkcert.sh and doc/dovecot-openssl.cnf for generating a valid certificate/private key, but those files are currently not installed. Perhaps the ebuild should install these additional doc/ files and issue a notice of some kind? I'm not sure how best to handle the generation of a valid cert/key (i.e. if automatic generation makes sense) but I'm fairly certain that silently installing an invalid one isn't ideal. Reproducible: Always
Care to explain how exactly is the certificate *invalid*? Already told once that the certificates are for *testing* purposes, if you need real ones, then create your own certificates as needed; we can't read your mind as for which certificates you need and its not really our business. So, what's invalid there? Plus using some bundled homebrew scripts turns out to be potentially a serious security issue (as recently with openldap).
http://www.sdesign.us/~drphibes/desktop.png illustrates the problem I observed with the gentoo-installed cert. it is "invalid" in the sense that any attempt to use it or verify it results in an error. if you create a self-signed cert with syntax similar to this: openssl req -new -x509 -nodes -out test.pem -keyout test.key -days 365 (as mkcert.sh does), then the cert passes the test: openssl verify -CAfile test.pem test.pem and you can use it. I am not trying to be argumentative or pedantic here, I am simply reporting my experience with the ebuild and what I had to do to get things working. If you feel there's no problem and no need to make any changes, fine. Phil
also i agree that running a third party script is not advisable. making it available to users, however, *might* be something to consider.
The author of ssl-cert.eclass is retired afaik. Also, postfix (and other ebuilds) install SSL certs in the same manner, so this bug equally applies. The beauty of ssl-cert means that all apps that require SSL certs get it made the same way, as many apps that ship with scripts to make certs are often buggy and use once only type things, so an eclass is the best solution imo. I'm not the best person to handle this, and as the mail apps seem to use it more I'm going to re-assign this bug.
why not advice the user to run cd /etc/ssl/dovecot openssl req -new -x509 -nodes -out server.pem -keyout server.key -days 365 and disable the eclass generation? the eclass generated certs failed for me too.
This bug should probably be recategorized to refer specifically to the docert() function in the ssl-cert.eclass. Note that bug #123316 is exactly the same issue on a different package. docert() is the culprit there also.
*** Bug 123316 has been marked as a duplicate of this bug. ***
Hi- Hopefully, this will explain what "Invalid SSL Certificate" means a little better. The cause and fix are listed below from an IBM article on the subject. http://www-01.ibm.com/support/docview.wss?uid=swg21266530 This is still happening in net-mail/dovecot-1.1.7-r1. Since courier-imap no longer supports qmail/vpopmail setups and dovecot will be replacing it. I'd suggest that the SSL cert be created in the same way that Courier IMAP and netqmail handle creating certs. With the netqmail and courier-imap, the emerge notes suggest that the user edit a config file before creating the cert. Those certs work fine with Thunderbird. Currently the dovecot config doesn't prompt the user to do this and creates a cert that isn't accepted by Thunderbird. Thunderbird won't allow a secure connection with the current gentoo dovecot config script generated cert. The user is forced to send his password via plain text. Something that the gentoo netqmail guide says not to do. Excerpt from the IBM article below: HTH, Thunderbird gives me the same error as for Firefox below: Firefox reports: Could not establish an encrypted connection because certificate presented by [host name] has an invalid signature. Internet Explorer reports: The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or you may need to adjust your browser settings. Cause The keyring file created by the CA database has the same name for both the certificate subject and certificate issuer. Resolving the problem Create another Certificate Authority and signed keyfile for the server using unique values for the certificate subject and issuer.
(In reply to comment #5) > why not advice the user to run > > cd /etc/ssl/dovecot > openssl req -new -x509 -nodes -out server.pem -keyout server.key -days 365 > > and disable the eclass generation? > > the eclass generated certs failed for me too. > This worked great and fixed the problem with Thunderbird. Thanks for that, and yes it would be helpful to have this instead of the current config script that creates a cert that doesn't work with Thunderbird SSL/TLS connections. Cheers,
Ditto on comment #9. I ran into this too with 1.1.7-r1. I thought I was being good by following the instructions to do "emerge --config ..." but it set me up for failure and google led me here for the fix.
This has had me stumped for hours today. I must admit that I find the subject confusing but surely someone knows how to do it properly. David Sperling was right though, the common names cannot match. I edited the eclass to make it generate a slightly different config for the CA, where it appends "CA" on the end of the common name. This made Windows slightly happier but it still wasn't satisfied. I imported the CA certificate as well (this normally gets deleted) and all errors disappeared from the certificate manager but Chrome still wouldn't connect. :(
Created attachment 215449 [details, diff] ssl-cert.eclass.patch Okay, I've more or less fixed this now. Here's a patch that does the bare minimum. I found a guide for creating your own self-signed CA. What was being done here was all wrong. For starters, you don't create a CSR for the CA itself. Even with this patch, it still doesn't install the CA certificate. Firefox will let you override this and Chrome will complain about it once per session but it may be a good idea to install it anyway.
Just read in the news that 768-bit RSA encryption has been broken and 1024-bit will be next. We theremore may want to raise the default value of SSL_BITS from 1024 to 4096.
Thank you guys for report and explanation of this problem. Should be fixed with: http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/ssl-cert.eclass?r1=1.17&r2=1.18 ... still I wonder, do we really need CA? It looks like self signed certificate is better then certificate signed with some unknown CA.
