fix ipps certificate lookup
ci/woodpecker/push/build Pipeline was successful

This commit is contained in:
juergen committed 2026-10-19 20:39:02 +02:00
1 parent 548ae918ea
commit 50497780c7
7 files changed
+314 -15

No files matched your search

@@ -0,0 +1,41 @@
# Spec Delta
## MODIFIED Requirements
### 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: Certificate is served for the connecting address
- **WHEN** a client connects over `_ipps` to one of the host's addresses — for example its LAN address or an IPv6 address — rather than to the advertised name
- **THEN** CUPS presents the container's certificate, so the names in its subject alternative names (including the advertised name) still apply
#### 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