Public bug reported:
Ubuntu's default NTS servers are currently presenting an expired TLS
certificate, causing chrony to fail NTS-KE and eventually lose time
synchronization.
This has been reproduced from multiple independent Ubuntu systems.
Affected NTS endpoints:
1.ntp.ubuntu.com
2.ntp.ubuntu.com
3.ntp.ubuntu.com
4.ntp.ubuntu.com
The individual IPv4 addresses were tested directly:
185.125.190.122
185.125.190.123
91.189.91.112
91.189.91.113
All four endpoints currently present the same expired certificate:
subject=CN=ntp.ubuntu.com
issuer=C=US, O=Let's Encrypt, CN=R13
notBefore=May 27 16:36:33 2026 GMT
notAfter=Aug 25 16:36:32 2026 GMT
Current date of testing: August 26, 2026.
Example test:
for ip in \
185.125.190.122 \
185.125.190.123 \
91.189.91.112 \
91.189.91.113
do
echo "===== $ip ====="
timeout 5 openssl s_client \
-connect "$ip:4460" \
-servername ntp.ubuntu.com \
</dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates
done
Result for every endpoint:
subject=CN=ntp.ubuntu.com
issuer=C=US, O=Let's Encrypt, CN=R13
notBefore=May 27 16:36:33 2026 GMT
notAfter=Aug 25 16:36:32 2026 GMT
IMPACT
chrony reports failed TLS certificate verification for the Ubuntu NTS
servers, for example:
TLS handshake with 91.189.91.113:4460 (4.ntp.ubuntu.com) failed :
Error in the certificate verification. The certificate is NOT trusted.
The certificate chain uses expired certificate.
Eventually chrony reports no selectable sources and the time since last
successful synchronization continues to increase.
DEFAULT CONFIGURATION
The affected Ubuntu 26.04 system uses the Ubuntu-provided default chrony
NTS configuration:
pool 1.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 2.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 3.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 4.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool ntp-bootstrap.ubuntu.com iburst maxsources 1 nts certset 1
NETWORK CONNECTIVITY TEST
This does not appear to be caused by general NTP or network
connectivity.
Classic NTP over UDP/123 works successfully:
sudo chronyd -Q 'server pool.ntp.org iburst'
Result:
System clock wrong by -0.004478 seconds (ignored)
TCP/4460 is also reachable, as demonstrated by openssl successfully
connecting to the NTS endpoints and retrieving their TLS certificates.
MULTIPLE SYSTEMS
The expired certificate was independently reproduced from:
- an Ubuntu 26.04 Frigate server
- a separate Ubuntu 26.04 Checkmk monitoring server
- an Ubuntu ThinkPad
The same expired certificate is returned on all tested systems.
Interestingly, one system is currently still synchronized with an Ubuntu
NTS source, presumably using previously obtained NTS cookies, while another
system can no longer establish a usable NTS connection.
EXPECTED RESULT
Ubuntu's NTS servers should present a valid TLS certificate and chrony
should be able to perform NTS key establishment and continuously
synchronize time.
ACTUAL RESULT
The Ubuntu NTS endpoints present a TLS certificate that expired on
2026-08-25 16:36:32 GMT. New NTS TLS handshakes therefore fail certificate
verification and chrony can eventually lose all usable synchronization
sources.
** Affects: chrony (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2165169
Title:
Ubuntu NTS servers present expired TLS certificate, causing chrony
time synchronization to fail
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/2165169/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
