Previous Next JavaScript must be enabled to correctly display this content

## 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 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 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`.