[Bug 2037869] [NEW] ssl-cert should (re)generate /etc/ssl/private/ssl-cert-snakeoil.key on first boot

[Steve Langasek]

Public bug reported:

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.)

This would then let us drop the code in casper as redundant and instead
keep the logic local to the responsible package.

** Affects: casper (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: ssl-cert (Ubuntu)
     Importance: High
         Status: Triaged

** Affects: casper (Ubuntu Mantic)
     Importance: Undecided
         Status: New

** Affects: ssl-cert (Ubuntu Mantic)
     Importance: High
         Status: Triaged


** Tags: foundations-todo

** Description changed:

  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.)
+ 
+ This would then let us drop the code in casper as redundant and instead
+ keep the logic local to the responsible package.

** Changed in: ssl-cert (Ubuntu)
   Importance: Undecided => High

** Changed in: ssl-cert (Ubuntu)
       Status: New => Triaged

** Changed in: ssl-cert (Ubuntu)
    Milestone: None => ubuntu-23.10

** Also affects: ssl-cert (Ubuntu Mantic)
   Importance: High
       Status: Triaged

** Tags added: foundations-todo

** Also affects: casper (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to casper in Ubuntu.
https://bugs.launchpad.net/bugs/2037869

Title:
  ssl-cert should (re)generate /etc/ssl/private/ssl-cert-snakeoil.key on
  first boot

Status in casper package in Ubuntu:
  New
Status in ssl-cert package in Ubuntu:
  Triaged
Status in casper source package in Mantic:
  New
Status in ssl-cert source package in Mantic:
  Triaged

Bug description:
  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.)

  This would then let us drop the code in casper as redundant and
  instead keep the logic local to the responsible package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2037869/+subscriptions