# Unpad Wifi Windows

> UnpadAccess on Windows (EAP-TLS)

- Skill: `faishalwahiduddin/unpad-wifi-windows` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add faishalwahiduddin/unpad-wifi-windows`
- Raw SKILL.md: https://api.skillmd.com/api/skills/faishalwahiduddin/unpad-wifi-windows/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: faishalwahiduddin (https://skillmd.com/u/faishalwahiduddin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/faishalwahiduddin/unpad-wifi-windows

---


# UnpadAccess on Windows (EAP-TLS)

UnpadAccess is Universitas Padjadjaran's campus Wi-Fi. It authenticates with
**WPA2-Enterprise + EAP-TLS**: a per-device client certificate, issued after the
device's MAC address is registered. There is no password.

Two facts drive almost every failure, and they are worth internalizing before
touching anything:

1. **Authorization is bound to the MAC address** captured at registration time.
   Any MAC randomization, or a different adapter than the one registered, means
   the RADIUS server rejects a device whose certificate is otherwise perfect.
2. **Association and internet access fail independently.** A device can complete
   802.1X, get a DHCP lease, and route packets, yet still have no usable
   internet because name resolution is broken. Diagnosing these as one problem
   wastes a lot of time.

## Workflow

### 1. Register the device and get the certificate

Registration must happen from the device itself — it captures that device's MAC.

- Connect to the open SSID **`UnpadAccessRegistration`**.
- Open `https://goah.unpad.ac.id`, log in with the PAuS ID.
- Click **Daftarkan Perangkat**, enter a device name (letters, digits, spaces;
  max 16 characters), confirm the OS, then **Simpan Data Perangkat**.
- Download the `.p12`. The portal displays its import password on the same page.
- Quota is 5 devices per PAuS ID.

The user must type their own PAuS password and any CAPTCHA. Do not enter
credentials on their behalf.

### 2. Import the certificate correctly

Double-click the `.p12`, choose **Current User**, supply the password from the
portal, and let the wizard place certificates automatically.

Automatic placement matters. The bundle contains a client certificate plus the
full CA chain, and each part has to land in a different store. Verify rather
than assume:

```powershell
Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Issuer -match 'Padjadjaran' } |
  Format-List Subject, NotAfter, HasPrivateKey
Get-ChildItem Cert:\CurrentUser\Root | Where-Object { $_.Subject -match 'Unpad Root CA' }
Get-ChildItem Cert:\CurrentUser\CA   | Where-Object { $_.Subject -match 'Padjadjaran' }
```

A healthy install shows the client certificate in `My` with
`HasPrivateKey: True`, the root CA in `Root`, and the intermediates in `CA`. If
everything landed in `My`, chain validation fails — reimport.

Certificates are typically valid for about three months. Check `NotAfter`
early; an expired certificate produces the same silent failure as a missing one.

### 3. Create the Wi-Fi profile

The documented path is to click the SSID and pick a certificate from the
dialog. That dialog is the single most common place people get stuck — it
frequently shows an empty certificate list.

Deploying a profile directly bypasses it entirely and is far more reliable.
Use `assets/UnpadAccess.xml` from this skill:

```powershell
netsh wlan add profile filename="UnpadAccess.xml" interface="Wi-Fi" user=current
```

The profile encodes the settings that matter: EAP-TLS (type 13), user
credentials, server validation disabled, and — critically —
`enableRandomization: false`.

Then connect:

```powershell
netsh wlan connect name="UnpadAccess" interface="Wi-Fi"
```

### 4. Verify layer by layer

Check in order, because each layer failing looks different:

```powershell
netsh wlan show interfaces | Select-String "State|SSID|Authentication"
netsh interface ipv4 show config name="Wi-Fi"
Test-Connection 8.8.8.8 -Count 2
Resolve-DnsName google.com
Invoke-WebRequest "http://www.msftconnecttest.com/connecttest.txt" -UseBasicParsing
```

Interpreting the result:

| Symptom | Meaning |
|---|---|
| Not associating | Certificate, MAC, or clock problem — see below |
| Associated, no DHCP lease | MAC not authorized on this SSID |
| Ping works, DNS fails | Almost always a stale or overridden DNS setting |
| DNS works, HTTP fails | Captive portal or upstream filtering |

Finally, forget `UnpadAccessRegistration` so the device stops drifting back to
the registration network.

## Failure modes worth knowing

**DNS overridden by a static resolver.** The highest-value check on this
platform. If someone has previously hardcoded a public DNS server on the
adapter, it silently overrides what the campus DHCP offers. The campus network
may block outbound DNS to public resolvers, so resolution dies while ICMP still
works — producing a device that pings `8.8.8.8` happily and resolves nothing.

```powershell
netsh interface ipv4 show dnsservers name="Wi-Fi"
```

`Statically Configured DNS Servers` is the tell; `DNS servers configured
through DHCP` is healthy. Reset it — this requires an elevated shell, and it
fails **silently** without one, which makes it easy to believe you fixed
something you did not:

```powershell
netsh interface ipv4 set dnsservers name="Wi-Fi" source=dhcp
netsh interface ipv6 set dnsservers name="Wi-Fi" source=dhcp
Clear-DnsClientCache
```

Confirm the setting actually changed before concluding anything. Also note a
stale DHCP lease can keep reporting the old resolver — reconnect and re-check
before drawing conclusions about what the network hands out.

**Clock skew.** TLS rejects certificates outside their validity window, and
Windows expresses this by showing an empty certificate picker rather than an
error. Ensure automatic time and UTC+07:00, then reboot.

**MAC randomization.** Windows can randomize per network. The supplied profile
disables it; verify with `netsh wlan show profile name="UnpadAccess"`.

**Scan list looks empty.** While associated to another network — especially a
phone hotspot — some adapters report only that network. Disconnect first, then
scan, or you will wrongly conclude the campus SSIDs are out of range.

**Beware of split DNS.** On campus, `unpad.ac.id` resolves to an internal
address. That is expected and not a fault.

## Resources

- `assets/UnpadAccess.xml` — deployable EAP-TLS profile.
- `scripts/wifi-watchdog.ps1` — monitors real connectivity and falls back to
  another SSID after a sustained outage. Useful while testing, since it checks
  ICMP → DNS → HTTP rather than ping alone. Ping alone gives false positives
  here: `8.8.8.8` answers on UnpadAccess even when the connection is unusable.
- `references/troubleshooting.md` — extended diagnostics and official links.