SSL problems on dovecot 2.1.7

SSL problems on dovecot 2.1.7

[Steinar Bang]

When I upgraded my debian-based imap server from squeeze to wheezy
yesterday, SSL stopped working.

I am using a http://cacert.org signed server sertificate, and I am
reusing the certificates that were used on the 1.x dovecot of debian
squeeze.

My three MUAs that worked against the previous 1.x dovecot with the same
certificate, now fails in various ways.

Any hints and guesses as to how to debug this further will be highly
appreciated.  Even more appreciated will be a pin point of the issue. :-)

Here are the error messages from the MUAs:
 - Emacs24(w/linked-in gnutls)/Ma Gnus 0.8 (Gnus git HEAD) on Windows 7 says
   "imap.mydomain.com certificate could not be verified."
 - Emacs23/Ma Gnus 0.8 (also Gnus git HEAD) on debian testing (with
   Emacs23 gnutls-cli is run in a subprocess), says:
   "Opening connection to imap.mydomain.com via tls...
    Opening TLS connection to `imap.mydomain.com'...
    Opening TLS connection with `gnutls-cli --insecure -p 993 imap.mydomain.com'...done
   Opening TLS connection to `imap.mydomain.com'...done
   Unable to open server nnimap+privat due to: Process *nnimap* not running"
 - Opera 12.15 (to see if this was Gnus related only) on Windows 7 just reports:
   "The connection with the IMAP server was unexpectedly interrupted."

When I try running gnutls-cli from the command line of the debian
testing machine (the same gnutls-cli that is used by the emacs23/gnus
combo), it seems to connect ok (the transcript of that session is
below).

The config for the SSL, from /etc/dovecot/conf.d/10-ssl.conf, is:

# SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>
ssl = yes

# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/mkcert.sh can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
ssl_cert = </etc/ssl/certs/imap_mydomain_com.pem
ssl_key = </etc/ssl/private/imap_mydomain_com.key


The access privileges of the files, are:
-rw-r--r-- 1 root root 2077 Mar 27 12:45 /etc/ssl/certs/imap_mydomain_com.pem
-rw------- 1 root root 3243 Jul 12  2011 /etc/ssl/private/imap_mydomain_com.key


What follows, is the transcript from the gnutls-cli session from a
debian testing machine to the server (which seems to be working as far
as I can tell...):

sb@edwards:~$ gnutls-cli -p 993 rainey.mydomain.com
WARNING: gnome-keyring:: couldn't connect to: /home/sb/.cache/keyring-yeEdM3/pkcs11: No such file or directory
Resolving 'rainey.mydomain.com'...
Connecting to '212.110.185.190:993'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1023 bits
 - Peer's public key: 1023 bits
- Certificate type: X.509
 - Got a certificate list of 1 certificates.
 - Certificate[0] info:
  - subject `CN=imap.mydomain.com', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support@cacert.org', RSA key 4096 bits, signed using RSA-SHA1, activated `2013-03-27 12:43:30 UTC', expires `2013-09-23 12:43:30 UTC', SHA-1 fingerprint `86f8a501bca1e2b0eadc677bf05b103d298ce247'
- The hostname in the certificate does NOT match 'rainey.mydomain.com'
sb@edwards:~$ gnutls-cli -p 993 imap.mydomain.com
WARNING: gnome-keyring:: couldn't connect to: /home/sb/.cache/keyring-yeEdM3/pkcs11: No such file or directory
Resolving 'imap.mydomain.com'...
Connecting to '212.110.185.190:993'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1022 bits
 - Peer's public key: 1021 bits
- Certificate type: X.509
 - Got a certificate list of 1 certificates.
 - Certificate[0] info:
  - subject `CN=imap.mydomain.com', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support@cacert.org', RSA key 4096 bits, signed using RSA-SHA1, activated `2013-03-27 12:43:30 UTC', expires `2013-09-23 12:43:30 UTC', SHA-1 fingerprint `86f8a501bca1e2b0eadc677bf05b103d298ce247'
- The hostname in the certificate matches 'imap.mydomain.com'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.2
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

* OK Waiting for authentication process to respond..
- Peer has closed the GnuTLS connection

Re: SSL problems on dovecot 2.1.7

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

Isn't it kinda strange that this, using the "--insecure" option, fails...

>  - Emacs23/Ma Gnus 0.8 (also Gnus git HEAD) on debian testing (with
>    Emacs23 gnutls-cli is run in a subprocess), says:
>    "Opening connection to imap.mydomain.com via tls...
>     Opening TLS connection to `imap.mydomain.com'...
>     Opening TLS connection with `gnutls-cli --insecure -p 993 imap.mydomain.com'...done

...while this (ie. without the "--insecure" option) doesn't...?

> sb@edwards:~$ gnutls-cli -p 993 rainey.mydomain.com
> WARNING: gnome-keyring:: couldn't connect to: /home/sb/.cache/keyring-yeEdM3/pkcs11: No such file or directory
[snip!]
> - Compression: NULL
> - Handshake was completed

> - Simple Client Mode:

> * OK Waiting for authentication process to respond..
> - Peer has closed the GnuTLS connection

Re: SSL problems on dovecot 2.1.7

[Adam Sjøgren]

Steinar Bang <sb@dod.no> writes:

[...]

> - The hostname in the certificate does NOT match 'rainey.mydomain.com'

[...]

> - Peer's certificate issuer is unknown
> - Peer's certificate is NOT trusted

Shouldn't you fix those, according to your own logic?


  Best regards,

    Adam

-- 
 "Hur långt man än har kommit                                 Adam Sjøgren
  är det alltid längre kvar"                             asjo@koldfront.dk

Re: SSL problems on dovecot 2.1.7

[Steinar Bang]

>>>>> asjo@koldfront.dk (Adam Sjøgren):

>> - Peer's certificate issuer is unknown
>> - Peer's certificate is NOT trusted

> Shouldn't you fix those, according to your own logic?

Indeed I should.  And I will do so when I figure out how.

But I don't think they are the real issue, because this article has that
same output and things seem to be working:
 http://blog.josefsson.org/2009/04/16/cacert-and-gnutls/

Also, the "gnutls-cli" session I listed doesn't seem to stop when
encountering these snags, but continues down to the start of a cleartext
IMAP dialog.

From what (little) I know about CA-certifictes and signing, I don't
understand that I'm getting these messages...?  Because the client
machine here is a debian testing machine, and the cacert.org root
certificate is already in /etc/ssl/certs/ on this machine.

When I tried to point the win7/emacs24/ma gnus/gnutls.dll combo at the
cacert.org root certificate, by adjusting gnutls-trustfiles:
 (push "c:/ProgramFiles/emacs-24.3/etc/gnutls/cacert.org_root.crt" gnutls-trustfiles)
and then tried to open the imaps server with gnutls-log-level set to 5,
emacs 24 crashed on me.


When I try to open the imap server with gnutls-log-level set to 1, this
is what I get:
Opening connection to imap.mydomain.com via tls...
gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [1] (Emacs) setting the trustfile:  c:/ProgramFiles/emacs-24.3/etc/gnutls/cacert.org_root.crt
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL
gnutls.c: [1] (Emacs) setting the priority string
(and there it just stops...)


With gnutls-log-level set to 2, this is what I get (which doesn't
enlighten me any more):

Opening connection to imap.mydomain.com via tls...
gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [2] (Emacs) allocating x509 credentials
gnutls.c: [2] (Emacs) using default verification flags
gnutls.c: [1] (Emacs) setting the trustfile:  c:/ProgramFiles/emacs-24.3/etc/gnutls/cacert.org_root.crt
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL
gnutls.c: [1] (Emacs) setting the priority string
gnutls.c: [2] ASSERT: gnutls_constate.c:716

gnutls.c: [2] ASSERT: gnutls_buffers.c:955

gnutls.c: [2] ASSERT: gnutls_buffers.c:955

gnutls.c: [2] ASSERT: gnutls_buffers.c:955

gnutls.c: [2] ASSERT: signature.c:305

gnutls.c: [2] ASSERT: gnutls_buffers.c:955

gnutls.c: [2] ASSERT: gnutls_buffers.c:1037

gnutls.c: [2] ASSERT: gnutls_buffers.c:1146

gnutls.c: [2] ASSERT: session_ticket.c:684

gnutls.c: [2] ASSERT: gnutls_buffers.c:955

gnutls.c: [2] ASSERT: mpi.c:255

gnutls.c: [2] ASSERT: dn.c:1207

gnutls.c: [2] (Emacs) Deallocating x509 credentials
Quit


(Sigh!  I feel a headache coming on...)

Re: SSL problems on dovecot 2.1.7

[Bjørn Mork]

Steinar Bang <sb@dod.no> writes:

> From what (little) I know about CA-certifictes and signing, I don't
> understand that I'm getting these messages...?  Because the client
> machine here is a debian testing machine, and the cacert.org root
> certificate is already in /etc/ssl/certs/ on this machine.

FWIW, I see exactly the same on Debian wheezy unless I explicitly point
"gnutls-cli" to the CA certificates. Try using

  gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt etc...


I tested "openssl s_client" too, and it seems to have the same problem.
It will not use the pre-defined system CA certificates unless I point it
to them using

  openssl s_client -CApath /etc/ssl/certs etc...


I assume there is some reason behind this and that it's documented
somewhere. I'll just accept it.


Bjørn

Re: SSL problems on dovecot 2.1.7

[Steinar Bang]

Turns out this wasn't an SSL issue at all.  Or at least I think it
wasn't... it may come back to that.

One problem I had with debugging this, was that I've had no logging
since the upgrade.  Which eventually (as in: half an hour ago) led me to
suspect the syslogd... and it turned out that I didn't have one:

 rainey:~# dpkg -S /etc/syslog.conf 
 sysklogd: /etc/syslog.conf
 rainey:~# dpkg -l sysklogd
 Desired=Unknown/Install/Remove/Purge/Hold
 | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
 |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 ||/ Name                        Version            Architecture       Description
 +++-===========================-==================-==================-============================================================
 rc  sysklogd                    1.5-6              i386               System Logging Daemon

sysklogd exists for squeeze and sid, but not for wheezy and testing:
 http://packages.debian.org/squeeze/sysklogd

It turns out debian has changed its preferred syslogd from sysklogd to
rsyslog: http://wiki.debian.org/Rsyslog

An "apt-get install rsyslog" installed the new syslogd and then dovecot
started logging to /var/log/mail.log.

It turns out the reason I can't log in, is that I'm trying a cram-md5
login, which none of the configured password providers can provide:
 May  9 15:08:47 rainey dovecot: auth: Fatal: CRAM-MD5 mechanism can't be supported with given passdbs
 May  9 15:08:47 rainey dovecot: master: Error: service(auth): command startup failed, throttling for 60 secs

Oh well!

Re: SSL problems on dovecot 2.1.7

[James Cloos]

It is unexpected that, on a debian box, gnutls would claim that cacert
is an unknown issuer.

Debian has long included cacert in its default set of trusted certs.

Perhaps you need to run update-ca-certificates(8)?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6