PBR Radio System

MOTOTRBO R7 — SCEPman EAP-TLS Enrolment

Overview

How Motorola MOTOTRBO R7 portable radios obtain a device certificate from SCEPman (via SCEP) and authenticate to the WPA3-Enterprise Wi-Fi using EAP-TLS, validated by Aruba ClearPass. SCEPman is Azure-hosted; the radios reach it through an internal Traefik reverse proxy because the R7 SCEP client will not connect to the public Azure endpoint directly.

SystemMOTOTRBO R7 / SCEPman / Aruba ClearPass
CAPBR-ROOT-CA_V1 (SCEPman, Azure App Service)
Radio SCEP hostnamepki-internal.pbr.org.au → Traefik proxy (10.1.8.55)
Main PKI / OCSP hostnamepki.pbr.org.au → Azure direct (untouched by proxy)
Radio VLANVLAN 40
StatusWorking / verified end-to-end

Why the proxy exists

The R7 SCEP client resolves the SCEP host but will not open a TCP connection to a public IP (it connects fine to private/RFC1918 addresses). It also expects a transport it trusts and cannot tolerate the TLS renegotiation Azure App Service triggers under L7 termination. The working solution is a TCP/TLS passthrough proxy on a private IP:

Azure App Service client-certificate mode stays "Optional Interactive User" (SCEPman's required setting). Passthrough does not have the renegotiation problem that L7 termination did, so this setting does not need changing.

Enrolment runbook (per radio)

Performed in Radio Management. Enrolment is done at the Kilvington Drive site, which is the only site that broadcasts the staging SSID. The radio uses the mototrbo staging WLAN (WPA2-Personal, password in 1Password) to reach pki-internal.pbr.org.au and enrol on boot, then operates on the production pbrb_radio WLAN (WPA3-Enterprise, EAP-TLS) which broadcasts at all sites.

Set the following under General → Wi-Fi Network → Wi-Fi Enterprise Certificates (both the Common Certificate and Device Certificate entries):

SCEP Server URLhttps://pki-internal.pbr.org.au/static
CA IdentifierOptional — leave blank. Confirmed not required on enrolment (SCEPman is single-CA). May be set to PBR-ROOT-CA_V1 but is not needed.
Fingerprint (MD5)3AF1978B9E4CC55B81C37B372AB2D3BA (no separators)
Common NamePer the CN convention below
Challenge PasswordFrom 1Password (SCEPman static challenge) — not stored here
Signature / KeySHA-256, RSA 2048

Critical: the fingerprint must be the MD5 of the CA cert as returned by the live GetCACert response, not a copy from a local cert store — they can differ and a mismatch causes the radio to reject the CA ("enrol failed" / "invalid cert"). Derive it with:

curl -s "https://pki-internal.pbr.org.au/static?operation=GetCACert" -o ca.bin
openssl x509 -inform DER -in ca.bin -noout -fingerprint -md5

After setting the fields, push the codeplug to the radio (confirm the push completes), then enrol over the mototrbo staging SSID at Kilvington. Confirm success: a 50-prefixed issuance appears in SCEPman, and the radio operates on pbrb_radio (WPA3-Enterprise).

WLAN / Wi-Fi site scoping

Two WLANs are involved, managed in Aruba Central:

SSIDSecurityPurposeBroadcast scope
pbrb_radioWPA3-Enterprise (EAP-TLS)Production radio Wi-FiAll sites (no zone)
mototrboWPA2-Personal (PSK)Staging / SCEP enrolment onlyKilvington Drive only — Aruba Central zone IT. Password in 1Password.

Aruba Central zone behaviour: an SSID with no zone broadcasts on all APs in the group; an SSID with a zone broadcasts only on APs that carry the same zone; an AP with no zone broadcasts only the no-zone SSIDs. The mototrbo staging SSID is bound to zone IT, and only the Kilvington Drive APs carry that zone — so staging is confined to Kilvington while pbrb_radio (no zone) remains fleet-wide. Note: zone IT currently means "the Kilvington Drive APs".

Certificate Common Name (CN) convention

The device certificate CN identifies the radio and, critically, marks it as a radio device so ClearPass can authorise it onto the radio VLAN without letting other PBR-CA certificates (DCs, servers, user certs) onto the same network.

Format:

<owner-or-role>-<radio-id>.radio.pbr.org.au

Example: IT_Manager-1900.radio.pbr.org.au

SegmentExampleMeaning
<owner-or-role>IT_ManagerThe assigned owner or role for the radio.
<radio-id>1900The radio's Radio ID (the Radio ID column in Radio Management). Uniquely identifies the radio.
.radio.pbr.org.au.radio.pbr.org.auThe discriminator. All radio certs carry this suffix; it is what ClearPass matches on to scope access to VLAN 40.

Why it matters: SCEPman issues certificates from the same CA (PBR-ROOT-CA_V1) for many device types. "Valid cert from our CA" alone is therefore not sufficient to authorise onto the radio network — a DC or server cert would also pass. ClearPass authorisation matches the .radio.pbr.org.au suffix in the CN so that only radios land on VLAN 40.

Rule: every radio device cert CN must end in .radio.pbr.org.au. The owner/role and device-id segments should be unique per radio for identification and traceability.

Traefik configuration

Dynamic config on the Docker host (pbr-docker-kl1), file provider. Rule file location: /docker/appdata/traefik3/rules/app-pki.yml. TCP passthrough — Traefik routes on SNI and forwards raw TLS to Azure, never terminating.

tcp:
  routers:
    pki-tcp-rtr:
      rule: "HostSNI(`pki-internal.pbr.org.au`)"
      entryPoints:
        - websecure-internal
      tls:
        passthrough: true
      service: pki-tcp-svc
  services:
    pki-tcp-svc:
      loadBalancer:
        servers:
          - address: "app-scepman-cbys7lti43ukq.azurewebsites.net:443"

Notes:

ClearPass EAP-TLS

EAP-TLS is mutual — both certificates must chain to a CA the other side trusts.

Troubleshooting reference

SymptomMeaning / Fix
Radio resolves SCEP host, no SYN to it (Palo log)R7 won't connect to a public IP — must use the internal passthrough proxy (private IP).
Connects to private IP but not publicConfirms the public-IP limitation; the proxy is the fix.
"enrol failed" / "invalid cert" after GetCACert succeedsFingerprint mismatch. Re-derive MD5 from the live GetCACert response (not a cert store) and re-push.
tls: no renegotiation (Traefik upstream)Caused by L7 termination + Azure client-cert mode "Optional Interactive User". Use TCP passthrough (canonical config) — it avoids the problem entirely.
Traefik 500, 0ms, unsupported protocol scheme ""Config didn't load — YAML parse error keeps the previous config. Check logs for did not find expected key; validate YAML; check provider-namespace refs (@docker/@file).
EAP-TLS fatal alert by client - unknown_caRadio rejects ClearPass's RADIUS cert. Issue the ClearPass EAP server cert from PBR-ROOT-CA_V1.
EAP-TLS parse_http_line1 ... OCSP / no OCSP responseClearPass OCSP hitting the passthrough proxy (or Azure host-header issue). Point ClearPass OCSP override directly at Azure on pki.pbr.org.au.
OCSP Certificate Status revoked, Reason supersededRadio is using an old cert that a re-enrolment superseded. Re-enrol cleanly so it holds the current cert. (Also confirms OCSP enforcement works.)

Useful SCEPman log query (Log Analytics) — static SCEP issuances, filtering out OCSP noise:

SCEPman_CL
| where TimeGenerated > ago(30d)
| where RequestUrl has "/static"
| order by TimeGenerated desc

Maintenance notes

RM Programming — Over-Wi-Fi Across Sites/Subnets

Overview

Programming MOTOTRBO R7 radios and repeaters over Wi-Fi with Radio Management (RM), across sites and subnets. RM Server / Device Programmer runs on pbr-radio-kl1 (10.8.40.10), RM version 2.157.149.0.

Out of the box, RM Wi-Fi programming only works when the radio and the Device Programmer are on the same subnet, because discovery uses mDNS multicast (224.0.0.251:5353) which doesn't route. Four changes were needed to make it work across sites — all four are required.

The Four Fixes

1. Disable Windows mDNS on the RM server (registry — most important)

Windows' Dnscache service binds UDP 5353 and silently consumes the radios' incoming discovery announcements — the Motorola Device Programmer never receives them. Radios show Waiting For Device forever with no error.

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" `
  -Name EnableMDNS -Value 0 -PropertyType DWord -Force
# Then REBOOT the server

Verify after reboot — the Motorola DP process (not svchost) must own the port:

Get-NetUDPEndpoint -LocalPort 5353 | Select LocalAddress,OwningProcess

2. Set Device Discovery Server Name in the radio codeplug

CPS → Wi-Fi → per network profile: set Device Discovery Server Name to pbr-radio-kl1 (or 10.8.40.10). This makes the radio send its discovery announcement unicast to the server (routable) instead of local multicast. Set it on every Wi-Fi profile the radio uses. DNS-SD port 5353, interval 90 sec.

3. RM Machine Authorization

RM Server Utility → Machine Authorization: the machine running the Device Programmer (including the RM server itself) must be listed with the Programmer permission ticked. Without it, connections fail with the generic "Failed to connect to the RM server" dialog and jobs never dispatch.

4. Use 10.8.40.10, not localhost

In the RM config, Job Processor and Device Monitor/DP settings, set the RM Server address to 10.8.40.10 — not localhost. With localhost, cross-site writes fail with Error 450 ("connection could not be established with the selected connection type") while local writes still work.

Quick Troubleshooting

SymptomCheck
Waiting For Device forever, cross-siteFix 1 — who owns UDP 5353? Windows updates/rebuilds can re-enable mDNS
Cross-site radio never discovered at allFix 2 — Device Discovery Server Name missing on the active Wi-Fi profile
"Failed to connect to RM server" dialogFix 3 — Machine Authorization
Error 450 on cross-site writes onlyFix 4 — localhost addressing

Ports

UDP 5353 (radio → server, discovery) · TCP 443 (RM server/clients) · TCP 8002-8003 (DP → radio, programming session) · TCP 50000-50100 / UDP 20000 (IP Program, repeaters). Traffic currently rides the Palo Alto intrazone-default allow — add explicit rules if radio VLANs move to their own zone.

Notes