Troubleshooting¶

Need help solving a perplexing issue? We're listening to you and creating workarounds for troubleshooting the most common issues.

Check back here regularly for new content. If something's missing, please let us know by clicking the Feedback tab (bottom-right side of your screen), and we'll get on it.

If you can't find the answer to your question here, please reach out to Venafi Customer Support.

Certificate discovery¶

For issues with discovering certificates, consider the following.

A certificate hosted in the SNI environment not discovered¶

Because of the nature of SNI virtual hosting, Venafi Control Plane might not find all public certificates hosted in these environments, even after you add a domain to the target list.

To resolve this issue, add the explicit FQDN as a target to the Internet Discovery Service target list.

For additional information, see this Support article.

VSatellites¶

When troubleshooting VSatellites, consider the following troubleshooting tips.

One or more of my VSatellites appear to have lost connection¶

Lost VSatellite connections occur most often because of a network failure between VSatellite and TLS Protect Cloud™. Regardless of the cause, when all VSatellites have lost connection, you cannot deploy a new one.

Try the following methods to troubleshoot disconnected VSatellites:

1. Verify that the machine that's hosting VSatellite is up and running.
2. Verify that there's network connectivity between that VSatellite machine and TLS Protect Cloud:
   • Make sure the VSatellite machine isn't blocked and can make outbound connections to port 443.
   • Verify that the VSatellite is able to reach https://vsat-gw.venafi.cloud:9443
3. If at this point a VSatellite continues to lose connection, uninstall and then reinstall the VSatellite.

`curl -I https://vsat-gw.venafi.cloud:9443`

If your connection is successful, you'll get a 404 error. As strange as that may sound, getting a 404 error confirms that you did connect to the endpoints successfully.

If you don't have cURL, you can install it on Ubuntu using `apt-get install curl` or on RHEL using `yum install curl`.

If you continue to have issues, please contact Venafi Customer Support.

Why isn't the VSatellite installer using the environment variables?¶

When installing VSatellite, if you are using sudo, you might encounter issues where the installer does not use the environment variables (such as http_proxy, https_proxy, no_proxy, VSATELLITE_SERVICE_CIDR, or VSATELLITE_CLUSTER_CIDR). This is because sudo might not preserve your user environment variables when elevating privileges.

To resolve this, do one of the following:

• Switch to the root user before exporting any environment variables using sudo su. Or,
• Use the -E flag with sudo to preserve the user environment variables: sudo -E ./vsatctl install

If you are already operating as the root user, you can proceed without additional steps.

I shut down a VSatellite more than 30 days ago and now it won't start¶

Avoid shutting down any VSatellite for more than 30 days. If a VSatellite is turned back on within this period, it will function normally. However, if a VSatellite remains offline for more than 30 days, it will not be able to rotate its credentials. After 90 days of being offline, the VSatellite will stop functioning, and you'll need to uninstall and reinstall (redeploy) a VSatellite to replace this one.

Can't figure out why my VSatellite isn't working correctly¶

Use the vsatctl tool to collect VSatellite logs for diagnosis. You can review the logs and share them with support, as needed. For the specific vsatctl command reference, see support-bundle.

Firefly¶

Use this section to help you troubleshoot any problems with your Firefly installation. Each section digs into a commonly seen error message found when running Firefly. To use this page you will need to read the logs of your Firefly installation.

Invalid Grant, Verification Error¶

The Firefly logs may show the following error:

{"error":"invalid_grant","error_description":"crypto/ecdsa: verification error"}

This error indicates that the public key that you have configured in the Firefly Service Accounts page doesn't match the private key that is present in the venafi-credentials secret that is stored in Kubernetes.

To fix this issue, copy the public key associated with the private key and paste it into the Public Key text box in the Firefly Service Accounts page.

Client Authentication Method¶

running REST, GraphQL or gRPC server requires control plane configuration to specify client authentication method

This error message appears when there the server field is used in your Firefly configuration, but the Firefly configuration tied to the clientID has its authentication method set to None.

If you are using Kubernetes, you can remove the server field, which will disable the REST, gRPC, and GraphQL endpoints since Kubernetes doesn't need these endpoints.

If you are running Firefly in Docker, make sure to select an authentication other than None to solve the problem.

Single sign-on (SSO) ¶

Multiple Okta SSO claims not working with Teams assignments¶

The most common cause for issues with SSO claims stems from using the team rules operators incorrectly.

To resolve issues, first carefully review these usage guidelines when creating your team membership rules, and then try again.

Issues with getting Okta SSO claims from groups¶

To troubleshoot this issue:

• Carefully review Before you begin in the Okta configuration topic.
• Review Customize tokens returned from Okta with a Groups claim on the okta Developer website.