luci-app-acme: Wrong date of issued certs

[agevlakh]

Is there an existing issue for this?

• I have searched among all existing issues (including closed issues)

screenshots or captures

No response

Actual behaviour

When the certificate is issued, the certificate and its release date appear in the web interface. if the same certificate is reissued, the date remains the same as when it was first created. I checked the current date via openssl, the certificate has been updated.

Expected behaviour

there must be an up-to-date certificate date in the web interface.

Steps to reproduce

1 issue the certificate
2 check the date in the web interface
3 force the certificate to be updated the next day
4 the date in the web interface will not be updated

Additional Information

{
        "kernel": "6.6.119",
        "hostname": "bananapi",
        "system": "ARMv7 Processor rev 3 (v7l)",
        "model": "Bananapi BPI-R2",
        "board_name": "bananapi,bpi-r2",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.5",
                "revision": "r29087-d9c5716d1d",
                "target": "mediatek/mt7623",
                "description": "OpenWrt 24.10.5 r2
9087-d9c5716d1d",
                "builddate": "1766005702"
        }
}

What browsers do you see the problem on?

Firefox

Relevant log output

[systemcrash]

@stokito @tohojo

[stokito]

The list of certs is just a list of files /etc/ssl/acme/*.fullchain.crt

https://github.com/openwrt/luci/blob/master/applications/luci-app-acme/htdocs/luci-static/resources/view/acme/acme.js#L12

And then the date modification is printed to table
https://github.com/openwrt/luci/blob/master/applications/luci-app-acme/htdocs/luci-static/resources/view/acme/acme.js#L525

If the file is a symlink then its mtime may be not changed.

I don't have a router near and can't re-test. Please show the output of the ls -l /etc/ssl/acme/.

[agevlakh]

root@bananapi:~# ls -l /etc/ssl/acme/
lrwxrwxrwx    1 root     root            32 Jan  1  1970 temple.test.com.chain.crt -> /etc/acme/temple.test.com/ca.cer
lrwxrwxrwx    1 root     root            38 Jan  1  1970 temple.test.com.combined.crt -> /etc/acme/temple.test.com/combined.cer
lrwxrwxrwx    1 root     root            45 Jan  1  1970 temple.test.com.crt -> /etc/acme/temple.test.com/temple.test.com.cer
lrwxrwxrwx    1 root     root            39 Jan  1  1970 temple.test.com.fullchain.crt -> /etc/acme/temple.test.com/fullchain.cer
lrwxrwxrwx    1 root     root            45 Jan  1  1970 temple.test.com.key -> /etc/acme/temple.test.com/temple.test.com.key

root@bananapi:~# ls -l /etc/acme/temple.test.com/
-rw-r--r--    1 root     root          1802 Jan 13 22:13 ca.cer
-rw-------    1 root     root             3 Dec  3 02:32 temple.test.com..save
-rw-r--r--    1 root     root          1789 Jan 13 22:13 temple.test.com.cer
-rw-r--r--    1 root     root           857 Jan 13 22:13 temple.test.com.conf
-rw-r--r--    1 root     root          1001 Jan 13 22:13 temple.test.com.csr
-rw-r--r--    1 root     root           188 Jan 13 22:13 temple.test.com.csr.conf
-rw-------    1 root     root          1675 Nov 14 21:26 temple.test.com.key
-rw-------    1 root     root          5266 Jan 13 22:13 combined.cer
-rw-r--r--    1 root     root          3591 Jan 13 22:13 fullchain.cer

In web interface I have date 14.11.2025 . It is first date of issue.

This is a bit discouraging. I'd like to see the issue date of the current certificate, not the original issue date. Otherwise, what's the point of that date anyway?

[stokito]

I think it would be better to just remove the date. But let's see what other says.

[systemcrash]

There is no *.fullchain.cer. There is, however, a fullchain.cer. Perhaps that should be relaxed. But the render function does: let domain = cert.name.replace(/\.fullchain\.crt$/, ''); so the domain would be ``.

[agevlakh]

@stokito
Isn't there a function that uses openssl or gnuts to extract the actual certificate issue date? Maybe even the expiration date as well, so there's more useful information in the web interface...

[stokito]

Why would you need it?

[agevlakh]

Why needed wrong date cert on web-interface? Needed issue date logically or nothing

[stokito]

Calling the openssl to get cert date is possible but this is an additional feature and we should keep the Luci small and easier to maintain. For example, instead of the openssl there may be mbedtls or gnutls. So we better to just show a date of a file modification for simplicity or remove it to not confuse users.

A user may check the cert manually by opening a site. We may add a link to the domain to simplify the process. Even if the cert is expired it's anyway low chances that a user will check the Luci page. The LE had a notification email on expiration but they removed the feature https://community.letsencrypt.org/t/end-of-expiration-notifications/232505
There are some Certificate Transparency services (Facebook had, I used) so maybe they can be used to track when a cert was expired or issued.

The acme.sh itself has a notification system https://github.com/acmesh-official/acme.sh/wiki/notify
I think this is a great thing and we can add some UI to configure it.
In the same time... the ACME become too complicated. But maybe it's fine, things related to security better to be comprehensive.

[agevlakh]

I completely agree with you; we need to find a balance between ease of use and functionality; cluttered software is definitely not needed. But you must admit, an incorrect date can be misleading... Something needs to be done about that.

[systemcrash]

It's not a big step to parse a certificate for dates, but it's an assumption that tools like openssl would be available. So the file metadata is the best we have...