Identity-First Connectivity™
NetFoundry is built on strong Identity-First Connectivity™ - a security model that leverages certificates as a foundational mechanism to establish identity, enforcing authentication before connection to protect all communications within a network. Apart from the "certificate" based device identity model, NetFoundry also supports human identities via OIDC auth.
Every controller, router, and endpoint in a NetFoundry network is assigned a cryptographic identity - represented by an X.509 certificate. The Root CA issues an intermediate CA for the controlelr which issues the leaf certificates for routers and endpoints.
NetFoundry enforces Identity‑First Connectivity™ using mTLS universally — it is not optional or situational, but the mechanism by which all trust is established across the network. Certificates underpin mutual TLS (mTLS) across both the control plane and the data plane, ensuring that every connection is authenticated and encrypted using keys negotiated via mTLS. This security model applies consistently across all NetFoundry communications, including controllers, routers, endpoints, and application sessions.
NetFoundry certificates are used to:
Uniquely identify controllers, routers, and endpoints
Authenticate every control plane and data plane connections and establish mTLS
This article explains how certificates are issued and renewed within a NetFoundry network, including:
Certificate validity and renewal behavior by NetFoundry component
The NetFoundry / OpenZiti PKI model
Requirements for successful certificate renewal on routers and tunnelers
A reference table summarizing validity, and summary of certificate lifecycles
Known deployment scenarios that may prevent automatic renewal
This information is intended for customers operating NetFoundry Cloud, Hybrid, or supported on-premises deployments.
Terminology
Root CA: The trust anchor of the PKI.
Intermediate CA (Issuer): A subordinate CA used to issue leaf certificates.
Leaf Certificate: Certificates used directly by controllers, routers, and clients.
Ziti PKI: The PKI used by a Ziti network, rooted in the Control Plane Root CA.
Note: The terms Intermediate CA and Issuer are used interchangeably throughout this document.
NetFoundry PKI Model
Single Control Plane PKI
All NetFoundry-supported and OpenZiti-tested configurations use a single PKI, commonly referred to as the Control Plane PKI. This PKI is also referred to as the Ziti PKI for the network.
There is exactly one root of trust in supported deployments.
PKI Components
A typical supported deployment includes:
Control Plane Root
A self-signed Root CA
The root of trust for the entire Ziti network
Edge Enrollment Signer
An Intermediate CA (also called the Issuer)
Used to issue identity and enrollment certificates
Controller Identity Certificates
Client and server leaf certificates
SANs match advertised controller addresses
Alternate Server Certificates
Server leaf certificates (e.g., console, WSS)
SANs do not match advertised controller addresses
Exceptions to the PKI Model
The following configurations may use multiple PKIs (for example, separate “edge” and “web” roots):
NetFoundry unsupported deployments
OpenZiti quickstart environments
Legacy NetFoundry on-premises installations
These configurations are outside the scope of this article and may require custom certificate management procedures.
Certificate Renewal Behavior
Certificate renewal in NetFoundry is designed to be non-disruptive for supported components and configurations.
The table below summarizes certificate validity, renewal timing, and management responsibility for each NetFoundry component.
Note: Intermediate CA and Issuer refer to the same certificate role.
| Attribute | Controller (NF Cloud / Hybrid)Includes Control Plane, Edge, and Web certs from a single PKI | NetFoundry On-Prem Controller | Ziti Router | Ziti Edge Tunnel |
|---|---|---|---|---|
| Root CA Validity | 10 years | 10 years | N/A | N/A |
| Root CA Renewal | Automated** | 30 days | N/A | N/A |
| Root CA Management | Automated** | Automatically renewed by CM and distributed by controller and TM | N/A | N/A |
| Intermediate CA (Issuer) Validity | 10 years | 10 years | N/A | N/A |
| Intermediate CA (Issuer) Renewal | Automated** | 30 days | N/A | N/A |
| Intermediate CA (Issuer) Management | Automated** | Automatically renewed by CM and presented by controller | N/A | N/A |
| Leaf Certificate Validity | Ziti PKI: 10 years Public PKI: 3 months | 10 years | 1 year | 1 year |
| Leaf Certificate Renewal Window | Ziti PKI: 30 daysPublic PKI: 60 days | 30 days | 1 week | 30 days |
| Leaf Certificate Management | Ziti PKI managed by MOP – automated and non-disruptivePublic PKI managed by Let’s Encrypt – automated and non-disruptive | Automatically renewed by CM and presented by controller | Non-disruptive; renewal request initiated by router | C-SDK generates event; T-SDK handles renewal |
** The renewal of the root CA and intermediate CA after the 10 year period would be automated in the upcoming releases. This is under development.
Operational Requirements for Certificate Renewal
Writable Identity Storage (Critical)
For Ziti Routers and Ziti Edge Tunnelers, certificate renewal requires write access to the filesystem location where identity materials are stored.
Write access is required to:
Store renewed client certificates
Regenerate private keys when required
Update the list of clustered controller endpoints
If the identity directory is read-only, automatic renewal will fail and the component will eventually be unable to authenticate.
For read-only tunneler deployments, monitor certificate expiration windows and plan certificate renewal appropriately.