Hi Zakaria

Thank you for your suggestion.

I don't think an out of date ca trust is the issue with me. I'm running Debian Bullseye (i.e. latest Debian release) and its fully up to date with all patches.

I will look into your suggestion though.

Laura

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, January 24th, 2022 at 21:29, Zakaria <hi@zakaria.website> wrote:

Hi Laura,

I dont know if it will work, but I came across similar issue with letsencrypt using recent openssl, and it fails verifying with the same error message and the following has resolved it for me.

Try to run the following command against the client certificate full chain and cert file:-

openssl verify -CAfile fullchain1.pem cert1.pem

if it did throw the same error then try verifying using the following updated full chain with valid lets encrypt intermediary and root certificate, if it will work.

wget -O isrgrootx1.pem https://letsencrypt.org/certs/isrgrootx1.pem && wget -O isrg-root-x1-cross-signed.pem https://letsencrypt.org/certs/isrg-root-x1-cross-signed.pem && wget -O lets-encrypt-r3.pem https://letsencrypt.org/certs/lets-encrypt-r3.pem && wget -O lets-encrypt-r3-cross-signed.pem https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem && cat isrgrootx1.pem isrg-root-x1-cross-signed.pem lets-encrypt-r3.pem lets-encrypt-r3-cross-signed.pem > combined_chain1.pem && dos2unix combined_chain1.pem && rm -f lets-encrypt-r3*.* && rm -f isrg*.*

If didnt then try to use updated ca bundle directly from OS using following commands and reference it in verify certificates list

ssl_client_ca_file = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
ssl_verify_client_cert = yes

On how to update, it depends on your OS, and the following works with me

yum install ca-certificatesupdate-ca-trust

Refer to https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/

Give it a try and if you found another solution please let me know, and good luck.

Zakaria

On 24 Jan 2022 20:25, Laura Smith <n5d9xq3ti233xiyif2vp@protonmail.ch> wrote:

...

I'm having a frustrating problem trying to use "doveadm sync" to pull mails off a server for migration purposes.

# 2.3.17.1 (476cd46418): /etc/dovecot/dovecot.conf

# Pigeonhole version 0.5.17.1 (a1a0b892)

# OS: Linux 5.10.0-11-amd64 x86_64 Debian 11.2

I have tried both explicit "ssl_client_ca_dir = /etc/ssl/certs" and commenting it out (i.e. relying on OpenSSL default per the docs)

I always get the same:

Info: Received invalid SSL certificate: unable to get issuer certificate: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 (check ssl_client_ca_* se

ttings?)

Received invalid SSL certificate: unable to get issuer certificate: /C=US/O=Internet Sec

urity Research Group/CN=ISRG Root X1 (check ssl_client_ca_* settings?) - disconnecting

openssl s_client -starttls imap -servername $name -connect $name:143 is happy though:

---

Certificate chain

0 s:CN = <REDACTED>

   i:C = US, O = Let's Encrypt, CN = R3

1 s:C = US, O = Let's Encrypt, CN = R3

   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1

   i:O = Digital Signature Trust Co., CN = DST Root CA X3

---

---

No client certificate CA names sent

Peer signing digest: SHA256

Peer signature type: RSA-PSS

Server Temp Key: X25519, 253 bits

---

SSL handshake has read 4954 bytes and written 412 bytes

Verification: OK

---

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Server public key is 2048 bit

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

Early data was not sent

Verify return code: 0 (ok)

---

just an idea, but maybe that's the problem?:

https://doc.dovecot.org/configuration_manual/authentication/proxies/

"Note

ssl_client_ca_dir or ssl_client_ca_file aren’t currently used for verifying the

remote certificate, although ideally they will be in a future Dovecot version. For

now you need to add the trusted remote certificates to ssl_ca."

Hi Markus

Thanks for your suggestion, I have a couple of questions about it though.

First, my understanding from the docs was that ssl_client_ca_* were override parameters and that in the absence of the parameters, Dovecot would default to using OpenSSL defaults ? (And building on that, as per my manual tests, you can see OpenSSL returns an "OK" on the validation).

Second, I'm dealing with standard Let's Encrypt certs here, no private PKI certs here.

Laura

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

I thought that

ssl_ca = </etc/ssl/certs/ca-certificates.crt

is worth a try.

Does ssl_ca even apply to dsync/imapc ?

Looking at the docs its all about client certificate authentication ? Something which does not apply to my environment, and even if it did, it would not apply to dsync/imapc because I am initiating the connection, not the remote end ?

On 26/01/2022 11:19 Markus Winkler <ml@irmawi.de> wrote:

Hi Laura,

On Wed, 26 Jan 2022 at 12:09:04AM +0000, Laura Smith wrote:

...

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

...

I thought that

ssl_ca = </etc/ssl/certs/ca-certificates.crt

is worth a try.

Does ssl_ca even apply to dsync/imapc ?

as I wrote: I cannot test your scenario and the link to the documentation I sent was only a rough idea.

...

Looking at the docs its all about client certificate authentication ? Something which does not apply to my environment, and even if it did, it would not apply to dsync/imapc because I am initiating the connection, not the remote end ?

In my understanding this parameter is not only about client certificate authentication. If you want, then please have a look at this:

https://doc.dovecot.org/settings/core/#core_setting-ssl_ca

[...] These CAs are also used by some processes for validating outgoing SSL connections, i.e. performing the same function as ssl_client_ca_file. [...]

And that's why I wrote: it's worth a try (it takes only two minutes to test it ...). IMHO of course. If you don't want to test it, OK. But I have no further ideas, sorry.

Regards, Markus

Hi Laura, did you try this? Did it work?

Aki

For the benefit of list, I've decided to work-around the problem using:

imapc_ssl_verify = no

Obviously I still welcome suggestions as to how I can get dsync working with Let's Encrypt certificates and when OpenSSL validates "ok" but Dovecot does not (despite Dovecot supposedly falling-back to OpenSSL).

For the record, I have done this sort of dsync before (i.e. "dsync backup" from source that has Let's Encrypt cert), I've never had a problem before, so I'm wondering if it's something peculiar to Dovecot 2.3.17.1 (whether a bug or a feature, it would be nice to know what's changed since I would have thought this sort of scenario should work "out of the box").