Troubleshooting
Check that your client has a certificate to authenticate and that you are using the correct WiFi configuration profile or XML.
Check that you've done the following:
If your Clients need to verify on connecting the first time, and you're seeing this dialog:
Make sure that you have referenced the RADIUS server certificate in your WiFi profile and provided the server certificate's SAN attribute (FQDN) and common name (CN):
Mon Jul 12 12:38:09 2021 : ERROR: (14872) eap_tls: ERROR: SSL says error 20 : unable to get local issuer certificate
Mon Jul 12 12:38:09 2021 : ERROR: (14872) eap_tls: ERROR: TLS Alert write:fatal:unknown CA
Mon Jul 12 12:38:09 2021 : Error: tls: TLS_accept: Error in error
Mon Jul 12 12:38:09 2021 : Auth: (14872) Login incorrect (eap_tls: SSL says error 20 : unable to get local issuer certificate): [host/8dc38402-20fb-41db-a8f3-4e4e95637173/<via Auth-Type = eap>] (from client contoso port 1 cli 18-9K-EA-0H-7F-C5)
it can have the following root causes:
- Client throws error
TLS Alert read:fatal:unknown CA- Your Client doesn't know the Server certificate and rejects the connection. Check that you've added your Server certificate as described here.
- You've changed/added a new Server certificate and your XML profile on the client is using the old one. In that case, please double-check that you've either updated your WiFi/Wired profile or re-generated your XML after adding the certificates and pushed that to your clients.
- Server throws error
TLS Alert write:fatal:unknown CA- Your RADIUS server doesn't know the issuer of the certificate which was used for authentication. Add your CA as described here.
Wed Apr 7 08:14:39 2021 : Auth: (312) Login incorrect (eap_tls: TLS Alert write:fatal:decrypt error): [host/00128t09-cbna-469c-9768-2783d28eikl9/<via Auth-Type = eap>] (from client contoso port 1 cli 84-FD-D1-8C-0E-33)
Wed Apr 7 08:14:41 2021 : ERROR: (320) eap_tls: ERROR: TLS Alert write:fatal:decrypt error
Wed Apr 7 08:14:41 2021 : Error: tls: TLS_accept: Error in error
... then it is probably a bug of the TPM software on your Windows machines. More information on that can be found in the SCEPman documentation.
Wed Dec 14 07:24:24 2022 : ERROR: (95878) eap_tls: ERROR: (TLS) Alert read:fatal:access denied
Wed Dec 14 07:24:24 2022 : Auth: (95878) Login incorrect (eap_tls: (TLS) Alert read:fatal:access denied): [host/kad933-161d-4aa8-aeaa-b5a4d3d53b12]
Wed Dec 14 07:11:06 2022 : ERROR: (95717) eap_tls: ERROR: (TLS) Alert read:fatal:access denied
... there can be two reasons. One is that your WiFi profile is referencing the wrong root certificate for server validation. Please make sure that your profile is setup correctly. If it is and you are still facing this issue, try to set your KSP to Software KSP.
The setting Key Storage Provider (KSP) determines the storage location of the private key for the end-user certificates. Storage in the TPM is more secure than software storage, because the TPM provides an additional layer of security to prevent key theft. However, there is a bug in some older TPM firmware versions that invalidates some signatures created with a TPM-backed private key. In such cases, the certificate cannot be used for EAP authentication as it is common for Wi-Fi and VPN connections. Affected TPM firmware versions include:
- STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100
- Intel: 11.8.50.3399, 2.0.0.2060
- Infineon: 7.63.3353.0
- IFX: Version 3.19 / Specification 1.2
If you use TPM with this firmware, either update your firmware to a newer version or select "Software KSP" as key storage provider.
Thu Jul 27 14:28:23 2023: message authenticator, wrong value
Thu Jul 27 14:28:23 2023: buf2radmsg: message authentication failed
Thu Jul 27 14:28:23 2023: radsrv: ignoring request from default (8.222.246.231), validation failed.
then one of your access points or switches that is trying to connect to your RADIUSaaS instance via a RADIUS Proxy is transmitting a mismatching Shared Secret.
To identify the affected access point or switch, first determine the RADIUS proxy by expanding the error message and searching for the
proxyip property. Now that you know the proxy, use your inventory and knowledge of specific locations or groups of devices that cannot connect to your network to identify the misconfigured network device. Finally, update the shared secret to match the value configured in your RADIUSaaS instance for that proxy.In order to log in to the RADIUSaaS web portal ("RADIUSaas Admin Portal"), the following requirements have to be met:
- The UPN/email address you provided as technical admin has to be authenticatable against some Azure AD (it does not have to be an identity from the tenant whose users will leverage RADIUSaaS for network authentication).
- The UPN/email address you provided as technical admin must have been registered on your RADIUSaaS instance as described here. In case it is the initial admin, please contact us if you believe we registered the wrong user.
- The Azure AD user object behind the UPN/email address has to be entitled to grant the RADIUSaaS Enterprise Application the following permissions (see screenshot below):
- Read the Basic User Profile
- Maintain access to data you have given it access to (allow request of refresh token)
- In case your Azure AD user has no rights to grant the required permissions, no corresponding Enterprise Application will be auto-created in your Azure AD. To circumvent this, either ask your IT department to grant your user the needed permissions or alternatively, they may manually create the required Enterprise Application and assign your user to it.
- To manually create the Enterprise Application, please follow these steps:
- Create a new Enterprise Application
- Give it a name such as "RADIUSaaS Admin Center"
- Enable users sign-in
- Optionally, apply your Conditional Access policies
- Configure the following permissions (either an Admin or User consent level):
- Under Users and groups assign every relevant RADIUSaaS admin that shall be able to access the platform.
Last modified 6d ago