Your message dated Mon, 12 Jul 2021 16:14:47 +0200
with message-id <5509987.G0MgPEPYWr@alpha8>
and subject line Re: Bug#989553: Acknowledgement (imapd: bullsey regression:
unable to get certificate CRL)
has caused the Debian Bug report #989553,
regarding imapd: bullsey regression: unable to get certificate CRL
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
989553: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989553
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: cyrus-imapd
Version: 3.2.6-2
Severity: normal
File: imapd
Dear Maintainer,
After upgrading to bullseye clients using tls cannot connect due to:
Jun 06 13:41:06 alpha1 cyrus/imapsr[2393]: inittls: Loading hard-coded DH
parameters
Jun 06 13:41:06 alpha1 cyrus/imapsr[2388]: verify error:num=3:unable to get
certificate CRL
Jun 06 13:41:06 alpha1 cyrus/imapsr[2388]: imaps TLS negotiation failed:
android3.centauri.home [10.21.2.203]
This happens with both, an empty crl.pem and one with a test
certificate:
root@alpha1:~# ls -l /etc/ssl
total 20
drwxr-xr-x 1 root root 10826 2021-01-24 17:54 certs
-rw-r--r-- 1 root root 0 2021-06-07 10:34 crl.pem
-rw-r--r-- 1 root root 593 2014-08-27 10:47 crl.pem.bak
-rw-r--r-- 1 root root 11943 2020-02-22 12:55 openssl.cnf
drwx--x--- 1 root ssl-cert 68 2020-12-28 16:16 private
-rw-r--r-- 1 root root 18 2018-04-01 18:14 README-crl
The relevant imapd.conf contains the following tls related stuff:
tls_server_cert: /etc/ldap/servercrt.pem
tls_server_key: /etc/ldap/serverkey.pem
tls_client_ca_file: /etc/ldap/cacert.pem
tls_session_timeout: 1440
tls_ciphers: TLSv1.2:+TLSv1:+HIGH:!aNULL:@STRENGTH
tls_versions: tls1_2 tls1_3
tls_require_cert: true
tls_crl_file: /etc/ssl/crl.pem
Commenting out the "tls_crl_file" statement lets clients connect again,
but this would disable certificate revocation.
Jun 07 15:16:29 alpha1 cyrus/imapsr[3112]: login: android3.centauri.home
[10.21.2.203] internet EXTERNAL+TLS User logged in
SESSIONID=<cyrus-1623071789-3112-1-1100243944884731647>
Jun 07 15:16:29 alpha1 cyrus/imapsr[3135]: inittls: Loading hard-coded DH
parameters
Jun 07 15:16:29 alpha1 cyrus/imapsr[3135]: starttls: TLSv1.3 with cipher
TLS_AES_128_GCM_SHA256 (128/128 bits new) authenticated as internet
Thanks Jürgen
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cyrus-imapd depends on:
ii cyrus-common 3.2.6-2
ii libc6 2.31-12
ii libcom-err2 1.46.2-1
ii libsasl2-2 2.1.27+dfsg-2.1
ii libssl1.1 1.1.1k-1
ii libwrap0 7.6.q-31
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages cyrus-imapd recommends:
ii rsync 3.2.3-4
cyrus-imapd suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
OK, it is not cyrus that causes the problem ...
The crl.pem was 7 years old and caused the problem. I don't fully understand
the thing, but may be that openssl becomes more and more picky with each new
version.
- does a crl depend on on the ca that created the revoked cert? As you see
the ca in my previous post was created for openvpn and openvpn comes with its
own easy-rsa. Openvpn likes to have a private ca for each vpn.
- did previous versions of openssl accept a crl without known ca? Obviously
the openvpn private ca was never registered in /etc/ssl/certs.
- probably I only tested the crl only with openvn. But at least it caused no
problems with cyrus until Bullseye.
- For cyrus we are using certs that are created for a self-signed ca that is
registered in /etc/ssl/certs.
I was able to create a crl that is accepted by openssl in the following way:
$ openssl ca -revoke Centauri/certs/centauri_revoked_cert.pem -config
centauri.cnf
$ openssl ca -gencrl -out crl.pem -config centauri.cnf
$ openssl verify -CRLfile crl.pem -crl_check Centauri/certs/cyrus-
internet_cert.pem
Centauri/certs/cyrus-internet_cert.pem: OK
$ openssl verify -CRLfile crl.pem -crl_check Centauri/certs/
centauri_revoked_cert.pem
C = DE, ST = Hessen, L = xxx, O = xxx, OU = REVOKE-TEST, CN =
alpha.centauri.home, emailAddress = xxx
error 23 at 0 depth lookup: certificate revoked
error Centauri/certs/centauri_revoked_cert.pem: verification failed
Thank you very much for the helpful discussion on github
Jürgen
--- End Message ---
