0

I've got a Mayan EDMS running on a computer on the local network. The Web App is exposed via HTTPS on the non-standard port 8001 and it uses an SSL certificate that is signed by our own CA.

The CA is installed in my browser, but my browsers won't accept the certificate, saying:

Firefox does not trust this site because it uses a certificate that is not valid for <locally resolved hostname>:8001. Error code: SSL_ERROR_BAD_CERT_DOMAIN"

(Firefox)

and

Your connection is not private

...

NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is <locally resolved hostname>; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection.

Proceed to (unsafe)

(Chromium)

The CN used to be <locally resolved hostname>, but when that suddenly stopped working, I changed it to <locally resolved hostname>:8001.

Chromium will let me proceed, but FF won't, saying the server uses HSTS.

Main question:

What are the reasons a browser would reject a certificate with the error codes given?

In particular:

  1. Can these error codes occur if there is something wrong with the certificate other than the CN or hostname, like something with the CN, algorithms, protocol negotiation...
  2. Can/should the CN contain the port? FF's message seems to imply this and it seems reasonable, but Chromium says the CN with the port is invalid, including the port didn't fix the problem, and I'm finding conflicting information on this.
  3. Is there anything in the TLS/SSL/HSTS standards that does not allow local domain names or domains with local IPs as CNs/hostnames in certificates?
Johannes Bauer
  • 103
  • 2
  • No, CN in subject must not contain :port, and SAN.dnsName (which as answered you need) cannot. When Firefox says "not valid for host:port" that is _not_ saying "does not contain exactly host:port". As another variation, the cert can contain a wildcard which is not the string a.hostname.i.use but nevertheless is _valid for_ a.hostname.i.use and even a.hostname.i.use:9999 . – dave_thompson_085 Aug 11 '22 at 02:37

1 Answers1

3

The error message is key to the solution here:

This server could not prove that it is ; its security certificate does not specify Subject Alternative Names

It's not enough to just specify the common name of the server in question, you also have to fill in the Subject Alternative Names. This answer explains how to do it with OpenSSL, but the process should be similar, should you choose to use a different tool..

Don't roll your own
  • 84
  • 2