Taranac under your corporate root

Most organisations that run 802.1X already have a PKI: an Active Directory Certificate Services (AD CS) hierarchy or another corporate root that every managed laptop, phone and switch trusts. Taranac’s Internal CA can sit under that root. Your corporate CA signs a subordinate CA (a SubCA) for Taranac. Taranac then issues server, user and device certificates from it, and everything that already trusts the corporate root trusts them as well, with nothing new to distribute.

This page covers that setup end to end: getting the SubCA in (import it, or have Taranac generate the key and a CSR), what Taranac does with the issuing chain above it, the CRLs of that chain, expiry alerts, renewing the SubCA with its own key, and replacing its chain. The CA itself is an ordinary Internal CA once it is in. Issuing, revoking and its own CRL work as described on PKI & trust.

internal ca · issuing chain

certificate EAP-TLS trustchain handed outserver.pem ┌ Corp Root CA self-signed · external – ✓ – └ Corp Issuing CA external – ✓ ✓ └ Taranac SubCA Internal CA ✓ ✓ ✓ └ NAC server cert issued here – – ✓

EAP-TLS verifies clients against the Taranac CA alone the root stays out of server.pem

Term	What it means in Taranac
External issuer	The CA that signed an Internal CA’s certificate is outside Taranac. The PKI tree shows such a CA with the badge External issuer: and the issuer’s name.
Issuing chain	Every certificate above the Internal CA, up to and including the self-signed corporate root. Stored with the CA, in its own field, separate from the CA’s certificate.
CA certificate field	The CA’s own certificate, exactly one. Whatever is in it is an EAP-TLS trust anchor.
CA request	A key and a CSR for a CA certificate, generated in Taranac and Awaiting signature by your corporate CA. Completing it creates the Internal CA.
Renewal CSR	A CSR built from an existing externally signed CA’s stored key and subject, for your CA to sign again.
Upper-chain CRL	The CRL that a certificate of the issuing chain signs: the revocation list for what sits directly below it.

The issuing chain is handed out wherever a chain is needed, so that a device verifying a certificate from the SubCA can walk it to the corporate root:

• EST /cacerts and SCEP GetCACert (see EST enrollment and SCEP enrollment);
• issued-certificate downloads: PKCS#12, and PEM with the chain;
• the CA certificate through the API with include_chain=true (GET /api/v1/nac/pki/cas/{ca_id}/cert). Download CA certificate (PEM) in the PKI tree gives the CA’s own certificate only;
• the TACACS+ client-CA bundle (see TACACS+ over TLS);
• NAC and TACACS+ server certificates issued from the CA, or from any Internal CA below it;
• Internal CAs you create under it, which inherit the chain through their parent.

The chain never joins EAP-TLS trust. FreeRADIUS verifies client certificates against the Internal CA’s own certificate alone. This is deliberate. If the corporate root were an EAP-TLS trust anchor, every certificate the corporate PKI has ever issued (every domain laptop, every user certificate from another issuing CA) would pass EAP-TLS. If you do want clients of another corporate issuing CA to authenticate, add that CA as a Trusted CA or on an LDAP configuration’s EAP-TLS tab, where it is a decision you can see.

The NAC server certificate’s server.pem is the server certificate followed by its intermediates: the SubCA and every corporate CA above it, with the root left out. A supplicant that trusts the corporate root can therefore verify the RADIUS server without having any intermediate installed. The chain is taken from the CA as it is at deploy time, and a node rewrites it within 30 seconds when the CA is renewed or its chain is replaced. See The server certificate.

	Import	Request (CSR)
Where the key is generated	Elsewhere: you already hold the SubCA’s key and certificate	In Taranac. The key never leaves it
What you paste	The CA certificate, its private key, the issuing chain	Nothing at first. Later, the signed certificate and the issuing chain
When to use it	A SubCA that already exists, or a policy that keys must be generated on your own hardware	A new SubCA for Taranac. The usual choice

Both end in the same Internal CA. Taranac stores the chain, fills each chain certificate’s CRL URL from the distribution point of the certificate below it, and signs the CA’s first CRL.

1. On Settings → PKI / Certificates (/nac/settings/pki), click Import above the CA tree.
2. Set CA Type to Intermediate CA and Issuer to External CA (issuing chain).
3. Paste the SubCA’s own certificate into CA certificate (PEM), exactly one certificate, and its key into Private key (PEM) (with Key password (if encrypted) if it is encrypted).
4. Paste every certificate above it into Issuing chain (PEM), up to and including the self-signed root, in any order. Upload chain reads it from a file.
5. Click Import CA. If the CA has warnings (see below), the toast says so and the CA’s Issuing chain card lists them.

A certificate field may also hold a single binary (DER) .cer file, uploaded with the button next to it. A chain of several certificates has to be PEM. AD CS exports the chain as PKCS#7 (.p7b), which you convert with openssl pkcs7 -inform DER -print_certs -in chain.p7b -out chain.pem.

The Issuer choice Internal CA in Taranac is for an intermediate signed by one of your existing Internal CAs, chosen as its Parent CA. An intermediate has one or the other, never both. A Root CA import must be self-signed. A certificate issued by someone else is refused as a root, with the issuer named, and has to be imported as an intermediate with its chain.

1. Click Request (CSR) above the CA tree.
2. Give it a display name (the Internal CA will carry it), the subject fields (at least the Common Name (CN)), the Key algorithm (RSA 4096-bit by default; also RSA 2048-bit, ECDSA P-384 and ECDSA P-256) and, optionally, a Path length.
3. Click Generate key and CSR, then Download CSR (<name>.csr).
4. Have your corporate CA sign the CSR as a subordinate CA. For AD CS, use the Subordinate Certification Authority template, as in the AD CS walkthrough below.
5. Under the CA tree, open the request from Awaiting signature. Paste the signed certificate into Signed CA certificate (PEM) and the issuing chain into Issuing chain (PEM).
6. Click Complete. The request disappears and the Internal CA takes its place in the tree.

Path length is what the CSR asks for. The signing CA decides what it actually grants. Leave it empty (or above 0) if you want to create Taranac CAs under this one, because 0 forbids them.

While a request is pending, its name is taken. No CA or other request can be created under it. Delete request deletes the key with it, so a certificate later signed for that CSR can never be used.

Completing a request is refused when:

• the certificate does not hold the request’s public key (it was signed for another CSR);
• it is not a CA certificate, or its Key Usage does not carry both keyCertSign and cRLSign. Without cRLSign the RADIUS server would reject the CRL this CA signs, and with it every EAP-TLS login under the CA;
• the chain breaks one of the rules below.

The Internal CA’s subject is the one in the signed certificate. A signing CA may rewrite the subject the CSR asked for.

The same rules apply to an import, a completed request, a renewal and Replace chain. A chain that breaks one is refused, and the message names the certificate at fault:

Rule	Why
It reaches a self-signed root	TACACS+ and the EST gateway verify to the root and accept no partial chain. A chain that stops short would import fine and then fail every TLS login and renewal.
Every certificate in it is on the path from the CA to the root	A stray certificate is refused (“…is not on the path from this CA to its root. Remove it”). Duplicates and a copy of the CA’s own certificate are ignored.
Every member is a CA certificate and not expired
At most 8 certificates
Each certificate’s AKI matches its issuer’s SKI	OpenSSL refuses a chain where they differ. The usual cause is a copy of the issuer that was renewed with a new key. Take the one that signed the SubCA.
No path length constraint is violated	Counted the way OpenSSL counts, including the levels of Internal CAs already under the CA (on renewal and Replace chain). A two-tier AD CS whose root has pathLen=1, or whose issuing CA has pathLen=0, cannot sign a SubCA for Taranac.

Some properties are legal but cause trouble later. They do not block the import. The CA’s Issuing chain card lists them and the tree shows a warning count:

Warning	What it means
A restricted extended key usage without clientAuth	TACACS+ TLS clients and EST renewal under this CA fail the purpose check.
A restricted extended key usage without serverAuth	Strict clients refuse server certificates issued under it.
Name constraints	Certificates with names outside the constraints fail verification.
pathLen 0	The CA cannot have child CAs.
An upper certificate expires before the CA	Every chain through it stops verifying on that date. See Expiry.
The CA’s key identifier is not of the SHA-1 kind (e.g. RFC 7093)	Fine. Certificates issued here copy it. Older tools may assume otherwise.
The CA certificate field holds more certificates	Each is an EAP-TLS trust anchor. Replace chain trims the field (see Replace chain).
Stored as a root, but issued by someone else	TLS clients cannot verify its certificates. Replace chain adds the issuing chain.

Open the CA (Edit CA in the tree) to see its Issuing chain card. Each certificate above the CA is listed with its expiry and the state of the CRL it signs: loaded (with its next update), not downloaded yet, failed (with the error), or no CRL URL. The card also holds Renew certificate and Replace chain for a CA signed outside Taranac.

Each certificate of the chain gets the CRL it signs from the first http:// or https:// distribution point (CDP) in the certificate below it. AD CS often lists an ldap:// CDP first; it is skipped. A certificate whose child names no http(s) CDP starts with no CRL URL.

The External CRL Fetch job (every 15 minutes by default, Settings → Workers) downloads these CRLs like those of Trusted CAs, with the same address rules (see Fetching CRLs from a URL). Their consumer is TACACS+ over TLS, which checks a device’s whole chain against them. FreeRADIUS does not use them, because EAP-TLS trusts the issuing CA alone. A distribution point that this node cannot reach therefore never blocks the import. It raises the CRL download failing alert for that certificate, always as a warning.

Edit CRL URL sets a certificate’s URL by hand. Download and save fetches the CRL at once and checks that this certificate signed it. If either fails, nothing is saved and the reason is shown. Clear removes the URL and the stored CRL. The certificates it signs are then not checked for revocation, and its CRL alerts close.

An Internal CA is only as good as the first certificate of its chain to expire. The daily expiry check (06:00) raises Internal CA chain expires soon for every Internal CA whose earliest expiry, its own certificate or any certificate above it, is within 90 days (warning) or 30 days (critical). Once that date has passed, it raises Internal CA chain expired (critical). The alert names the certificate. Its key is nac_ca_expiry:<ca_id>.

What fails depends on which certificate expired:

Expired	What stops working
The Internal CA itself	TACACS+ TLS logins, EST renewals and EAP-TLS through it. Renew it.
A certificate above it	TACACS+ TLS logins and EST renewals through it. EAP-TLS is not affected, because FreeRADIUS trusts the CA itself. Have the issuer renew that certificate, then replace the chain.

The dashboard’s certificate-expiry widget shows an Internal CA by the same earliest date.

A CA signed outside Taranac is renewed in place: same key, same record. Every certificate it issued keeps verifying, and its CRL continues with the same numbering.

1. On the CA’s Issuing chain card, click Renew certificate.
2. Under 1. Renewal CSR, click Generate and download CSR (<name>_renewal.csr). The CSR is built from the CA’s stored key with its current subject, path length and key usage. Generate a new CSR replaces a pending one. Until the renewal is done, the card notes that a renewal CSR is waiting.
3. Have your CA sign it with the same template as the current certificate (AD CS: Subordinate Certification Authority).
4. Under 2. Renewed certificate, paste the renewed certificate into Renewed CA certificate (PEM) and the chain into Issuing chain (PEM). Use the chain as it is now: if your issuing CA was renewed too, its certificate may have changed.
5. Click Renew.

The renewed certificate must hold the same public key, the same subject and, when both carry one, the same subject key identifier as the current one. Anything else is refused, because the certificates the CA issued name it by subject and key identifier and would stop verifying. AD CS’s SubCA template takes the subject from the request. A CA policy that rewrites subjects makes renewal impossible. The Key Usage must carry keyCertSign and cRLSign, and the chain follows the chain rules. Chain certificates that did not change keep their CRL settings.

After the renewal:

• NAC and TACACS+ server certificates issued from this CA, or from a CA below it, send the renewed CA certificate on every node within 30 seconds. They keep the same leaf and key, and nothing needs redeploying. A TACACS+ node serving its generated certificate or an uploaded one is left alone. The EST gateway’s trust follows in the same interval.
• An expired CA becomes active again. It is enabled again only if the expiry is what disabled it. A CA you disabled stays disabled, and so does an expired CA whose record does not show that the expiry disabled it. Enable such a CA by hand.

Renew certificate is offered only for a CA signed outside Taranac whose certificate field holds its own certificate alone. A CA with several certificates in that field needs Replace chain first. A CA created in Taranac, or signed by another Internal CA, is renewed by creating a new one.

Replace chain gives a CA signed outside Taranac a new issuing chain while it keeps its key, its issued certificates and its EST setup. Use it when:

• your corporate CA renewed an issuing CA or the root, and the chain you stored is no longer the one the devices hold;
• the CA was stored as a root although someone else signed it. It becomes an intermediate with its chain;
• its certificate field holds more certificates than its own.

In the drawer, paste the new chain and click Replace chain. The same chain rules apply, counting the Internal CAs already under it against every path length. A chain certificate that is in the new chain too keeps its CRL URL and CRL. The others start from the distribution points, as on import.

When the certificate field holds other certificates, the drawer lists them first under These certificates leave EAP-TLS trust. Each one is an EAP-TLS trust anchor today. The field is trimmed to the certificate that matches the CA’s key, so clients whose certificates chain only to one of the listed certificates stop authenticating over EAP-TLS. Add as Trusted CA next to each one keeps it trusted, as a Trusted CA you can see and manage. Replacing is possible only after you tick I understand that these certificates leave EAP-TLS trust. Nothing is removed silently.

Server certificates issued from the CA pick up the new chain on every node within 30 seconds, as after a renewal.

This uses Request (CSR), so the SubCA’s key is generated in Taranac and never exported. You need nac_pki.edit in Taranac. In AD CS you need Enroll permission on the Subordinate Certification Authority template (SubCA), and the template must be published on the issuing CA (certsrv.msc → Certificate Templates → New → Certificate Template to Issue). By default only Domain Admins and Enterprise Admins may enroll on it.

1. Request. In Taranac, click Request (CSR), name the CA, fill in the subject, keep RSA 4096 (choose EC only if the corporate CA and every device support it), and leave Path length empty. Click Generate key and CSR, then Download CSR.

2. Sign. On a host that can reach the enterprise CA:

   certreq -submit -config "ca01.corp.example\Corp Issuing CA" -attrib "CertificateTemplate:SubCA" taranac.csr taranac.cer

   If the request is held for manager approval, issue it in certsrv.msc → Pending Requests (or certutil -resubmit <RequestId> on the CA) and collect it with certreq -retrieve -config "…" <RequestId> taranac.cer. A standalone CA has no templates: submit without -attrib, then approve and retrieve.

3. Export the chain. certutil -ca.chain chain.p7b, then openssl pkcs7 -inform DER -print_certs -in chain.p7b -out chain.pem. Or export each CA certificate as Base64 from the MMC. The chain is everything above the new SubCA, up to the root, in any order.

4. Complete. Open the request under Awaiting signature, paste taranac.cer into Signed CA certificate (PEM) (it is Base64 already) and chain.pem into Issuing chain (PEM), then click Complete.

5. Check the chain card. Open the new CA. Its upper-chain CRL URLs come from the http(s) CDPs. If AD CS publishes only an ldap:// CDP, enter an http URL with Edit CRL URL, or leave it empty: revocation above the SubCA is then not checked for TACACS+ TLS.

6. Use it. Choose it as the EST or SCEP CA or as the Default CA, issue the NAC server certificate from it, and trust it for TACACS+ over TLS. Domain members already trust the root, so they validate the RADIUS server without a GPO change.

Renewal follows the same path: Renew certificate → Generate and download CSR, then certreq with the same template, and the renewed certificate and chain go back into Taranac. Start when the expiry alert first appears, not after it turns critical.

Refusal or symptom	Cause	Fix
The CA certificate field takes exactly one certificate, but N were found	The certificate was pasted together with its chain	Put the CA’s own certificate in CA certificate (PEM), the rest in Issuing chain (PEM)
This certificate was issued by ’…’, so it is not a root	A corporate SubCA imported as a root	Import it as Intermediate CA with External CA (issuing chain)
The issuing chain stops at ’…’	The root or an intermediate is missing	Add every certificate up to and including the self-signed root
…names its issuer by key identifier …, but the issuer ’…’ has key identifier …	The chain holds a renewed copy of the issuer with a new key	Take the issuer certificate that signed the SubCA
The certificate does not hold this request’s public key	The signed certificate is for another CSR	Have the CA sign this request’s CSR
The CA certificate must carry Key Usage with both keyCertSign and cRLSign	Signed with a template that is not for CAs	Sign with the Subordinate Certification Authority template
Certificate ’…’ allows N CA certificate(s) below it…	A path length above the SubCA leaves no room for it (or for the Internal CAs under it)	Sign from a CA without that limit, or with a larger one
The new certificate holds a different public key (renewal)	The CA signed a new key, not the renewal CSR	Sign the renewal CSR from Renew certificate
The certificate field of CA ’…’ still holds several certificates (renewal)	The CA’s certificate field holds more than its own certificate	Replace chain first, then renew
CRL download failing on an upper-chain certificate	The distribution point is not reachable from this node	Make it reachable, set another URL with Edit CRL URL, or Clear it
TACACS+ TLS logins fail under the SubCA, EAP-TLS works	A certificate above the CA has expired	Get it renewed, then Replace chain

• PKI & trust: Internal CAs, issued certificates, the server certificate, CRL.
• EST enrollment and SCEP enrollment: devices enrolling from the SubCA and receiving its chain.
• TACACS+ over TLS: the client-CA bundle and revocation checking built from the chain.
• EAP-TLS for domain users: the AD CS scenario end to end.