Openssl never finishes generating uhttpd.key on Turris Omnia

Installing and Using OpenWrt
1

I am trying to setup a TO with 19.07 from scratch, but when it boots up, uhttpd is not running and is waiting the the openssl step to complete. It stays in the state forever. A workaround seems to be to perform a first boot from 18.06 to get the key file generated and then upgrade to 19.07.

root@OpenWrt:~# ps -w | grep uhttp
 3265 root      1220 S    /bin/sh /etc/rc.common /etc/rc.d/S50uhttpd boot
 3372 root      3568 S    /usr/bin/openssl req -x509 -sha256 -outform der -nodes -days 730 -newkey rsa:2048 -keyout /etc/uhttpd.key
 4152 root      1064 S    grep uhttp
2

Turned out not to be a workaround after all: I cannot connect to LuCI even though it is running.

netstat -nap | grep uhttp
tcp        2      0 0.0.0.0:80              0.0.0.0:*               LISTEN      3222/uhttpd
tcp        2      0 0.0.0.0:443             0.0.0.0:*               LISTEN      3222/uhttpd
tcp        0      0 :::80                   :::*                    LISTEN      3222/uhttpd
tcp        0      0 :::443                  :::*                    LISTEN      3222/uhttpd
3

could be that the openssl key generation hangs during maiden boot since there is almost nothing running at that time in the system and thus having a hard time to gather entropy and to generate certificate.

2 Likes
4

@fantom-x, @anon45274024 has a good point:

Try the suggestions here:

2 Likes
5

I will try that, but even on 18.06 I get this, yet it did not prevent openssl from generating a new key.

sysctl kernel.random.entropy_avail
kernel.random.entropy_avail = 3
6

different versions of openssl 1.0.2s <> 1.1.1c, different prerequisites for key generation?

1 Like
7

Mvebu is especially difficult target on entropy perspective as the WiFi driver does not generate entropy to the kernel pool, like e.g. ath9k and similar drivers do.

I bought a chaoskey entropy key for my wrt3200acm and introduced the drivers for it to OpenWrt. That helps a lot.

You might try generating the key manually later, after the boot process has completed. Jill the uhttps keygen process and possibly uhttps, wait a few minutes, and restart uhttpd to generate the keys.

1 Like
8

It seemed to me that urngd was doing a pretty good job of generating early, and quickly, on a reboot.

9

Seems like it is only in master.

10

hmm, I assumed that it would have found its way into 19.x, I wonder if that is an oversight.

11

Took ~2h to get it this hight :slight_smile: I will try havengd shortly.

kernel.random.entropy_avail = 98

1 Like
12

haveged has solved the problem. Is there any downside of using it vs urngd that only exists in master?

13

Not to my knowledge.

1 Like
14

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