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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)