Dovecot 2.3.0 TLS
All,
our dovecot installation provides a bundle of intermedia CA certificates using the ssl_ca option.
2.3.0 does not supply the bundle, resulting in various clients either complaining about an unverifiable server cert, or quietly not connecting. The log has
Jan 5 17:01:46 Bounce dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=XXX, lip=YYY, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown: SSL alert number 46, session=<uKK/kAlia+GCUyU5>
We fixed the issue by downgrading to 2.2.33.2.
Cheerio, hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 11.01.2018 12:18, Hauke Fath wrote:
All,
our dovecot installation provides a bundle of intermedia CA certificates using the ssl_ca option.
2.3.0 does not supply the bundle, resulting in various clients either complaining about an unverifiable server cert, or quietly not connecting. The log has
Jan 5 17:01:46 Bounce dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=XXX, lip=YYY, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown: SSL alert number 46, session=<uKK/kAlia+GCUyU5>
We fixed the issue by downgrading to 2.2.33.2.
Cheerio, hauke
Was the certificate path bundled in the server certificate?
Aki
On Thu, 11 Jan 2018 12:20:45 +0200, Aki Tuomi wrote:
Was the certificate path bundled in the server certificate?
No, as a separate file, provided from the local (intermediate) CA:
ssl_cert = </etc/openssl/certs/server.cert ssl_key = </etc/openssl/private/server.key ssl_ca = </etc/openssl/certs/ca-cert-chain.pem
Worked fine with 2.2.x, 2.3 gives
% openssl s_client -connect XXX:993 CONNECTED(00000006) depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische Universitaet Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische Universitaet Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet Darmstadt/OU=XXX/CN=XXX.tu-darmstadt.de i:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet Darmstadt/CN=TUD CA G01/emailAddress=tud-ca@hrz.tu-darmstadt.de
Server certificate -----BEGIN CERTIFICATE----- [...] %
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 11.01.2018 13:20, Hauke Fath wrote:
On Thu, 11 Jan 2018 12:20:45 +0200, Aki Tuomi wrote:
Was the certificate path bundled in the server certificate? No, as a separate file, provided from the local (intermediate) CA:
ssl_cert = </etc/openssl/certs/server.cert ssl_key = </etc/openssl/private/server.key ssl_ca = </etc/openssl/certs/ca-cert-chain.pem
Worked fine with 2.2.x, 2.3 gives
% openssl s_client -connect XXX:993 CONNECTED(00000006) depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische Universitaet Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische Universitaet Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet Darmstadt/OU=XXX/CN=XXX.tu-darmstadt.de i:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet Darmstadt/CN=TUD CA G01/emailAddress=tud-ca@hrz.tu-darmstadt.de
Server certificate -----BEGIN CERTIFICATE----- [...] %
Seems we might've made a unexpected change here when we revamped the ssl code. Can you try if it works if you concatenate the cert and cert-chain to single file? We'll start looking if this is misunderstanding or bug.
Aki
On Thu, 11 Jan 2018 13:22:07 +0200, Aki Tuomi wrote:
Can you try if it works if you concatenate the cert and cert-chain to single file? We'll start looking if this is misunderstanding or bug.
This is a production machine, so I would rather stick with the downgrade until you've looked into the issue. I went home late yesterday. ;)
Cheerio, Hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 11.01.2018 13:28, Hauke Fath wrote:
On Thu, 11 Jan 2018 13:22:07 +0200, Aki Tuomi wrote:
Can you try if it works if you concatenate the cert and cert-chain to single file? We'll start looking if this is misunderstanding or bug. This is a production machine, so I would rather stick with the downgrade until you've looked into the issue. I went home late yesterday. ;)
Cheerio, Hauke
Fine. You might want to invest into a test environment, by the way. It's far more safe to try out new major releases and stuff. =)
Aki
On Thu, 11 Jan 2018 13:29:02 +0200, Aki Tuomi wrote:
You might want to invest into a test environment, by the way. It's far more safe to try out new major releases and stuff. =)
Fair enough.
With SSL certs, this gets a bit involved, though. This is a small site with a few dozen users, so I have a bit of flexibility. And in the present case a test bed wouldn't have saved me: The first reports came in a week after roll-out, mainly from users of android clients. I don't know if the desktop clients cache the intermediate certs, or if they just don't care.
Cheerio, hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 11 January 2018 at 14:29, Aki Tuomi <aki.tuomi@dovecot.fi> wrote:
On 11.01.2018 13:28, Hauke Fath wrote:
On Thu, 11 Jan 2018 13:22:07 +0200, Aki Tuomi wrote:
Can you try if it works if you concatenate the cert and cert-chain to single file? We'll start looking if this is misunderstanding or bug. This is a production machine, so I would rather stick with the downgrade until you've looked into the issue. I went home late yesterday. ;)
Cheerio, Hauke
Fine. You might want to invest into a test environment, by the way. It's far more safe to try out new major releases and stuff. =)
Aki
...and I am still unable to successfully compile 2.3RC on FreeBSD 8.4 and 9.3 ....and my reports were ignored, so should I assume support for those has been dropped?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft."
Dear Odhiambo,
Am 22.01.2018 um 19:58 schrieb Odhiambo Washington:
...and I am still unable to successfully compile 2.3RC on FreeBSD 8.4 and 9.3 ....and my reports were ignored, so should I assume support for those has been dropped?
Support for FreeBSD 8.4 stopped August 1, 2015. Support for FreeBSD 9.3 stopped December 31, 2016
Please see here: https://www.freebsd.org/security/unsupported.html
You should really upgrade to current version 10.4 or 11.1.
Gruß Matthias
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook
On 22 January 2018 at 23:10, Matthias Fechner <idefix@fechner.net> wrote:
Dear Odhiambo,
Am 22.01.2018 um 19:58 schrieb Odhiambo Washington:
...and I am still unable to successfully compile 2.3RC on FreeBSD 8.4 and 9.3 ....and my reports were ignored, so should I assume support for those has been dropped?
Support for FreeBSD 8.4 stopped August 1, 2015. Support for FreeBSD 9.3 stopped December 31, 2016
Please see here: https://www.freebsd.org/security/unsupported.html
You should really upgrade to current version 10.4 or 11.1.
Gruß Matthias
Hello Matthias,
I am running the latest version of Dovecot on FreeBSD 8.4, 9.3 and 11. I am not really planning to upgrade now, unless I am told that Dovecot 2.3.x will not compile on them. In which case I can let them run the version they have and forget about 2.3. Until I hear such from Aki or Timo, I will wait :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft."
On 22.01.2018 22:14, Odhiambo Washington wrote:
On 22 January 2018 at 23:10, Matthias Fechner <idefix@fechner.net <mailto:idefix@fechner.net>> wrote:
Dear Odhiambo, Am 22.01.2018 um 19:58 schrieb Odhiambo Washington:...and I am still unable to successfully compile 2.3RC on FreeBSD 8.4 and 9.3 ....and my reports were ignored, so should I assume support for those has been dropped?Support for FreeBSD 8.4 stopped August 1, 2015. Support for FreeBSD 9.3 stopped December 31, 2016 Please see here: https://www.freebsd.org/security/unsupported.html <https://www.freebsd.org/security/unsupported.html> You should really upgrade to current version 10.4 or 11.1. Gruß MatthiasHello Matthias,
I am running the latest version of Dovecot on FreeBSD 8.4, 9.3 and 11. I am not really planning to upgrade now, unless I am told that Dovecot 2.3.x will not compile on them. In which case I can let them run the version they have and forget about 2.3. Until I hear such from Aki or Timo, I will wait :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft."
Have you tried compiling latest 2.3.0 instead of RC?
Aki
On 23 January 2018 at 10:35, Aki Tuomi <aki.tuomi@dovecot.fi> wrote:
On 22.01.2018 22:14, Odhiambo Washington wrote:
On 22 January 2018 at 23:10, Matthias Fechner <idefix@fechner.net> wrote:
Dear Odhiambo,
Am 22.01.2018 um 19:58 schrieb Odhiambo Washington:
...and I am still unable to successfully compile 2.3RC on FreeBSD 8.4 and 9.3 ....and my reports were ignored, so should I assume support for those has been dropped?
Support for FreeBSD 8.4 stopped August 1, 2015. Support for FreeBSD 9.3 stopped December 31, 2016
Please see here: https://www.freebsd.org/security/unsupported.html
You should really upgrade to current version 10.4 or 11.1.
Gruß Matthias
Hello Matthias,
I am running the latest version of Dovecot on FreeBSD 8.4, 9.3 and 11. I am not really planning to upgrade now, unless I am told that Dovecot 2.3.x will not compile on them. In which case I can let them run the version they have and forget about 2.3. Until I hear such from Aki or Timo, I will wait :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft."
Have you tried compiling latest 2.3.0 instead of RC?
Aki
Hello Aki,
I didn't even know that 2.3 was released. After the disappointment with the RC, I kinda got withdrawn. I have just tested the 2.3 release and it compiles successfully on all my servers.
Thank you.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft."
On 01/11/2018 12:22 PM, Aki Tuomi wrote:
On 11.01.2018 13:20, Hauke Fath wrote:
On Thu, 11 Jan 2018 12:20:45 +0200, Aki Tuomi wrote:
Was the certificate path bundled in the server certificate? No, as a separate file, provided from the local (intermediate) CA:
ssl_cert = </etc/openssl/certs/server.cert ssl_key = </etc/openssl/private/server.key ssl_ca = </etc/openssl/certs/ca-cert-chain.pem
Worked fine with 2.2.x, 2.3 gives
% openssl s_client -connect XXX:993 CONNECTED(00000006) depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische Universitaet Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische Universitaet Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de verify error:num=21:unable to verify the first certificate verify return:1
Certificate chain 0 s:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet Darmstadt/OU=XXX/CN=XXX.tu-darmstadt.de i:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet Darmstadt/CN=TUD CA G01/emailAddress=tud-ca@hrz.tu-darmstadt.de
Server certificate -----BEGIN CERTIFICATE----- [...] %
Seems we might've made a unexpected change here when we revamped the ssl code. Can you try if it works if you concatenate the cert and cert-chain to single file? We'll start looking if this is misunderstanding or bug.
Aki
Hello, let me confirm this issue. I have a setup similar to Hauke Fath. Doing the workaround suggested by Aki
cat /etc/openssl/certs/ca-cert-chain.pem >> /etc/openssl/certs/server.certand removing "ssl_ca" from the config file presents the correct CA-Chain. Whereas the original config presented my three time my own server cert as chain.
Since server certs tend to change more frequent than the CA chains I really want to keep them in separate files.
So this is really a show stopper for me.
CU, Olaf
-- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik
Dipl.-Geophys. Olaf Hopp
- Leitung IT-Dienste -
Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp@kit.edu atis.informatik.kit.edu
www.kit.edu
KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft
Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.
On Thursday 11 of January 2018, Aki Tuomi wrote:
Seems we might've made a unexpected change here when we revamped the ssl code.
Revamped, interesting, can it support milions certs now on single machine? (so are certs loaded by demand and not wasting memory)
Aki
-- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
On January 23, 2018 at 7:09 PM Arkadiusz Miśkiewicz <arekm@maven.pl> wrote:
On Thursday 11 of January 2018, Aki Tuomi wrote:
Seems we might've made a unexpected change here when we revamped the ssl code.
Revamped, interesting, can it support milions certs now on single machine? (so are certs loaded by demand and not wasting memory)
Aki
-- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
Unfortunately not. This time round it was about putting the ssl code mostly in one place, so that we use same code for all SSL connections.
Aki
On Tue, Jan 23, 2018 at 10:05 AM, Aki Tuomi <aki.tuomi@dovecot.fi> wrote:
On January 23, 2018 at 7:09 PM Arkadiusz Miśkiewicz <arekm@maven.pl> wrote:
On Thursday 11 of January 2018, Aki Tuomi wrote:
Seems we might've made a unexpected change here when we revamped the ssl code.
Revamped, interesting, can it support milions certs now on single machine? (so are certs loaded by demand and not wasting memory)
Aki
-- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
Unfortunately not. This time round it was about putting the ssl code mostly in one place, so that we use same code for all SSL connections.
Just to chime in, having some way of supporting SSL certs dynamically would be tremendously useful. Like splitting out the retrieval of certs/key to a socket, that would typically just be a built-in regular dovecot service ("go and get the certs that are configured in dovecot configs"), but could also be a custom unix listener that could return certs/keys. Dovecot would send in the local IP/port and/or SNI name (if there was one) to the socket and then use whatever comes back. A perl/python/etc script doing the unix listener could then grab the appropriate cert/key from wherever (and dovecot would presumably have a time-based cache for certs/keys). This is just wish-listing :)
Currently, I've got a million different domains on my dovecot boxes, so allowing them all to use per-domain SSL is a bit challenging. I've been searching for an SSL proxy that supports something like nginx/openresty's "ssl_certificate_by_lua_file" (and can communicate the remote IP to dovecot like haproxy does) to put in front of dovecot, to no avail. Having something like that built directly into dovecot would be a dream -- or that can at least farm that functionality out to a custom daemon).
On 11.01.2018 13:20, Hauke Fath wrote:
>/On Thu, 11 Jan 2018 12:20:45 +0200, Aki Tuomi wrote: />>/Was the certificate path bundled in the server certificate? />/No, as a separate file, provided from the local (intermediate) CA: />//>/ssl_cert = </etc/openssl/certs/server.cert />/ssl_key = </etc/openssl/private/server.key />/ssl_ca = </etc/openssl/certs/ca-cert-chain.pem />//>/Worked fine with 2.2.x, 2.3 gives />//>/% openssl s_client -connect XXX:993 />/CONNECTED(00000006) />/depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische
Universitaet />/Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de />/verify error:num=20:unable to get local issuer certificate />/verify return:1 />/depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische
Universitaet />/Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de />/verify error:num=21:unable to verify the first certificate />/verify return:1 />/--- />/Certificate chain />/0 s:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet />/Darmstadt/OU=XXX/CN=XXX.tu-darmstadt.de />/i:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet />/Darmstadt/CN=TUD CA G01/emailAddress=tud-ca at hrz.tu-darmstadt.de
<https://dovecot.org/mailman/listinfo/dovecot> />/--- />/Server certificate />/-----BEGIN CERTIFICATE----- />/[...] />/% />//
Seems we might've made a unexpected change here when we revamped the ssl
code. Can you try if it works if you concatenate the cert and cert-chain
to single file? We'll start looking if this is misunderstanding or bug.
AkiI have the CA cert concatenated with the actual cert (one file).
Code: # openssl s_client -showcerts -connect some.server.host:587 CONNECTED(00000003) depth=1 C = US, ST = State, L = Town, O = Company Name, OU = CERTIFICATION AUTHORITY, CN = CA Company Name, emailAddress = XXX@XXXX verify error:num=19:self signed certificate in certificate chain
Certificate chain 0 s:/C=US/ST=State/L=Town/O=Company Name/OU=IT Department/CN=some.server.host/emailAddress=XXX@XXXX i:/C=US/ST=State/L=Town/O=Company Name/OU=CERTIFICATION AUTHORITY/CN=CA Company Name/emailAddress=XXX@XXXX -----BEGIN CERTIFICATE----- MIIGUzCCBDsCCQC0iFO/81SS6DANBgkqhkiG9w0BAQ0FADCBsDELMAkGA1UEBhMC SEsxDjAMBgNVBAgMBUhLU0FSMRAwDgYDVQQHDAdDZW50cmFsMRYwFAYDVQQKDA1D b2xvc3NhbCBNaW5kMSAwHgYDVQQLDBdDRVJUSUZJQ0FUSU9OIEFVVEhPUklUWTEZ MBcGA1UEAwwQQ0EgQ29sb3NzYWwgTWluZDEqMCgGCSqGSIb3DQEJARYbcGV0ZXIu a2FobEBjb2xvc3NhbG1pbmQuY29tMB4XDTE5MDYyOTA1MzA0NloXDTI0MDYyOTA1 MzA0NlowgaUxCzAJBgNVBAYTAkhLMQ4wDAYDVQQIDAVIS1NBUjEQMA4GA1UEBwwH Q2VudHJhbDEWMBQGA1UECgwNQ29sb3NzYWwgTWluZDEWMBQGA1UECwwNSVQgRGVw ........... B9Kuzi4+x3+3W/Hpzup+cGu/Rm3BrZ9EQuLU0l8/51o5++VJ0eYjO8sXmnf/OD9g m4SHlaIv1I9iF6xDbFSqVDhoyXZfci+Fp9Yg8IfdnRPuyhm+A9n80IpOVptMkHgH 5WHuteE3p7ZWz0sCHXihbt6P03Sp8VrN8TzBkRVDaGMMEErXq17dbX6FAWzcwreA I9MyC457hKbNvkRuMWyYTuTWXXAA15sCyyLsG6LuOuH0nexW7NdwipKzNq6QAtqT Evt/+OmEhVrQFllEeW9KT2AKab8FA4/F4SHBl8J1JMeZ+jgJ9DWeRYgUUGzj82bu 7nI27hEgpmT3Oz2a5WGbHRl7ryTNcPkYx1UOo1/7dIN8dZDRxdK31ZcXhwfRs/bu YBt/NGRaiAv5+RsA+qytjmgLZyTWjyAeKSHsL+OU4R5IvrLOpl6O -----END CERTIFICATE----- 1 s:/C=US/ST=State/L=Town/O=Company Name/OU=CERTIFICATION AUTHORITY/CN=CA Company Name/emailAddress=XXX@XXXX i:/C=US/ST=State/L=Town/O=Company Name/OU=CERTIFICATION AUTHORITY/CN=CA Company Name/emailAddress=XXX@XXXX -----BEGIN CERTIFICATE----- MIIF3jCCA8YCCQDf2f6HjwgkqTANBgkqhkiG9w0BAQ0FADCBsDELMAkGA1UEBhMC SEsxDjAMBgNVBAgMBUhLU0FSMRAwDgYDVQQHDAdDZW50cmFsMRYwFAYDVQQKDA1D b2xvc3NhbCBNaW5kMSAwHgYDVQQLDBdDRVJUSUZJQ0FUSU9OIEFVVEhPUklUWTEZ MBcGA1UEAwwQQ0EgQ29sb3NzYWwgTWluZDEqMCgGCSqGSIb3DQEJARYbcGV0ZXIu a2FobEBjb2xvc3NhbG1pbmQuY29tMB4XDTE1MDYxNDA0MDA1OVoXDTI1MDYxMTA0 MDA1OVowgbAxCzAJBgNVBAYTAkhLMQ4wDAYDVQQIDAVIS1NBUjEQMA4GA1UEBwwH Q2VudHJhbDEWMBQGA1UECgwNQ29sb3NzYWwgTWluZDEgMB4GA1UECwwXQ0VSVElG ................ riwfRMSnfXTQWtv1pkV+vGk02tuZQSatY6v18Uw0EdeuwfrV8n4WBYXCbzDQoQsa Jipzub5H/5u8nIIUFPFeTeqnaRihjFJfFQkTH8lteVkq0ctRHVF4Il0OfigW4Q0j CJ/jcarQ5gQa8l1SOZIj1OqwEYaLeruc7U6gn+PEZPhxw0jPJBCjo3eBI4sIpWOe JpB0S1JHhzFLnyZTQmat0qDxbmWW/PqYj8TAGskBTh+OVdqvxXVbNVv9pUtVV/oy x8l7mOfPWYQlbhD+b7Rk2Qc+o6ohL5XXCm66vJoMbD86eaMegtcLrq7eG03I8EfO F8seAmJ4aQ89dlFvcbLwdhYoDq02BtcoCLkSQlRTng3pdMuITdSoTczbusmPlvI6 dOw+FBqbIL+bAGHdUrQJJgZ5MhbN6V+a/Ntkn7ByaYRPO0yAJ0DrytkGR6tCzNLs egZqM8EcD56riKdlGv2OSe2+ -----END CERTIFICATE-----
Server certificate subject=/C=US/ST=State/L=Town/O=Company Name/OU=IT Department/CN=some.server.host/emailAddress=XXX@XXXX issuer=/C=US/ST=State/L=Town/O=Company Name/OU=CERTIFICATION AUTHORITY/CN=CA Company Name/emailAddress=XXX@XXXX
No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: X25519, 253 bits
SSL handshake has read 4074 bytes and written 373 bytes Verification error: self signed certificate in certificate chain
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 5120 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: Session-ID-ctx: Resumption PSK: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1561802629 Timeout : 7200 (sec) Verify return code: 19 (self signed certificate in certificate chain) Extended master secret: no Max Early Data: 0
- OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot.
I confirm the same problem described by *Hauke Fath* on 11 Jan 2018. Mozilla Thunderbird connects fine but iOS Mail does not.
Dovecot log: 1561801584 imap-login: Info: Disconnected (no auth attempts in 1 secs): user=<>, rip=X.X.X.X, lip=X.X.X.X, TLS handshaking: Connection closed 1561801592 imap-login: Info: Disconnected (no auth attempts in 6 secs): user=<>, rip=X.X.X.X, lip=X.X.X.X, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46
Kind regards, Peter
Hi Aki and all,
Thanks for the feedback.
I have removed the home-made root CA and the home-made server cert signed by the root CA, replaced it with valid Let's Encrypt cert and all works well.
Whilst the home-made certs have always worked well (years) with Thunderbird clients and iOS 12.x, the new iOS 13.0 is now very picky about the cert parameters. The Let's Encrypt cert is a good solution, although I may eventually explore learning how to properly use OpenSSL to generate home-made root CA and server certificates. Can anyone point me to a good resource that has all the information for generating these certs?
Kind regards, Peter
On 11.01.2018 13:20, Hauke Fath wrote:
>/On Thu, 11 Jan 2018 12:20:45 +0200, Aki Tuomi wrote: />>/Was the certificate path bundled in the server certificate? />/No, as a separate file, provided from the local (intermediate) CA: />//>/ssl_cert = </etc/openssl/certs/server.cert />/ssl_key = </etc/openssl/private/server.key />/ssl_ca = </etc/openssl/certs/ca-cert-chain.pem />//>/Worked fine with 2.2.x, 2.3 gives />//>/% openssl s_client -connect XXX:993 />/CONNECTED(00000006) />/depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische
Universitaet />/Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de />/verify error:num=20:unable to get local issuer certificate />/verify return:1 />/depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische
Universitaet />/Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de />/verify error:num=21:unable to verify the first certificate />/verify return:1 />/--- />/Certificate chain />/0 s:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet />/Darmstadt/OU=XXX/CN=XXX.tu-darmstadt.de />/i:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet />/Darmstadt/CN=TUD CA G01/emailAddress=tud-ca at hrz.tu-darmstadt.de
<https://dovecot.org/mailman/listinfo/dovecot> />/--- />/Server certificate />/-----BEGIN CERTIFICATE----- />/[...] />/% />//
Seems we might've made a unexpected change here when we revamped the ssl
code. Can you try if it works if you concatenate the cert and cert-chain
to single file? We'll start looking if this is misunderstanding or bug.
AkiHi Aki,
I believe that Dovecot 2.3.6 sends only one certificate even though my Dovecot uses two concatenated certificates.
Thanks for looking into this.
Regards, Peter
On 2.7.2019 8.06, Peter via dovecot wrote:
On 11.01.2018 13:20, Hauke Fath wrote: >/On Thu, 11 Jan 2018 12:20:45 +0200, Aki Tuomi wrote: />>/Was the certificate path bundled in the server certificate? />/No, as a separate file, provided from the local (intermediate) CA: />//>/ssl_cert = </etc/openssl/certs/server.cert />/ssl_key = </etc/openssl/private/server.key />/ssl_ca = </etc/openssl/certs/ca-cert-chain.pem />//>/Worked fine with 2.2.x, 2.3 gives />//>/% openssl s_client -connect XXX:993 />/CONNECTED(00000006) />/depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische Universitaet />/Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de />/verify error:num=20:unable to get local issuer certificate />/verify return:1 />/depth=0 C = DE, ST = Hessen, L = Darmstadt, O = Technische Universitaet />/Darmstadt, OU = XXX, CN = XXX.tu-darmstadt.de />/verify error:num=21:unable to verify the first certificate />/verify return:1 />/--- />/Certificate chain />/0 s:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet />/Darmstadt/OU=XXX/CN=XXX.tu-darmstadt.de />/i:/C=DE/ST=Hessen/L=Darmstadt/O=Technische Universitaet />/Darmstadt/CN=TUD CA G01/emailAddress=tud-ca at hrz.tu-darmstadt.de <https://dovecot.org/mailman/listinfo/dovecot> />/--- />/Server certificate />/-----BEGIN CERTIFICATE----- />/[...] />/% />// Seems we might've made a unexpected change here when we revamped the ssl code. Can you try if it works if you concatenate the cert and cert-chain to single file? We'll start looking if this is misunderstanding or bug.
Aki
Hi Aki,
I believe that Dovecot 2.3.6 sends only one certificate even though my Dovecot uses two concatenated certificates.
Thanks for looking into this.
Regards, Peter
Hi!
Can you provide readable output of
openssl s_client -connect host:993
Aki
Hi Aki,
I failed to disclose that the described problem occurs on iOS 13.0 beta.
After trying again and again, it appears that a bug in iOS 13.0 beta is the likely culprit. I am reading on Reddit that there is some bug in iOS with certificate trust...
https://www.reddit.com/r/signal/comments/c2q6c6/anyone_using_signal_in_ios_1...
Kind regards, Peter Kahl
On 3 Jul 2019, at 02:55, Peter Kahl via dovecot <dovecot@dovecot.org> wrote:
I failed to disclose that the described problem occurs on iOS 13.0 beta.
After trying again and again, it appears that a bug in iOS 13.0 beta is the likely culprit. I am reading on Reddit that there is some bug in iOS with certificate trust...
I am accessing my dovecot mail via iOS 13 beta without issue. (noe on eta 3, but had no issues with beta 2 or 3. Well, no issues with MAIL that is).
I am running current doevcot.
I just opened the mail client on my phone:
imap(kremels@kreme.com)<12940><14ffIdeMDf9JDqGg>: ID sent: name=iPhone Mail, version=17A5522f, os=iOS, os-version=13.0 (17A5522f)
On 4.7.2019 12.14, @lbutlr via dovecot wrote:
On 3 Jul 2019, at 02:55, Peter Kahl via dovecot <dovecot@dovecot.org> wrote:
I failed to disclose that the described problem occurs on iOS 13.0 beta.
After trying again and again, it appears that a bug in iOS 13.0 beta is the likely culprit. I am reading on Reddit that there is some bug in iOS with certificate trust... I am accessing my dovecot mail via iOS 13 beta without issue. (noe on eta 3, but had no issues with beta 2 or 3. Well, no issues with MAIL that is).
I am running current doevcot.
I just opened the mail client on my phone:
imap(kremels@kreme.com)<12940><14ffIdeMDf9JDqGg>: ID sent: name=iPhone Mail, version=17A5522f, os=iOS, os-version=13.0 (17A5522f)
I think the problem manifests itself when using custom CA certificates.
Aki
participants (11)
-
＠lbutlr
-
Aki Tuomi
-
Aki Tuomi
-
Arkadiusz Miśkiewicz
-
Hauke Fath
-
Mark Moseley
-
Matthias Fechner
-
Odhiambo Washington
-
Olaf Hopp
-
Peter Kahl
-
peter.kahl＠eosec.com