When you start implementing your application, you may face SSL errors such as this one:

"javax.net.ssl.SSLHandshakeException: General SSLEngine problem" .

This error means that the low-level encryption failed and can be caused by a number of reasons, including:

• Handshake cipher negotiation 
  • See details of the ciphers here and some Java requirements.
  • You may need to force the TLS negotiation by explicitly disabling some ciphers. For example with Java you can force this behaviour by setting

    jdk.tls.disabledAlgorithms

Another type of error that can be seen is

"ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify

failed: self signed certificate in certificate chain (_ssl.c:1123)".

This suggest the encryption part of the communication is established but the validation of the certificate failed.

There can be multiple root causes  

• Certificate substitution (re-sign or replace) by a firewall:
  • This is when a corporate firewall insert or re-sign a server side SSL certificate.
  • In some cases this can make the certificate chain invalid (not signed by a known Certificate Authority) 
•  keystore configuration:
  • Access to the key store fails ( access rights, invalid path) due to the language / driver or environment and user
  • The keystore accessed doesn't have the right root CA loaded. 
    • This can happen due to lack of OS patch
    • The keystore found is a custom one and may miss one root certificate to validate the chain  

For encryption between your client application and your AuraDB Instance certificates are used to authenticate the identity of the remote host.

To validate the server side certificate on Aura , your client application needs to validate the SSL chain against the root certificates (from public Certificate Authority) that are stored in your keystore. 
If your java application does not find the keystore to access the root certificates so it can validate the chain of certificates and confirm the connection is secured it will produce an error.

 

This can also be tested with the neo4j+ssc (ssc stands for self-signed certificate ) URI scheme instead of neo4j+s as this would simply skip validation of the certificates and should tell us if that helps us progress.

They can check the configurations for keystore. I think, the java application is not able to read the root certificate of the system and therefore you get the SSL errors.

 

If using Java we can set the path manually -Djavax.net.ssl.keyStore=<<path>>  or by default it will search in the below location.

 $JAVA_HOME/lib/security/jssecacerts
 $JAVA_HOME/lib/security/cacerts

 

You can generate better traces, by setting the additional debug flag and share the logs with us.

Simply ensure you pass the flag to the JVM :
-Djavax.net.debug=all

 

Finally something that can help is to run a standalone tool

• A web based tool to validate the certificates on the Aura end are good: 
  • Go to https://www.sslshopper.com/ssl-checker.html
  • Enter the URI (without the neo4j protocol specifier) for your AuraDB Instance:
    • 35373ca1.databases.neo4j.io
    • Example :
      • AuraDB Instance URI neo4j+s://abcd1234.databases.neo4j.io
      • The hostname to validate is abcd1234.databases.neo4j.io
      • The full URL becomes :
        https://sslshopper.com/ssl-checker.html#hostname=abcd1234.databases.neo4j.io 
• A command line tool for advanced diagnostics
  • openssl to validate and get further traces.
  • Example:

openssl s_client -showcerts -connect d6112ca0.databases.neo4j.io:443
CONNECTED(00000003)
depth=2 C = US, ST = Texas, L = Houston, O = SSL Corporation, CN = SSL.com Root Certification Authority RSA
verify return:1
depth=1 C = US, ST = Texas, L = Houston, O = SSL Corporation, CN = SSL.com RSA SSL subCA
verify return:1
depth=0 CN = neo4j.io
verify return:1
---
Certificate chain
0 s:CN = neo4j.io
i:C = US, ST = Texas, L = Houston, O = SSL Corporation, CN = SSL.com RSA SSL subCA
-----BEGIN CERTIFICATE-----
MIIG2DCCBMCgAwIBAgIQVPy/CGr0+7HqKM+SMYoK1jANBgkqhkiG9w0BAQsFADBp
MQswCQYDVQQGEwJVUzEOMAwGA1UECAwFVGV4YXMxEDAOBgNVBAcMB0hvdXN0b24x
GDAWBgNVBAoMD1NTTCBDb3Jwb3JhdGlvbjEeMBwGA1UEAwwVU1NMLmNvbSBSU0Eg
...
sX4KP0qZRNHvOogmgC86GoePXCqEvEvUxh1V7kdqqKfUxVT3j+Jg9VOwFtMjZaEL
MsQytznYtWIUX4xjeAWjbW5aCX2wWUxCWfDAuw==
-----END CERTIFICATE-----
1 s:C = US, ST = Texas, L = Houston, O = SSL Corporation, CN = SSL.com RSA SSL subCA
i:C = US, ST = Texas, L = Houston, O = SSL Corporation, CN = SSL.com Root Certification Authority RSA
-----BEGIN CERTIFICATE-----
MIIGbzCCBFegAwIBAgIICZftEJ0fB/wwDQYJKoZIhvcNAQELBQAwfDELMAkGA1UE
BhMCVVMxDjAMBgNVBAgMBVRleGFzMRAwDgYDVQQHDAdIb3VzdG9uMRgwFgYDVQQK
...
vnN1/6jEKFJvlUr5/FX04JXeomIjXTI8ciruZ6HIkbtJup1n9Zxvmr9JQcFTsP2c
bRbjaT7JD6MBidAWRCJWClR/5etTZwWwWrRCrzvIHC7WO6rCzwu69a+l7ofCKlWs
y702dmPTKEdEfwhgLx0LxJr/Aw==
-----END CERTIFICATE-----
2 s:C = US, ST = Texas, L = Houston, O = SSL Corporation, CN = SSL.com Root Certification Authority RSA
i:C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA
-----BEGIN CERTIFICATE-----
MIIF2DCCBMCgAwIBAgIRAOQnBJX2jJHW0Ox7SU6k3xwwDQYJKoZIhvcNAQELBQAw
fjELMAkGA1UEBhMCUEwxIjAgBgNVBAoTGVVuaXpldG8gVGVjaG5vbG9naWVzIFMu
QS4xJzAlBgNVBAsTHkNlcnR1bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEiMCAG
...
ftzABne6cC2HLNdoneO6ha1J849ktBUGg5LGl6RAk4ut8WeUtLlaZ1Q8qBvZBc/k
pPmIEgAGiCWF1F7u85NX1oH4LK739VFIq7ZiOnnb7C7yPxRWOsjZy6SiTyWo0Zur
LTAgUAcab/HxlB05g2PoH/1J0OgdRrJGgia9nJ3homhBSFFuevw1lvRU0rwrROVH
13eCpUqrX5czqyQR
-----END CERTIFICATE-----
3 s:C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA
i:C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA
-----BEGIN CERTIFICATE-----
MIIDuzCCAqOgAwIBAgIDBETAMA0GCSqGSIb3DQEBBQUAMH4xCzAJBgNVBAYTAlBM
MSIwIAYDVQQKExlVbml6ZXRvIFRlY2hub2xvZ2llcyBTLkEuMScwJQYDVQQLEx5D
...
03YnnZotBqbJ7DnSq9ufmgsnAjUpsUCV5/nonFWIGUbWtzT1fs45mtk48VH3Tyw=
-----END CERTIFICATE-----
---
Server certificate
subject=CN = neo4j.io

issuer=C = US, ST = Texas, L = Houston, O = SSL Corporation, CN = SSL.com RSA SSL subCA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 6441 bytes and written 399 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 4F548D3B1FD86891A6B0C800459D9E2FA46C9AB366A14B82A93259BD23171A95
Session-ID-ctx: 
Resumption PSK: 458F62AA653A1020F1717DD07F4644AACB7D6F3C2D5B27F62A3AC4CE5928E0D291D971782F6CB104E8F178E38F65F1C7
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - f3 a3 bd 91 72 64 6e e4-8b 38 f1 e2 f6 86 fd 2e ....rdn..8......
0010 - 63 95 32 95 08 e3 e3 d4-93 31 19 b1 cc 96 bf c8 c.2......1......

Start Time: 1629736594
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: BC5BDB2431F9378945F6424F0EC9073949FB15EAE349B7A54A865FDDC28CFC83
Session-ID-ctx: 
Resumption PSK: 593264944811DAF18D1DCA4731D7A1F091EC3EABCD7F4895AC9231BCFA02F254460AD3BF9AEB2E51B178935C6B677E01
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - a0 98 b7 b5 b5 a0 1f 90-c0 c3 dd cf 2e bb 56 44 ..............VD
0010 - 25 2e 4a 36 97 e5 7f ef-ba a1 43 c9 c8 07 78 17 %.J6......C...x.

Start Time: 1629736594
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
^C