Skip to content

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:

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.

Note

Connections between VSatellite and TLS Protect Cloud always initiate from VSatellite. TLS Protect Cloud does not establish connections. Therefore, if the connection goes down, it will only be re-established if VSatellite initiates it.

Verifying connectivity to required endpoints

To quickly verify connectivity to the required endpoints, you could use the cURL utility to request headers from each base URL. For example:

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

Note

Changing the IP address on the (physical or virtual) machine where you're hosting VSatellites can also cause the VSatellite to fail. For more information, see the related known issue.

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

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.

The Firefly Configuration in this screenshot 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.

TIP

When in doubt, set up rules for both single and multiple operators.

Issues with getting Okta SSO claims from groups

To troubleshoot this issue: