The short answer
An EAP-TLS deployment needs two certificates, and they come from different places. The RADIUS server certificate needs only the serverAuth extended key usage, so an ordinary publicly trusted SSL/TLS certificate works — provided the server answers to a real hostname in a domain you own. The client certificates need clientAuth, and since 15 May 2026 no publicly trusted CA issues that extension at all, so those must come from a CA you run. Whether you buy the server certificate or issue it yourself turns on one question: can you push a trust configuration to every device that will connect?
If you already know you want the server certificate from a public CA, the product you need is a standard publicly trusted SSL/TLS certificate for the RADIUS host's fully qualified domain name. There is no separate RADIUS or 802.1X certificate product to look for, and anything sold as one is an ordinary server certificate under a different label.
Vendor documentation for EAP-TLS is thorough about configuration and almost silent about procurement. Cisco, Juniper and FreeRADIUS all tell you a certificate is required and that it must be trusted; none of them tells you which of the two certificates you can buy, what happens to the arrangement when public certificate lifetimes fall to 47 days, or why the client half of the question stopped being a choice in May 2026. That gap is what this page covers.
Which certificates does EAP-TLS need?
Two: one on the RADIUS server and one on every client. EAP-TLS, defined in RFC 5216 and updated for TLS 1.3 in RFC 9190, runs a full TLS handshake inside the 802.1X exchange, and that handshake authenticates both ends. The RADIUS server presents a certificate proving its name. The supplicant presents a certificate proving the identity of the user or device. Each certificate is checked by the other party, and each needs a different extended key usage.
That symmetry is why the question "which certificate do I need for 802.1X" has no single answer, and why a lot of forum advice contradicts itself. Someone describing a purchase from a public CA and someone describing an internal PKI build are frequently both right, because they are talking about opposite ends of the same handshake. The extended key usage field is the reliable way to tell them apart: id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1) belongs to the RADIUS server, id-kp-clientAuth (OID 1.3.6.1.5.5.7.3.2) belongs to the supplicant, and RFC 5280 is what defines the extension that carries them. A certificate without the right value gets rejected after verifying perfectly, which produces some of the more confusing errors in this protocol.
PEAP and EAP-TTLS build the same tunnel and need the same server certificate; they simply authenticate the user with a password inside it rather than a certificate. Everything below about naming, trust configuration and lifetimes applies to those methods without change. Only the client half differs.
Can the RADIUS server certificate come from a public CA?
Yes. The RADIUS server is the TLS server in this exchange, so it needs serverAuth, which is the one purpose public CAs still issue and the only one they issue. Cisco's own EAP-TLS guidance treats a public CA and a private CA as equally valid for the authentication server certificate, and FreeRADIUS documents both paths. Nothing about EAP-TLS requires a special certificate type, a particular validation level, or an extension you have to request.
Which validation level to buy is a smaller question than it looks. The supplicant checks the issuer and the name; it does not read the organisation field or care how the applicant was vetted, so domain validation is technically sufficient. Organisations still tend to choose an OV certificate for infrastructure hosts because the organisation name is recorded in the certificate and shows up in audits and inventories, which is a documentation argument rather than a security one. Either works on the wire.
Two conditions have to hold for the public route to be available at all. The server must answer to a name you can prove control of in the public DNS, which rules out a large share of existing RADIUS deployments. And the supplicants have to be configured to trust a CA and require a name, rather than to trust one specific certificate — otherwise every renewal becomes a fleet-wide outage. Both conditions get their own section below, because both are where deployments come unstuck.
Can you buy client certificates for EAP-TLS?
No, and this is no longer a matter of preference. EAP-TLS client certificates must carry clientAuth, and publicly trusted CAs stopped issuing that extended key usage during 2026: DigiCert on 1 May, Certum and Sectigo on 15 May. After those dates there is no public CA, price point or certificate product that will supply one. Client identity in EAP-TLS now comes from a CA you operate, full stop.
For most 802.1X deployments this changed nothing, because almost nobody was buying client certificates to begin with. A client certificate names a user or a device, and a public CA has no mechanism for verifying that a given laptop belongs to your estate — it verifies control of domain names. The organisations affected by the cutoff were the ones using public certificates as machine credentials in adjacent systems: RADIUS-over-TLS peering between proxies, appliance-to-appliance links, and API clients that happened to reuse a server certificate. Our page on the clientAuth EKU removal covers how to find those and what replaces them.
The practical sources for EAP-TLS client certificates are Active Directory Certificate Services, a managed private CA from a cloud provider, or a device-identity platform that enrolls certificates over SCEP or an MDM channel. The requirement on the RADIUS side is modest: it has to trust the issuing root, and that trust should be scoped to client verification rather than added to a system-wide store, so the RADIUS server does not quietly start accepting credentials from every CA the operating system ships with.
What name does the server certificate need?
A fully qualified domain name in a zone you control, present in the certificate's subject alternative name, and identical to what the supplicants are configured to expect. This is where the public CA route most often turns out to be unavailable: a RADIUS server called nps01.corp.local or radius.internal cannot be certified publicly, at any price, by any CA.
The prohibition is old and absolute. Publicly trusted CAs were required to stop issuing certificates containing internal names or reserved IP addresses by 1 November 2015, and every one still outstanding was revoked by 1 October 2016. The namespaces themselves make the rule self-enforcing: .local is reserved by RFC 6762 for Multicast DNS, and ICANN reserved .internal in July 2024 specifically so it would never be delegated, which means nobody can ever demonstrate ownership of a name in either. Our guide to certificates for internal server names goes through the remaining routes in detail.
The usual fix costs nothing. Give the RADIUS server a second name on a domain you already own — radius.example.com — certify that, and point the supplicant profiles at it. The host keeps its internal name for everything else; the certificate and the 802.1X configuration use the public one. Split-horizon DNS can resolve that name to a private address internally, so nothing about the server has to become reachable from outside.
How do Windows, Android and Apple decide to trust it?
Each supplicant is told two things: which CA to trust, and which server name to require. Both have to be set for the validation to mean anything. A supplicant given a root CA and no name will accept any certificate that CA has ever issued, to anyone, which on a public root is a very large set. A supplicant given a name and no CA has nothing to anchor the check to.
Windows exposes this as "Validate server certificate", a list of trusted root authorities, and a "Connect to these servers" field that most deployments leave empty. Apple platforms handle it inside a configuration profile, which pins the expected certificate or CA and the server name together. Android 11 QPR1 and later removed the option to skip validation altogether: an enterprise Wi-Fi profile has to name a root CA and a domain, which in practice means the profile must arrive through an MDM rather than being typed in by the user.
That Android change is the quiet reason many organisations end up buying a public certificate. A root already in the device's trust store removes the hardest part of onboarding — getting a private root onto a phone that nobody manages — and leaves only the domain field to fill in. The trade is that the name field stops being optional hardening and becomes the entire security boundary, so it has to be right on every profile rather than most of them.
How much the missing name check costs you depends on the method. Under PEAP or EAP-TTLS a rogue access point that a supplicant accepts receives the user's password material, which is why the setting has been drilled into Wi-Fi guidance for years. Under EAP-TLS the client authenticates with a certificate, so there is no password to hand over, but the mutual guarantee is still lost: the device has no assurance it is talking to your network. Weaker consequences, same defect.
What do 200-day certificates do to a RADIUS server?
They convert a background task into a recurring risk. Since 15 March 2026 a publicly trusted TLS certificate may not exceed 200 days, and CA/Browser Forum ballot SC-081v3 takes that to 100 days on 15 March 2027 and 47 days on 15 March 2029. A certificate from your own CA has no such ceiling. On a web server the difference is a scheduling question; on a RADIUS server it is the difference between a renewal nobody notices and a renewal that stops every device authenticating.
The failure mode is specific. Supplicant profiles that pin a particular server certificate, or that were built by accepting a certificate once and remembering it, stop matching the moment the certificate is replaced. By 2029 that would mean roughly eight such events a year on a host whose failure looks to users like the Wi-Fi being down. The same class of problem shows up when a public CA rotates its intermediate: profiles anchored to the wrong certificate in the chain fail even though the server certificate renewed correctly and the hierarchy is intact.
Two things make the public route sustainable. Anchor supplicants to a root CA plus a server name, never to a leaf certificate, so a replacement from the same CA with the same name needs no client-side change. And automate the renewal and the service reload, because 47-day certificates are not a manual process. If neither is realistic in your environment, that is a genuine argument for keeping a long-lived certificate from your own CA on this particular host — not a sign you are doing something wrong.
Public CA or private CA: how to decide
Decide on device management, not on security posture. If you can push configuration to every device that will ever connect, a private CA is usually the better fit, because the certificate can outlive the lifetime schedule entirely. If some devices are unmanaged, a public certificate saves you from distributing a root you cannot distribute. The table below is the comparison in full.
| Consideration | Public CA | Your own CA |
|---|---|---|
| Getting the root onto devices | Already there | MDM, GPO or manual install |
| Maximum lifetime | 200 days, 47 from 15 Mar 2029 | Whatever you set |
| Server naming | Public FQDN required | Any name, including .local |
| What trusting the root implies | Every certificate that CA ever issued | Only hosts you enrolled |
| Unmanaged or BYOD devices | Workable | Hard — the root has to arrive somehow |
Read the fourth row alongside the first. The convenience of a public root and its weakness are the same property: every device already trusts it, and so does every device belonging to an attacker who can obtain a certificate from that CA. The server-name requirement is what narrows a public root back down to your server, which is why a public certificate and an unset name field is the worst of the available combinations and, judging by how often the field is left empty, a common one.
A mixed arrangement is often the honest answer. Managed laptops get a profile pointing at your private root, unmanaged phones get a separate SSID whose RADIUS server presents a public certificate with the domain pinned, and the client certificates come from your internal CA in both cases because there is no alternative. More moving parts, but it matches how most estates actually look.
How do I check the certificate I already have?
Read the extended key usage and the subject alternative name straight off the file, before trusting any label in a management console. Three commands settle whether a certificate in hand can serve the role you intend, and they are worth running before a migration rather than during one.
Confirm the purpose with openssl x509 -in radius.pem -noout -ext extendedKeyUsage. A RADIUS server certificate should report TLS Web Server Authentication. If that is all it reports, the absence of client authentication is correct and expected for a certificate issued after May 2026, not a defect. A client certificate should report TLS Web Client Authentication; one that reports only server authentication will verify cleanly and then be refused for the job it was given.
Confirm the names with openssl x509 -in radius.pem -noout -ext subjectAltName and compare the output character by character against the domain configured in the supplicant profiles. Then check the clock with openssl x509 -in radius.pem -noout -dates, because a 200-day certificate issued at the start of a project expires inside the same budget year. If you want to see what the server is actually presenting rather than what is sitting in a file, our OpenSSL commands cheat sheet covers inspecting a live endpoint and the chain it sends.
What goes wrong most often?
Four failures account for most EAP-TLS certificate trouble, and none of them is a cryptography problem. Each has a specific tell, and each gets misdiagnosed as something harder than it is.
The server name field was left empty. Everything works, nobody notices, and the deployment has no protection against a rogue access point presenting a different certificate from the same public CA. This one produces no error at all, which is why it survives audits.
The server sends an incomplete chain. A supplicant that trusts the root still needs the intermediate, and unlike a browser it will not fetch one for you. The symptom is a certificate that validates in a web browser and fails on the wireless network, which sends people looking at their RADIUS configuration instead of the certificate bundle.
Profiles pinned to a leaf certificate. Built once by accepting a certificate and remembering it, these work until the first renewal and then fail everywhere simultaneously. With 200-day certificates that arrives twice a year, and the clue is that the outage starts at a renewal rather than a configuration change.
A client certificate without clientAuth. Common where someone reused a server certificate as a machine credential, and now unavoidable for anyone who tries to replace such a certificate from a public CA. The certificate verifies, the handshake fails, and the error mentions certificate purpose rather than trust.
Frequently Asked Questions
Answers to common questions about certificates and our services.
Can I use a regular SSL certificate for my RADIUS server?
Yes, provided the RADIUS server answers to a hostname in a domain you own. An ordinary publicly trusted SSL/TLS certificate asserts the serverAuth extended key usage, and serverAuth is exactly what a RADIUS server presents during the EAP-TLS or PEAP handshake. There is no separate RADIUS certificate product and no special extension to ask for. The two conditions that rule it out are an internal-only hostname, which no public CA can certify, and a fleet of supplicants configured to pin one specific certificate rather than a CA plus a name.
Does the RADIUS server certificate need the clientAuth EKU?
No. The RADIUS server acts as the TLS server in the EAP tunnel, so it needs id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1) and nothing more. This matters in 2026 because public CAs stopped issuing clientAuth entirely, with Certum and Sectigo issuing their last such certificates on May 15, 2026. That change does not touch your RADIUS server certificate. It does settle the client side, where clientAuth is mandatory and a private CA is now the only source.
Where do EAP-TLS client certificates come from now?
From a certificate authority you run. EAP-TLS client certificates must carry id-kp-clientAuth, and since May 15, 2026 no publicly trusted CA issues that extended key usage at any price. In practice this changed very little, because client certificates identify a user or a device rather than a domain name, and a public CA never had a way to verify that identity. Active Directory Certificate Services, a managed private CA from a cloud provider, or a dedicated device-identity platform all work; the requirement is that your RADIUS server trusts the issuing root.
Can I get a certificate for a RADIUS server named nps01.corp.local?
Not from a public CA. The Baseline Requirements have prohibited internal names and reserved IP addresses in publicly trusted certificates since November 1, 2015, and .local is reserved by RFC 6762 for Multicast DNS, so there is nothing for a CA to validate. Two routes remain. Give the server a second, real name such as radius.example.com and certify that, keeping the internal name for other purposes, or issue the certificate from your own CA and distribute the root.
Is a public CA or a private CA more secure for a RADIUS server?
Neither is inherently stronger; the risk moves rather than shrinking. A private CA issues only to hosts you enrolled, so trusting its root on a supplicant means trusting your own issuance process. A public root is already trusted by every device, which is convenient and also means that trusting it alone accepts any certificate that CA has ever issued to anyone. A public certificate is safe here only when each supplicant is also configured to require the server's name, which is the setting most deployments forget.
How does the 200-day certificate limit affect a RADIUS server?
It turns a once-every-few-years task into a recurring one. Since March 15, 2026 a publicly trusted TLS certificate may not exceed 200 days, dropping to 100 days on March 15, 2027 and 47 days on March 15, 2029 under CA/Browser Forum ballot SC-081v3. A private CA has no such cap, so many deployments keep a long-lived internal certificate on the RADIUS server precisely to avoid the rotation. If you do use a public certificate, automate the renewal and verify that supplicants validate by CA and name rather than by thumbprint.
Do I need to reissue certificates when I change RADIUS servers?
You need a certificate for the new host, and you need to check what the supplicants were told to expect. If their profiles name a CA and a server domain, a replacement certificate from the same CA with a matching name works with no client-side change. If any profile pins a specific certificate, or names the old host explicitly, every device holding that profile has to be updated before the cutover. Auditing the profiles is the work; getting the certificate is the easy part.
Does any of this apply to PEAP rather than EAP-TLS?
The server half applies exactly the same way. PEAP and EAP-TTLS also build a TLS tunnel that the RADIUS server terminates with a serverAuth certificate, so everything here about naming, supplicant trust and lifetimes carries over unchanged. The difference is the client half: PEAP authenticates the user with a password inside the tunnel instead of a certificate. That makes the server-name check more urgent rather than less, because a rogue server that the supplicant accepts receives credentials it can reuse.
Getting the server certificate
If the RADIUS host has a public FQDN and you have decided to buy rather than issue, an ordinary DV or OV SSL/TLS certificate is the right product — it arrives with serverAuth, which is what the supplicant checks. My-SSL is a Certum reseller, so the certificates chain to a publicly trusted root that devices already carry. If you are not sure whether your server name can be certified publicly, send us the hostname and we will tell you before you order rather than after.
Related reading
- The clientAuth EKU removal — why public certificates stopped identifying clients, and how to find the ones in your estate still trying to.
- Certificates for internal server names — what to do when the host you need to certify is called something no CA can validate.
- What is mutual TLS? — the same two-way handshake EAP-TLS runs, seen from the application side.