How To Resolve Untrusted Server Certificate Error

What Is an Untrusted Server Certificate Error?

An untrusted server certificate error occurs when a client device cannot verify the identity of the server it is connecting to. During 802.1X authentication, the client checks the RADIUS server’s certificate against its trusted root certificate store.

If the check fails — because the certificate authority (CA) is unknown, the certificate chain is incomplete, the certificate has expired, or the server name does not match — the device rejects the connection and displays an untrusted certificate warning.

The two primary types of server certificates relevant here are RADIUS server certificates, which authenticate a RADIUS server in 802.1X environments, and web server certificates (SSL/TLS), which secure browser connections. This article focuses on RADIUS server certificates because that is where the “untrusted” error most commonly occurs in enterprise Wi-Fi and VPN deployments.

Understanding Untrusted Server Certificate Warnings

Depending on the operating system, client supplicant, and error type, users and IT administrators will see different messages. The most common untrusted certificate error messages in RADIUS and Wi-Fi environments include:

• “The original certificate provided by the server is untrusted” — displayed on Windows devices connecting to enterprise Wi-Fi or VPN when the RADIUS server certificate cannot be validated against a trusted root CA. –

• “Server certificate is re-signed as untrusted” — logged in firewall and network appliance events (common on Fortinet/FortiAnalyzer) when SSL inspection intercepts and re-signs a certificate using an untrusted intermediate CA. –

• “Error: unknown certificate verification error” or “Unknown certificate verification error” — displayed in EAP supplicant logs when the client cannot complete certificate chain verification. –

• “Your connection is not private” (NET::ERR_CERT_AUTHORITY_INVALID) — browser-facing error when the certificate CA is not in the system trust store. –

• NPS Event ID 6273, Reason Code 265 — logged in Windows Event Viewer when the NPS server certificate chain is not trusted by the authenticating client.

How to Diagnose a RADIUS Untrusted Certificate Error

Diagnosing the root cause before attempting a fix prevents wasted effort. Follow these steps:

1. Check Windows Event Viewer on the NPS server. Open Event Viewer and navigate to Custom Views > Server Roles > Network Policy and Access Services. Look for Event ID 6273 or 6274.

The Reason Code on a 6273 event identifies the exact failure: Reason Code 265 means the certificate chain is not trusted; Reason Code 22 means the certificate cannot be validated (often an incomplete EAP handshake due to a faulty or expired certificate).

1. Verify the NPS server certificate is valid. On the NPS server, open the Certificates MMC snap-in and check that the server certificate is in the Personalstore, has not expired, and chains to a trusted root CA.

2. Confirm the root CA is distributed to clients. The root CA certificate must be present in the Trusted Root Certification Authorities store on every client device. If it is not, clients will reject the server certificate regardless of whether the certificate itself is valid.

3. Check the server name in the Wi-Fi profile. In the client’s Wi-Fi or VPN profile settings, confirm that the “Connect to these servers” field matches the Subject Alternative Name (SAN) on the RADIUS server certificate exactly — including case. A single character difference produces a certificate trust failure on Windows 11.

4. Review the certificate chain for completeness. The RADIUS server certificate must include all intermediate CA certificates. An incomplete chain causes “unknown certificate verification error” even when the root CA is trusted.

Types of Untrusted Certificate Errors

It’s important to be aware of the most common untrusted certificate errors.

Server Name Mismatch (NET::ERR_CERT_COMMON_NAME_INVALID)

This error occurs when the server name in the Wi-Fi or VPN profile does not exactly match a Subject Alternative Name (SAN) on the RADIUS server certificate.Even a case difference (e.g., “radius1.local” vs. “Radius1.local”) is enough to trigger this error on Windows 11.

The server name configured in the client’s Wi-Fi or VPN profile must match exactly what is listed in the Subject Alternative Name (SAN) on the RADIUS server certificate. In RADIUS environments, this is not a browser URL — it is the server name field in the Windows Wi-Fi profile or mobile device management (MDM) profile.

Untrusted Certificate Authority (CA)

This error occurs when the RADIUS server certificate is issued by a CA the client device does not trust. Internal CA root certificates must be distributed to all client devices via Group Policy, MDM (Intune, Jamf), or manual import If the CA root is absent from the client’s Trusted Root Certification Authorities store, the client rejects the certificate as untrusted — even if the certificate itself is valid and not expired. Self-signed certificates also fall into this category, since no CA is trusted by default.

Expired Certificate Error (NET::ERR_CERT_DATE_INVALID)

This error message comes up when the certificate has passed its expiration date, or when the client device’s system clock differs from the certificate’s valid date range. In RADIUS environments, expired certificates on the NPS server are a common cause of sudden authentication failures, particularly for devices that are off the domain network when the certificate renewal is pushed. Self-managed certificates without automated renewal are the most common source of expiration errors.

Certificate Revoked Error (NET::ERR_CERT_REVOKED)

This error appears when the issuing CA has explicitly invalidated it before its expiration date — typically because the private key was compromised, the certificate was issued in error, or the organization’s domain ownership changed. In enterprise RADIUS environments, a failed revocation check (where the client cannot reach the Certificate Revocation List (CRL) distribution point) can also produce this error, even if the certificate itself has not been revoked. Verify CRL distribution point URLs are reachable from client devices.

A RADIUS server certificate must include all intermediate CA certificates in the chain, from the server certificate up to (but not including) the trusted root. If any intermediate certificate is missing, clients will see a certificate verification failure even when the root CA is trusted on both the server and client. To resolve this, include the complete certificate chain in the RADIUS server’s certificate configuration, or create a PKCS#8 bundle that includes all certificates from leaf to root.

How to Fix Untrusted Certificate Errors in RADIUS and 802.1X

Here are the best ways to resolve untrusted certificate errors.

Check for Time-Misalignment

Certificate issues frequently stem from time misalignment. When the client device’s clock differs from the server’s by more than the certificate’s validity window, the certificate appears expired or not yet valid. This happens when Network Time Protocol (NTP) is configured for an on-premises NTP server that is unreachable from home, or when users travel across time zones and automatic time sync fails.

For Windows :

1. Right-click the clock in the taskbar and select “Adjust date/time.”

2. Turn off “Set time automatically” and “Set time zone automatically.”

3. Set the correct date, time, and year under “Change date and time.”

4. Open the Services console (search “Services” in Start), find “Windows Time,” and set Startup Type to “Automatic.”

5. Right-click “Windows Time” and select Start (or Restart if already running).

6. Reboot the device and attempt to reconnect.

If the device clock is accurate and the error persists, the cause is in the certificate configuration — not the clock. Proceed to the steps below.

Resolve Untrusted Certificate

When time correction does not resolve the error, the fix is on the infrastructure side. IT administrators should work through the following:

1. Verify the NPS server certificate is current and trusted. Check that the NPS server certificate has not expired, is issued by a CA trusted by all client devices, and that the full certificate chain (including intermediates) is installed on the NPS server.

2. Distribute the root CA certificate to clients. Use Group Policy (GPO) to push the CA certificate to the Trusted Root Certification Authorities store on all domain-joined devices. For BYOD and non-domain devices, use MDM (Intune, Jamf, or similar) to distribute the trusted root certificate profile.

3. Verify the server name in client Wi-Fi profiles. The “Connect to these servers” field in the Wi-Fi profile must match the Subject Alternative Name (SAN) on the RADIUS server certificate exactly, including case.

4. Check CRL distribution point reachability. If clients are performing revocation checks, the CRL distribution point URL in the certificate must be reachable from client devices. Unreachable CRL endpoints cause revocation check failures that appear as untrusted certificate errors.

5. Replace self-signed certificates. Self-signed certificates should not be used for RADIUS authentication in production environments. Issue certificates from a trusted internal CA or a publicly trusted CA.

Eliminate Untrusted Certificate Errors with Managed PKI

Most untrusted certificate errors in RADIUS environments are due to the same root causes: manual certificate management, inconsistent CA distribution, and no automated renewal. When a certificate expires unexpectedly or a CA root is missing from a subset of devices, IT teams spend hours in event logs tracing down a fix that should not have been needed in the first place.

SecureW2 JoinNow Cloud RADIUS and Dynamic PKI automate the certificate lifecycle end to end. Certificates are issued from a trusted CA, distributed to managed and BYOD devices through MDM integration, and renewed before they expire, all without requiring IT to touch each device. The RADIUS server certificate is always current, the CA is always in the client trust store, and the chain is always complete.

If your organization is still managing RADIUS certificates manually, schedule a demo to see how Cloud RADIUS eliminates the configuration errors that cause untrusted certificate warnings.

Frequently Asked Questions

What does “server certificate is re-signed as untrusted” mean?

This message typically appears in firewall and network appliance logs (especially Fortinet/FortiAnalyzer) when SSL/TLS inspection is enabled. The appliance intercepts the connection, re-signs the certificate using its own CA, and presents that re-signed certificate to the client. If the appliance’s CA is not in the client’s trusted root store, the client sees the certificate as untrusted.

The fix is to add the appliance’s CA certificate to the trusted root store on client devices, or to exclude RADIUS traffic from SSL inspection.

What does “the original certificate provided by the server is untrusted” mean?

This error appears on Windows when a client device cannot validate the RADIUS server’s certificate during 802.1X authentication. It means the certificate authority that issued the RADIUS server certificate is not in the device’s Trusted Root Certification Authorities store. The fix is to distribute the CA root certificate to all client devices via Group Policy or MDM.

How do I fix an unknown certificate verification error in RADIUS?

An unknown certificate verification error occurs when the client cannot complete the certificate chain verification — usually because an intermediate CA certificate is missing from the server or client configuration. Verify the RADIUS server’s certificate includes all intermediate CA certificates, and that the root CA is distributed to client devices.

Why does Windows 11 fail to connect to enterprise Wi-Fi with a certificate error?

Windows 11 enforces stricter certificate validation than earlier Windows versions. The most common cause is a server name mismatch between the “Connect to these servers” field in the Wi-Fi profile and the Subject Alternative Name (SAN) on the RADIUS server certificate. Even a case difference (uppercase vs. lowercase) triggers a certificate trust failure on Windows 11.

How do I trust a RADIUS server certificate on Windows?

To trust a RADIUS server certificate on a domain-joined Windows device, use Group Policy to push the issuing CA’s root certificate to the Trusted Root Certification Authorities store (Computer Configuration > Windows Settings > Security Settings > Public Key Policies). For non-domain devices, use MDM to deploy the trusted root certificate profile to client devices.