On Tue, Oct 3, 2017 at 3:51 PM, Stephen Frost <sfrost@snowman.net> wrote:
Tom, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Magnus Hagander <magnus@hagander.net> writes: > > On Tue, Oct 3, 2017 at 6:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> I'm not an SSL expert, so insert appropriate grain of salt, but AIUI the > >> question is what are you going to verify against? > > > One way to do it would be to default to the "system global certificate > > store", which is what most other SSL apps do. For example on a typical > > debian/ubuntu, that'd be the store in /etc/ssl/certs/ca-certificates.crt. > > Exactly where to find them would be distribution-specific though, and we > > would need to actually add support for a second certificate store. But that > > would probably be a useful feature in itself. > > Maybe. The impression I have is that it's very common for installations > to use a locally-run CA to generate server and client certs. I would not > expect them to put such certs into /etc/ssl/certs. But I suppose there > might be cases where you would actually pay for a universally-valid cert > for a DB server ...
In many larger enterprises, they actually deploy systems with their own CA installed into the system global certificate store (possibly removing certain other CAs from that set too, and distributing their own version of the relevant package that maintains the CA set).
I think this is also something that's seen more now than it used to be. Back when we initially did the SSL support, few people actually did this. That's not just for this scenario of course -- larger enterprises are much more likely to *have* proper PKI management today, and if they do then it will include the Linux boxes.
Bottom line: things in this area has change greatly in the past 10-15 years.
