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).
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.
The reference to "scrambled credentials" implies a syntax error, some
kind of credential checker would be a useful tool at this point.
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.
<bp@www.zefox.net> 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.
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.
On Sat, 31 Aug 2024 00:54:42 -0000 (UTC), bp wrote:
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.
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 <https://gitlab.com/ldo/ssl_try_python/>.
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.
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?
The procedure for being your own CA is a lot simpler in OpenSSL 3. I
have some notes here <https://gitlab.com/ldo/ssl_try_python/>.
Fortunately it seems OpenSSL 3 is installed. I'll try your exercise
shortly
Richard Kettlewell <invalid@invalid.invalid> wrote:
<bp@www.zefox.net> writes:Sorry, that terminology came from the informational window presented by Chromium saying it didn't like the certificate.
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.
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.
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.
On Sun, 1 Sep 2024 00:23:58 -0000 (UTC), bp wrote:
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.
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.
On Sun, 1 Sep 2024 00:43:57 -0000 (UTC), bp wrote:
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?
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.
Presumably the client (a Pi5 running RasPiOS) already has created its
own?
Its own CA? Hard to think why it would.
The procedure for being your own CA is a lot simpler in OpenSSL 3. I
have some notes here <https://gitlab.com/ldo/ssl_try_python/>.
Fortunately it seems OpenSSL 3 is installed. I'll try your exercise
shortly
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.
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: | Weed Hopper |
|---|---|
| Location: | Clearwater, FL |
| Users: | 14 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 231:38:50 |
| Calls: | 55 |
| Calls today: | 1 |
| Files: | 50,127 |
| D/L today: |
33 files (4,307K bytes) |
| Messages: | 275,362 |