On 18.09.2018 18:27, Dave Cramer wrote:
The only server cert known to me that is needed to the client is the root.crt (the ca cert) of the server used to sign the client cert.
These three files are all that is needed to the odbc driver, to the native navicat dll connection, and to any other certs-based ssl connection such as openvpn.
Actually the jdbc code is not complaining about the certs (if I remove any of them it will complain), something is going wrong during the ssl handshake that I cannot understand.
Is there any way to log more stuff on the server postgres.log about the ssl handshake?
I'm sure there is but I don't know how. The server is not my domain.
Try connecting with psql. If you can connect with that then JDBC should be able to connect.
Hi to all,
IMO it will be better to inspect the SSL/TLS handshake at the client - the machine that is initiating the connection to the PostgreSQL server through the JDBC driver.
Here are some links with the basic stuff about debugging the SSL/TLS connections with the JVM:
- https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https - this is an introduction document. It points to the following two pages. The first is describing what debug tools are available and the second shows how to read the debug output:
- https://access.redhat.com/solutions/973783 - same as the above but in Q&A style
I've used the debug output once - I've needed to investigate why communication with test HTTPS endpoint is working from a browser but not from a Java 8 program. After nearly one day of looking at the connection logs the problem turned out to be in the certificate chain - the browser was happy with the intermediate certificates, but the JVM was not.
Best regards,
zloster