---
title: "Certificate Requirements"
slug: "certificate-requirements"
updated: 2026-10-16T12:26:57Z
published: 2026-10-16T12:26:57Z
canonical: "help.ipv.com/certificate-requirements"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.ipv.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Certificate Requirements

Certificates are specifically required for the following servers within the Curator System installation:

- The **Server** on which **Curator Server** is installed (to secure API calls to/from Curator Server).
- The **Web Server** on which the **Curator Gateway** web application (and potentially others) is installed, to secure user credential passthrough.

**Important Notes:**

- The certificates must be **installed prior to system installation**.
- They must be **trusted between the servers involved** (the Curator Server host and the IIS server).
- If **Process Engine** is installed on a separate server, it must also include the certificates from both the Curator Server host and the IIS server within its **Trusted Root Certificate Authorities folder**.
- Certificates should match the **FQDNs (Fully Qualified Domain Names)** of the servers used in Curator System configuration.

> *Note:* We **can** work with certificates from a domain **not matching** the server's domain, but this requires referencing the server **as if it were on the same domain as the certificate**, and setting up a corresponding **DNS entry**.

It is **preferable** that certificates are installed in **both the Root folder and Personal folder** of the Certificate Store on the relevant servers.

---

#### Self-Signed Certificates (Can I Use Them with Curator?)

A certificate signed by a **trusted Certificate Authority (CA)** verifies the identity of the certificate holder.

> 🔍 **Clarification:** "Trusted CA" does **not** necessarily mean a **public CA** (like DigiCert, Sectigo, or Let's Encrypt). It simply means the certificate must be signed by an authority that is **trusted by the client machine**. This trust could come from:
> 
> 
> - A **well-known public CA** (pre-installed in most operating systems)
> - Or a **private or customer-created CA** (e.g., a home-grown root certificate) that has been **manually distributed and installed** into the **Trusted Root Certificate Store** on all client systems.

This approach is distinct from a **self-signed certificate**, which is signed by the same entity that owns it (i.e., not by a separate CA, public or private). While self-signed certificates can work for certain **Web Applications** (such as Clip Link and Clip Select), they are **not supported with Curator Connect**.

Use of self-signed certificates may be suitable in the following scenarios:

- No outbound internet access is required
- The environment is **air-gapped**
- No access to a trusted certificate authority (internal or public) is available

In such environments:

- The certificate must be installed as a **trusted certificate** on every system accessing Curator
- This avoids untrusted certificate alerts from browsers or embedded renderers (like Adobe panels)

> ✅ **Recommendation:** Use self-signed certificates **only in isolated or air-gapped systems**. For all other environments, consider using a **public CA** or a **trusted internal CA**, with proper certificate distribution to all clients.