How to setup uhttpd, https and haproxy at the same time?

Hello

My first problem is this: I have a self-generated certificate for uhttpd. But I have found no way to be able to use it.

If I could solve this, I could start debugging the interaction of haproxy and uhttpd.

If I simply point /etc/config/uhttpd to my certificate and its key, uhttpd sees that the certificate section in its config file does not match my certificates, and it starts to generate a new certificate. The certificate generation will crash for some reason:

Wed Jul 26 18:58:31 2017 kern.info kernel: [751703.524752] Wed Jul 26 18:58:31 2017 kern.info kernel: [751703.524752] do_page_fault(): sending SIGSEGV to px5g for invalid read access from 0000004c Wed Jul 26 18:58:31 2017 kern.info kernel: [751703.533398] epc = 77d0ab04 in libc.so[77ca2000+92000] Wed Jul 26 18:58:31 2017 kern.info kernel: [751703.538684] ra = 00401274 in px5g[400000+2000]

If I comment out the certificate part of the config, uhttpd will crash:

Wed Jul 26 18:58:57 2017 daemon.info procd: Instance uhttpd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash

I have no idea how to write the certificate section into the config in a way that uhttpd would accept it. I have the C, O and CN fields defined inside. Every time I try, it will attempt to regenerate the certificates and then crash.

I did # opkg remove px5g-mbedtls --force-depends and now I get

# /etc/init.d/uhttpd start 4+0 records in 4+0 records out 4 bytes (4B) copied, 0.000135 seconds, 28.9KB/s Generating a 2048 bit RSA private key ........................................+++ ..............+++ writing new private key to '/etc/ipsec/private/myKey.der.new' /etc/ipsec/private/myKey.der.new: No such file or directory 2006420664:error:02001002:lib(2):func(1):reason(2):NA:0:fopen('/etc/ipsec/private/myKey.der.new','w') 2006420664:error:20074002:lib(32):func(116):reason(2):NA:0: mv: can't rename '/etc/ipsec/private/myKey.der.new': No such file or directory mv: can't rename '/etc/ipsec/certs/myCert.der.new': No such file or directory

presumably from openssl.

AFAIK, there is no such logic. uhttpd only checks for the existence of the cert and key files based on config values in /etc/config/uhttpd:

    option cert '/etc/uhttpd.crt'
    option key '/etc/uhttpd.key'

the "cert" section only provides values for generating a new certificate, if needed, but those values have no role when a certificate is found.

See https://github.com/lede-project/source/blob/master/package/network/services/uhttpd/files/uhttpd.init#L156
and https://github.com/lede-project/source/blob/master/package/network/services/uhttpd/files/uhttpd.init#L34

the directory /etc/ipsec looks strange.
You should try generating the certs by yourself using the openssl command variant as displayed in the init file.
Relevant cmdline examples can be found e.g. in https://github.com/openwrt/luci/pull/807

I have certificates that are generated perfectly fine and work with Strongswan (which is where the /etc/ipsec.d comes from). I started an attempt to set up lighttpd, but I might as well try uhttpd again.

Edit:

With the section removed and my own certificates in place, I keep getting

Wed Jul 26 20:21:07 2017 daemon.err uhttpd[11419]: Error: No sockets bound, unable to continue

If I change it to use the certificates it generated earlier, it will start. But then Firefox will silently fail with http and complain about the certificate with https. I have option redirect_https '1' set.

Edit:

Adding my own CA certificate to /etc/ssl/certs in PEM form didn't change anything.

Concatenating the device cert and the CA cert (both in DER form) to /etc/uhttpd.crt didn't change anything.

Got uhttpd to start with my certificate and key by converting them from binary .der to ascii .pem format. Still will not load the user interface. But I must get back to that later.

Edit:

The root certificate must be imported to Firefox separately. Having it in OS X keychain is not enough.

Then is the problem that the thing now works only with https://routerdevice.mydomain.com, and a plain https://routerdevice will produce a complaint. Also, http://routerdevice shows me the "LuCI - Lua Configuration Interface" text, but will not redirect to the login screen. And http://routerdevice.mydomain.com goes nowhere.