From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | kzuk(at)akamai(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14329: libpq doesn't send complete client certificate chain on first SSL connection |
Date: | 2016-09-21 08:06:33 |
Message-ID: | c2315357-00b1-5141-c06c-8fca91736027@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 09/20/2016 01:10 PM, kzuk(at)akamai(dot)com wrote:
> My educated guess is that in fe-secure-openssl.c in initialize_SSL function
> whole certificate chain is loaded into SSL_context, but only client
> certificate is loaded to SSL object. SSL object is created before loading
> certificate chain into SSL_context, so it doesn't see this update. Only the
> next connection, with new SSL object, picks up the certificate chain from
> SSL_context. It doesn't explain why it works with OpenSSL 1.0.1 though, so
> that may be a false trail.
Yeah, that's probably what's happening. The OpenSSL man page for
SSL_CTX_use_certificate() says:
> The SSL_CTX_* class of functions loads the certificates and keys into
> the SSL_CTX object ctx. The information is passed to SSL objects ssl
> created from ctx with SSL_new by copying, so that changes applied to
> ctx do not propagate to already existing SSL objects.
It says the same in both 1.0.1 and 1.0.2 versions, though. I guess we
have been relying on a bug that was fixed in 1.0.2, in that the
intermediate CA certs were actually propagated from the context to the
existing SSL object, contrary to what the man page says. I don't
immediately see any relevant change in the OpenSSL commit logs between
1.0.1 and 1.0.2, though.
I think we need to rearrange the code so that we call
SSL_CTX_use_certificate() first, and SSL_new() after that. I wonder if
that's going to break 1.0.1, though.
Setting up a test environment with the required certificates and CAs is
a bit tedious. Would you be interested in adding a test case for this in
the SSL test suite, in src/test/ssl, and posting a patch for that? I can
take a stab at fixing this, but having a test case ready would give me a
head start.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | 自己 | 2016-09-21 08:08:16 | 回复:Re: BUG #14330: can not select into `composite data types` in plpgsql |
Previous Message | Pavel Stehule | 2016-09-21 07:12:33 | Re: BUG #14330: can not select into `composite data types` in plpgsql |