Comment 0 for bug 2037869

casper has a script, 22sslcert, whose purpose is to regenerate the default snakeoil certificate on boot of a live system. This was done to fix bug #337723, which reported that the snakeoil SSL certificate (and private key!) was the same on all live systems booted from the same image.

The rationale given in the bug for wanting a different key on each system is not entirely correct; it claims the certificate is used for "browsing over https", which is not so. And the ssl-cert package is included in the live images for all desktop flavors because it's a dependency of cups-daemon, which is in desktop-common; but cups-daemon does not use this keypair, instead generating its own on demand (since 2017). However, there are other packages that are not part of the default desktop environment and may be installed by the user afterwards that reference this key (postfix is one), so we shouldn't have the same "private" key on all installed systems.

The casper script fixed this for the live environment, and ubiquity also includes code to wipe it from the target system. But subiquity-based installs don't do this - because they populate the target system from the read-only squashfs, not from the live environment - and I think OEM installs also fail to do this because the ubiquity code in question isn't part of oem-config, so the "private" key may be unique to the preinstalled system but will also definitely have been exposed to the OEM in the factory.

An option for implementing this consistently might be to have the ssl-cert package ship a systemd unit with ConditionFirstBoot=yes. This will be a no-op when installing the package on a system that has already been installed, but would allow both live environments and newly-installed systems to regenerate the snakeoil key when /etc/machine-id is not yet initialized. (To be determined if this satisfies the OEM install case, where /etc/machine-id might be populated before the end-user takes ownership.)