![razorsql postgresql ssl certificate razorsql postgresql ssl certificate](https://d2908q01vomqb2.cloudfront.net/887309d048beef83ad3eabf2a79a64a389ab1c9f/2020/08/18/AuroraPostgreSQL-Visual-Studio10.png)
- #Razorsql postgresql ssl certificate upgrade#
- #Razorsql postgresql ssl certificate full#
- #Razorsql postgresql ssl certificate password#
- #Razorsql postgresql ssl certificate plus#
# openssl x509 -in 3_root_usertrust-selfsigned.crt -text # openssl x509 -in 2_intermediate_sectigo.crt -text SHA256 Fingerprint=E7:93:C9:B0:2F:D8:AA:13:E2:1C:31:22:8A:CC:B0:81:19:64:3B:74:9C:89:89:64:B1:74:6D:46:C3:D4:CB:D2Īnd also examined the text versions of the certificates to confirm that the intermediate and root certificates have the v3_ca extension (the wildcard server certificate does not have this extension): # openssl x509 -in 1_wildcard_server.crt -text # openssl x509 -in 3_root_usertrust-selfsigned.crt -noout -sha256 -fingerprint # openssl x509 -in 2_intermediate_sectigo.crt -noout -sha256 -fingerprint 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
![razorsql postgresql ssl certificate razorsql postgresql ssl certificate](https://i.stack.imgur.com/UM4Zh.png)
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:
#Razorsql postgresql ssl certificate password#
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
#Razorsql postgresql ssl certificate plus#
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.
#Razorsql postgresql ssl certificate full#
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.
![razorsql postgresql ssl certificate razorsql postgresql ssl certificate](https://www.milesweb.in/hosting-faqs/wp-content/uploads/2018/06/add-new-endpoint-min.png)
My goal is to be able to connect to this PostgreSQL database remotely via psql and also via JDBC.
#Razorsql postgresql ssl certificate upgrade#
After a recent certificate upgrade (Comodo, now Sectigo), I can no longer establish remote psql or JDBC connections to this database over SSL. 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.