Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: <bp@www.zefox.net>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: Chromium and self-signed certificates
Date: Sat, 31 Aug 2024 00:54:42 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 138
Message-ID: <vatpki$n4it$1@dont-email.me>
References: <v9g9tq$14v2$1@dont-email.me> <wwvfrr72n8d.fsf@LkoBDZeT.terraraq.uk> <v9lbmq$115gc$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 31 Aug 2024 02:54:43 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c37a56f7cd7199a200308148e504739b";
	logging-data="758365"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1++QQKjkM4ZclAoWPKjSmjWicpfj0Crl9M="
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (FreeBSD/14.0-RELEASE-p9 (arm64))
Cancel-Lock: sha1:U4Wr8s4dDDIvZ09kAr2RKhJvD5g=
Bytes: 7098

bp@www.zefox.net wrote:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> <bp@www.zefox.net> writes:
>>> I'm trying to get chromium under RasPiOS to open an
>>> https connection to a private webserver that's using
>>> a self-signed certificate. Apache starts up without
>>> reporting any errors, chromium opens the page but
>>> reports only an http connection. All I'm aiming for
>>> at this point is encryption, not authentication. 
>>>
>>> Looking at the page that opens and examining the
>>> certificate reports only one thing that looks like
>>> it might be an error. Under Certificate Basic Constraints
>>> the field value contains:
>>>
>>> Critical
>>> Is a Certification Authority
>>> Maximum number of intermediate CAs: unlimited
>>>
>>> Anybody got a link to a good description of how to
>>> troubleshoot this sort of problem? For example, where
>>> does chromium put its error logs?
>> 
>> 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:
>>   https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9
>> 
>> If that is indeed the issue then you need to go back to where the
>> self-signed certificate was generated and regenerate it with a
>> pathLenConstraint. How you do that depends on how you generated it.
>> 
>> 
>> 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.  

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 = bp@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 = bp@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 
https://docs.freebsd.org/en/books/handbook/security/ combined with some
private correspondence suggesting it worked correctly. 

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