Auto-generated self-signed certificate does not regenerate after expiration

[schuster]

Describe the bug
I'm using the default cups-files.conf configuration, which as I understand it automatically generates self-signed certificates. This worked fine until the certificate expired last September, and as a result network printing (from a Mac client to my Linux server) mysteriously stopped working.

Today I finally did some research to discover that the expired certificate was the cause. Specifically I ran the following from /etc/cups/ssl:

[root@atlantis ssl]# openssl x509 -enddate -noout -in atlantis.crt 
notAfter=Sep 17 13:24:10 2025 GMT

I was able to work around the issue by removing the existing files from the ssl directory. The next time I printed, CUPS generated a new certificate.

To Reproduce
Steps to reproduce the behavior:

1. Set up a printer on a CUPS server and share the printer.
2. Set up the printer on a remote MacOS client.
3. Ensure that CUPS has a self-signed certificate (e.g. by printing a test page from the remote client).
4. Wait for the certificate to expire. (There may be a way to manually set the certificate as expired. I don't know enough about certificates to say).
5. Try printing from the MacOS client.

Expected behavior
The CUPS server notices the expired certificate, automatically generates a new one, and the print job in step 5 succeeds.

Actual behavior
The Mac is stuck trying to print indefinitely, apparently because it refuses to establish a connection with a server with an expired certificate, and the CUPS server is not regenerating the expired certificate.

System Information:

• Server OS and its version: Arch Linux 6.18.6-arch1-1
• Client OS and its version: MacOS Sonoma 14.8.3
• Application Firefox 147.0 (64-bit)
• CUPS version (server-side): 2.4.16-1

Additional context
The /etc/cups/ssl directory had drwx------ permissions, with owners root:cups. The cups server runs as root. As far as I can tell, all of those are the defaults under Arch Linux.

Even before my workaround, I was still able to print from my Android phone. I suspect that the Android/Linux CUPS client falls back to unencrypted printing by default, while MacOS refuses to print without encryption by default.

The printer uses a driver, which I can see in the error logs is deprecated. The driver appears to be /var/cache/cups/Brother_HL-L2300D_series.data based on the logs.

[michaelrsweet]

I suspect Android/Linux clients might not be checking the expiration date of the cert and still using encryption. Without knowing what version of CUPS is running on your Linux clients, it is impossible to say.

This will require some changes to the current OpenSSL and GNU TLS server-side setup code; scheduling a fix for CUPS 2.5, for now your workaround (delete the old cert) is the recommended workaround.

[schuster]

The Linux client is a Pixel 9 phone, running Android version 16, with security update from April 5, 2026.

[ValdikSS]

The certificates are generated for 10 years though, should be enough for most cases.

        Validity
            Not Before: Mar 31 09:38:15 2026 GMT
            Not After : Mar 28 09:38:15 2036 GMT

[michaelrsweet]

@ValdikSS Certainly the default (long) life of the self-signed certs has helped to minimize the impact of this bug, but I do want to fix this since servers often get used for more than 10 years, especially in the world of VMs/VPSs where the underlying hardware can be updated regularly without disrupting the server image.