Troubleshooting Tip: FortiAuthenticator 802.1x EAP-TLS error 'certificate verify failed' due to empty subject
Description
Â
This article describes steps to troubleshoot an 802.1x EAP-TLS certificate error caused by an empty subject when FortiAuthenticator is used as the RADIUS server.
Â
Scope
Â
FortiAuthenticator v6.6+,v8.0+.
Â
Solution
Â
Step 1:
Navigate to  https://FAC_IP/debug/ and to RADIUS Authentication -> Enter Debug Mode -> Enter detailed debug mode.
Make a note of the exact username and timestamp of the issue.Â
Â
Step 2:
Â
Download the RADIUS logs from https://FAC_IP/debug/Radius .
Additionally, log downloads are not supported in FortiAuthenticator ('FAC') up to version 8.0.2. In this case, the logs must be manually copied and saved to a text file.
The RADIUS logs show up as below:
2026-02-10T15:19:45.950564+01:00 FAC01 radiusd[10665]: rlm_eap_tls: Certificate passed CRL check.
2026-02-10T15:19:45.950684+01:00 FAC01 radiusd[10665]: (1042) eap_tls: (TLS) Creating attributes from client certificate
2026-02-10T15:19:45.950702+01:00 FAC01 radiusd[10665]: (1042) eap_tls: TLS-Client-Cert-Serial := "000000000000"
[...]
2026-02-10T15:19:45.950746+01:00 FAC01 radiusd[10665]: (1042) eap_tls: TLS-Client-Cert-Subject-Alt-Name-Dns := "CLT.fortinet.training.lab"
2026-02-10T15:19:45.950778+01:00 FAC01 radiusd[10665]: (1042) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Server Authentication, 1.3.6.1.4.1.311.21.8.781199.15483521.279691.6037140.10025820.148.1072425.821865, TLS Web Client Authentication"
[...]
2026-02-10T15:19:45.950873+01:00 FAC01 radiusd[10665]: (1042) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.2.4.5.6.7.8.9.1"
2026-02-10T15:19:45.950879+01:00 FAC01 radiusd[10665]: Certificate chain - 1 cert(s) untrusted
2026-02-10T15:19:45.950886+01:00 FAC01 radiusd[10665]: (TLS) untrusted certificate with depth [0] subject name
2026-02-10T15:19:45.950958+01:00 FAC01 radiusd[10665]: (1042) eap_tls: (TLS) send TLS 1.3 Alert, fatal internal_error
2026-02-10T15:19:45.950966+01:00 FAC01 radiusd[10665]: (1042) eap_tls: ERROR: (TLS) Alert write:fatal:internal error
2026-02-10T15:19:45.950976+01:00 FAC01 radiusd[10665]: (1042) eap_tls: ERROR: (TLS) Server : Error in error
2026-02-10T15:19:45.950994+01:00 FAC01 radiusd[10665]: (1042) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:0A000086:SSL routines::certificate verify failed
2026-02-10T15:19:45.951002+01:00 FAC01 radiusd[10665]: (1042) eap_tls: ERROR: (TLS) System call (I/O) error (-1)
2026-02-10T15:19:45.951010+01:00 FAC01 radiusd[10665]: (1042) eap_tls: ERROR: (TLS) EAP Receive handshake failed during operation
2026-02-10T15:19:45.951019+01:00 FAC01 radiusd[10665]: (1042) eap_tls: ERROR: [eaptls process] = fail
2026-02-10T15:19:45.951028+01:00 FAC01 radiusd[10665]: (1042) eap: ERROR: Failed continuing EAP TLSÂ
The above error suggests that the subject name is missing in the certificate, in particular, no subject name is printed in this line: '(TLS) untrusted certificate with depth [0] subject name'.Â
Â
Step 3:
Verify the Client certificate.
Â
Â
Check that SAN (Subject Alternative Name) and subject both have the proper values set in the client certificate.
If the client certificate is missing, a new client certificate with the fields set correctly must be issued and used instead.
When using Microsoft AD CS or other Certificate Authorities, ensure the certificate template is configured to build the Subject Name from Active Directory information (specifically the Common Name).
Failure to configure this correctly may result in certificates being issued with an empty Subject field, which can cause authentication failures such as EAP‑TLS errors.
Therefore, it is recommended to verify the template configuration on the CA and ensure that the Subject Name is properly populated before issuing certificates.
Â
Related articles:
