Re: what can go in root.crt ?
От | Andrew Dunstan |
---|---|
Тема | Re: what can go in root.crt ? |
Дата | |
Msg-id | f9f54351-85d7-1d23-a8f7-d7fd8fd73d2b@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: what can go in root.crt ? (Chapman Flack <chap@anastigmatix.net>) |
Ответы |
Re: what can go in root.crt ?
|
Список | pgsql-hackers |
On 5/25/20 3:32 PM, Chapman Flack wrote: > On 05/25/20 15:15, Chapman Flack wrote: >> Does that mean it also would fail if I directly put the server's >> end-entity cert there? >> >> Would I have to put all three of WE ISSUE TO ORGS LIKE YOURS, >> WE ISSUE TO LOTS, and WE ISSUE TO EVERYBODY in the root.crt file >> in order for verification to succeed? >> >> If I did that, would the effect be any different from simply putting >> WE ISSUE TO EVERYBODY there, as before? Would it then happily accept >> a cert with a chain that ended at WE ISSUE TO EVERYBODY via some other >> path? Is there a way I can accomplish trusting only certs issued by >> WE ISSUE TO ORGS LIKE YOURS? > The client library is the PG 10 one that comes with Ubuntu 18.04 > in case it matters. > > I think I have just verified that I can't make it work by putting > the end entity cert there either. It is back working again with only > the WE ISSUE TO EVERYBODY cert there, but if there is a workable way > to narrow that grant of trust a teensy little bit, I would be happy > to do that. > The trouble is I think you have it the wrong way round. It makes sense to give less trust to a non-root CA than to one of its up-chain authorities, e.g. only trust it for certain domains, or for a lesser period of time. But it doesn't seem to make much sense to trust the up-chain CA less, since it is what you should base your trust of the lower CA on. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: