TrueNAS Connect: TLS certificate for account-service.tys1.truenasconnect.net expired 2026-07-24 — all handle_update_ips calls failing server-side

TrueNAS Connect
1

Summary

The TLS certificate presented by account-service.tys1.truenasconnect.net:443expired on 24 Jul 2026 23:59:59 UTC and has not been renewed. Any enrolled system that calls that endpoint now fails TLS verification. On my system this breaks TrueNAS Connect’s interface-IP sync and generates a continuous error/retry loop in middlewared.

This is a server-side certificate expiry at iX, not a client misconfiguration. I’ve included the evidence that rules out local causes so we can skip that round-trip.

Environment

  • TrueNAS SCALE 25.10.5

  • Enrolled in TrueNAS Connect and previously working

  • Timezone America/New_York; NTP in sync

  • Detected via remote syslog forwarding to a central log server (VictoriaLogs), which is why the error was visible at all — see “Why this went unnoticed” below

Reproduction

On any TNC-enrolled system, run:

openssl s_client -connect account-service.tys1.truenasconnect.net:443 \
  -servername account-service.tys1.truenasconnect.net </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

Then check /var/log/truenas_connect.log for CERTIFICATE_VERIFY_FAILED.

Requested actions

  1. Renew the certificate on account-service.tys1.truenasconnect.net (and please check sibling hosts in the *.tys1.truenasconnect.net zone, which may share the same issuance schedule).

  2. Add expiry monitoring/automated renewal for TNC service endpoints. A 90-day DV certificate reaching notAfter unrenewed suggests the renewal isn’t automated or its alerting didn’t fire.

  3. Surface the failure in the client UI (feature request). The TrueNAS Connect status indicator continued to report the system as connected while every sync attempt failed. A repeated CallError from TNC should raise a UI alert, not only a log line. Right now the only way to notice is to read /var/log/truenas_connect.log or forward syslog off-box.

  4. Consider retry backoff. Retrying every ~5 minutes with a full Python traceback per attempt produces significant log volume for a condition that cannot resolve client-side.

Why this went unnoticed for 18 hours**

Worth noting as context for request.: the certificate lapsed at 00:00 UTC and the evidence sat in /var/log/truenas_connect.log the entire time with no alert, no UI indication, and no email. It was only found because this system had just been onboarded to a central syslog collector, where a severity-based query surfaced it immediately. Any user without off-box log aggregation would still not know.

Cannot login truenas connect since yesterday
Friendly name / Custom domain for Webshare
2

Looks like this has been resolved today with another 90 day cert.

truenas ~ % openssl s_client -connect ``account-service.tys1.truenasconnect.net:443``
-servername ``account-service.tys1.truenasconnect.net`` </dev/null 2>/dev/null
| openssl x509 -noout -dates
notBefore=Jul 27 11:35:42 2026 GMT
notAfter=Oct 25 11:35:41 2026 GMT