![]() I checked the fingerprints of each individual certificate in Path #1 to confirm their identity: # openssl x509 -in 1_wildcard_server.crt -noout -sha256 -fingerprint rw- 1 postgres postgres 2094 Aug 15 00:27 3_root_usertrust-selfsigned.crt rw- 1 postgres postgres 2167 Aug 15 00:27 2_intermediate_sectigo.crt rw- 1 postgres postgres 2313 Aug 15 00:26 1_wildcard_server.crt Instead, clients must have the root certificate of the server'sĪssembling and verifying the certificate chain for Path #1 # ls -l It is not necessary to add the root certificate to server.crt. Doing this avoids the necessity of storing intermediateĬertificates on clients, assuming the root and intermediateĬertificates were created with v3_ca extensions. "intermediate" certificate authorities can also be appended to theįile. The first certificate in server.crt must be the server's certificateīecause it must match the server's private key. I checked the certification paths via ssltest and found that there are two paths available ( Path #1 and Path #2):įrom the documentation on PostgreSQL 9.6 Secure TCP/IP Connections with SSL: Hostssl all all 34.84.31.82/32 password # remote host I don't want to require client certificates, only encryption with a required password. This file was set up to allow only the public IP address of the localhost and the remote host I am testing. #ssl_crl_file = 'root.crl' # commented out - no client certificates #ssl_ca_file = 'root.crt' # commented out - do not require client certs Ssl_key_file = 'server.key' # private key Ssl_cert_file = 'server.crt' # wildcard cert plus intermediate certs Since there was no difference in client behavior, I commented out ssl_ciphers and ssl_prefer_server_ciphers to allow the defaults. ![]() I had tried to limit the set of ciphers to attempt to force TLSv1.2 for all SSL connections. What have I missed that could be causing these remote connections to fail?Īs user postgres: # cd /var/lib/pgsql96/data I must have missed something, since I'm unable to connect remotely via psql or JDBC. Starting from the server key (which hasn't changed since I had remote access working), I have attempted to cover the full series of steps to verify that I have my keys, certificates, firewall and database set up correctly. My goal is to be able to connect to this PostgreSQL database remotely via psql and also via JDBC. After a recent certificate upgrade (Comodo, now Sectigo), I can no longer establish remote psql or JDBC connections to this database over SSL. ![]() This work is licensed under aĬreative Commons Attribution 4.0 International License.I have a PostgreSQL 9.6.11 database on Amazon Linux that has been configured with a 2048-bit SSL wildcard server certificate and password-based (no client certificates) remote connections since January 2012. See Bitbucket’s post for a few more details. You should end up with something like this: Repeat with each server you connect to.Using the details from that message, add a hostfingerprints.Use a Mercurial command such as hg incoming that causes it to wail aboutĪ server’s certificate not being verified.Remove the cacerts line from your hgrc.Maybe this approach will work again in the future, once the wave of reissued certificates has broken, but for now there’s a straightforward solution: ![]() Regenerating the permissions file didn’t help. Which, as dumb as it looks, is the recommended way to enable certificate checking through the system keychain. The culprit turned out to be this line in my ~/.hgrc: Git(hub) seemed to be fine, but any Mercurial commands involving the network - either trying to connect to Bitbucket or Kiln - would fail. I imagine the root cause is the whole OpenSSL mess and everyone reissuing their certificates, but it posed an immediate practical local problem: I couldn’t push to my source control. Gross as it is, the message is straightforward: the SSL certificate failed to verify. Routines:SS元_GET_SERVER_CERTIFICATE:certificate verify failed When I tried to push my last post to Bitbucket I received this ugly error: abort: error: _ssl.c:507: error:14090086:SSL
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |