Troubleshooting issues with self-signed certificate

After you create a self-signed certificate and try to connect to the Oracle NoSQL Database Proxy, sometimes the connection fails.

Table G-1 Connection failure scenarios and fixes

Value of CN	Client Connection URL	Result of the connection
CN=localhost	https://localhost:8089	Connection successful
CN=proxy-nosql.example.com	https://proxy-nosql.example.com:8089	Connection successful
CN=*.example.com	https://proxy-nosql.example.com:8089	Connection successful
CN=proxy-nosql	https://proxy-nosql:808	Connection successful
CN=proxy-nosql.example.com	https://proxy-nosql:8089	Connection fails
CN=proxy-nosql.example.com	https://10.0.0.9:8089	Connection fails
CN=localhost	https://10.0.0.9:8089	Connection fails
CN=localhost	https://proxy-nosql:8089	Connection fails
CN=localhost	https://proxy-nosql.example.com:8089	Connection fails
CN=proxy-nosql	https://proxy-nosql.example.com:8089	Connection fails
CN=*.example.com	https://proxy-nosql.subdomain.example.com:8089	Connection fails

General Guidelines in avoiding connection failure errors:

When a client tries to connect to the Oracle NoSQL Database Proxy it fetches the SSL certificate and compares the NoSQL Database proxy server hostname or NoSQL Database proxy server domain name. it wants to connect with the Common Name (CN) provided in the SSL certificate. If they are exactly the same it will use the SSL certificate to encrypt the connection, otherwise, the connection fails.
When the connections fails, determine if you need to change the CN or add a SAN and regenerate the certificate.
Example:
```
 CN=proxy-nosql.example.com
subjectAltName=DNS:proxy-nosql,DNS:localhost,IP:10.0.0.9,DNS:proxy-alias.example.com
```

Sample error scenarios with solution:

Example 1 : The value of CN=proxy-nosql.example.com and the application is connecting using https://proxy-nosql:8089 and the connection fails.

The reason for connection failure is that the hostnames are not the same. You can implement one of the following solutions:

The client connection URL can be modified to https://proxy-nosql.example.com:8089
You can change the CN in the certificate as CN=proxy-nosql
You can add proxy-nosql as SAN subjectAltName=DNS:proxy-nosql

Example 2 : The value of CN=*.example.com and the application is connecting usinghttps://proxy-nosql.subdomain.example.com:8089 and the connection fails.

The reason for connection failure is that domain names are not the same. You can implement one of the following solutions:

You can change the CN in the certificate as CN=*.subdomain.example.com
You can add subdomain.example.com SAN subjectAltName=DNS:*.subdomain.example.com

Example 3: The value of CN=proxy-nosql.example.com and the application is connecting using https://localhost:8089 and the connection fails.

The reason for connection failure is that the hostnames are not the same. You can implement one of the following solutions:

The client connection URL can be modified to https://proxy-nosql.example.com:8089
You can change the CN in the certificate as CN=localhost
You can add localhost as SAN subjectAltName=DNS:localhost

Example 4: The vale of CN=proxy-nosql.example.com and the application is connecting using https://10.0.0.9:8089 and the connection fails

The reason for connection failure is that you are trying to use an IP to do the connection. You can implement one of the following solutions:

The client connection URL can be modified to https://proxy-nosql.example.com:8089
You can add the IP as SAN subjectAltName=IP:10.0.0.9

Simple commands to test if the connection would be successful :

You can use simple curl commands to simulate the connection and validate your configuration.

Use case 1: View the certificate only CN:

$ openssl x509 -text -noout -in certificate.pem | grep CN
Issuer: C=US, ST=CA, L=San,CN=proxy-nosql/emailAddress=localhost@oraclevcn.com
Subject: C=US, ST=CA, L=San, CN=proxy-nosql/emailAddress=localhost@oraclevcn.com

Fail test using curl:

$ curl --cacert certificate.pem https://node1-nosql.example.com:8087
curl: (51) Unable to communicate securely with peer: requested domain name does
not match the server's certificate.

Reason: The address in the url node1-nosql.example.com doesn't match with CN=proxy-nosql in the certificate. And there is no SAN.

Success test using curl:

$ curl --cacert certificate.pem https://proxy-nosql:8087

Reason: The address in the url matches with CN=proxynosql in the certificate

Use case 2: Viewing the certificate CN and SAN

$ openssl x509 -text -noout -in
certificate.pem | grep CN   
Issuer: CN=*.example.com  
Subject: CN=*.example.com

$ openssl x509 -text -noout -in certificate.pem | grep -e DNS -e IP
  DNS:proxy-nosql,  DNS:*.subdomain.example.com, IP Address:10.0.0.9

Success test using curl:

$ curl --cacert certificate.pem https://proxy-nosql.subdomain.example.com:8087

Reason: Even if the address in the url proxy-nosql.subdomain.example.com doesn't match with CN=*.example.com in the certificate, it matches with the SAN in the certificate subjectAltName=DNS:*.subdomain.example.com.

$ curl --cacert certificate.pem https://proxy-nosql:8087

Reason: Even if the address in the url proxy-nosql doesn't match with CN=*.example.com in the certificate, it matches with the SAN in the certificate subjectAltName=DNS:proxy-nosql.