Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Newsgroups: comp.sys.raspberry-pi Subject: Re: Chromium and self-signed certificates Date: Thu, 15 Aug 2024 16:51:38 -0000 (UTC) Organization: A noiseless patient Spider Lines: 70 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 15 Aug 2024 18:51:38 +0200 (CEST) Injection-Info: dont-email.me; posting-host="3eda70b34deb8f9ac27a51e172dd374a"; logging-data="1086988"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18iazzET55AdER74GLTa6UN/lRA9gh6ACo=" User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (FreeBSD/14.0-RELEASE-p9 (arm64)) Cancel-Lock: sha1:TM1hjJTxUUnmMuYeNbNQKgEVbxc= Bytes: 4011 Richard Kettlewell wrote: > 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. Thanks very much for enlightening replies! bob prohaska