dovecot - May 2018 - Dovecot send duplicated certificates when using ssl_alt_cert

Hello,

I'm running dovecot 2.3.1 (c5a5c0c82) and trying to experiment with using
both RSA and ECDSA certificates.

My configuration is as follow:

ssl_alt_cert = </path/to/my.rsa.key
ssl_alt_key = </path/to/my.rsa.key

ssl_cert = </path/to/my.ecdsa.pem
ssl_key = </path/to/my.ecdsa.key

Both certificates are let's encrypt certificate, so both are using the same
intermediate CA.

The certificate chain are:
 for rsa:
	- my certificate
	- Let's Encrypt Authority X3
	- DST Root CA X3

 for ecdsa:
 	- my certificate
	- Let's Encrypt Authority X3
	- DST Root CA X3

My problem is that when connecting, dovecot includes 2 copies of Let's
Encrypt Authority X3 in the certificate chain.

I think this is a bug. When building the chain, dovecot should ignore duplicated
certificates and when opening the connection, it should only send intermediates
related to the used certificate (either RSA or ECDSA).

(and as a side note, when using dovecot -n, dovecot hides the ssl_key (ssl_key =
# hidden, use -P to show it) but not the ssl_alt_key. This is probably a bug
too).

---------------
openssl s_client -showcerts -host imap.example.com -port 993 -servername
imap.example.com

CONNECTED(00000005)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=imap.example.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIHPDCCBiSgAwIBAgISA2e3bP2o1mpdOr9kTDm/R/zuMA0GCSqGSIb3DQEBCwUA
?
-----END CERTIFICATE-----
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
?
-----END CERTIFICATE-----
 2 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
?
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=imap.example.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 5140 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 591240C021A02B399CCB010F37AF7AD83227DC1770C606F73B3EEA3514AF07FB
    Session-ID-ctx: 
    Master-Key:
7D5A5BFC1B4B8EECF4F41DC084265AF6D32B82130F381B8DDF685B589D54D9BDEBFC20F1DD80E150CD56850C0D062E9E
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 3a 72 98 05 72 af 3d ed-26 a9 e7 2b 68 6b 0a 25  
:r..r.=.&..+hk.%
    ?

    Start Time: 1526482021
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

On 2018-05-16 (08:54 MDT), Jean-Daniel Dupas <jddupas at xooloo.com>
wrote:
> 
> My problem is that when connecting, dovecot includes 2 copies of Let's
Encrypt Authority X3 in the certificate chain.
I think Dovecot 2.2 also has this issue, if I remember previous posts
accurately. Recommendations to include the full chain in the cert didn't
seem to work.

-- 
Eyes the shady night has shut/Cannot see the record cut And silence
sounds no worse than cheers/After earth has stopped the ears.

On 17.05.2018 16:33, @lbutlr wrote:
> On 2018-05-16 (08:54 MDT), Jean-Daniel Dupas <jddupas at xooloo.com>
wrote:
>> My problem is that when connecting, dovecot includes 2 copies of
Let's Encrypt Authority X3 in the certificate chain.
> I think Dovecot 2.2 also has this issue, if I remember previous posts
accurately. Recommendations to include the full chain in the cert didn't
seem to work.
>
Hi!

This is a thing that gets fixed in 2.3.2, but it's also OpenSSL version
dependent, so if you are using older than 1.1.0, you'll get this issue,
due to how OpenSSL deals with the certs.

Aki