home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   RBERRYPI      Support for the Raspberry Pi device      21,939 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 20,403 of 21,939   
   Richard Kettlewell to bp@www.zefox.net   
   Re: Chromium and self-signed certificate   
   14 Aug 24 15:27:46   
   
   INTL 3:770/1 3:770/3   
   REPLYADDR invalid@invalid.invalid   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  8fc6d44d   
   REPLY:  16ee3a59   
   PID: SoupGate-Win32 v1.05   
    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).   
      
   --   
   https://www.greenend.org.uk/rjk/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 10/0 1 90/1 103/705 105/81 106/201 124/5016 129/305 153/757   
   SEEN-BY: 153/7715 218/0 1 601 700 840 870 930 220/70 221/1 6 360 226/17   
   SEEN-BY: 226/30 100 227/114 229/110 111 114 200 206 300 317 400 426   
   SEEN-BY: 229/428 470 550 616 664 700 240/1120 266/512 267/800 282/1038   
   SEEN-BY: 291/111 292/854 301/1 113 812 310/31 320/219 322/757 335/364   
   SEEN-BY: 341/66 342/200 396/45 460/58 633/280 712/848 770/1 3 100   
   SEEN-BY: 770/330 340 772/210 220 230 5020/400 1042 5058/104 5075/35   
   PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca