• Tom Lane's avatar
    Rearrange libpq's SSL initialization to simplify it and make it handle some · 4ed4b6c5
    Tom Lane authored
    additional cases correctly.  The original coding failed to load additional
    (chain) certificates from the client cert file, meaning that indirectly signed
    client certificates didn't work unless one hacked the server's root.crt file
    to include intermediate CAs (not the desired approach).  Another problem was
    that everything got loaded into the shared SSL_context object, which meant
    that concurrent connections trying to use different sslcert settings could
    well fail due to conflicting over the single available slot for a keyed
    certificate.
    
    To fix, get rid of the use of SSL_CTX_set_client_cert_cb(), which is
    deprecated anyway in the OpenSSL documentation, and instead just
    unconditionally load the client cert and private key during connection
    initialization.  This lets us use SSL_CTX_use_certificate_chain_file(),
    which does the right thing with additional certs, and is lots simpler than
    the previous hacking about with BIO-level access.  A small disadvantage is
    that we have to load the primary client cert a second time with
    SSL_use_certificate_file, so that that one ends up in the correct slot
    within the connection's SSL object where it can get paired with the key.
    Given the other overhead of making an SSL connection, that doesn't seem
    worth worrying about.
    
    Per discussion ensuing from bug #5468.
    4ed4b6c5
fe-connect.c 109 KB