Server seemingly randomly chooses between multiple certificates for IPPS

When printing to a ghostscript-printer-app server via IPPS from CUPS, the server seems to use one of three common names for the certificate:

• The mDNS hostname (print.local)
• The DNS hostname (print.intra.my.domain)
• The IPv6 ULA (fd11:367d:c329:80:****:**ff:fe**:****)
  It seems to choose randomly between the three, even for jobs sent from the same client shortly after each other. /var/snap/ghostscript-printer-app/common/cups/ssl contains different certificates and keys for all three; even after deleting these, it still seems to choose one of the three hostnames at random and generates new certificates as they are used.

This means that only the first print job from each client will reliably work - on subsequent jobs, if a different certificate is sent, the client won't trust the certificate as it is different from the one sent with the first job.

I have worked around this by manually issuing a single certificate that is valid for all three hostnames and symlinking it to all three hostnames in /var/snap/ghostscript-printer-app/common/cups/ssl, but this surely isn't intended behaviour.

Reproduziere das Problem, indem du aufeinanderfolgende IPPS-Aufträge von CUPS sendest, und untersuche /var/snap/ghostscript-printer-app/common/cups/ssl, einschließlich der Zertifikate und Schlüssel für die drei gemeldeten Namen. Vergleiche, welches Zertifikat der Server bei jeder Verbindung präsentiert, und ermittle das beabsichtigte Verhalten bei der Zertifikatsauswahl. Erledigt ist die Aufgabe, wenn die Zertifikatsauswahl bei aufeinanderfolgenden Aufträgen nicht mehr unerwartet inkonsistent ist.