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?
Improve this question
1
  • 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
    Commented Aug 11, 2022 at 2:37

1 Answer 1

Reset to default
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..

Improve this answer
2
  • Dank you, especially for the link. That did it!
    – Johannes Bauer
    Commented Aug 11, 2022 at 12:42
  • @JohannesBauer Glad I could be of help. The same issue trips me up as well from time to time.
    – Don't roll your own
    Commented Aug 11, 2022 at 13:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .