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,606 of 21,939   
   Richard Kettlewell to bp@www.zefox.net   
   Re: Chromium and self-signed certificate   
   01 Sep 24 12:44:46   
   
   INTL 3:770/1 3:770/3   
   REPLYADDR invalid@invalid.invalid   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  fb2e8eb5   
   REPLY:  5d4a69ce   
   PID: SoupGate-Win32 v1.05   
    writes:   
   > Richard Kettlewell  wrote:   
   >>  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.   
   >>   
   > Sorry, that terminology came from the informational window presented by   
   > Chromium saying it didn't like the certificate.   
      
   The word “scrambled” doesn’t appear anywhere else in your posting. I   
   don’t know what the window you saw said but what you wrote was “the   
   website sent back unusual and incorrect credentials” (which is certainly   
   a commonly occurring Chrome/Chromium error).   
      
   >> 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.   
      
   The cabforum.org requirement is in section 7.1.2.7.12 - subjectAltName   
   must be present and must contain a dNSName or ipAddress. Section 7.1.4.3   
   covers Common Name: if it is present then it must be a copy of the   
   dNSName from the subjectAltName. Given the wording I think it’s optional   
   in website certificates.   
      
   > 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.   
      
   You are talking about two different things here.   
      
      
   A self-signed certificate for a website does stand on its own (if you   
   can persuade a browser to accept it). It doesn’t prove anything in   
   isolation, since your browser has no reason to trust the public key in   
   the certificate, and the resulting TLS connection can only resist   
   passive snooping at best.   
      
   Historically it was a common choice since it was relatively easy to   
   persuade browsers to accept self-signed certificates. As you’ve found,   
   it’s harder today.   
      
      
   An alternative approach is to run your own CA, and inject its root   
   certificate into your operating system’s or browser’s store of root   
   certificates. If you do this then effectively you are doing the same as   
   a public CA, albeit most likely in a much more informal way. Provided   
   you can keep all the private keys involved secret, the TLS connection   
   will resist direct active attacks.   
      
   The root certificate in this case will be self-signed; it is using the   
   certificate format to convey a public key, the name of the CA and some   
   policy information. The trust derives from you adding the root   
   certificate to the browser’s certificate store, not from the signature   
   in the certificate itself.   
      
   This is a common enough choice in large organizations who want to secure   
   internal connectivity without using the public PKI. I did it myself for   
   a while on my home network but found it more effort than it was worth   
   when LetsEncrypt could do it for free.   
      
   If you take this approach you will still need to follow whatever rules   
   the browser implements for both the root CA certificate and the website   
   certificate, and most likely they will be some subset of the   
   cabforum.org requirements.   
      
   --   
   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