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.

Reproduce the issue by sending successive IPPS jobs from CUPS and inspect /var/snap/ghostscript-printer-app/common/cups/ssl, including the certificates and keys for the three reported names. Compare which certificate the server presents on each connection and determine the intended certificate-selection behavior. Done means the certificate choice is no longer unexpectedly inconsistent across successive jobs.