Troubleshooting
Table of Contents
Expand all | Collapse all
-
- Activate Next-Generation Trust Security
-
-
- Configure Akamai Connection
- Configure AWS Connection
- Configure Azure Key Vault Connection
-
- Workload Identity Federation Authentication
- Workload Identity Federation - Azure Identity Provider Authentication
- Next-Gen Trust Security Generated Key Authentication
- User Permissions
- Workload Identity Federation Authentication
- Next-Gen Trust Security Generated Key Authentication
- User Permissions
- Supported OIDC Claims
-
-
-
- Working with the Built-in CA
- Add AWS Public CA
- Add AWS Private CA
- Add DigiCert One Certificate Authority
- Add Entrust
- Add GlobalSign Atlas
- Add GlobalSign MSSL
- Add GoDaddy
- Add Google Cloud Private CA
- Add a HID PKIaaS CA
- Add Certificate Manager - Self-Hosted
- Set Up an OpenSSL Certificate Authority Connector
- Create a Sectigo Certificate Manager Certificate Authority
- Add Zero Touch PKI
- Set Up Certificate Expiration Notifications
- Using a Custom DNS Provider
-
-
-
-
- Create an F5 BIG-IP LTM Machine
- Create a Microsoft Azure Private Key Vault Machine
- Create a Microsoft Azure Application Registration Machine
- Create a Microsoft IIS Machine
- Create a Microsoft Windows (PowerShell) Machine
- Create a Microsoft SQL Server Machine
- Create a Common KeyStore Machine
- Create a Citrix ADC Machine
- Create an Imperva WAF Machine
- Create a VMware NSX Advanced Load Balancer (AVI) Machine
- Create an A10 Thunder ADC Machine
- Create a Cloudflare Machine
- Create Kemp Virtual LoadMaster Machine
- Create a Palo Alto Panorama Machine
- Create a Radware Alteon Machine
-
- Provision to an F5 BIG-IP LTM
- Provision to a Microsoft Azure Private Key Vault
- Provision to Microsoft IIS
- Provision to Microsoft Windows (PowerShell)
- Provision to Microsoft SQL Server
- Provision to a Common KeyStore
- Provision to a Citrix ADC
- Provision to an Imperva WAF
- Provision to VMware NSX Advanced Load Balancer (AVI)
- Provision to an A10 Thunder ADC
- Provision to Cloudflare
- Provision to a Kemp Virtual LoadMaster
- Provision to Palo Alto Panorama
- Provision Certificates to Radware Alteon
-
-
- 47-Day Validity Readiness TLS Certificates dashboard
- About the Certificate Inventory
- Managing Certificate Lifecycle Settings
- Reissuing Certificates in Next-Gen Trust Security
- Downloading Certificates, Certificate Chains, and Keystores
- Retiring, Recovering, and Deleting Certificates
- Finding Certificates in the Certificate Inventory
- Importing Certificates from a CA Using EJBCA
- Domain-Based Validation for External Emails
-
- Create a Workload Identity Management or Discovery Agent Built-in Account
- Create an OCI Registry Built-in Account
- Create a Certificate Manager - Self-Hosted Built-in Account
- Create a Scanafi Built-in Account
- Toggling a Built-in Account on or Off
- Editing Built-in Accounts
- Deleting Existing Built-in Accounts
- Renew Existing Built-in Accounts
- Troubleshooting
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 CyberArk 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, Next-Gen Trust Security 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 Next-Gen Trust Security.
Try the following methods to troubleshoot disconnected VSatellites:
- Check to see if the VSatellite service is experiencing an outage by visiting VSatellite Service Status.
- Verify that the machine that's hosting VSatellite is up and running.
- Verify that there's network connectivity between that VSatellite machine and Next-Gen Trust Security:
- 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:443
Note: If your VSatellite was installed prior to 21 March 2025, it continues to make outbound connections on port 9443.
Note: Connections between VSatellite and Next-Gen Trust Security always initiate from VSatellite. Next-Gen Trust Security never initiates connections. If the connection drops, it is reestablished only when VSatellite initiates it again.
Verifying Connectivity to Required Endpoints
To quickly verify connectivity, use the curl utility to request headers from the base URL. For example:
curl -I https://vsat-gw.venafi.cloud:443
Note: When 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.
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.
Warning: However, do not proceed to redeploy if the dysfunctional VSatellite is your only VSatellite. Learn more
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 vsatctl support-bundle.
Can I Recover Lost VSatellites?
You can use the VSatellite Recovery wizard to recover lost VSatellites in either of the following situations:
- Disaster recovery, when all of your VSatellites are lost and you need to manually restore trust using a backed-up DEK.
- Node reinstallation, when one or more VSatellites are lost but at least one VSatellite remains active.