Archive the advertise-valid-ipps-certificate change

Moves the completed change to
openspec/changes/archive/2026-10-18-advertise-valid-ipps-certificate/ and syncs
the printserver/cups capability into openspec/specs/: the image dependency
requirement now mentions the TLS tooling, and two requirements are added for the
name-valid _ipps certificate and for starting cleanly on stale runtime state.

openspec/specs/printserver/cups/spec.md

@@ -9,9 +9,10 @@ driver.
 ## Requirements
 
 ### Requirement: Container image builds with required dependencies
-The container SHALL include CUPS, cups-filters, Avahi/mDNS, D-Bus and the
-conversion tools needed to turn client documents into PostScript, and SHALL NOT
-require any 32-bit runtime libraries.
+The container SHALL include CUPS, cups-filters, Avahi/mDNS, D-Bus, the
+conversion tools needed to turn client documents into PostScript and the TLS
+tooling needed for the secure AirPrint service, and SHALL NOT require any 32-bit
+runtime libraries.
 
 #### Scenario: Image contains CUPS
 - **WHEN** the image is built
@@ -21,6 +22,10 @@ require any 32-bit runtime libraries.
 - **WHEN** the image is built
 - **THEN** the image contains no i386 multiarch libraries and no Brother vendor binaries
 
+#### Scenario: TLS tooling is available
+- **WHEN** the image is built
+- **THEN** `openssl` is installed so the entrypoint can generate the certificate for the secure AirPrint service
+
 ### Requirement: Brother BR-Script3 PPD is installed
 The container SHALL install Brother's official HL-4150CDN BR-Script3 PPD from
 the committed asset so CUPS can emit device options as PostScript.
@@ -73,6 +78,40 @@ The system SHALL share the queue over IPP and advertise it via AirPrint
 - **WHEN** Avahi runs alongside CUPS
 - **THEN** the printer is advertised via AirPrint with URF, sides and colour capabilities so macOS and iOS/iPadOS clients can discover it without a driver
 
+### Requirement: Secure AirPrint certificate matches the advertised name
+The container SHALL serve the secure `_ipps` (TLS) service with a certificate
+whose subject alternative names cover the names clients use to reach it, so
+clients that validate the name complete the secure connection instead of falling
+back to a generic driver.
+
+#### Scenario: Certificate is created on first start
+- **WHEN** the container starts and no certificate is present in the certificate directory
+- **THEN** a self-signed certificate and key are generated whose subject alternative names cover the container host name, its `<host name>.local` form, the name Avahi advertises, `localhost`, `localhost.localdomain`, `host.containers.internal` and `127.0.0.1`
+
+#### Scenario: Additional names are accepted
+- **WHEN** the container is started with `CERT_EXTRA_NAMES` set to a comma-separated list of DNS names and/or IP addresses
+- **THEN** every listed name is included as a subject alternative name of the generated certificate
+
+#### Scenario: Validity is configurable
+- **WHEN** the container is started with `CERT_DAYS`
+- **THEN** the generated certificate is valid for that number of days
+
+#### Scenario: An existing certificate is reused
+- **WHEN** the container starts and the existing certificate already covers every required name
+- **THEN** it is kept instead of reissued, so clients that trusted it do not have to trust a new certificate
+
+#### Scenario: Missing names trigger reissue
+- **WHEN** the container starts and a required name — for example a newly added `CERT_EXTRA_NAMES` entry — is not covered by the existing certificate
+- **THEN** a certificate covering it is generated
+
+#### Scenario: CUPS presents the certificate
+- **WHEN** a client connects over `_ipps` to the name Avahi advertises
+- **THEN** the certificate CUPS presents contains that name in its subject alternative names
+
+#### Scenario: A validating client must trust the certificate
+- **WHEN** a client validates the certificate chain
+- **THEN** the connection is rejected until the self-signed certificate is trusted on the client, while the plain `_ipp` service keeps working
+
 ### Requirement: Supported client platforms
 The shared printer SHALL be usable from macOS, iOS/iPadOS, Linux and Windows.
 
@@ -99,6 +138,18 @@ The container SHALL expose CUPS on port 631 and mDNS on UDP port 5353.
 - **WHEN** the container runs
 - **THEN** UDP port 5353 is available for AirPrint discovery
 
+### Requirement: Startup recovers from stale runtime state
+The container SHALL start successfully after a restart even though the previous
+run left runtime state behind, without requiring a new container or volume.
+
+#### Scenario: Restart with leftover runtime state
+- **WHEN** the container is restarted and the runtime directory still holds the previous run's D-Bus and Avahi sockets and PID files
+- **THEN** D-Bus and Avahi start again, CUPS serves the queue and AirPrint discovery works
+
+#### Scenario: Avahi cannot start
+- **WHEN** the Avahi daemon fails to start
+- **THEN** the entrypoint logs a warning and keeps serving IPP rather than exiting
+
 ### Requirement: Printer endpoint and advertised name are configurable at runtime
 The container SHALL accept the network printer address and the advertised printer name through environment variables so the same image can target a different printer or name without rebuilding.