Certificate Monitor: Distinguished name error with Let's Encrypt IP Address Cert

I am getting an error message "Distinguished name 2.5.4.3 not found" when I check my VPS IP address.

I am using a 6-day IP Address certificate from Let's Encrypt. It currently has 4 days left.

Ref: https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability

Thanks for the report - and for including the Let's Encrypt link, it pointed us straight at the cause.

Let's Encrypt's new short-lived IP-address certificates don't include a Common Name (CN) in the subject. Where an ordinary certificate has something like CN=example.com, these leave the subject empty and place the IP address only in the Subject Alternative Name (SAN) field. Certificate Monitor was reading the CN unconditionally, so when it wasn't present the check failed with "Distinguished name 2.5.4.3 not found" (2.5.4.3 is the internal identifier for the CN field).

This is now fixed. Certificate Monitor handles a missing CN gracefully and, for IP-address certificates, shows the IP from the SAN as the identity instead. Everything else was already read correctly and is unaffected.

You can download the fixed build here.

Thanks again for catching this early! IP certificates are brand new and you're one of the first to run them through the app.

I tried the pre-release on Debian 13 Linux and Windows. I am still getting the same error for my VPS IP Address.

$ sha1sum certmonitor_linux_amd64.deb
2ddde27403be2e98843463e3228d28cf392e9b3a certmonitor_linux_amd64.deb

$ sha1sum /usr/bin/certmonitor
d84beca93df729de6c53ea0cbbe4ace212daabed /usr/bin/certmonitor

Windows x64 portable EXE sha1: 82d3ede74cd9d67e21b674d99eb580a36cd9278a


Suggestion:

Notifications: "Certificate expiring (1 day)" or a setting to manually specific the amount of minutes/hours for the 6 day certificates.

Thanks for testing. The pre-release you tried only fixed part of the problem the certificate check was still failing deeper inside the TLS handshake, which is why the same error came back.

The complete fix is in the new release, version 26.7. It no longer relies on the certificate's Common Name for IP-address hosts (Let's Encrypt IP certificates don't have one - the IP is carried only in the Subject Alternative Name), so bare-IP certificates are now read and monitored correctly. Please download the new release and re-test.

On your suggestion about the expiry notification for six-day certificates: 26.7 already handles this automatically. Instead of a fixed number of days or a manual minutes/hours value, the "expiring soon" warning now scales to each certificate's own lifetime - a 90-day certificate is still flagged in its final month, while a six-day certificate is only flagged in its last day or so, near its renewal point. There's nothing to configure, and a short-lived certificate no longer shows as expiring the moment it is issued.

Thanks for the report and the suggestion - both went straight into this release.

I can confirm the new release works. Thank you!

I just noticed Windows is using my local time while Debian is using UTC. I have no opinion on it but I figured I'd report it.
Certificate expiring date:
Windows: 9 Jul 2026 08:35
Debian: 9 Jul 2026 12:35

Windows:

> time
The current time is: 12:04:44.47

Debian:

$ timedatectl
Local time: Mon 2026-07-06 12:04:50 EDT
Universal time: Mon 2026-07-06 16:04:50 UTC
RTC time: Mon 2026-07-06 16:04:50
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Thanks for reporting this. It turned out to be a bug in the component we use for parsing certificates. On Windows it converted UTC timestamps to local time correctly, but on other platforms it left them in UTC.

This has now been fixed in the new build.