When a FreeIPA sub-CA fits VPN, Wi-Fi and device certificates
A FreeIPA sub-CA is a lightweight certificate authority subordinate to the main ipa CA, and it can be limited to specific profiles and principals and disabled as a group. When a team needs certificates for VPN concentrators, Wi-Fi access or a managed device fleet, a sub-CA lets that population be issued, tracked and withdrawn without touching the certificates that protect the web interface and internal services. By default, the Dogtag certificate system inside FreeIPA runs a single ipa CA that signs everything the domain issues, including host, service and user certificates. Every additional certificate class added to that one CA widens the blast radius of a mistake, a compromised profile or a wrongly granted request.
Splitting issuance is usually a decision for the identity or PKI owner, not the team that operates the VPN or the wireless controller. The people who own the security architecture should decide which certificate classes deserve their own signing boundary, what each boundary may sign and who may request certificates from it. The network team should then confirm what its equipment needs in terms of certificate format, extensions, chain delivery and revocation checking. A useful first exercise is an inventory of every certificate population the organization plans to issue, with its validity period, expected volume, revocation expectations and owner. If that inventory is thin, a sub-CA is probably premature.
Whether a sub-CA fits your environment depends on your device platforms, your RADIUS or VPN software, your revocation workflow and the FreeIPA version you run. Sub-CA creation, the commands and options for scoping them, and the way disabling one affects issued certificates all vary by release, so confirm the exact behavior against the FreeIPA documentation for your version before you design around it. Treat the rest of this page as a map of the decisions involved rather than a substitute for that check.
Choosing between the ipa CA, a sub-CA and a separate CA
This table compares three ways to issue VPN, Wi-Fi and device certificates: the main ipa CA, a FreeIPA sub-CA per use case, and a CA outside FreeIPA. Read each row against your own revocation and audit needs, and treat the last row as the deciding factor for most teams.
| Decision factor | Main ipa CA with profiles and CA ACLs | FreeIPA sub-CA per use case | Separate CA outside FreeIPA |
|---|---|---|---|
| What it isolates | Little beyond profiles and ACLs; all certificates share one CA signing key and one trust chain | Signing key and trust chain per use case, so one sub-CA's compromise or disablement does not touch the others | Full separation of keys, software and administrators from the FreeIPA estate |
| Operating cost | Lowest: no extra CA objects, but profile and ACL reviews grow with each certificate type | Moderate: each sub-CA needs its own naming, ACLs, profiles and renewal checks during audits | Highest: a second PKI, its own hardware or software, staff, backups and renewal process |
| Revocation | Revoke individual certificates; the ipa CA publishes the CRL, so revocation stays inside one PKI | Revoke individual certificates, or disable the sub-CA to invalidate every certificate it issued | Handled by the separate CA's own revocation and CRL process, which you must integrate with network access checks |
| Disabling a group of certificates | Requires revoking each certificate one by one | Disabling the sub-CA invalidates its certificate group as a unit; confirm how each RADIUS or VPN server checks status | Done by the external CA, but Wi-Fi and VPN endpoints must be configured to honor its revocation data |
| Limiting what the CA can sign | Achieved with certificate profiles and CA ACLs, which apply to all requesters | Achieved by creating the sub-CA with a restricted scope and attaching ACLs to it | Enforced by the external CA's own policy, outside FreeIPA's ACL model |
| Audit evidence | One CA and one set of ACL records to review | Separate CA records and ACLs per use case, which adds review effort but clarifies scope | Evidence lives in the external system, so the assessor needs both sets of records |
| Fits when | A small number of certificate types, one owner and a single trust domain | Several distinct use cases, such as VPN and Wi-Fi, that need separate revocation control | Device or Wi-Fi certificates must sit under a hardened PKI or policy that FreeIPA cannot meet |
| Confirm before choosing | Whether ACLs and profiles cover every requester and certificate type you plan to issue | Which sub-CA scopes your RADIUS, VPN and MDM systems can check and how they handle a disabled CA | Who will operate the external CA, how its revocation reaches your network devices, and who signs off on policy |
How to scope a sub-CA for each use case
A sub-CA for VPN gateways should issue only server certificates for the gateways and, if your design uses them, client certificates for remote users in a separate sub-CA. Keep the server and client roles apart so that a compromise or retirement of one group does not invalidate the other. Decide early whether the gateway certificate needs the server authentication usage only, and confirm with your VPN vendor which extended key usages and subject alternative names its gateway checks during the TLS handshake.
- Signing scope: Restrict the sub-CA to the gateway hostnames or the CA ACL groups that request gateway certificates, so no other service can obtain a certificate from it.
- Profile and validity: Use a custom profile with the server authentication usage and the gateway names in the SAN. Choose a validity period that matches your renewal process, and confirm with the vendor any maximum lifetime the gateway accepts.
- Client trust: Install the sub-CA chain on each gateway and on any client that validates it. Confirm whether the client OS or VPN agent reads the chain from the system store or from a bundled file.
- Revocation path: Confirm how the gateway checks revocation (CRL or OCSP) and whether it can reach the CRL distribution point from its network zone.
- Test: Connect from managed and unmanaged clients, rotate a gateway certificate, and disable the sub-CA in a lab to observe the gateway's behavior.
Before go-live, check that the gateway rejects a certificate issued from a sub-CA that is not in its trust list.
For 802.1X Wi-Fi, the sub-CA usually issues the RADIUS server certificate and, in certificate-based designs, the device or user client certificates. The RADIUS server certificate is the one most often misconfigured, because every supplicant must trust it. Keep the RADIUS server certificate in a sub-CA dedicated to network infrastructure so that its trust path is small and easy to explain to device management teams.
- Signing scope: Limit the sub-CA to RADIUS server hostnames and, separately, to device identities if you enroll client certificates from it. Do not let the same sub-CA sign both unless you have a reason to share the trust.
- Profile and validity: Use a server profile for RADIUS with the server authentication usage and the names your supplicants expect. Confirm the EAP method's requirements for certificate type and key usage with your RADIUS server documentation.
- Client trust: Push the sub-CA root or chain to devices through your MDM or directory policy, and pin the expected server name in the supplicant profile where your platform allows it.
- Revocation path: Confirm whether your RADIUS server and supplicants check revocation, and how an offline device would learn about a revoked certificate.
- Test: Authenticate a test device on each supplicant platform in your fleet, renew the RADIUS certificate, and verify that a device with a certificate from another sub-CA is refused.
Plan the renewal window for the RADIUS certificate so that the replacement can reach every supplicant before the old one expires.
Device and user certificates identify individuals or managed endpoints, so their sub-CA carries the highest sensitivity in the group. Scope it to a narrow set of templates and principals, and separate user certificates from device certificates when the trust, lifetime and revocation needs differ. Decide who approves enrollment and how departed staff or lost devices are removed from the trust path.
- Signing scope: Use CA ACLs to limit which groups or hosts may request certificates from this sub-CA, and deny the broad default groups.
- Profile and validity: Create a profile for the client usage you need, such as client authentication, and keep validity short enough that a stale certificate does not outlive the employment or device lifecycle. Confirm the lifetime your identity provider and endpoint management tools accept.
- Client trust: Deliver the chain to managed devices only, and document how unmanaged devices are handled, since they may never receive the chain.
- Revocation path: Define the process for lost devices and departed staff, including whether you disable the whole sub-CA (which affects every certificate it issued) or revoke individual certificates.
- Test: Enroll a test user and device, revoke one certificate, confirm the service rejects it, and confirm that other certificates from the same sub-CA still work.
A practical test is to list every certificate the sub-CA issued and confirm each one maps to a known owner or device.
What disabling a FreeIPA sub-CA does and does not do
Disabling a FreeIPA sub-CA stops that CA from issuing new certificates, and that is the lever you use to end trust in the scope it covered. It does not, by itself, tell every relying service to reject the certificates it already signed. Those certificates remain cryptographically valid until they expire or are revoked, so the outcome depends on what each service checks. Before you disable a sub-CA for a VPN, Wi-Fi or device group, confirm three things: whether the VPN gateway, RADIUS server or EAP-TLS endpoint validates the chain back to the ipa CA and then consults revocation, whether the service caches revocation data, and how long it tolerates an unreachable CRL.
Revocation is a separate step from disabling. Revoking individual certificates through the ipa CA writes them into the certificate revocation list, and the CRL is published from the first server in your topology, the one that handles renewal and CRL publication by default. Check which server holds that role before an incident, because a stale or unreachable CRL distribution point means revoked certificates may still work. The backup documentation also warns that restoring an outdated backup into an active replica topology can break replication, so a recovery that rolls back CA state must be planned with the same care as the revocation itself. Rehearse both paths in a test environment rather than discovering the answer during an incident.
If a relying service does not check revocation, or checks it only sporadically, disabling the sub-CA gives you no guarantee for certificates already in circulation. In that case you must either shorten validity for the sub-CA's future certificates, rely on the service's own allow-list or identity mapping to refuse the group, or remove access at the service layer. Write this into the runbook as an explicit decision for each service, and record who owns it. The sub-CA control is strongest when every consumer enforces revocation and the CRL is reachable from every network segment that needs it.
Creating and scoping a FreeIPA sub-CA step by step
This sequence takes a FreeIPA sub-CA from a healthy, backed-up ipa CA to a tested certificate chain on a relying service, with each step confirmed before the next begins. The result is a sub-CA that can sign only the profiles and principals you intended.
Confirm ipa CA health and backups
Before changing anything, the FreeIPA administrator checks that the ipa CA is running on the expected servers, that certificate tracking shows no pending renewals or expired certificates, and that a recent full backup exists. Backups are taken with ipa-backup, and the backup documentation warns that the first server handles certificate renewal and CRL publication by default, so confirm which server is the renewal master. The step is done when the CA status reports healthy on every server and the backup is verified as restorable in a test location.
Decide the sub-CA name and scope
Write down the purpose of the sub-CA (for example, VPN, Wi-Fi or device certificates), the certificate profiles it will sign with, the principals or host groups allowed to request from it, and the validity period your policy requires. Name the sub-CA so an auditor can tell its purpose from the name alone. Illustrative example: a sub-CA named for VPN clients that may use only one client profile. The step is done when this scope sheet is approved by the people who own the relying services and the identity policy.
Create the sub-CA under the ipa CA
Using the ipa command-line tools, the administrator creates the lightweight sub-CA as a subordinate of the ipa CA, following the exact syntax in the FreeIPA documentation for the installed version. Check the version first, because command options differ between releases. The step is done when the new sub-CA appears in the CA list with the expected name, parent and enabled state, and when the ipa CA itself still reports its original status.
Restrict profiles and principals with CA ACLs
Create CA ACL rules that tie the new sub-CA to the approved certificate profiles and to the principals or host groups allowed to request from it. Do not rely on the sub-CA being new to limit its use, since existing rules may grant broader access. Review any admin bypass permission for the sub-CA. The step is done when a request from a principal outside the ACL is refused, and a request from an approved principal with an approved profile succeeds.
Issue a test certificate to a pilot client
Choose one enrolled pilot client that matches the approved scope, generate a key and request, and issue a certificate from the sub-CA using the approved profile. Keep the test certificate's subject and extensions consistent with the scope sheet. The step is done when the certificate is issued, shows the sub-CA as issuer, and carries the profile's key usage and validity values as documented for your version.
Verify the chain on the relying service
Install the sub-CA certificate chain on the relying service, such as the VPN concentrator, Wi-Fi controller or device management system, and confirm that it trusts the chain up to the ipa CA. Then present the pilot certificate and confirm that the handshake or authentication succeeds. Also test a certificate issued from a non-permitted request path to confirm the service rejects it when it should. The step is done when the service accepts the pilot certificate and records the expected issuer.
Record the scope and schedule the review
Store the scope sheet, the CA ACL definitions, the test results and the chain location in your change records, and add the sub-CA to the certificate inventory so renewal and revocation procedures cover it. Ask your FreeIPA support provider or the FreeIPA documentation for the revocation and disable procedure for the sub-CA before production use. The step is done when the records name an owner for the sub-CA and the inventory lists it with its parent CA.
Security and operational risks of sub-CA design
A sub-CA narrows what a certificate authority can sign, but it also creates new places where keys, permissions and backups can fail. The cards below pair each risk with the control to put in place before issuing from a sub-CA, so the design holds up under review.
Blast radius of a sub-CA key
A compromised sub-CA signing key lets an attacker mint certificates for every profile and identity that sub-CA is allowed to issue. Before go-live, confirm which principals and profiles the sub-CA covers and keep that scope as small as the use case allows. Record who can reach the sub-CA key material and how it is stored, because the damage is limited to what that one key can sign.
Over-broad CA ACLs
CA ACLs decide which profiles, principals and issuing CAs a request may use. A rule that is too wide can let a sub-CA sign certificates for services it was never meant to cover, such as internal web hosts when it was created for VPN clients. Review each ACL against the intended device or user group, and test a request that should fail to confirm the rule denies it.
Administrator bypass permissions
Administrators with the permission to bypass CA ACLs can request certificates outside the rules that govern everyone else. This can quietly defeat the sub-CA scope. Identify which accounts hold that permission, keep the group small, and review its membership on the same schedule as other privileged access. Ask whether any automation account holds it without a documented reason.
Revocation checking by relying services
Disabling a sub-CA invalidates the certificates it issued only if the services that accept them check revocation. A VPN concentrator, Wi-Fi controller or application that ignores CRLs or OCSP status will keep trusting those certificates. Before relying on sub-CA disablement as a control, confirm with each relying system's vendor how it checks revocation and what happens when it cannot reach the publication point.
Backups must include sub-CA data
A backup that omits sub-CA configuration, certificates and keys can restore a CA that cannot sign or revoke the certificates it issued. The FreeIPA backup documentation describes full and data-only backups, and restoring an outdated backup into an active replica topology can break replication. Test a restore into an isolated environment and confirm that sub-CA records appear in the restored deployment.
First server handles renewal and CRL
By default, the first server in a FreeIPA topology handles certificate renewal and CRL publication for the CA, including sub-CAs. If that server fails or is retired without reassigning the role, renewals and revocation updates stop quietly. Confirm which server holds the renewal and CRL role, monitor its health, and document the steps to move the role before you decommission it.
Limits to confirm before you rely on sub-CAs
Before you commit to sub-CAs, confirm the FreeIPA version in your environment and compare it with the release you plan to run. The release notes for FreeIPA 4.13.0 introduced random certificate serial numbers by default, so check whether your version issues them and whether your sub-CA issuance, profiles and any tooling that tracks serial numbers behave as your design assumes. Confirm the same for the latest 4.13.x stabilization release you intend to deploy, since security fixes can change authentication behavior. Ask your vendor or test lab to reproduce issuance on the exact version, not on a development build.
Next, confirm that your relying products accept the chain. Test whether your VPN concentrator, Wi-Fi controller and RADIUS server trust the sub-CA certificate as an intermediate, whether they need the full chain delivered during the TLS handshake, and whether they check revocation through CRLs or OCSP. Check how each product handles a certificate that was revoked by disabling the sub-CA, because some products cache trust or revocation data for long periods. Also confirm how renewal of the sub-CA certificate is handled: who renews it, on which server, how long relying systems keep the old chain, and whether you must push a new trust anchor to every device.
Finally, confirm how CA data replicates across your server topology. Identify which server acts as the renewal master and which servers hold CA signing material, then verify that a sub-CA created on one replica appears consistently on the others. Ask whether disabling a sub-CA on one server propagates to every replica before you rely on it as a revocation control, and test that propagation directly. Review the backup guidance for restoring an outdated backup into an active topology, because CA state is part of what can diverge. Record your findings in a written test plan so the design rests on observed behavior in your environment.
Questions buyers ask about FreeIPA sub-CA work
What does FreeIPA sub-CA work cost and what drives the price up?
Cost depends on the written scope, not on a list price, and DeployOpen does not publish one. The main cost components are the design of the sub-CA hierarchy and its signing limits, the configuration on the FreeIPA side, the work on each relying system that must trust the new chain, testing, and the documented revocation and disable process. The biggest drivers are the number of relying systems (VPN concentrators, Wi-Fi controllers, MDM and device fleets), how many certificate profiles and identity groups each sub-CA needs, and whether revocation must be tested end to end. Ask any vendor for a quote that lists each component separately, states which items are one-time and which recur (such as certificate renewal checks and periodic reviews), and names what the client must supply.
How long does a sub-CA rollout take?
The timeline is set by the number of relying systems, the change windows you can use, and how many trust stores must be updated. Design and approval of the signing limits usually take longer than the FreeIPA commands themselves. Plan for a test phase against a non-production client, a pilot group of devices or users, and then staged rollout to production systems. Each relying system with its own trust store or certificate handling adds steps. Ask for the timeline as a list of milestones tied to your change calendar, and confirm which parts depend on your internal approvals, not on the implementer.
What must our team provide before a sub-CA project starts?
Expect to provide administrative access to the FreeIPA servers and to the relying systems that will trust the sub-CA, along with change windows for production work. You also need a test client that matches a real device or VPN endpoint, and a named owner for each relying service who can approve configuration changes and testing. Finally, provide the list of certificate types, identity groups and expected lifetimes, and the process your organization uses to report lost devices or departed staff. Missing any of these is a common cause of delay, so confirm each item in writing before the scope is agreed.
Can our own staff set up a FreeIPA sub-CA without outside help?
Yes, if your team already runs FreeIPA and understands the Dogtag CA, certificate profiles and CA ACLs. The work involves creating a subordinate CA, restricting what it can sign, distributing its chain to relying systems and documenting how to disable it. Teams without recent PKI experience tend to make mistakes in the signing limits and in revocation testing, because errors there are only visible during an incident. A partner can plan the design, implement it in a test environment, and hand over runbooks, so your staff can operate it afterward. Decide which parts your team will own before you start.
How is a sub-CA project different from issuing a single service certificate?
Issuing a service certificate gives one host a certificate from an existing CA, with a key, a signing request and automatic renewal. A sub-CA is a new certificate authority that signs many end-entity certificates and must itself be trusted by every system that accepts them. That means changing trust stores on relying systems, deciding what the sub-CA may sign, and defining how a whole group of certificates is invalidated by disabling it. The design and testing effort is therefore larger, and it touches the security policy of each service that relies on the sub-CA.
What should we check in revocation before we sign off?
Confirm that revoking one certificate and disabling the whole sub-CA both produce the results you expect on every relying system. Check how quickly each service picks up the revocation information, whether the CRL is published where those services can reach it, and what happens to devices that stay offline. Also confirm which team can disable the sub-CA, how that action is logged, and how you would reissue certificates afterward. Ask the implementer to show these tests in a non-production environment, and to document the steps in a runbook your operations team can follow.
Does DeployOpen issue audit reports or certifications for a sub-CA design?
No. DeployOpen plans, implements, tests and documents the sub-CA setup and prepares evidence such as configuration records, ACL settings and test results. Independent auditors and certification bodies issue any audit report or attestation. If your assessment requires specific controls, agree with your auditor in advance which evidence they expect, and include producing that evidence in the written scope.
How DeployOpen scopes and delivers sub-CA work
DeployOpen plans, implements, documents and supports FreeIPA lightweight sub-CAs inside your own infrastructure, so the sub-CA design fits your identity, device and certificate policies. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- The written scope names each sub-CA, the certificate types it signs and the systems that will trust it.
- We record which profiles and CA ACLs each sub-CA may use, and who may request certificates from it.
- The scope states what is out of bounds, such as issuing from the root ipa CA or changing existing trust chains.
How we build
- We create the sub-CAs on the FreeIPA servers you control and test issuance against a non-production realm first.
- We configure restricted profiles and ACLs, then verify that each sub-CA can sign only its intended certificate types.
- We test disabling a sub-CA in a lab and confirm the effect on certificates it issued before any production use.
How we hand over
- You receive documentation of each sub-CA's purpose, signing scope, profiles, ACLs and owners.
- Runbooks cover issuing, renewing, disabling and revoking certificates, with the steps your operators will repeat.
- Knowledge transfer sessions walk your team through backup steps before and after sub-CA changes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Retainer work can cover reviews of sub-CA ACLs and profiles as your VPN, Wi-Fi or device policies change.
- Ask us to confirm how your FreeIPA release and sub-CA configuration will be checked before each upgrade window.
