Обсуждение: SSL and USER_CERT_FILE round 2
Adding "sslkey" and "sslcert" to the PQconnectdb connection string. After some discussion, I think it is more appropriate to add the key/cert file for SSL into the connect string. For example: PQconnectdb("host=foo dbname=bar sslmode=require sslkey=/opt/myapp/share/keys/client.key sslcert=/opt/myapp/share/keys/client.crt"); Any comments?
pgsql@mohawksoft.com wrote: > Adding "sslkey" and "sslcert" to the PQconnectdb connection string. > > After some discussion, I think it is more appropriate to add the key/cert > file for SSL into the connect string. For example: > > PQconnectdb("host=foo dbname=bar sslmode=require > sslkey=/opt/myapp/share/keys/client.key > sslcert=/opt/myapp/share/keys/client.crt"); > > > Any comments? > > I think if you're going to provide for these then you should also provide for the CA cert and CRL. Otherwise, it seems sensible. cheers andrew
> > > pgsql@mohawksoft.com wrote: >> Adding "sslkey" and "sslcert" to the PQconnectdb connection string. >> >> After some discussion, I think it is more appropriate to add the >> key/cert >> file for SSL into the connect string. For example: >> >> PQconnectdb("host=foo dbname=bar sslmode=require >> sslkey=/opt/myapp/share/keys/client.key >> sslcert=/opt/myapp/share/keys/client.crt"); >> >> >> Any comments? >> >> > > I think if you're going to provide for these then you should also > provide for the CA cert and CRL. > > Otherwise, it seems sensible. I thought about that, but the root and crl are for the server, and that makes sense that the keys would be in the server directory. The server needs to protect its data against clients wishing to connect. The client on the other hand, needs to access one or more postgresql servers. It makes sense that the server keys and credentials be hard coded to its protected data directory, while the client needs the ability to have multiple keys. Think of it this way, a specific lock only takes one key while a person needs to carry multiple keys on a ring.
pgsql@mohawksoft.com wrote: >> >> I think if you're going to provide for these then you should also >> provide for the CA cert and CRL. >> >> Otherwise, it seems sensible. >> > > I thought about that, but the root and crl are for the server, and that > makes sense that the keys would be in the server directory. The server > needs to protect its data against clients wishing to connect. The client > on the other hand, needs to access one or more postgresql servers. > > It makes sense that the server keys and credentials be hard coded to its > protected data directory, while the client needs the ability to have > multiple keys. > > Think of it this way, a specific lock only takes one key while a person > needs to carry multiple keys on a ring. > This is completely wrong. Why do you think your web browser has CA keys embedded in it? So it can know which server keys to trust. As documented, if a CA certificate set is present on the libpq client, the client will only trust server keys signed with a chain starting from that set. CA certificates and CRLs can in general be used on both sides of an SSL connection, and we make explicit provision for them on both sides. See http://www.postgresql.org/docs/current/static/libpq-ssl.html cheers andrew