warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ

[Ante Karamatić]

Postfix package doesn't utilize update-ca-certificate's hooks mechanism. By simply copying certs from /etc/ssl/certs/ca-certificates.crt to /var/spool/postfix/etc/ssl/certs/ca-certificates.crt, this warning and potential security issues could be avoided.

Something like this would be a start:

$ cat /etc/ca-certificates/update.d/postfix
#!/bin/bash

if [ -e /var/spool/postfix/etc/ssl/certs/ca-certificates.crt ]; then
        echo "Updating postfix chrooted certs"
        cp /etc/ssl/certs/ca-certificates.crt /var/spool/postfix/etc/ssl/certs/ca-certificates.crt
        systemctl reload postfix
fi

[Paride Legovini (paride)]

Hi Ante and thanks for this bug report. According to what I see in the scripts the certs gets copied over: it happens via /lib/systemd/system/postfix@.service which has this
ExecStartPre directive:

ExecStartPre=/usr/lib/postfix/configure-instance.sh %i

and configure-instance.sh copies the certs in the chroot when postfix is (re)started. I tested this on Focal and it works as intended.

However I don't see any mechanism that reloads Postfix after update-ca-certificate is called, so it may make sense to add a reload hook in /etc/ca-certificates/update.d/.

Would this explain the issue you hit and that made you file this bug report, or do you think there's something going wrong and the certs do not get copied over? Do you agree a reload hook would be the correct fix here?

[Paride Legovini (paride)]

A reload is not enough to trigger a configure-instance.sh run, a full restart is needed.

[Simon Déziel (sdeziel)]

Thanks for the detailed analysis Paride and Ante. While a service restart is indeed required to refresh the chroot dir of the main/default instance, it feels a bit intrusive and could be avoided by directly calling "/usr/lib/postfix/configure-instance.sh" via a hook in /etc/ca-certificates/update.d/

configure-instance.sh will update the default instance's chroot when called without any parameter.

[Paride Legovini (paride)]

Fixing this properly is not straightforward.

* I'm -1 for calling configure-instance.sh when ca-certificates is updated as that script is not meant do be run while postfix is running. We can't be sure that changing the postfix environment without restarting it won't have unexpected consequences. We could check the script now, but we can't be sure of what it will do in the future.

* Even if configure-instance.sh is run, I think that at least a postfix reload is needed to make it pick up the new certificates.

* Postfix only Recommends: ca-certificates, so when implementing the fix we should take into account the fact that ca-certificates may not be installed. This shouldn't really add complexity but it's something to keep in mind.

* While a postfix restart should update the certificates in the chroot, I agree that doing it automatically on ca-certificates update is too invasive. (Moreover, while me and Simon found out that a restart works, the linked debbug mentions it does not, so this should be double-checked.)

* A solution would to fix this on the ca-certificates side, making ca-certificates detect running services possibly needing a restart and interactively asking to restart them. This is basically what e.g. glibc and pam do, and the debconf logic could be taken from there. This solution also has downsides: it's one more blocking debconf question, and added interaction logic between packages without a dpkg relation (at least not in the ca-certificates -> postfix direction). Ideally this change should land in Debian.

In the end I think this should be fixed on the Postfix side by adding a debconf question asking if postfix should be restarted on ca-certificates updates, and dropping a script in /etc/ca-certificates/update.d/ doing the restart if desired. This is also something I'd like to see land in Debian and not in an Ubuntu delta.

I'm sorry for the wall-of-text :-)

[Vincent Lefevre (vincent-vinc17-net)]

Any news?

Note that under Debian, even a reboot will not update the file. So I currently have:

-rw-r--r-- 1 195453 2021-10-19 01:46:43 /etc/ssl/certs/ca-certificates.crt
-rw-r--r-- 1 200061 2019-09-20 11:53:51 /var/spool/postfix/etc/ssl/certs/ca-certificates.crt

[Lucas Kanashiro (lucaskanashiro)]

This bug is in our backlog, we still did not have time to tackle it. Paride made a great analysis above, and I believe we should try to talk to the Debian maintainer to see if they agree with the proposed solution and land the fix there.

[Scott Kitterman (kitterman)]

I'm open to putting a fix in Debian. I haven't come up with a solution that I'm happy with and don't currently have a lot of time to work on this.

I think Paride Legovini's "wall-of-text" post is on the right track, but I would really prefer to avoid asking a question about this.

Anything in configure-instance.sh needs to be init system agnostic. I don't mind a systemd specific solution since that's our default init, but not in configure-instance.sh (no idea if there is one, but that's a boundary condition to a proper fix in my view).

If someone comes up with a patch, I can test it and will be glad to land it in Debian if suitable and functional.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Scott Kitterman (kitterman)]

So I looked into this a bit more and based on http://www.postfix.org/postconf.5.html#smtp_tls_CAfile is doesn't appear to me that the ca-certificates.crt file needs to be in the chroot at all. What happens if you just delete the chroot copy? Looking in the git history, I can see we used to install this file into the chroot, but I'm not sure we needed to.

[Scott Kitterman (kitterman)]

Not a ca-certificates issue.

[Scott Kitterman (kitterman)]

This is an unneeded leftover and the file in the chroot (/var/spool/postfix) can be deleted.

When using smtp*_tls_CAfile, the smtp or smtpd daemon copies from /etc/ssl/certs before entering the chroot (CApath is different), so it doesn't need to be there. We stopped copying the file into the chroot in 3.4.7-1, but didn't clean up the old one. I've committed a change to the Debian postfix git repository, which will be in the next Debian upload, to do this.

[Christian Ehrhardt  (paelzer)]

Thank you Scott!

As reference, that mentioned change is [1] and not yet part of a Debian upload to sync/merge.

[1]: https://salsa.debian.org/postfix-team/postfix-dev/-/commit/01fb7f1b307fb9bbc025d90dd404c9bff89f76ff

[Christian Ehrhardt  (paelzer)]

Thanks to Scott this is Fixed in version postfix/3.6.3-5

And since the package is in sync this is in Jammy now:
 postfix | 3.6.3-5ubuntu2 | jammy | source, amd64, arm64, armhf, ppc64el, riscv64, s390x