LetsEncrypt node certificate renews, but type is "Requested"

Support
, , ,
1

I had LE certs apparently expire, as mail quit syncing due to certificate error. Cluster-admin also had cert error opening the browser page. Loading the TLS cert page might have triggered a renewal, as all certs indicated a Jan 6, 2026 expiration, but while SOGo and NextCloud are type=automatic and status=Active (app enabled certs), the node cert is type=requested and status=active. Web UI now serves the updated cert, but mail continues to fail. I notice the following error message in system logs when the cert was “renewed”:

2025-10-09T10:35:46-05:00 [1:<mark>traefik</mark>1:<mark>traefik</mark>\] 2025-10-09T15:35:46Z ERR Error while creating certificate store error="unable to find certificate for domains \\"ns8.qzoneinc.com\\": falling back to the internal generated certificate" tlsStoreName=default

What is the problem? This cert has been auto-renewing for several cycles already, and has seemingly died of its own for now reason.

Thanks!

2

Does it help to save the mail app settings?

3

Just saved Mail app settings. How long until I would see a change in TLS Certificates?

4

I hoped that you’d see a change immediately. At least the mail cert should be valid again.

5

No change at all. Mail clients still pull expired cert. Active node cert still has “requested” type, but expiration is now Jan 7, 2026… verified in browser security. Going to restart the server.

6

This error message appears after Traefik restarts. In this case it is harmless and can be ignored.

If Traefik continues to serve the web site with a self signed certificate where a let’s encrypt one is expected, lookup the acmeCA= string in the Logs page: it is a key to select relevant Traefik log lines.

1 Like
7

Very well… But no, the cluster-admin web pages are secured by the expected LetsEncrypt certificate. The phone and computer mail apps are not getting the certificate and report an expired cert.

Now I notice, my laptop mail app says the cert was issued by R11, and expired Oct 7. The web cert is issued by R13. I’ve never noticed this before and can’t comment on significance?

8

If you go to Mail > Settings, under the General card, you’d find the server name used by Postfix and Dovecot. Ensure it is listed in the Requested certificate.

If not, use the Manage names action to re-add it.

9

Yes, mail host is ‘ns8.qzoneinc.com’ and node host is ‘ns8.qzoneinc.com’.

10

Any other name in the Requested certificate? Are they correctly configured in DNS?

11

No other names. Still valid DNS, all point to server IP. As I mentioned, two other LE certs have successfully renewed and work (SOGo and NextCloud), just the node cert in question (that happens to be associated with mail.

12

If the TLS certificates page lists only valid certs (included the one for Mail) and Mail still presents a different one, expired, that means it didn’t receive the cert update event.

Did you already reboot the node as said? Try to restart only Mail, from the software center page (it’s a 3.12 core feature).

13

Yes, rebooted the server hardware twice. Just restarted the mail instance, and no appearance of any changes.

14

Just tried to recreate the cert by adding an alternate name and requesting cert…Added ‘test.qzoneinc.com’

Fired up a fresh browser session and pointed to ns8-ui , Chrome happily accepted the new cert (which includes the alternate name. However, mail clients (Mac and iPhone) still report the original expired cert. Maybe this is just a Mac thing after the Mail app update? I’m so confused.

[edit] - Not a Mac thing, Android and Windows clients fail to sync, as well. I think we are down to NS Mail instance not receiving the cert, and don’t know why the node cert shows as type=requested instead of automatic.

15

Try to search in the System logs page.

  • select app mail1, or similar
  • select date from October 7 to now
  • type get-certificate in the search query field

Hopefully the log can give some clue.

The label may sound strange, but Mail just adds its name to the certificate with type Requested. This allows to specify alternative names like imap.example.org.

1 Like
16

Maybe that’s the issue? The host FQDN shouldn’t be the same name as the mail server FQDN.

EDIT:

Only relevant for webapps.

17

In a galaxy far far away, I was told by Obi Wan @stephdl to make sure that FQDN’s are very specific to a task.

2 Likes
18 
2025-10-08T11:52:06-05:00 [1:mail1:agent@mail1]

get-certificate --cert-file=tls-certs/server.pem --key-file=tls-certs/server.key ns8.qzoneinc.com 2025-10-08T12:41:03-05:00 [1:mail1:agent@mail1] ./systemd/user/get-certificate.service 2025-10-08T12:41:06-05:00 [1:mail1:get-certificate] Error retrieving certificate: too many values to unpack (expected 2) 2025-10-08T21:09:41-05:00 [1:mail1:agent@mail1] get-certificate --cert-file=tls-certs/server.pem --key-file=tls-certs/server.key ns8.qzoneinc.com 2025-10-08T21:17:48-05:00 [1:mail1:agent@mail1] get-certificate --cert-file=tls-certs/server.pem --key-file=tls-certs/server.key ns8.qzoneinc.com 2025-10-08T21:29:52-05:00 [1:mail1:agent@mail1] get-certificate --cert-file=tls-certs/server.pem --key-file=tls-certs/server.key ns8.qzoneinc.com 2025-10-09T09:45:33-05:00 [1:mail1:agent@mail1] get-certificate --cert-file=tls-certs/server.pem --key-file=tls-certs/server.key ns8.qzoneinc.com 2025-10-09T10:35:50-05:00 [1:mail1:agent@mail1] get-certificate --cert-file=tls-certs/server.pem --key-file=tls-certs/server.key ns8.qzoneinc.com 2025-10-09T13:21:19-05:00 [1:mail1:get-certificate] Error retrieving certificate: too many values to unpack (expected 2) 2025-10-09T13:35:47-05:00 [1:mail1:agent@mail1] get-certificate --cert-file=tls-certs/server.pem --key-file=tls-certs/server.key ns8.qzoneinc.com

1 Like
19

No, that’s not relevant. Mail can use any host name, provided MX and other DNS records are correctly registered.

1 Like
20

There’s a recurring error that prevents Mail from obtaining the certificate copy. The context may provide more information.

In system logs page

  • Try to restrict the log search time window around that line, 1 minute is enough
  • remove the get-certificate filter
  • select cluster context
  • raise lines limit to 2000