INTL 3:770/1 3:770/3   
   REPLYADDR bp@www.zefox.net   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  d98879b4   
   REPLY:  18cfcff7   
   PID: SoupGate-Win32 v1.05   
   bp@www.zefox.net wrote:   
   > 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.   
      
   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: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 19/38 90/1 105/81 106/201 129/305 153/757 7715 218/700 840   
   SEEN-BY: 220/70 226/17 30 100 227/114 229/110 111 114 200 206 300   
   SEEN-BY: 229/317 400 426 428 470 550 616 664 700 266/512 267/800 282/1038   
   SEEN-BY: 291/111 292/854 310/31 320/219 322/757 342/200 396/45 460/58   
   SEEN-BY: 633/280 281 412 418 420 509 2744 712/848 770/1 3 100 330   
   SEEN-BY: 770/340 772/210 220 230 5020/400 5075/35   
   PATH: 770/3 1 633/280 229/426