System requirements for Trust Protection Foundation components
Before installing and using any CyberArk product, carefully review CyberArk's supported operating system and hardware configurations.
Also, review any additional or special requirements specified in the documentation provided with each product.
CyberArk Trust Protection Foundation components
Supported Software and Hardware Configurations
Hardware requirements
| Feature | Requirement |
|---|---|
|
Processor |
4 processing cores |
|
Memory |
16 GB RAM |
|
Disk Space (for the Trust Protection Foundation application) |
5 GB The Trust Protection Foundation application can be installed on a secondary partition. |
Number of Trust Protection Foundation servers needed
| Feature | Requirement | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Number of Trust Protection Foundation servers (Up to 50K active certificates, 1K SSH servers, and 175 code signing requests per second*) |
2 total (assuming all in-use features are enabled on both servers) |
||||||||||||||||||
|
Number of Trust Protection Foundation servers (Up to 250K or more active certificates and 5K SSH servers) |
6 total
|
||||||||||||||||||
|
Number of Trust Protection Foundation servers (Up to 1M or more active certificates and 20K SSH servers) |
Implementations of this size are professionally designed by CyberArk according to the customer's needs. |
||||||||||||||||||
|
Server Agents doing SSH work |
2 additional CyberArk servers for every 20,000 SSH servers being managed |
||||||||||||||||||
|
Server Agents doing certificate work |
2 additional CyberArk servers for every 40,000 servers being managed |
||||||||||||||||||
|
Network latency to database |
For best performance results, you should minimize the network latency between the database server and the CyberArk Trust Protection Foundation - Self-Hosted servers. For comparison, we compared the following at various latency levels:
While these speeds are not guaranteed, they are illustrative of the significant impact latency can have on overall system performance.
|
||||||||||||||||||
| Network latency to HSM |
For best performance, minimize the latency between your HSM and your CyberArk Trust Protection Foundation - Self-Hosted servers. These numbers are from a configuration using two CyberArk Trust Protection Foundation - Self-Hosted servers configured with the minimum hardware requirements. They represent a mix of ECC and RSA keys and were derived using the Code Sign Manager - Self-Hosted HSM REST API. Results may vary if you are using other mechanisms. While these speeds are not guaranteed, they are illustrative of the impact latency can have on system performance. Your HSM performance will affect your final result.
|
* Total number of signing request per second using a variety of ECC and RSA keys on an HSM, and using the HSM REST API to sign.
Server Configuration requirements
| Feature | Requirement |
|---|---|
Trust Protection Foundation only supports English Language Installation Media from Microsoft. While it does support region setting configurations to ensure that date and times appear correctly, the Windows servers on which you install Trust Protection Foundation must be derived from Windows English installation media. |
|
| Microsoft runtime library | Install the Microsoft Edge WebView2 Evergreen runtime library to render embedded web content before installing or upgrading CyberArk Trust Protection Foundation - Self-Hosted. Download from Microsoft. |
Regarding job scheduling and timezones, there is a potential issue with timezone support on different Windows Server versions. Newer Windows Server versions may have updated timezones that older versions cannot parse correctly. This could lead to scheduling issues. It is recommended to have consistent OS versions across Trust Protection Foundation servers.
Multiple servers connected using the same database are referred to as a cluster. To help you understand how your cluster is connected together, and to facilitate communication between servers in the cluster, CyberArk Trust Protection Foundation - Self-Hosted provides a feature called Message Bus, which uses an MQTT broker to maintain near-immediate connection between all servers in the cluster. CyberArk Trust Protection Foundation - Self-Hosted includes its own MQTT broker which allows the servers in the cluster to communicate in mesh mode. You can also use a separate external MQTT broker to allow your servers to communicate via the MQTT broker (hub-and-spoke mode). For details on how to use Message Bus, see Message Bus.
If you have three or more Trust Protection Foundation servers, some servers may not require the features in the following table, which lists additional server requirements and roles only for those Trust Protection Foundation servers that support inbound web services. For more information, see Enable web services on required servers.
| Feature | Requirement |
|---|---|
|
Install the following required Microsoft Internet Information (IIS) web server roles:
|
|
|
Windows Server Roles (Web Server\Application Development\.NET Extensibility) |
Microsoft Windows 2025 Server
Microsoft Windows 2022 Server
Microsoft Windows 2019 Server
Microsoft Windows 2016
|
|
Microsoft runtime libraries |
You need to install both the following Visual C++ Runtime libraries: For more information, see the following from Microsoft: Latest supported Visual C++ Redistributable downloads |
| Windows service dependencies |
The following services should not be disabled:
|
|
IIS 7.5 Add-On |
Microsoft URL Rewrite Module 2.1 |
|
.NET Framework (CyberArk web services enabled) |
.NET Framework 4.8 is required for all OS versions. Download .NET Framework 4.8 from https://dotnet.microsoft.com/download/dotnet-framework/net48. |
| Port 80 Binding Requirements |
If you are using SCEP (Simple Certificate Enrollment Protocol), you must allow port 80 binding. SCEP will not work without port 80 binding. Additionally, the timestamping service requires port 80. If access to port 80 is blocked, the Time Stamp Service endpoints in Code Sign Manager - Self-Hosted will not be able to get timestamping data. If you are not using SCEP, and you don't care about access to the Time Stamp Service Endpoints, you can disable access on Port 80. |
TIP You can save valuable time in assessing and installing system prerequisites by running the Prereq Check Script and the Base Configuration Utility available at https://community.cyberark.com/marketplace/. After signing in, expand PS Utilities and download the following:
Supported Databases
Trust Protection Foundation requires a database to store system configuration information, archive certificates and private keys, and secure sensitive data.
Common requirements (on-premises or cloud-based databases)
For specifics about setting up a cloud instance using a supported cloud provider, see Cloud hosting using Amazon RDS, Azure SQL managed Instance, or Google Cloud SQL.
BEST PRACTICE CyberArk recommends having enough drive space available on the SQL server to restore an entire copy of the database if required for recovery or troubleshooting. During a critical problem resolution, if the need arises to restore an older copy of the database for comparison or data recovery, it is a best practice to ensure that it is possible to have the current and previous databases available simultaneously.
| Feature | Description |
|---|---|
|
Supported platforms |
The database should not be installed on the Trust Protection Foundation server except in test environments. SQL AlwaysON Availability Groups are supported for Disaster Recovery and High Availability. Unless otherwise specified, all updates, patches, and service packs (SPs) for the Microsoft SQL Server versions (in English only) listed below are supported by CyberArk Trust Protection Foundation. If an SP is specified below, it represents the minimum SP required for the given SQL version. If you use a cloud server for Trust Protection Foundation, you should use it for both the database and the CyberArk Trust Protection Foundation - Self-Hosted servers. We do not recommend splitting between a cloud provider and on-prem. CyberArk typically releases major Trust Protection Foundation software updates every six months. Microsoft releases new SPs and patches for its SQL Server versions regularly. Releases rarely occur at the same time. CyberArkrecommends that you keep your SQL Server version updated with the latest SPs and patches from Microsoft. Supported:
For more information, see the SQL Server installation guide. IMPORTANT Currently CyberArk Trust Protection Foundation - Self-Hosted is only supported on English installations of Microsoft SQL Server. |
|
Database recovery model requirements |
For databases containing Trust Protection Foundation data, we strongly recommend using the FULL recovery model in MSSQL. This model ensures that all transactions are fully recorded in the transaction log file, preserving the log sequence for database restore operations. Unlike the SIMPLE recovery model, the FULL recovery model supports point-in-time restore, page restore, and file restore. The SIMPLE recovery model, while easier to manage, is not loss-less and does not support transaction log backups. This could lead to data loss, which is unacceptable for databases containing TPP data. For more information on the benefits of each model, please refer to Microsoft’s documentation on SQL Server Recovery Models. |
|
Minimum weekly rebuild of table indexes
The performance of index operations online is the major benefit of using MS SQL Enterprise edition rather than Standard edition. With Standard edition, you can only rebuild and reorganize indexes (a recommended weekly manual task) by taking your database server offline, resulting in an outage of CyberArk Trust Protection Foundation - Self-Hosted. Enterprise edition allows CyberArk Trust Protection Foundation - Self-Hosted to perform these maintenance tasks automatically and in the background with the service remaining active. For help choose the best edition for you, see Which edition of Microsoft SQL Server should I use? |
Cloud hosting using Amazon RDS, Azure SQL managed Instance, or Google Cloud SQL
If you want to host CyberArk Trust Protection Foundation - Self-Hosted in a cloud data center, you can pick between Amazon RDS, Azure SQL Managed Instance, or Google Cloud SQL. Support for these cloud providers is described in the following table.
IMPORTANT If you use a cloud server for Trust Protection Foundation, you should use it for both the database and the CyberArk Trust Protection Foundation - Self-Hosted servers. We do not recommend splitting between a cloud provider and on-prem.
NOTE Azure SQL Single Database and Azure SQL Elastic pool products are not compatible with CyberArk Trust Protection Foundation - Self-Hosted. Additionally Azure SQL Managed Instance does NOT support Azure Active Directory authentication for Trust Protection Foundation.
In the table below, values are given for specific levels, showing you the minimum system requirements based on the bigger of how many active certificates and SSH keys you have.
- Level 1: Minimum requirements for up to 50k active certificates and 1k SSH servers
- Level 2: Minimum requirements for up to 250k active certificates and 5k SSH servers
- Level 3: Minimum requirements for up to 1M active certificates and 20k SSH servers
For example, if you have 40,000 active certificates and 3,000 SSH servers, you would need to meet the Level 2 requirements since the number of SSH servers exceeds the level 1 allowance.
Locally Hosted MSSQL Requirements
In the table below, values are given for specific levels, showing you the minimum system requirements based on the bigger of how many active certificates and SSH keys you have.
- Level 1: Minimum requirements for up to 50k active certificates and 1k SSH servers
- Level 2: Minimum requirements for up to 250k active certificates and 5k SSH servers
- Level 3: Minimum requirements for up to 1M active certificates and 20k SSH servers
EXAMPLE If you have 40,000 active certificates and 3,000 SSH servers, you would need to meet Level 2 requirements since the number of SSH servers exceeds the level 1 allowance.
Supported HSMs
CyberArk Trust Protection Foundation supports integrations with Hardware Security Modules (HSMs) to encrypt private keys, credentials, and other secrets stored in the database. You can also use the HSM integration for the central generation of private keys when you also have Advanced Key Protect. If either of these use cases apply to you, use the following tables to see what HSMs are supported and which HSMs have been self-certified from their vendors as being compatible.
IMPORTANT CyberArk recommends you consult the partner documentation for minimum supported versions.
TIP The following tables show vendor support for generating private keys. In all cases, this refers to Hardware Central Key Generation. Learn more about Supported methods of key generation.
|
Supported HSM |
Docs |
Encrypt Secrets |
HCKG for private keys1 |
Code Signing Certificate Private Key Storage2 |
|---|---|---|---|---|
|
Entrust nShield Connect HSM |
Partner PDF |
|
|
|
|
Thales SafeNet Luna SA (including Azure Dedicated HSM) |
Partner Docs |
|
|
|
Vendor Self-Certified HSMs
NOTE The HSM Partners on the list below have gone through the process of self-certification. This process involves testing the specific PKCS#11 mechanisms that Trust Protection Foundation uses when an HSM is used to protect things like private keys and credential objects, and when Advanced Key Protect is enabled.
Self- certification means that the partner has done the testing and proven successful results and integration with CyberArk. Successful self-certification results indicate that the integration will work as expected. The HSM vendor may need to be engaged if something is working unexpectedly. Consult the partner's documentation to know what firmware version requirement is.
|
HSM Vendor HSM Product |
Docs |
Encrypt Secrets |
HCKG for private keys3 |
Code Signing Certificate Private Key Storage4 |
|---|---|---|---|---|
|
Atos Trustway Proteccio |
PDF (no public link; contact vendor) |
|
|
|
| AWS CloudHSM | CyberArk Docs |
|
|
|
|
Crypto4A QxEDGE |
|
|
|
|
|
Entrust Entrust nShield as a Service |
Partner Docs |
|
|
|
|
Fortanix Fortanix DSM |
Partner Docs |
|
|
|
|
FutureX Vectra Plus |
Partner Docs |
|
|
|
|
Gradiant KeyConnect |
|
|||
|
Securosys Primus HSM and Cloud HSM Service |
Partner Docs (Login required) |
|
|
|
|
Thales TCT T-Series Luna |
Partner Docs |
|
|
|
|
Thales Data Protection on Demand |
Partner Docs |
|
|
|
|
Utimaco CryptoServer |
Partner Docs (Login required) |
|
|
|
Port and network access
Port requirements
Depending on your environment, Trust Protection Foundation can use the following ports:
|
Port |
Description |
|---|---|
|
Default Port Assignments |
|
|
80 |
While CyberArk Trust Protection Foundation - Self-Hosted provides several methods of ensuring encryption of traffic, Port 80 binding is ONLY required if you are using SCEP or the Time Stamp Service endpoints, as these features require http access to the internet to function correctly. If you are not using SCEP, and you don't care if the Time Stamp Service endpoints in Code Sign Manager - Self-Hosted can get time stamping data, you can disable Port 80 binding in IIS. All other CyberArk web services will continue to function if access to port 80 is blocked. |
|
443 |
Hyper Text Transfer Protocol Secure (HTTPS) should be enabled if Policy Tree is secured with a certificate. |
|
50443 |
This port is used by Trust Protection Foundation to handle certificate requests via Enrollment Over Secure Transport (EST) protocol. Allow this port only on servers which will handle such requests. |
| 8883 | This is the IANA-assigned port for encrypted (TLS) MQTT connections between servers in the cluster using the Message Bus feature. By default, Message Bus uses this encrypted port. If you opt for unencrypted communication, the IANA-assigned port is 1883. |
|
Operational Port Assignments |
|
|
135 |
Trust Protection Foundation communicates with the Microsoft Certificate Services and the server hosting Internet Information Services over DCOM. The default DCOM port is 135 (dynamic port range 49152-65535). Trust Protection Foundation contacts the IIS application on port 135; however, the application returns its response on a different port. This can pose a problem in a firewall environment. For information on configuring DCOM with firewalls, see the following Microsoft Technical Document: http://support.microsoft.com/kb/154596. |
|
21 |
Port 21 can be used for sending reports via the FTP protocol. Reports can also be sent using the SMB protocol (port 445). |
|
22 |
Trust Protection Foundation uses the Secure Shell protocol (SSH) to communicate with servers and appliances. The default SSH port is 22. SCP and SFTP run as subsystems of SSH on port 22. Trust Protection Foundation supports Open SSH and Tectia SSH versions 4 and 5.3.x. |
|
25, 587 |
Trust Protection Foundation uses the Simple Message Transfer Protocol (SMTP) to communicate with a configured email server to send email notifications. The default SMTP port is 25. |
|
161 |
Trust Protection Foundation uses the Simple Network Management Protocol (SNMP) channel to send selected events to an SNMP management system via an SNMP trap. |
|
445 |
Port 445 can be used for sending reports via the SMB protocol. Reports can also be sent using the FTP protocol (port 21). |
|
514 |
The CyberArk Log server can send log messages to a syslog server. By default, the Syslog channel uses UDP port 514, but an administrator may configure an alternate port in the Syslog channel configuration. The Log server can also use TLS for sending Syslog messages, if configured. For more information, see About syslog channels. |
|
Default Database Ports |
|
|
1433 |
For more information on running the Trust Protection Foundation database on a Microsoft SQL system, see Setting up your Microsoft SQL database server. |
Network access requirements
Platform requirements
There are a number of systems that require network access to be enabled for Trust Protection Foundation to run.
- All Trust Protection Foundation servers need access to the database server
- If using an HSM to (1) encrypt private keys, credentials, and other secrets stored in the CyberArk database, or (2) for the central generation or storage of private keys, all Trust Protection Foundation servers need access to the HSM.
- If using an identity provider, like Active Directory or LDAP, all Trust Protection Foundation servers need network access to the identity infrastructure.
- Each Trust Protection Foundation server that has the Event Processing component enabled must have access to the configured logging channels. For example, email server, syslog, SMTP, etc.
- For each Trust Protection Foundation server that has a web service enabled (e.g. UI consoles, Web SDK, Agent service, etc.), all clients that are connecting to the service must have network access to the Trust Protection Foundation server, either directly or through a proxy.
Feature-specific requirements
Most features in Trust Protection Foundation can be configured to only use a subset of servers to use that feature. For example, when integrating with a certificate authority, the Trust Protection Foundation server(s) integrated with that certificate authority need network access to connect to that certificate authority, but other servers in your cluster would not need that access.
There are three ways you can control what Trust Protection Foundation servers need access:
- Processing engines. For more information see Management Zones.
- Network discovery zones. For more information see Configuring discovery zones.
- Turning off the associated component on a specific server's CyberArk Configuration Console. For more information see Trust Protection Foundation components.
Most product features have a Network Access component for the feature. We recommend you review what features you plan to use, as well as which Trust Protection Foundation server(s) will be responsible for these features, and configure network access accordingly.
VTrust Protection Foundation MMC Snap-In Collection
The CyberArk Configuration Console is built upon the Microsoft Management Console (MMC) Framework. Some of the nodes, such as the Events and the Code Signing are snap-ins that are available to be installed on other Windows servers and workstations, even if they are not setup to be CyberArk servers. If you plan leverage this functionality, it can only be installed on Windows systems that meet the following requirements:
- .NET 4.7.2
- Windows 8.1 or later or Windows Server 2016 or later
Code Signing Workstation Clients
-
Windows
-
.NET Framework 4.8
-
Windows 10 or later
-
Windows Server 2016 or later
-
-
Linux versions tested by CyberArk
-
Debian 9 and later
-
Ubuntu 16.04 and later
-
CentOS Stream 8 and later
-
Red Hat Enterprise Linux (RHEL) 7 and later
-
-
macOS
-
Monterey 12 and later
-
Server Agent
CyberArk Server Agent
Unless otherwise specified, all updates, patches, editions, and service packs (SPs) for a listed operating system version are supported. The 64-bit architecture is supported across most platforms (see below). IPv6 is supported on all operating systems.
NOTE CyberArk typically releases major software updates twice a year. Operating system vendors release new SPs and patches regularly. Releases rarely occur at the same time.
Supported Operating Systems
-
Microsoft Windows 10, Microsoft Windows 11, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 (64-bit only), Windows Server 2022, and Windows Server 2025.
Before installing the Server Agent, verify that target systems use one of the supported x86-64 operating systems as noted above.
-
All supported versions of Windows Server require the Visual C++ Redistributable package. You can download the latest version of the redistributable package from the official Microsoft website at learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist.
-
The Server Agent requires .NET 4.8 or later on all Windows versions.
-
- AIX 7.1 (PPC) and AIX 7.2 (PPC)
- Solaris 10 (SPARC), and Solaris 11 (SPARC)
- Red Hat Enterprise Linux (RHEL) 6, RHEL 7, RHEL 8, and RHEL 9 (64-bit only)
- Community Enterprise Operating System (CentOS) 6, CentOS 7, and CentOS 8 (64-bit only)
- SUSE Linux Enterprise Server versions 11 and 12 (64-bit only)
Compatible Keystores
For information about compatible keystores for certificate installation, see Server Agent-supported keystores.
Disk Space Requirements
200 MB free disk space (150 MB for agent and 50 MB to store results waiting to be returned to the Trust Protection Foundation server).
Certificate Authority Drivers
Certificate Authority integrations are a required component of the Certificate Manager - Self-Hosted and Code Sign Manager - Self-Hosted products for any level of automation beyond discovery and expiration monitoring. Verify that your current Certificate Authorities are on the list of supported integrations below. If not, they may be supported by a third party through our Adaptable Framework.
Supported Enterprise Certificate Authorities
The following internal CA drivers are supported on the past four versions of Trust Protection Foundation:
-
Adaptable CA
Includes a reference sample of DigiCert PKI Platform (Magnum).
- Microsoft Standalone CA
- Microsoft Enterprise CA (ADCS)
- OpenSSL
- OpenTrust Enterprise PKI
- RedHat Certificate System
- RSA Certificate Manager
- DigiCert PKI Platform
TIP For a complete list of supported version numbers, see
Supported Public Trust Certificate Authorities
The following external CA drivers are supported on the past four versions of Trust Protection Foundation and all include an API interface and are cloud-based hosting platforms:
- Amazon Certificate Manager (ACM)
- Sectigo Certificate Manager (SCM)
- DigiCert CertCentral
- Entrust Certificate Services
- GlobalSign MSSL
- HID PKIaaS
- QuoVadis
- Symantec Managed PKI for SSL
- VikingCloud
TIP For a complete list of supported version numbers, see
Supported Code Sign Manager - Self-Hosted Certificate Authorities
-
Adaptable CA
-
DigiCert
-
Entrust Certificate Service
-
Microsoft CA
-
Microsoft CA Pool
-
Out-of-band
-
Sectigo
-
Self-signed
Provisioning (Certificate Installation) Drivers
Agentless Provisioning drivers support the automatic installation of TLS certificates to their host systems and are a feature of Certificate Manager - Self-Hosted that require a Trust Force™ license for each endpoint you install to. Below is a list of natively supported integrations with certificate keystores, applications, cloud services, and enterprise appliances. If your application is not listed, it does not necessarily mean that automatic installation cannot be achieved. For example, provisioning to a Tomcat web server is possible using the Java Keystore driver. Other integrations are possible using the Adaptable Framework through third parties and the CyberArk Marketplace. Review the list of what drivers you plan to use as part of your deployment.
Supported Keystores and Applications for Provisioning (Certificate Installation)
The following provisioning drivers are supported on the past five versions of Trust Protection Foundation, except where noted:
-
Adaptable Application
- Apache/PEM (OpenSSL)
- IBM Global Security Kit (GSK)
- Java Keystore (JKS and JCEKS)
- Microsoft CAPI
- Microsoft IIS
- Network Security Services (Oracle iPlanet)
-
PKCS#12
See About CSR-supported formats for more information.
TIP For a complete list of supported version numbers, see
NOTE For a list of supported keystores to which you can provision using the Server Agent, see Server Agent-supported keystores.
Supported Appliances
The following appliance drivers are supported on Trust Protection Foundation:
- Amazon Web Services IAM/ELB/CloudFront
- Apache
- Azure Key Vault (Microsoft)
- CAPI (IIS 7+)
- Citrix NetScaler MPX (with HSM)
- Citrix NetScaler VPX
- F5 Big-IP F5 LTM Advanced
- Google Cloud Load Balancer (external proxies only)
- HashiCorp Vault PKI
- IBM GSK
- IBM Sterling Connect:Direct
- IBM WebSphere DataPower
- Imperva MX (doesn't support file validation)
- iPlanet
- JKS
- Palo Alto Networks Next Generation Firewall
- PEM
- Riverbed SteelHead WAN Optimizer
- Tealeaf PCA (Passive Capture Appliance)
TIP For a complete list of supported version numbers, see
Supported browsers and supported vendors, products, and versions
Supported and Compatible Web Browsers
| Status | Browser |
|---|---|
|
Supported |
Microsoft Edge (Chromium, latest version) and Google Chrome (latest version) |
|
Compatible |
Firefox 78 ESR |
Monitor Resolution
Minimum supported monitor resolution requirement: 1280 x 1024.
Supported Vendors, Products, and Versions
Click a column heading to sort by vendors, products, versions, or types of integrations.
| Vendor | Supported Products | Supported Versions* | Integration Types |
|---|---|---|---|
|
Amazon |
Amazon Certificate Manager (ACM) |
|
Certificate Authority |
|
Amazon |
ACM, IAM, ALB, ELB, CloudFront |
Cloud Service |
|
|
Apache |
HTTP Server | 2.2 and 2.4 | Application |
| Bouncy Castle | Clients using BC bcpkix library | 1.64 | Certificate Enrollment via EST Protocol |
| Cisco | IOS | 15.7(3)M3 | Certificate Enrollment via EST Protocol |
| Cisco | libest (Client) | 1.1.0 | Certificate Enrollment via EST Protocol |
|
Citrix |
NetScaler VPX |
14.1, 13.1 build 42.47, 13.0 build 58.32 |
Network Appliance |
|
Citrix |
v13.0 build 58.32 |
Network Appliance | |
| CyberArk | Enterprise Password Vault | 12, 14.2 | Credential Provider |
|
Dell |
iDRAC 8 (using RACADM 8.3)** |
2.41.40.40 firmware |
IoT |
|
DigiCert |
DigiCert CertCentral |
NA |
Certificate Authority |
|
Entrust |
Entrust Certificate Services |
NA |
Certificate Authority |
|
Entrust nShield |
Entrust nShield Connect HSM |
12.40.2 (client; minimum version) |
Hardware Security Module |
|
F5 |
Big-IP Local Traffic Manager (LTM) / Application Delivery Controller (ADC) |
15.1.9.1 build 0.0.5, |
Network Appliance |
|
GlobalSign |
GlobalSign MSSL |
NA |
Certificate Authority |
|
Hewlet-Packard (HP) |
iLO 4 (using HPQLOCFG 1.5)** |
2.50 firmware |
IoT |
|
HID PKIaaS |
HID PKIaaS |
NA |
Certificate Authority |
|
IBM |
6.0x, 6.1x, 6.2x, 6.3x, 6.4x for Windows and 6.0x, 6.1x, 6.2x, 6.3x, 6.4x for UNIX |
Application |
|
|
IBM |
10.5.0, 10.6.0 |
Network Appliance |
|
| IBM |
7.0.3.15, 7.0.4.20 (gsk7cmd, gsk7capicmd & iKeyMan); 8.0.14.34 (gsk8capicmd) |
Keystore | |
| Imperva | MX | 13.6 | Appliance |
|
Microsoft |
Enterprise or Standalone CA running on Windows Server 2003-2012, 2016, 2019, and 2022 |
Certificate Authority |
|
|
Microsoft |
Internet Information Services (IIS) |
8.0, 8.5, 10.0.1607, and 10.0.1809 |
Application |
|
Microsoft |
Key Vault, Web App |
Cloud Service |
|
| Microsoft |
Windows Server 2012, 2012 R2, 2016, and 2019 |
Keystore |
|
| Mozilla |
Network Security Services (NSS) For more information, visit https://en.wikipedia.org/wiki/Network_Security_Services. |
3.x | Keystore |
|
OpenSSL |
OpenSSL CA |
1.0.0, 3.0.0 |
Certificate Authority |
|
OpenSSL |
NA |
Keystore |
|
|
OpenTrust |
Enterprise PKI |
4.7.1 |
Certificate Authority |
|
Oracle |
Sun Java System Web Server / Oracle iPlanet Web Server For more information, visit https://en.wikipedia.org/wiki/Oracle_iPlanet_Web_Server. |
6.1, 7.0 |
Application |
| Oracle | Java Keystore (JKS and JCEKS) | 1.6, 1.7, 1.8 |
Keystore |
|
Palo Alto Networks |
Next Gen Firewall | 10.2.7+, 11.1.x+, and 11.2 | Appliance |
|
QuoVadis |
QuoVadis |
NA |
Certificate Authority |
|
RedHat |
Red Hat Certificate System |
8.1 |
Certificate Authority |
|
Riverbed |
VCX555H 9.0.0b |
Appliance |
|
|
RSA Security |
RSA Certificate Manager |
6.8 and 6.9 |
Certificate Authority |
| RSA Security | PKCS#12 | NA | Keystore |
|
Sectigo |
Sectigo Certificate Manager (CCM) |
NA |
Certificate Authority |
|
Symantec |
Symantec Managed PKI for SSL |
NA |
Certificate Authority |
|
Symantec |
DigiCert PKI Platform*** |
NA |
Certificate Authority |
| Thales | estclient | 1.0.1 | Certificate Enrollment via EST Protocol |
|
Thales |
SafeNet Luna SA |
6.22 (client) |
Hardware Security Module |
|
VikingCloud |
VikingCloud |
NA |
Certificate Authority |
* CyberArk Labs has tested these versions. Other versions might be compatible but are not supported by CyberArk.
** For Dell iDRAC and HP iLO, refer to the Adaptable Application driver reference samples. See Adaptable Application .
*** DigiCert PKI Platform is provided as a supported reference sample for the Adaptable CA driver. See Adaptable CA.