SNI certificates - Doesn't seem to work with LuCI and TLS

Installing and Using OpenWrt
1

I recently tried to upload a certificate with the X509v3 Subject Alternative Name defined. It looks like none of the three underlying TLS implementation are able to use those certificates. Has anyone else tried this, or am I making a mistake somewhere?

2

No idea, until you tell what you have done. You might have an error in the cert creation parameters, or something similar. Have you been able to verify that the same certificate works somewhere else? (in a non-Openwrt/LEDE device) Or verified it via openssl command line?

Based on quick googling, I think that OpenSSL should be able to use that cert, but the support for that feature may require some compile-time flag, or something similar.

3

Creating a cert with openssl, not using the extension works fine, except that now Chrome marks it as insecure (Firefox is OK with it) with 'Subject Alternative Name missing. The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address.'

So, I don't think I'm making a mistake, but I never rule that out for sure.

I.e. I can get LuCI to use TLS and install a cert and have it all be trusted by Firefox, but not by Chrome. Not a huge deal, but I like things to be 100% correct...

4

OpenSSL has supported SNI by default since 0.9.8j (2009), with prior versions needing a compile-time flag. I'm not familiar with SNI at all, however have you by chance searched Google yet? From a quick glance at a few top returned results, SNI does require browsers and web servers to be of a certain version, but a quick glance did seem to indicate all modern browser versions support it. As to web servers, most major ones do as well, but I didn't see uHTTPd on the list (which I'm assuming you're using, since servers like Nginx can't be utilized due to it lacking support for plain cgi).

5

Yes, I'm using the pretty bog standard uhttpd.

6

I must have been replying as you submitted #3... Are you using an IP or hostname in the CN? If so, this was depreciated and obsoleted decades ago in the RFC, due to the potential for exploits, and Google finally distrusted all certificates incorrectly (lazily would be a better term, as a SAN takes a few min at most to configure) storing an IP or DNS in the CN in the last few months.

Please post the output of openssl x509 -text -noout -in <name_of_cert>, removing any IPs/FQDNs or DN info you don't want made public.

  • What error is Chrome throwing (CTRL+SHIFT+J >> Security Tab)
7

The CN has a hostname. As indicated before, Chrome says 'Subject Alternative Name missing. The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address'. I've fixed this for all my various management tools (I've add my own authority). Lede with LuCI is the only one that doesn't work. If I do set up the certificate that way, I can't successfully connect to the web interface at all (if I recall the browser barfs with a protocol error).

8

I think that uhttpd has practically outsourced the ssl handling to the underlying libraries like openssl or mbedtls via ustreamssl, so uhttpd itself shouldn't have a role here. But probably @jow is the only one who really knows about the uhttpd internals to comment on that.

9

Maybe I'm misunderstanding...

  • LuCI certificate is signed by a [self-signed] CA, does not have a SAN, lists the DNS as the CN, and the WebUI will load fine with the cert if accessed from a browser other than Chrome?
    • If so, Chrome is going to barf an error because Google finally disabled the trusting of certs incorrectly utilizing a CN for storing the IP or DNS, since an exploitable vulnerability has existed for decades, and is why the RFC obsoleted the use of the CN for storing an IP or DNS decades ago. Instead of the public and commercial market abiding by this, everyone chose to disregard and continue issuing certs storing the IP or DNS in the CN.
      • This became effective with an update to all chromium channels sometime in November-ish of 2017 IIRC.
    • Error: "Subject Alternative Name Missing" or NET::ERR_CERT_COMMON_NAME_INVALID or "Your connection is not private"

If my understanding above is correct, the cert needs to be regenerated with a SAN profile, removing the DNS (FQDN or hostname) from the CN. Technically you can store the IP or DNS in the CN, provided the same information is stored in the cert's SAN profile, but again, this is not what the CN is for.

Edit: It appears I misquoted the date... this became effective as of Chrome v58 (April 2017), with a workaround for commercially signed certs removed as of v65 (Nov/Dec)

10

I just create my own cert and upload it to the box (/etc/uhttpd.{crt,key}). So, no self-signed cert...

11

Yes, and I think I tried all of the ones available.

12

You have a self-signed CA, not a self-signed cert.

In order for you to resolve the issue, that cert needs to be recreated with a SAN profile. If you don't know how to configure one, see this openssl.cnf

  • Lines 233 - 236
  • Lines 383 - 389

  • Applicable commands: Lines 557 & 565
13

I forgot to mention, any cert being used for a web server should always have the loopback IP included in the SAN. This prevents browser errors if tunneling through SSH.