After updating the TLS certificate used for Redgate Clone in the Admin Console, the CLI is still refusing to connect. The CLI returns an error message:

ERROR: Authentication failed (FailedAuthentication=20): Get "https://dev-clone.redgate-platform.com:8132/cloning-api/api/v1/data-images": tls: failed to verify certificate: x509: certificate signed by unknown authority

Determine whether the API is serving the certificate correctly

Use an external (online) SSL checker

If:

• your Redgate Clone instance is accessible from the public Internet
• and the configured DNS name is resolvable from the public Internet
• and your security policies allow it

then you can use one of the online SSL check services to analyze the API's SSL responses. This will flag up any issues with the served certificate.

From a desktop environment

From a desktop environment that can connect to Redgate Clone, navigate to https://{address}:{port}/. Use the browser tools to view the certificate of the returned page and check that the certificate contains the expected data fields to match the certificate you have uploaded.

From a terminal

nmap

nmap -p {port} --script ssl-cert {address}

openssl

cat /dev/null | openssl s_client -showcerts {address}:{port} 2>/dev/null | openssl x509 -inform pem -noout -text

Redgate Clone is serving the expected certificate

If Redgate Clone is serving the expected certificate, the client machine (the machine running the CLI) may be configured incorrectly.

When using a self-signed certificate

• Ensure that the certificate is installed on the client machine (see instructions on Self signed certificates here).
• Check that the certificate can be used from the client machine.
  • Run curl -i --cacert rgclone.crt $RGCLONE_API_ENDPOINT/cloning-api/api/v1.0/version to make an HTTP request to the Redgate Clone API using the certificate.
    • If this returns output which starts with HTTP/2 200 , then:
      • Double-check the certificate has been installed correctly into the client machine's trust store (see above).
      • If the client machine is using a proxy trust store, ensure that the proxy is configured to trust the certificate.
    • Otherwise
      • Check that the contents of the rgclone.crt file that you installed is a valid certificate and it matches the certificate exported from Redgate Clone. 
        • The contents of a valid certificate file will look like:
          

          -----BEGIN CERTIFICATE-----
          (multiple lines of base 64 encoded data)
          -----END CERTIFICATE-----

When using a certificate from a certificate provider

• Check the certificate is valid for the instance DNS addressed used by the Redgate Clone cluster.
• Check the certificate provider is trusted by your client machine.

Redgate Clone is serving the previous certificate

1. Ensure the new TLS certificate and key have been correctly deployed as a Config change, please see Configuration
2. Ensure the nginx service has been restarted as detailed in the "Updating Expired / Changing TLS Certificate" of Communications security

Redgate Clone is serving "nginx default certificate"

Check the logs of the nginx service for entries relating to SSL:

kubectl logs -n ingress-nginx services/ingress-nginx-controller | grep backend_ssl

You may see a log entry with the message 

Error obtaining X.509 certificate: unexpected error creating SSL Cert: certificate and private key does not have a matching public key: tls: private key does not match public key

This suggests that nginx cannot load the certificate that has been uploaded.

The following diagnostic commands will need to be performed on the certificate file.

Check that the certificate contains the entire chain

The certificate file must include the server certificate, all intermediate certificates and the root certificate. Display the certificate chain:

openssl crl2pkcs7 -nocrl -certfile {certificate file} | openssl pkcs7 -noout -print_certs

The output should start with a certificate where the subject  is the domain name used to access Redgate Clone. The issuer  of each certificate should equal the subject  of the next certificate. The final certificate should have its issuer equal to its own subject.

If the certificates are in the wrong order, you can modify the certificate file with a text editor. Move the certificate blocks around to match the required order.

If any certificates are missing (e.g.

the root certificate is not present) you will need to request the full chain of certificates from your certificate provider.