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 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 1 - Subject Alternative Name Configuration:
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 2 - Common Name Does Not Match Short Hostname: 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 3 - Wildcard Common Name Does Not Match Subdomain: The value of CN=*.example.com and the application is connecting using https://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 4 - Common Name Does Not Match Localhost: 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 5 - Common Name Does Not Match IP Address: The value 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.comFail 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:8087Reason: 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.9Success test using curl:
$ curl --cacert certificate.pem https://proxy-nosql.subdomain.example.com:8087Reason: 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:8087Reason: 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.