PKI & trust

EAP-TLS authenticates a user or device by their certificate instead of a password. For that to work Taranac has to do two things: decide which certificates it trusts (the issuing CAs), and — optionally — issue the certificates itself. The PKI / Certificates page covers both. It lets you stand up an internal Certificate Authority, issue and revoke user and device certificates, manage the RADIUS server’s own certificate, and pull in external CAs you already operate (a corporate AD CS, a partner’s CA).

If you are running EAP-TLS at all, every certificate path on your network passes through here. This page explains the pieces, how to configure them in the admin UI, and when to lean on Taranac’s built-in PKI versus an external one you already have.

The PKI page — a CA tree on the left, the issued-certificate table on the right, and the live CA bundle composition at the bottom.

pki · ca bundle & trust

Internal CAs Taranac issues

Trusted CAs uploaded (AD CS)

LDAP / AD CAs auto-pulled

ca_clients.pem combined trust list · enabled CAs

EAP-TLS · clientAuth chains to enabled CA ✓ accept

EAP-TLS · clientAuth on the CRL · revoked ✗ reject

Term	What it means in Taranac
Internal CA	A Certificate Authority that Taranac generates (or imports) and uses to sign certificates. Can be a self-signed Root or an Intermediate signed by a parent CA.
Issued certificate	An end-entity certificate signed by an Internal CA. Type is user, device, or server.
Server certificate	The certificate FreeRADIUS presents to clients during EAP (its TLS identity). Exactly one is active at a time.
Trusted CA	An external CA certificate you upload so Taranac trusts client certificates issued by it — without Taranac issuing anything.
CA bundle	The combined trust list (ca_clients.pem) FreeRADIUS uses to verify client certificates. Assembled from Internal CAs, Trusted CAs, and the CAs of LDAP/AD domains.
CRL	Certificate Revocation List — the signed list of revoked certificates that FreeRADIUS checks so revoked credentials stop authenticating.
EST	Enrollment over Secure Transport (RFC 7030) — a REST API devices and MDM use to request and renew certificates automatically.

The CA bundle that FreeRADIUS uses to validate a client certificate is built from three independent sources. The panel at the bottom of the PKI page shows exactly what is in it:

• Internal CAs — CAs Taranac runs itself (this page).
• Trusted CAs — external CA certificates you uploaded on the Trusted CAs page.
• LDAP / AD domain CAs — pulled automatically from any LDAP source you configured for EAP-TLS.

A client certificate authenticates if it chains to any enabled CA in the bundle. You do not have to issue certificates from Taranac to use EAP-TLS — you can trust an external issuer and never touch the Internal CA features at all.

An Internal CA is either a Root (self-signed, the top of a chain) or an Intermediate (signed by a parent Root or Intermediate). A two-tier hierarchy — one offline-style Root, one issuing Intermediate — is the textbook design, but for a lab, pilot, or small site a single Root that issues directly is perfectly fine.

Field	Root	Intermediate
Signed by	itself	a parent Internal CA
Default key algorithm	rsa4096	rsa4096
Default validity	10 years (1–30)	5 years (must fit inside the parent’s remaining life)
Supported key algorithms	rsa2048, rsa4096, ec256, ec384	same

On the PKI page, the left panel lists your Certificate Authorities as a tree. Use Root CA to create a self-signed root, or Import to bring in a CA you already have.

When creating a Root you supply a display name and the subject fields — Common Name plus optional Organization, Organizational Unit, Country, State, Locality — along with the key algorithm and validity in years. To build a hierarchy, create an Intermediate and pick its parent CA.

Import brings in a CA you already operate: paste the CA certificate (PEM) and its private key (with the key password if it is encrypted), choose whether it is a root or intermediate, and — for an intermediate — point it at its parent. On import Taranac validates the material strictly and rejects anything that is not a usable CA:

• the PEM must parse;
• it must carry BasicConstraints with CA = true;
• it must carry KeyUsage with keyCertSign = true;
• it must not be expired;
• if a private key is supplied, it must match the certificate;
• an intermediate must actually be signed by the parent CA you reference.

Each CA has a status — active, expired, revoked, or disabled. Only active CAs can issue certificates, and only active, enabled CAs are written into the FreeRADIUS bundle. Disable a CA to pull it out of the trust bundle without deleting it. A CA can only be deleted once it has no active issued certificates, which protects you from orphaning live credentials.

The right panel lists everything an Internal CA has issued, filterable by Status (active / revoked / expired) and Type (user / device / server). Each row shows the name, type, subject, serial, issue date, and expiry.

Use Issue Certificate to have Taranac generate a key pair and sign the certificate in one step, or From CSR to sign a Certificate Signing Request from a device that generated its own key (the private key never leaves the device — Taranac stores only the signed certificate).

Field	Notes
CA	Which Internal CA signs it (must be active).
Name	Admin label, e.g. “John — Laptop”.
Type	user, device, or server. User/device get clientAuth; server gets serverAuth.
Subject CN	e.g. john@company.com or LAPTOP-001.company.local.
Key algorithm	rsa2048, rsa4096, ec256 (default), ec384.
Validity (days)	Default 365, capped at the CA’s own expiry.
SAN — UPN / email	For user certificates (e.g. john@company.com).
SAN — DNS	For device certificates (FQDNs).
Linked user / endpoint	Optionally tie the certificate to a Taranac user or endpoint for tracking and lifecycle.

Download an issued certificate as a password-protected PKCS#12 (.p12) archive — the usual choice for installing on a laptop or phone — or as PEM. You can include the CA chain in the download. For user-facing delivery, Taranac can instead email a one-time download link (see Delivering certificates to users below) so you never handle key material by hand.

• Revoke marks a certificate revoked with an RFC 5280 reason (key_compromise, ca_compromise, affiliation_changed, superseded, cessation_of_operation, certificate_hold, unspecified) and immediately regenerates the CA’s CRL so the credential stops authenticating.
• Reassign applies only to device certificates: hand a device certificate to a different user, or unlink it entirely. User certificates cannot be reassigned.
• Reissue and send revokes the old certificate (reason superseded), issues a fresh one with the same parameters and a new key, and emails the user a download link — the clean recovery path when a certificate is lost or suspected compromised.

EAP-TLS and PEAP both require the RADIUS server to present its own certificate to clients. The Server Certificate settings manage that identity. Exactly one server certificate is active at a time, and it has three possible sources:

Source	When to use it
self_signed	Default on first boot. Fine for a lab or closed pilot; clients must be told to trust it (or skip server validation).
internal_ca	Issue the server certificate from one of your Internal CAs — clients that already trust the CA validate the server automatically.
uploaded	Upload a certificate from a public or corporate CA (cert + key + chain). Best when clients should validate the server against a CA they already trust.

You can also generate a CSR here, send it to an external CA, and import the signed result. After changing the certificate, deploy it to push it into the FreeRADIUS volume so the new identity takes effect.

The Trusted CAs page is for the case where certificates are issued elsewhere and you only need Taranac to trust them. Upload the CA’s PEM certificate and Taranac adds it to the bundle. Per trusted CA you also configure:

Setting	Values	Purpose
Identity source	cert_cn, cert_san_upn, cert_san_email, cert_subject	Which field of the client certificate becomes the authenticated identity for policy.
Cert type	user, computer, both	What kind of certificates this CA is allowed to authenticate.
CRL checking	on/off + CRL URL or uploaded CRL	Whether revocation is enforced for this CA.
OCSP	on/off + OCSP URL	Optional OCSP revocation checking.

This is the typical path for a Windows estate that already issues machine and user certificates from Active Directory Certificate Services (AD CS) — you trust the AD CS CA and let domain-joined devices authenticate with the certificates they already hold.

When you revoke a certificate, Taranac re-signs the issuing CA’s CRL and writes it where FreeRADIUS reads it, then reloads. A daily worker also re-signs every active CA’s CRL so the nextUpdate timestamp stays fresh, and a status worker marks expired certificates as expired.

CRL checking is a single global toggle. When it is on, FreeRADIUS requires a valid CRL for every CA in the bundle — Internal, Trusted, and LDAP alike. If any CA is missing a CRL, client certificates from that CA are rejected. Taranac’s pipeline deploys CRLs for all three sources to keep this consistent, but it is the thing to check first if certificates from one issuer suddenly stop authenticating after you enable CRL checking.

EST (RFC 7030) lets devices and MDM systems request and renew certificates over HTTPS without manual P12 handling. Taranac exposes the standard EST endpoints under /.well-known/est/ (cacerts, simpleenroll, simplereenroll, csrattrs). Configure it on the PKI Settings page.

Setting	Default	Description
Enable EST	off	Turns the EST endpoint on.
EST CA	—	Which Internal CA signs EST-enrolled certificates.
Validity (days)	365	Validity for EST-issued certificates.
Require approval	off	When on, requests are queued for admin approval before issuance.
Allowed auth	basic,tls	First enrollment via HTTP Basic (a Taranac/LDAP user); renewal via mutual TLS with the existing certificate.
Auto SAN from identity	on	Add a UPN SAN from the authenticated identity.

Taranac chose EST over the older SCEP because it runs over HTTPS with strong authentication (mutual TLS or Basic over TLS), has a clean renewal flow (simplereenroll), and is supported by modern iOS, Windows, Android, and ChromeOS. Leave Require approval off for demos and pilots; turn it on in production so enrollment requests are reviewed before a certificate is signed.

Rather than emailing key material yourself, Taranac can generate a one-time download link: a single-use, time-limited URL (default 72 hours) that delivers the P12/PEM and shows its password. Use Send link for one certificate, Send all certificates for every active certificate a user holds, or Reissue and send to rotate a compromised credential. Optionally, Taranac can auto-issue a certificate when a local user is created or when a new LDAP user is first synced, using your configured certificate defaults, and email the link automatically.

Certificate defaults (on PKI Settings) pre-fill the issuing CA, key algorithm, validity, and templates for the subject and label, so issuing is one click and stays consistent. The Organization (O) is inherited from the issuing CA, following standard PKI practice.

Situation	Recommendation
Pilot, demo, lab, or greenfield site with no existing PKI	Use the Internal CA — stand up a Root (or Root + Intermediate) and issue from it. No external infrastructure needed.
Windows estate already issuing certificates from AD CS	Add the AD CS CA as a Trusted CA (or via the LDAP/EAP-TLS source). Let domain devices use the certificates they already have.
Mixed: domain laptops via AD CS, plus BYOD / contractors / IoT	Trust AD CS and run an Internal CA for the non-domain devices. Both feed the same bundle.
You need automated, hands-off enrollment and renewal for managed devices	Use the Internal CA as the EST issuer and enroll via MDM.
Clients must validate the RADIUS server against a CA they already trust	Source the server certificate from that external/public CA (upload) rather than self-signed.

Certificate	Suggested algorithm	Suggested validity
Root CA	rsa4096 or ec384	10–20 years
Intermediate CA	rsa4096 or ec384	3–5 years
User / device certificate	ec256 (default) or rsa2048	1 year (365 days)
Server certificate	rsa2048	1–2 years

Type	Extended Key Usage	Typical subject / SAN
user	clientAuth	CN = user@domain; SAN = UPN and/or email
device	clientAuth	CN = device FQDN; SAN = DNS name(s); reassignable between users
server	serverAuth	the RADIUS server identity (one active)

key_compromise · ca_compromise · affiliation_changed · superseded · cessation_of_operation · certificate_hold · unspecified

Task	Cadence
Re-sign CRLs for all active CAs	daily
Mark expired certificates as expired	daily
Expiry alerts (server cert, CA, issued certs)	daily
Clean up used / expired download tokens	daily

Expiry alerting warns ahead of time — server certificate at 30 days (critical at 7), Internal CA at 90 days (critical at 30) — via the standard alert/email mechanism.

• NAC policy — how an authenticated certificate identity drives access decisions.
• Endpoints — devices a certificate can be linked to.
• Captive portal — onboarding flows for devices that are not yet certificate-enrolled.
• Deployment bundle & docs: github.com/TaranacLabs/taranac