Certificate date 2015-2018 for OpenWrt 23.05rc1 login page?

Hi there,
Running snort, basic fire wall.
Should the login certificate valid date range be 2015-2018, or 2023?
I assume 2023?
Can post screen shot shortly, just making this post now.
Internet also slowed to a crawl about the same time, expect it happened in last 12 hours.

Thank you for your time and consideration.

I don't use the RC, but 22.03.5 stable, it's the same.

there's no (valid) public cert shipping with openwrt, you need to get one yourself.

1 Like

https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings

https://oldwiki.archive.openwrt.org/doc/howto/certificates.overview

Welcome to the community!

This cert was generated on your first boot (unless you copied it from an old config).

1 Like

Awesome thanks for the pointers and the help and the welcome :).
I was getting a bit worried as it seemed a very strange date range for a this-year OpenWRT install.
Glad to know that doesn't indicate anything problematic and is instead, entirely to be expected.
Sounds like generating current certificates with proper date ranges is the way go, I assume that'll happen the moment I type in openssl reg

I'm not sure what this means in context of OpenWrt.

Are you asking how to make OpenWrt generate a new certificate now that the device is up and has current time?

Yes.
The certificate is generated with the current time of your router. Routers typically have no battery backuped realtime clock, so the initial time may vary, and if you generate the ceertificate before there is connectivity and correct time via NTP, you may end with cert with wrong dates.

Easiest way to get w new cert with correct dates is:

  • check that the router has current time
  • rm the old cert from /etc.
    /etc/uhttpd.crt and uhhtpd.key (if I remember right)
  • restart the uhttpd service (the LuCI web server).
    /etc/init.d/uhttpd restart

New cert should be generated automatically.

5 Likes

@hnyman, perfect answer, thank you very much.
It's uhttpd.key but close enough to find it quickly.
That did exactly what I wanted, sorry for the nubness.
I assume openwrt doesn't much with the date until ntp is online so as to not affect the system directly?
Is there any harm in having a check built in that updates the clock to at least the build time of the openwrt install automatically, or does that pose security risks that I am unaware of?
Is there any risk in having my certificate issuer details, or cert issues, on the internet - I realise it made sense to me for trouble shooting purposes, I'm just wondering now.
Erm just checked updated cert details and no, no risk, I assume. Lucky roll there, 36a777d.

Best regards

That is already there.

Initially, when the system is booted up, the clock is set to the most recent file timestamp in /etc.
In practice that is either the firmware build date or the date of a file in a restored settings backup.

As soon as there is network connectivity, NTP is used to get the real time.

(no idea, how you got your ancient cert date. From an old backup?)

2 Likes

Yeah same here.
I did not know the clock went that far back. That in itself is quite bizarre and you've raised an excellent query.
I believe the default clock date on this hardware is approx 2017, so probably, during first start up certificate generation.
I'm not rolling backwards, so yeah, cross fingers

I'm also pondering random number seed regeneration on bootup, I guess that's worth another thread.

Well, you have /etc/urandom.seed initialised after each boot for the next boot,
and even that is less important since Linux kernel moved in 5.17 to blake2 hash based random and urandom
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.42&id=9f9eff85a008b095eafc5f4ecbaf5aca689271c1

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.