luci: luci-app-uhttpd: generated certificate from gui does not contain alt_name resulting in error in browser Edge and Chrome

Steps to reproduce:

go to: Services → uHTTPd→ uHTTPd Self-signed Certificate Parameters
set parameters to your liking
Save & Apply
click “remove old certificate and key” button

Actual behavior:

The generated certificate will not be accepted by modern browsers

Expected behavior:

A certificate that will be accepted by modern browsers

Additional Information:

The effect you can see on windows and edge for example is. That if you have not trusted the certificate edge will show an NET::ERR_CERT_AUTHORITY_INVALID error. This error can be ignored and the website can be accessed. However, to get rid of the certificate error the normal way is to download the certificate and install it in the “Trusted Root Certificate” store for the local machine. The problem is, if you use the current generated certificate you get an NET:ERR_CERT_INVALID error which you not be ignored and you can not access the website until you removed the certificate from the certificate store again.

As a workaround you can create the certificate manually The commands are

openssl ecparam -name prime256v1 > ec.param
openssl req -x509 -nodes -days 3650 -newkey ec:ec.param -keyout mycert.key -out mycert.crt -config myconfig.conf

The used config looks like this

[req]
distinguished_name  = req_distinguished_name
x509_extensions     = v3_req
prompt              = no
string_mask         = utf8only
utf8            = yes

[req_distinguished_name]
C                   = <Country>
ST                  = <State>
L                   = <local>
O                   = <organisation>
OU                  = <organisation unit>
CN                  = <fqdn of openwrt device (openwrt.lan)>

[v3_req]
keyUsage            = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage    = serverAuth
subjectAltName      = @alt_names

[alt_names]
DNS.1               = <fqdn of openwrt device (openwrt.lan)>
IP.1                = <ipv4 of openwrt device (10.0.0.1)>
IP.2                = <ipv6 of openwrt dervice (fd18:211d:d95::1)>
<add more IPs if needed>

The certificate generated this way gets accepted and the certificate error vanishes as soon as the certificate is installed in the certificate store.

The workaround makes it clear that the certificates generated over the ui lacks the alternative names which seems to be a requirement for modern browsers.

About this issue

Original URL
State: open
Created 8 months ago
Comments: 32 (15 by maintainers)

Most upvoted comments

@jow-

I think that the commit in your staging repo would help for the “step 8+9” problem:

as long as the Certificate does not hold the alt names it does not matter what CA you are using you will be locked out from the openwrt pages. Ironically this is only the case when the CA is trusted

Most users never bother to add the self-signing CA into the trusted CA database, so they never run into this as we just once accept the NET::ERR_CERT_AUTHORITY_INVALID warning.

But apparently some users do tinker with CA database and will then later run into NET:ERR_CERT_INVALID. Those two new fields might help these users.

I applied the patch to my live OpenWrt system (with OpenSSL) and both Firefox, Edge and Chrome (in Windows) showed the new fields in the certificate data for the new self-generated certificates. Normal NET::ERR_CERT_AUTHORITY_INVALID warning, but nothing else.

So, the patch in your repo works at least with OpenSSL based OpenWrt. However, I doubt that those parameters will not work with px5g tools with wolfssl or mbedtls.

Looking at px5g sources, e.g. https://github.com/openwrt/openwrt/blob/main/package/utils/px5g-mbedtls/px5g-mbedtls.c , we might need to add support for extendedKeyUsage and subjectAltName into px5g.

If the new generation attributes only work with OpenSLL and cause errors with mbedtls (?), the change might now be added only to the OpenSSL based variant of the command. I tested also that modification:

root@router5:~# diff -u /rom/etc/init.d/uhttpd /etc/init.d/uhttpd
--- /rom/etc/init.d/uhttpd      2023-11-24 17:25:42.000000000 +0200
+++ /etc/init.d/uhttpd  2023-11-25 14:33:12.000000000 +0200
@@ -52,7 +52,7 @@
        local KEY_OPTS="rsa:${bits:-2048}"
        local UNIQUEID=$(dd if=/dev/urandom bs=1 count=4 | hexdump -e '1/1 "%02x"')
        [ "$key_type" = "ec" ] && KEY_OPTS="ec -pkeyopt ec_paramgen_curve:${ec_curve:-P-256}"
-       [ -x "$OPENSSL_BIN" ] && GENKEY_CMD="$OPENSSL_BIN req -x509 -sha256 -outform der -nodes"
+       [ -x "$OPENSSL_BIN" ] && GENKEY_CMD="$OPENSSL_BIN req -x509 -sha256 -outform der -nodes -addext extendedKeyUsage=serverAuth -addext subjectAltName=DNS:\"${commonname:-OpenWrt}\""
        [ -x "$PX5G_BIN" ] && GENKEY_CMD="$PX5G_BIN selfsigned -der"
        [ -n "$GENKEY_CMD" ] && {
                $GENKEY_CMD \

hnyman on Nov 25, 2023

@stangri or better “provide option to add alt name to CSR” , the local signing is good as it is, one may change hostname right after first boot made the first key.

brada4 on Nov 23, 2023