Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative
От | Daniel Gustafsson |
---|---|
Тема | Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative |
Дата | |
Msg-id | B5E2B87D-3E8A-4597-9A7F-8489B3B67556@yesql.se обсуждение исходный текст |
Ответ на | Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative
|
Список | pgsql-hackers |
> On 03 Aug 2017, at 13:36, Daniel Gustafsson <daniel@yesql.se> wrote: > >> On 03 Aug 2017, at 13:06, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> >> Why can't you have the root certificate in the keychain, too? Just not implemented yet, or is there some fundamental problemwith it? > > Just not implemented yet, awaiting Keychain discussions. Supported in this new patchset. > Yeah, discussion -> documentation -> code was my plan. Attached is an updated set of patches, rebased on top of master, with bug fixes and additional features missing in the first set. While not complete (yet), in case anyone is testing this I’d rather send a fresh batch rather than sitting on them too long while I keep hacking at the docs. While not every part of this rather large changeset has been touched, this includes all the patches for completeness sake. This patchset has certificate revocation as the main thing left. I’ve done work on supporting CRLs via a Keychain and a CRL policy but that needs more work (any help is much welcome). DH parameters are loaded via the GUC, and instead of DER format (which is what Secure Transport wants) it uses PEM such that it can load the same precomputed parameter as be-secure-openssl.c and the same files. Keychains are supported for root certificates in the frontend as well and are added to the backend for identities as a first test for how it can be integrated. Referencing an identity in a keychain is done by prefixing the certificate parameter with keychain: and specifying the common name rather than filename. The current code doesn’t support setting the passphrase for a Keychain, it will try with a blank password (since thats handy for testing) and if that fails it will bring up a GUI element for the passphrase. How to set a passphrase in the server is open for discussion, a Keychain cannot be created without a passphrase (it can be blank, but you still need to pass ‘’ to it). There is a first stab at documentation included, it needs a lot more work to fully separate generic SSL information and backend specific information but it’s a WIP. Additionally, a fix for an issue in the SSL tests is included which only surface in the Secure Transport tests since it uses connstring parameters with spaces in them. 0001: Adds support for running the SSL tests against another set of server binaries. Not changed from previous submission, except rebased on top of master. 0002: Secure Transport support for frontend & backend. 0003: A rough first stab at updating the docs to split SSL documentation into generic SSL information, and backend specific information. Lot’s to do still here but it’s a start. 0004: A fix for an issue in the SSL tests which broke Secure Transport testing. The SELECT ‘$connstr’ clause in the test doesn’t play nice with connstrings containing sslcert:'keychain:common name’ parameters. cheers ./daniel -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: