Subj : Re: Chromium and self-signed certificates To : bp@www.zefox.net From : Richard Kettlewell Date : Sun Sep 01 2024 12:44:46 writes: > Richard Kettlewell wrote: >> 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/ --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .