I'm trying to get chromium under RasPiOS to open an https connection to
a private webserver that's using a self-signed certificate.
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?
<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).
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?
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.
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.
Are the certificates and keys the same between SSH and TLS?
Richard Kettlewell <invalid@invalid.invalid> wrote:
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?
On Sun, 1 Sep 2024 16:12:50 -0000 (UTC), bp wrote:
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.
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.
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.
On Sun, 1 Sep 2024 22:49:42 -0000 (UTC), bp wrote:
Are the certificates and keys the same between SSH and TLS?
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.
Your scripts seem to work on both FreeBSD and RasPiOS. Now to see if I
can stumble through making them work between _between_ FreeBSD and
RasPiOS.
One obvious question is setting the "listen_addr" in the
try_server script. Can it be set to "any" or a range by IP or FQEN?
On Sat, 7 Sep 2024 01:39:00 -0000 (UTC), bp wrote:
Your scripts seem to work on both FreeBSD and RasPiOS. Now to see if I
can stumble through making them work between _between_ FreeBSD and
RasPiOS.
Hey, great.
One obvious question is setting the "listen_addr" in the
try_server script. Can it be set to "any" or a range by IP or FQEN?
That has to be a valid interface address, or just make it “0.0.0.0” to listen on all interfaces on the local machine. This makes it visible
across your network, with the consequent security implications, which is
why I used “127.0.0.1” (loopback interface, only visible on the local machine) in the published code.
| Sysop: | deepend |
|---|---|
| Location: | Calgary, Alberta |
| Users: | 263 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 22:19:50 |
| Calls: | 1,928 |
| Calls today: | 3 |
| Files: | 4,341 |
| D/L today: |
28 files (10,306K bytes) |
| Messages: | 404,008 |