Re: Chromium and self-signed certificates

<bp@www.zefox.net> writes:

Richard Kettlewell <invalid@invalid.invalid> wrote:

<bp@www.zefox.net> writes:

The reference to "scrambled credentials" implies a syntax error,
some kind of credential checker would be a useful tool at this
point.

 
I see nothing about “scrambled credentials” above. If the browser got as
far as displaying the certificate subject then it is certainly
syntactically well-formed, your browser just doesn’t like the contents.
 

Sorry, that terminology came from the informational window presented by
Chromium saying it didn't like the certificate.

The word “scrambled” doesn’t appear anywhere else in your posting. I
don’t know what the window you saw said but what you wrote was “the
website sent back unusual and incorrect credentials” (which is certainly
a commonly occurring Chrome/Chromium error).

You will probably need at least a subjectAltName extension containing
the DNS name of your server. This has been a cabforum.org requirement
for real certificates for a long time and I don’t know of any reason it
wouldn’t apply to self-signed certificates too.

>
The DNS name is displayed in the Common Name, pelorus.zefox.org, which I
thought was sufficient.

The cabforum.org requirement is in section 7.1.2.7.12 - subjectAltName
must be present and must contain a dNSName or ipAddress. Section 7.1.4.3
covers Common Name: if it is present then it must be a copy of the
dNSName from the subjectAltName. Given the wording I think it’s optional
in website certificates.

Lawrence D'Oliviero's reply following yours touches on what I suspect
is my greatest misunderstanding: I thought a self-signed certificate
stood on its own. If I'm reading right (and it's early times still)
it looks like I need both  server certificate _and_  CA-certificate
files. That is something I didn't catch on to until just now.

You are talking about two different things here.


A self-signed certificate for a website does stand on its own (if you
can persuade a browser to accept it). It doesn’t prove anything in
isolation, since your browser has no reason to trust the public key in
the certificate, and the resulting TLS connection can only resist
passive snooping at best.

Historically it was a common choice since it was relatively easy to
persuade browsers to accept self-signed certificates. As you’ve found,
it’s harder today.


An alternative approach is to run your own CA, and inject its root
certificate into your operating system’s or browser’s store of root
certificates. If you do this then effectively you are doing the same as
a public CA, albeit most likely in a much more informal way. Provided
you can keep all the private keys involved secret, the TLS connection
will resist direct active attacks.

The root certificate in this case will be self-signed; it is using the
certificate format to convey a public key, the name of the CA and some
policy information. The trust derives from you adding the root
certificate to the browser’s certificate store, not from the signature
in the certificate itself.

This is a common enough choice in large organizations who want to secure
internal connectivity without using the public PKI. I did it myself for
a while on my home network but found it more effort than it was worth
when LetsEncrypt could do it for free.

If you take this approach you will still need to follow whatever rules
the browser implements for both the root CA certificate and the website
certificate, and most likely they will be some subset of the
cabforum.org requirements.

--
https://www.greenend.org.uk/rjk/