Re: Support for NSS as a libpq TLS backend

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: Support for NSS as a libpq TLS backend
Дата
Msg-id 8f741a425fd135ca38a28063730715499f7f6445.camel@vmware.com
обсуждение исходный текст
Ответ на Re: Support for NSS as a libpq TLS backend  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Support for NSS as a libpq TLS backend  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Wed, 2021-03-24 at 13:00 -0400, Stephen Frost wrote:
> * Jacob Champion (pchampion@vmware.com) wrote:
> > Right, but to clarify -- I was asking if *NSS* supports loading and
> > using separate certificate databases as part of its API. It seems like
> > the internals make it possible, but I don't see the public interfaces
> > to actually use those internals.
> 
> Yes, this is done using SECMOD_OpenUserDB, see:
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11_Functions#SECMOD_OpenUserDB

Ah, I had assumed that the DB-specific InitContext was using this
behind the scenes; apparently not. I will give that a try, thanks!

> also there's info here:
> 
> https://groups.google.com/g/mozilla.dev.tech.crypto/c/Xz6Emfcue0E
> 
> We should document that, as mentioned in the link above, the NSS find
> functions will find certs in all the opened databases.  As this would
> all be under one application which is linked against libpq and passing
> in different values for ssl_database for different connections, this
> doesn't seem like it's really that much of an issue.

I could see this being a problem if two client certificate nicknames
collide across multiple in-use databases, maybe?

--Jacob

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Custom compression methods
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: multi-install PostgresNode