Chromium and self-signed certificates

The usual way I would do this is create your own CA (root) cert as the self-signed certificate; then the actual SSL certificate that the server is using will be signed with this certificate.

On the browser side, import the CA cert into the key store, and it will automatically trust certs signed with this CA cert.

On the one hand that’s just a description of something it found in the certificate. On the other hand it’s the kind of thing that browsers don’t like so it’s a reasonable candidate for your first problem.

Normally the error page when you try to visit an ill-configured https site can be persuaded to give you some kind of error indicator - you should check that before assuming that the unlimited path length is really the (only) issue.

If it is the problem:

pathLenConstraint is documented here:

The bigger picture:

No modern web browser is likely to accept a self-signed certificate without complaint (although the degree of moaning may vary), so getting past this issue may not improve matters as much as you hope.

Personally I use LetsEncrypt even for purely ‘internal’ certificates; it is a lot less painful than either self-signed certificates (which means tedious browser warnings) or running my own private CA (which means deploying the root to all the clients on my network, and fitting in with browser requirements, which can be a moving target).

It's very slowly dawning on me just how much I've bitten off here 8-( Your reply makes it clear that I didn't understand the relationship between a certificate and a CA-certificate, doubtless there's much more to learn.

My original goal was to get gmail to accept mail from my private mail server. When that proved opaque it seemed easier to get ssl/tls working with apache as a sort of rehearsal as it appeared better-documented. A single host handles both mail and web service and I supposed that one ssl/tls installation would work for both. Even if true the learning curve is much steeper than expected.

Thanks very much for enlightening replies!

bob prohaska

Perhaps a little progress has been made. I've generated a new host.crt and host.key pair and gotten apache to accept them. When I try to open an https connection chromium reports it's not secure, clicking on the not secure icon in the url bar lets me see the certificate details, with an "export" button at the bottom.

Clicking "export" brings up a file save dialog open to Documents and clicking "save" saves it in ~/Documents under the FQDN of the host.

Opening Settings > Privacy and Security > Security > Manage Certificates opens opens a page with an Authorities tab. That opens an Import button, clicking Import opens ~/Documents. Perhaps significantly, the default view doesn't recognize the file, viewing All Files lets me see the certificate. Selecting the certificate file and clicking open brings up a dialog box with checkmarks trusting websites, email users and software makers. Clicking the identifying websites box and clicking OK adds a new certificate to the authorities list, named not for the host but for the organization name. That the file wasn't recognized as a certificate seems suspicious to me.

At this point closing the old tabs and opening a new one to the server again reports a failure, to wit: pelorus.zefox.org normally uses encryption to protect your information. When Chromium tried to connect to pelorus.zefox.org this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be pelorus.zefox.org, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Chromium stopped the connection before any data was exchanged.

Clicking on the "not secure" icon again lets me see the certificate details. The Subject field contains

emailAddress = snipped-for-privacy@www.zefox.net CN = pelorus.zefox.org OU = pelorus.zefox.org O = zefox networks L = davis ST = ca C = us I gather the CN has to be the FQDN for the server, and it is.

The Issuer field appears the same: emailAddress = snipped-for-privacy@www.zefox.net CN = pelorus.zefox.org OU = pelorus.zefox.org O = zefox networks L = davis ST = ca C = us Could the identical OU and CN fields be troublesome? I'd think not...

The Certificate Basic Constraints field contains Critical Is a Certification Authority Maximum number of intermediate CAs: unlimited but it isn't obviously a problem, as this is a standalone certificate with a trust chain length of either zero or one, depending on how one counts.

The command to generate the self-signed certificate and key pair was openssl req -new -x509 -days 365 -sha3-512 -keyout host.key -out host.crt based on instructions from

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

Thanks to all for writing!

bob prohaska

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.

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.

I had a look at those instructions, and they don’t mention how to generate the actual CA cert. Having your own CA cert means you only have to import it once into a browser (or other SSL/TLS client), and it will thereafter trust all certs signed by this CA.

The procedure for being your own CA is a lot simpler in OpenSSL 3. I have some notes here

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

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

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.

Thanks for writing,

bob prohaska

Ok, that explains a lot. I thought the host certificate _became_ a CA certificate through the self-signing process..... So, I actually need _two_ certificates, one for the server and one for the signing authority, both created on the sesrver? Presumably the client (a Pi5 running RasPiOS) already has created its own?

Fortunately it seems OpenSSL 3 is installed. I'll try your exercise shortly

You've cleared up vast confusion, thank you!

bob prohaska

A CA cert needs to be self-signed, since of course there is nobody higher (within the SSL/TLS protocol, anyway) to vouch for a CA’s authenticity. The OS (or the browser) typically comes with a set of CA certs that it trusts, preinstalled. So any cert signed (directly or indirectly) by any of these CAs becomes trusted as well. And you should be able to add to these certs, or even remove them.

Its own CA? Hard to think why it would.

I should mention that my example use of TLS/SSL is as a wrapper for an entirely custom protocol, not related to HTTP/HTTPS. There are certain requirements for certs used for HTTP/HTTPS, where the “subject” field must contain the fully-qualified DNS name in the “CN=” part.

You can do it that way. That requires importing every single self-signed cert one by one. If you need several of these, then setting up your own CA just makes things simpler.

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).

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.

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.

That's what I thought the instructions cited in the FreeBSD Handbook did and what I was trying to do initially.

It appears there's something fundamental that I'm not understanding 8-(

In principle it would make sense to make a root CA for the three domains (zefox.com, zefox.net and zefox.org) under my control but if I disturb that one CA up all three become unreliable. I'm starting with one domain (and its only physical host) in an attempt to grade the learning curve a little flatter.

Thanks for writing!

bob prohaska

Ah, only a host certificate is needed for an anonymous client, like my browser?

That much I gathered. Still, it looks like there are are three uses for encrypted, authenticated communications between hosts: Mail, web traffic and remote logins. SSL is installed and working for remote logins on all the hosts under my control by default. Can a single ssl/tls configuration support all three services? Am I wrong to think of ssl and tls as one thing?

Apologies for all the naive questions!

bob prohaska

Possibly you have confused SSL with SSH (SSL/TLS can in principle be used for remote login but it’s unusual to do so).

If all multiple TLS-equipped services same domain name you can use a single key and certificate for all three of them.

SSL was renamed to TLS in 1999 when TLS 1.0 was introduced. So different versions of the same thing.

SSH is a different protocol.

That clears the fog a little. Are the certificates and keys the same between SSH and TLS?

Thank you!

bob prohaska

The basic encryption algorithms may be the same, but the usage is a little different. SSH has no concept of “certificates”, only of “host keys” versus “user keys”. Each key is of course actually a key pair, consisting of a public key (freely redistributable, but recipients need to be sure they get them from a trusted source) and a corresponding private key (never to be disclosed to anybody else).

There is a file in your SSH client config called “known_hosts”, which contains the public host keys of all the hosts you’ve previously connected to; this is used to guard against somebody trying to impersonate any of those hosts when you next try to connect.

If these are names intended to be accessed by the general public, then you need certs signed by official CAs that are trusted as standard by the browsers that the general public uses.

Setting up your own private CA only works for authentication between machines that you control.

There’s an overlap in key types (e.g. both can use ECDSA) but in practice you wouldn’t normally share keys between them.

The certificates formats are different. Many (probaly most) users don’t use certificates with SSH at all.

I understand that's the general intention, but can't browsers be told to trust a particular self-signed certificate by a user? That's what I was trying to do in my initial experiment, but apparently didn't construct the certificate correctly. If there's something else I'm doing wrong it'd to good to know now. The facility to export and import certificates to Chromium under Raspian Bookworm seems to suggest so.

Thanks for writing, and again for your patience!

bob prohaska