Received invalid SSL certificate: unable to get certificate CRL
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)
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,
On Mon, 24 Jan 2022 at 08:25:12PM +0000, Laura Smith wrote:
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."
Regards, Markus
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
Hi Laura,
On 25.01.22 11:48, Laura Smith wrote:
To be honest: I dont have a setup like yours to test it. I just remembered a mail from Aki in which he mentioned this part of the documentation and so I thought that
ssl_ca = </etc/ssl/certs/ca-certificates.crt
is worth a try.
Second, I'm dealing with standard Let's Encrypt certs here, no private PKI certs here.
Yes, I know. And it seems, that all is fine with them.
Regards, Markus
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
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 ?
Hi Laura,
On Wed, 26 Jan 2022 at 12:09:04AM +0000, Laura Smith wrote:
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
------- Original Message -------
On Monday, January 31st, 2022 at 06:24, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
Markus
Hi Laura, did you try this? Did it work?
Aki
Hi Aki
Sorry, your mail got caught in spam.
Tried it, it didn't work. So I just ended up using "-o imapc_ssl_verify=no".
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").
participants (4)
-
Aki Tuomi
-
Laura Smith
-
Markus Winkler
-
Zakaria