Hello,
my university is issuing a new wifi certificate, which is not accepted by iwd 3.12 under Linux 7.1.11 (Arch Linux). A debug session gudied by GPT-6 claims the cause for this is that the server certificate has an empty subject field, and that the Linux ASN.1 parser rejects it despite it being comformant with RFC 5280. My wifi administration reproduced the issue but refuses to reissue the certificate with a populated subject field to remain compatible with macOS.
The quote below is a more detailed report generated by GPT-6. The "userpace diagnostic harness" refers to tests it did in the cloud, the rest describes commands I executed locally. My report to the administration and their response are forwarded below that. The server certificate is attached.
Kind regards, Maximilian Stahlberg
Linux rejects an X.509 server certificate with an empty Subject DN and a critical subjectAltName containing a DNS name. This prevents eduroam authentication using iwd following a server-certificate change at the University of Bremen.
Environment: - Arch Linux, kernel 7.1.11-arch1-1 - iwd 3.12-1 - ELL 0.83-1
The exact server certificate is attached as server.pem. Its DER representation is 562 bytes. It has an empty Subject, encoded as an empty SEQUENCE, and a critical SAN containing DNS:radius.wlan.uni-bremen.de. This form is permitted by RFC 5280 §§4.1.2.6 and 4.2.1.6.
OpenSSL successfully verifies this certificate against the university CA, including sslserver purpose and the expected hostname. The command used was:
openssl verify -trusted /etc/iwd/ub-private-eduroam-ca.pem \ -purpose sslserver \ -verify_hostname radius.wlan.uni-bremen.de \ /proc/390085/root/tmp/iwd-tls-debug-server-cert.pem
Result:
/proc/390085/root/tmp/iwd-tls-debug-server-cert.pem: OK
During iwd authentication, strace captured this failure:
add_key(""..., ""..., ""..., 562, 110656685) = -1 EBADMSG (Bad message)
The abbreviated arguments result from running strace with -s 0. iwd subsequently reports “bad_certificate” and:
Linking certificate 1 / 1 failed, root not verified against trusted CA(s)
A separate userspace diagnostic harness using Linux 7.1.11's ASN.1 compiler, X.509 grammar and decoder, with semantic callbacks stubbed out, rejects the attached certificate immediately after its empty Subject:
ASN1: Data overrun error [m=81 d=148 ot=30 t=30 l=0] PARSE RESULT: -74
A parsing-only control with a nonempty Subject and adjusted enclosing lengths passes. That modified control was not signature-valid; it only isolates the ASN.1 parsing failure.
The implicated files are: - crypto/asymmetric_keys/x509.asn1 - scripts/asn1_compiler.c - lib/asn1_decoder.c
-------- Forwarded Message -------- Subject: Re: [Ticket#2026101610000474] new certificate incompatible with iwd/Linux certificate parser Date: 10/19/2026 03:17:07 PM
Hallo Maximilian Stahlberg,
we have deployed a notebook with ArchLinux and can reproduce your issue. Unfortunately we cannot follow your prosposal. We talked to a colleague who wrote the script which we use to generate the certificates and he left the subject blank on purpose. The reason is that macOS has issues if this field is filled. He also mentioned that this behaviour of iwd is known and might be a bug.
In this case we can only prospose to switch to wpa_supplicant to fix this issue for you.
Kind regards,
[redacted in forwarded message]
16/10/2026 17:56 - Maximilian Stahlberg wrote:
1. Your username (before @uni-bremen.de):
[redacted in forwarded message]
2. The device/operating system:
Arch Linux with Linux 7.1.11 and iwd 3.12
(Linux 7.2.10 is available but I can risk updating only next week.)
3. How does the problem express itself?:
iwd (a wifi management daemon not based on wpa-supplicant) does not
connect with the new certificate and the updated anonymous identity.
iwd reports a "bad_certificate"; strace shows certificate import
failing with add_key(...)=EBADMSG. A debug session guided by GPT-6
suggests this happens because the server certificate has an empty
"Subject" field; only "Subject Alternative Name" is populated. GPT
claims this is supported by RFC 5280 but that the Linux ASN.1 parser
rejects the empty Subject. It claims to have verified that populating
the Subject field would resolve the parsing issue, and proposes to
reissue the server certificate with "Subject CN=radius.wlan.uni-
bremen.de".
4. The building/room number where the error occured:
[redacted in forwarded message]
|