Re: Received invalid SSL certificate: unable to get certificate CRL
--- Original Message --- On Monday, January 31st, 2022 at 06:24, Aki Tuomi 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".
Re: Received invalid SSL certificate: unable to get certificate CRL
> On 26/01/2022 11:19 Markus Winkler wrote: > > > Hi Laura, > > On Wed, 26 Jan 2022 at 12:09:04AM +, Laura Smith wrote: > >‐‐‐ Original Message ‐‐‐ > >> > >> I thought that > >> > >> ssl_ca = >> > >> 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
Re: Received invalid SSL certificate: unable to get certificate CRL
Hi Laura, On Wed, 26 Jan 2022 at 12:09:04AM +, Laura Smith wrote: ‐‐‐ Original Message ‐‐‐ I thought that ssl_ca = 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
Re: Received invalid SSL certificate: unable to get certificate CRL
‐‐‐ Original Message ‐‐‐ > > I thought that > > ssl_ca = > 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 ?
Re: Received invalid SSL certificate: unable to get certificate CRL
Hi Laura, On 25.01.22 11:48, Laura Smith wrote: 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). 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 = 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
Re: Received invalid SSL certificate: unable to get certificate CRL
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").
Re: Received invalid SSL certificate: unable to get certificate CRL
> 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
Re: Received invalid SSL certificate: unable to get certificate CRL
Hi Laura, On Mon, 24 Jan 2022 at 08:25:12PM +, Laura Smith 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?) 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
Re: Received invalid SSL certificate: unable to get certificate CRL
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 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 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 = > > > > 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) > > > > ---
