RUTX50: Certificates have expired Immediate action required to avoid service disruptions

[mesrik]

Hello,

First post here and I’m sorry if I didn’t get something right.

OK, about the issue. After upgrading about a year and half old RUTX50 from RUTX_R_00.07.16.6 to RUTX_R_00.07.17.5 there’s a top of screen, just below menu bar message “Certificates have expired Immediate action required to avoid service disruptions.” and button “Manage certificates”. Which screen after entering shows the “uhttpd.crt” certificate has expired. Under Preview it shows:

Issued 2025-10-10

Expires 2025-07-23

Encryption ECC

Key size 256

… etc.

So the certificate had been expired couple of months ago, but previous firmware versions did not notice it.

WebUI doesn’t seem to allow renew or delete it. So I went and looked a bit via ssh using find seeing wheres’ the file and what I could do about it. Seems there is only one file that name at /etc/uhttpd.crt and it’s associated key with it at same directory. File is being included from /etc/config/uhttpd and if I’m not completely wrong its’s been used something to do with Hotspot service, which I do not have active but for some reason still tries to use that certificate reasons unknown to me at least at this time.

Just for curiosity I went and generated new regenerated certificate with same key and all the details from the old certificate with new dates of course, installed it to replace old file with same ownership and permissions, but that did not fix the issue.

I tried looking from Teltonika support Wiki and this community portal and did not find anything relating to this issue so I thought I post here about it and possibly someone else has idea how to fix it if it’s doable without waiting a future firmware upgrade.

Cheers,

riku

–

e: fixed product name on the subject.

[mesrik]

Oh, I just noticed that above WebGUI shows issued date of today, since I’ve got that myself generated certificate file there. I do have backups if I need to rollback though.

riku

–

[mesrik]

Hello,

I noticed that there are same certificates at /overlay/etc/upper directory. However updating either those will not clear warning on WebGUI.

Here is what I did to update uhttpd.crt on my Debian 13 to generate new certificate after copying uhttpd.key file first to it from the RUTX50 of course.

$ openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -x509 -key uhttpd.key -nodes -days 730 -out new-cert.pem -subj “/OU=Self Signed”
Warning: Not generating key via given -newkey option since -key is given

$ ls -ltr
total 44
-rw------- 1 mesrik staff 241 Oct 10 15:00 uhttpd.key
-rw-r–r-- 1 mesrik staff 583 Oct 10 18:25 new-cert.pem

$ openssl x509 -in new-cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2c:96:82:60:18:ba:2a:9c:b7:f2:a4:e9:b5:57:7c:ac:4d:59:b6:3d
Signature Algorithm: ecdsa-with-SHA256
Issuer: OU=Self Signed
Validity
Not Before: Oct 10 15:25:58 2025 GMT
Not After : Oct 10 15:25:58 2027 GMT
Subject: OU=Self Signed
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:67:71:35:6e:c9:92:ae:31:b5:a1:47:eb:9f:40:
0b:57:32:79:76:8c:5a:2a:87:1d:ee:51:8f:b2:7f:
7d:81:da:c7:19:d3:ca:01:e0:45:83:ba:ef:d1:bd:
98:96:30:49:99:d0:51:73:78:68:35:4e:11:39:0a:
1e:f0:65:87:0e
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
2F:55:DC:92:27:66:D7:71:AE:76:DB:FD:35:90:AB:72:03:51:0F:02
X509v3 Authority Key Identifier:
2F:55:DC:92:27:66:D7:71:AE:76:DB:FD:35:90:AB:72:03:51:0F:02
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:44:02:20:6d:2d:e0:3d:ea:db:52:a4:ad:5c:40:31:ee:64:
23:c6:4c:48:d1:2f:ab:55:cf:da:a3:8d:8b:eb:06:34:83:90:
02:20:27:6b:64:9a:5d:55:09:26:db:98:e0:b5:5d:2a:8c:2b:
98:c0:69:e2:82:a5:df:cb:9f:74:a0:75:88:6d:23:3f

$ scp new-cert.pem root@gw:/etc/uhttpd.crt
new-cert.pem 100% 583 85.5KB/s 00:00
$ scp new-cert.pem root@gw:/overlay/etc/upper/uhttpd.crt
new-cert.pem 100% 583 67.2KB/s 00:00
$

$ ssh root@gw
…

# /etc/init.d/uhttpd restart

# /etc/init.d/uhttpd status

running

#

And it still WebGUI shows that certificate has expired 2025-07-23.

I would appreciate it if anyone would give hint where that expiration is being cached and if there is a known way to update value from the certificate.

Cheers,

riku

[anon65719490]

Hello,

The server certificate and key used by the WebUI (uhttpd service) are stored in the /etc directory. Could you try to remove the existing certificate and key files (by running rm /etc/uhttpd.crt && rm /etc/uhttpd.key) and rebooting the router afterwards. After the reboot, the system should automatically regenerate new certificates.

Let me know how it goes.

Best regards,

[mesrik]

Hello,

Thank you for your reply. Here is what I see after removing and booting.

root@rutx50:~# date
Mon Oct 13 10:45:16 EEST 2025
root@rutx50:~# uptime
10:45:18 up 6 min, load average: 0.47, 0.59, 0.32
root@rutx50:~# ls -l /etc/uhttpd*
ls: /etc/uhttpd*: No such file or directory
root@rutx50:~#

Nope, unfortunately it did not help.

Looking from WebGUI System→Administration→Certificates still shows red “(i) Certificates have expired Immediate action required to avoid service disruptions.” and line uhttpd.crt shows “Certificate has ….” trunkated red line. Clicking Preview show dialog box top of screen “(x) Failed to load certificate data”.

I had tried just removing uhttpd.crt bit earlier and rebooted, it behaved the same.

riku

[mesrik]

Hello,

While looking around where that old date information came from I think I’ve found something.

root@rutx50:~# uci show | grep “certificates.@certificate\[8\]”
certificates.@certificate[8]=certificate
certificates.@certificate[8].path=‘/etc/uhttpd.crt’
certificates.@certificate[8].fullname=‘uhttpd.crt’
certificates.@certificate[8].type=‘cert’
certificates.@certificate[8].datetime=‘1753271990’
certificates.@certificate[8].cert_type=‘import’
certificates.@certificate[8].key_size=‘256’
certificates.@certificate[8].encryption=‘ecc’
uci: Entry not found
uci: Entry not found

uci: Invalid argument

root@rutx50:~# date --date=‘@1753271990’
Wed Jul 23 14:59:50 EEST 2025
root@rutx50:~#

As RutOS is based on OpenWRT it has the “uci” luci configuration tool, which while browsing what that shows I found that hhere that old certificate information is coming, as you can see above.

Two entry not found shown above are because /etc/uhttpd.key and .crt were removed. Returning files there removed those.

I have not much experience on OpenWRT (ie. RutOS and variants) and just dabbing still with it as I’ve worked my career on enterprise, ISP and telecommunications grade gear.

riku

[mesrik]

Hello,

To add above uci found certificate datetime, changing it does not seem to have any effect on what WebGUI shows.

I tried setting both epoch (seconds from 1-1-1970 00:00:00) value with newly created similar certificate shown above in conversation and RFC3999 (lookalike) 2027-10-10T15:25:58Z’ format what other working certificates are using. Then restarted uhttpd and when that did not show any change WebGUI showing value rebooted testing twice with epoch and RFC3999 timestamps. WebGUI is still complaining expired uhttpd certificate with “Expires 2025-07-23”.

OK, what I understand from these tests that certificate expiration date is nor used from that certificate itself at least after first time it’s been used and uhttpd does not seem to care what the ‘uci set certificates.@certificate[8].datetime’ value is set.

Right and once this was a dead end, I’ve undone and returned everything as they were to state I first opened this matter here.

While I’ve done some digging I’ve now have let finding this causing issue and how to fix it to wait until you have some kind of solution to this issue. So, I’m falling back to what you can come up with either ask me provide you more data about what you need to study or some change(s) I could try.

Up to you,

riku

[anon65719490]

Hello,

Thank you for your update and further testing. In this case, to investigate this specific issue effectively, we’ll need to continue this process privately, because sensitive/publicly unshareable information, such as the troubleshoot file, configurations, logs, SN, etc., needs to be collected.

You should find a support request form in the inbox of the email address you used for your forum registration. Kindly fill out the form, and please reference Ticket ID: 15921 when submitting it. Once the form is completed, we’ll contact you directly via email to investigate the issue in detail and help work towards a solution.

Best regards,

[mesrik]

Hello,

OK. I got the issues solved. To put it simply after updating /etc/uhttpd.crt file with a new certificate and then using “uci set certificates.@certificate[8].datetime=’new-end-date’ where that new-end-date is either value from epoch or rfc3999 timestamp like what other certificates uses what is needed is to issue “uci commit certificates”.

And that’s it, after both me and WebGUI are happy

Now if someone else is device gets this issue and it’s root cause is not yet fixed with new firmware releases. I wrote a simple helper script to assist doing what I described above. Running that will what commands needs to be issued. It will dig from uci registry correct commands once provided the updated certificate file name with the path of course.

Here were the commands I used updating /etc/uhttpd.crt certificate which a new one generated with existing key /etc/uhttpd.key copying all data from old certificate but the dates of course.

root@rutx50:~# openssl x509 -x509toreq -copy_extensions copyall -in /etc/uhttpd.crt -signkey /etc/uhttpd.key -out uhttpd-new.csr

root@rutx50:~# openssl req -in uhttpd-new.csr -noout -text

root@rutx50:~# openssl x509 -in uhttpd-new.csr -out uhttpd-new.crt -req -signkey /etc/uhttpd.key -days 730

root@rutx50:~# openssl x509 -in uhttpd-new.crt -noout -text

root@rutx50:~# cp -av /etc/uhttpd.crt /etc/uhttpd-old.crt

root@rutx50:~# cp uhttpd-new.crt /etc/uhttpd.crt

root@rutx50:~# openssl x509 -in /etc/uhttpd.crt -noout -text

This was run from root home directory shell. Now after that, the script (attached in zip file) copied to router root home directory I ran it and this is what it happened.

root@rutx50:~# ./uhttpd-crt-update.sh /etc/uhttpd.crt

Registered uhttpd ertificate end_date at the moment is:
uci get certificates.@certificate[8].datetime
==> 1753271990

The certificate end_date at filesystem is:
/etc/uhttpd.crt
==> 2027-10-15T06:46:25Z

# If you want to register /etc/uhttpd.crt cerificate end_date to

uhttpd registry, you can accomplish that by issuing
the following commands usin root user privileges.

# Make backup of certificate settings

uci export certificates > uhttpd-certificates.bak

# Update end_date

uci set certificates.@certificate[8].datetime=‘2027-10-15T06:46:25Z’

# Verify change and commit chante

uci get certificates.@certificate[8].datetime
uci commit certificates

# Verify using WebGUI the Certificate date is correct,

# if not, then you can roll back using commands

uci import certificates < uttpd-certificates.bak
uci commit certificates

# If it was, you may now or later remove the backup file

rm uhttpd-certificates.bak

=====================================================================
root@rutx50:~#

root@rutx50:~# uci export certificates > uhttpd-certificates.bak
root@rutx50:~# uci set certificates.@certificate[8].datetime=‘2027-10-15T06:46:25Z’
root@rutx50:~# uci get certificates.@certificate[8].datetime
2027-10-15T06:46:25Z
root@rutx50:~# uci commit certificates
root@rutx50:~#

And that’s it. Now WebGUI shows at System->Administration→Certificates uhttpd.crt is valid for 1 year and 11 months <Yay!>

Now, if there isn’t anything else someone else would like to add. This issue would be ready to made resolved.

riku

uhttpd-crt-update.zip (1.3 KB)