User-manager v5 does not send certificate chain in EAP-TLS handshake

RouterOS The User Manager
1

UPDATE 2026-06-02: Withdrawn — I must have observed something
incorrectly during the original test. After retrying, user-manager
works fine. Apologies for the noise. (Original report preserved below.)

Environment

  • Hardware: CCR2004

  • RouterOS: 7.23 (stable)

  • user-manager package: 7.23

Summary

When /user-manager is used as a RADIUS server for WPA-Enterprise PEAP-MSCHAPv2, the server presents only the leaf certificate in the EAP-TLS handshake. Intermediate and root CA certificates are not sent, even when imported with trust-store=all and trusted=yes. This breaks client trust validation when the leaf's issuer is not directly in client trust stores — which is the case for nearly all publicly-trusted CAs (e.g., Let's Encrypt intermediates are never in OS trust stores by design).

The same RouterOS instance correctly sends the full chain for HTTPS via /ip service www-ssl with the same cert objects, confirming the device is capable. The limitation appears specific to user-manager.

Reproduction

  1. Obtain a Let's Encrypt cert for radius.example.com. The current default LE chain uses intermediate Let's Encrypt YR2 → ISRG Root YR (cross-signed by ISRG Root X1) → built-in ISRG Root X1.

  2. Concatenate private-key + leaf + intermediate + cross-signed root into a single PEM:

    cat radius.key fullchain.cer > radius-bundle.pem

  3. Import into RouterOS:

    /certificate import file-name=radius-bundle.pem

    Four cert objects are created (radius-bundle.pem_0 through _3).

  4. Verify chain is linked correctly:

    /certificate print detail where name~"radius-bundle"

    All have trust-store=all trusted=yes. AKID/SKID linkage verifies: leaf → intermediate → cross-signed root → ISRG Root X1 (built-in).

  5. Bind:

    /user-manager set certificate=radius-bundle.pem_0

  6. Test with eapol_test (hostap):

    network={
    ssid="SomeWiFi"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="testuser"
    password="testpass"
    phase2="auth=MSCHAPV2"
}

    $ eapol_test -c peap.conf -a <router-ip> -s <radius-secret>

    Output:

    CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/CN=radius.example.com' ...
CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius.example.com
TLS: tls_verify_cb - preverify_ok=1 err=21 (unable to verify the first certificate)

    Only depth=0 event appears. The server presents only the leaf certificate. The client cannot verify the chain because the LE intermediate (YR2) is not in OS trust stores.

  7. Compare with HTTPS using the same cert binding:

    /ip service set www-ssl certificate=radius-bundle.pem_0

    $ openssl s_client -connect <router-ip>:443 -showcerts </dev/null \
    | grep -c 'BEGIN CERTIFICATE'
4

    HTTPS correctly sends 4 certs (leaf + chain).

Impact

WPA-Enterprise PEAP deployments using user-manager with publicly-trusted certificates (Let's Encrypt, etc.) require either:

  • Manual trust prompt on every device, repeated every certificate renewal (~60-90 days for LE)

  • A configuration profile distributed to every client device, including the intermediate certs

The chain must be sent in the TLS handshake. Clients cannot fetch intermediates via AIA during EAP because no network is available yet.

Request

  1. Is this a known limitation / planned fix?

  2. Any configuration to enable chain transmission that we missed?

2

From my observation, this depends on the clients' operating system. I also use User Manager with a LE certificate for WPA3 Enterprise and Dot1X and while the Windows clients display a prompt when the LE cert is renewed, the Android clients happily connect and silently accept the new certificates.