Let’s Encrypt DST Root CA X3, Centos 8 and Virtualmin

SYSTEM INFORMATION
OS type and version: CentOS Linux 8.4.2105
Webmin version: 1.973
Virtualmin version: 6.16
Related products version:

Postfix version 3.3.1
Postfix smtpd CA file /etc/pki/tls/certs/ca-bundle.crt
ca-certificates version 2021.2.50-80.0.el8_4

/etc/pki/tls/certs/ca-bundle.crt and this contains (after update to 2021.2.50-80.0.el8_4) the expired “DST Root CA X3” certificate, which expired on Sept 30, 2021.

The recent ca-certificates update for CentOS 7 has removed the problem certificate, but not for CentOS 8 - at least in my case.

Apart from using openssl to remove the expired certificate, is there an easy (e.g. yum update or config file edit) that can stop this certificate being served.

This problem only seems to affect Postfix. The TLS section of /etc/postfix/main.cf is below. It has worked perfectly until the DSt certificate expired.

Thanks in advance
Edit: As I was writing this, 145 new updates have been flagged, but none for ca-certificates.

/etc/postfix/main.cf

TLS CONFIGURATION

Basic Postfix TLS configuration by default with self-signed certificate

for inbound SMTP and also opportunistic TLS for outbound SMTP.

The full pathname of a file with the Postfix SMTP server RSA certificate

in PEM format. Intermediate certificates should be included in general,

the server certificate first, then the issuing CA(s) (bottom-up order).

smtpd_tls_cert_file = /etc/webmin/letsencrypt-cert.pem

The full pathname of a file with the Postfix SMTP server RSA private key

in PEM format. The private key must be accessible without a pass-phrase,

i.e. it must not be encrypted.

smtpd_tls_key_file = /etc/webmin/letsencrypt-key.pem

Announce STARTTLS support to remote SMTP clients, but do not require that

clients use TLS encryption (opportunistic TLS inbound).

smtpd_tls_security_level = may

Directory with PEM format Certification Authority certificates that the

Postfix SMTP client uses to verify a remote SMTP server certificate.

smtp_tls_CApath = /etc/pki/tls/certs

The full pathname of a file containing CA certificates of root CAs

trusted to sign either remote SMTP server certificates or intermediate CA

certificates.

smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt

Use TLS if this is supported by the remote SMTP server, otherwise use

plaintext (opportunistic TLS outbound).

smtp_tls_security_level = may
meta_directory = /etc/postfix
shlib_directory = /usr/lib64/postfix
virtual_alias_maps = hash:/etc/postfix/virtual
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
mailbox_size_limit = 0
allow_percent_hack = no
smtpd_tls_CAfile = /etc/webmin/letsencrypt-ca.pem
smtpd_relay_restrictions = ${{$compatibility_level} < {1} ? {} : {permit_mynetworks permit_sasl_authenticated defer_unauth_destination}}
smtpd_client_restrictions = permit_inet_interfaces permit_sasl_authenticated reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Delete the problem cert.

Unexpectedly, the problem has resolved itself.
I applied the waiting updates, although I could not see any Certificate or Postfix related, and due to a kernel update a reboot was required.
After the reboot, Postfix is working. Could it be that the ca-certificates update that I had manually applied a day earlier, required a reboot to be effective? I had restarted Postfix after the certificate update.

On the one hand it’s good that the problem has been resolved. On the other, it’s frustrating to not know exactly why, especially since I didn’t see any reports of problems with CentOS 8, unlike CentOS 7 which was widely reported.

For the record, the clients that reported the expired DST Root CA X3 certificate were iOS 14.8 and Outlook 2010.
And the expired DST Root CA X3 certificate is still in ca-bundle.crt, but no longer causing a problem

Only older systems will be affected.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.