"Failed to verify certificate: x509: certificate signed by unknown authority" when using the CLI
Published 11 June 2024
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 like this:
ERROR: Authentication failed (FailedAuthentication=20): Get "https://<your API endpoint>/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-----
- The contents of a valid certificate file will look like:
- Check that the contents of the
- If this returns output which starts with
- Run
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
- Ensure the new TLS certificate and key have been correctly deployed as a Config change, please see Configuration
- 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.