Bug#771334: upgrade hosed dovecot; Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY
Source: dovecot Version: 1:2.2.13-7 Severity: serious After upgrading to this version, I cannot connect to dovecot's imap or pop servers. joey@darkstar:~telnet kitenet.net imap Trying 66.228.36.95... Connected to kite.kitenet.net. Escape character is '^]'. Connection closed by foreign host. Offlineimap fails connecting to imaps; the ssl handshake fails. journald has logged: Nov 28 11:33:44 kite dovecot[14616]: imap-login: Fatal: Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY Nov 28 11:33:44 kite dovecot[14604]: master: Error: service(imap-login): command startup failed, throttling for 4 secs Nov 28 11:33:48 kite dovecot[14616]: imap-login: Fatal: Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY Nov 28 11:33:48 kite dovecot[14604]: master: Error: service(imap-login): command startup failed, throttling for 8 secs I suppose it's not cooincidental that the change in -7 had something to do with cert locations. My dovecot cert appears to be in /etc/dovecot/private/dovecot.pem, and it starts with -BEGIN PRIVATE KEY- Downgrading to -6 worked around this. -- see shy jo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771334: upgrade hosed dovecot; Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY
On Fri, 28 Nov 2014, Joey Hess wrote: After upgrading to this version, I cannot connect to dovecot's imap or pop servers. The only substantive change in -7 was to comment out the ssl_cert and ssl_key entries in /etc/dovecot/conf.d/10-ssl.conf. This is so people who do not have certificates set up (e.g. in new installs) don't run into this problem. But you are upgrading from an existing working setup right? In that case dpkg should have warned you that you are upgrading a conffile. Did that not happen? Actually I just looked and it seems the configuration files are not getting marked as conffiles even though we are handling them with ucfr. Let me investigate why this is happening. -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771334: upgrade hosed dovecot; Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY
After further investigation this seems to be the problem. Originally the dovecot-core postinst created self-signed ssl certificates and modified /etc/dovecot/conf.d/10-ssl.conf to enable them. ucf managed upgrades to these files. As of 2.2.13-6 we stopped doing that. However this meant that new users who did not have certs got an error because dovecot tries to use the non-existent certificate. So in 2.2.13-7 the configuration is shipped with the ssl cert location bits commented out. Now new users and anyone who has modified the locations in ssl_cert and ssl_key can successfully install or upgrade. But people like you have a 10-ssl.conf that looks exactly like the default one in -6. So apparently ucf thinks you haven't modified the default configuration and blindly installs the new configuration on top of it. I don't know if that should be considered a bug in ucf but the workaround in dovecot-cores postinst I am thinking of is to check the values of ssl_cert and ssl_key and see if there are actually files there and if so, avoid commenting them out or maybe it will be simple to change the value of the ssl parameter to no by default. (It seems obvious but I have a nagging feeling it might not work. I'll experiment.) -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
