Wi-Fi on campus

Gets you online. Use eduroam. It works here and at every other university in the world with the same profile. Two routes below: the eduroam configuration assistant, which fills the certificate settings in for you, and hand configuration for the system you picked at the top of this page.

Official documentation: THI Wi-Fi service.

Read this before configuring anything by hand

Both campus networks authenticate you with your campus login, the same password that reaches your mail, your grades and every other system. The password is sent to the access point's authentication server, so your device must confirm it is talking to the real one before sending it.

That confirmation is two settings, and both are required:

1. A CA certificate: which authority is allowed to vouch for the server.
2. A server name to match: which server that authority is allowed to vouch for.

With only the first, any server holding a certificate from the same public authority is accepted, and that is a large set. With neither, anything broadcasting the right network name is accepted. In both cases someone with a laptop in a lecture hall can collect your password. This is not theoretical. It is the standard attack against 802.1X networks, and hand-written configurations very often omit one or both.

The configuration assistant gets this right by construction, which is why it is the recommended route below.

Documented values

	eduroam	@thi
Network name	eduroam	@thi
Method	PEAP	TTLS
Inner method	MSCHAPv2	MSCHAPv2
CA certificate	HARICA TLS RSA Root CA 2021	HARICA TLS RSA Root CA 2021
Server name must end in	rz.fh-ingolstadt.de	rz.fh-ingolstadt.de
Identity	<kennung>@thi.de	<kennung>
Works off campus	yes, at any eduroam site	no
Device registration needed	no	yes

The CA ships with the standard certificate bundle on all three systems, so there is nothing to download. Where your system keeps it:

/etc/ca-certificates/extracted/cadir/HARICA_TLS_RSA_Root_CA_2021.pem

/etc/ssl/certs/HARICA_TLS_RSA_Root_CA_2021.pem

In the system keychain, under the certificate's name rather than a path. A profile refers to it by name, so there is no file to point at.

Older notes name the wrong CA

Notes written before 2026 name a USERTrust certificate. THI has moved to HARICA TLS RSA Root CA 2021. A profile still pointing at the old authority will either stop connecting or, worse, keep working while validating nothing.

eduroam, the easy way

The eduroam Configuration Assistant Tool generates a profile with the CA and server name already filled in. Choose Technische Hochschule Ingolstadt, download the installer for your system, run it, enter <kennung>@thi.de and your password.

The CAT installer is a Python script. If you would rather not run it directly on your system, generate the profile inside a container and copy out the resulting config:

docker run -it --rm debian:stable
apt update && apt install -y curl python3
curl "https://cat.eduroam.org/user/API.php?action=downloadInstaller&lang=en&profile=5182&device=linux&generatedfor=user&openroaming=0" > script.py
mkdir -p /root/.config/cat_installer
python3 script.py
cat /root/.config/cat_installer/cat_installer.conf

The CAT installer is a Python script and runs directly:

sudo apt install python3 python3-dbus
python3 eduroam-linux-*.py

CAT provides a .mobileconfig profile. Download it, open it, and approve it under System Settings → General → VPN & Device Management. macOS then handles the certificate check itself.

eduroam by hand

Only if you have a reason to avoid the installer. Both certificate settings below are mandatory; a profile without them is the failure described at the top of this page.

nmcli connection add type wifi con-name eduroam ssid eduroam \
  wifi-sec.key-mgmt wpa-eap \
  802-1x.eap peap \
  802-1x.phase2-auth mschapv2 \
  802-1x.identity "<kennung>@thi.de" \
  802-1x.ca-cert "/etc/ca-certificates/extracted/cadir/HARICA_TLS_RSA_Root_CA_2021.pem" \
  802-1x.domain-suffix-match "rz.fh-ingolstadt.de"

nmcli connection add type wifi con-name eduroam ssid eduroam \
  wifi-sec.key-mgmt wpa-eap \
  802-1x.eap peap \
  802-1x.phase2-auth mschapv2 \
  802-1x.identity "<kennung>@thi.de" \
  802-1x.ca-cert "/etc/ssl/certs/HARICA_TLS_RSA_Root_CA_2021.pem" \
  802-1x.domain-suffix-match "rz.fh-ingolstadt.de"

macOS does not expose server-name matching in the Wi-Fi dialogue. Use the CAT profile. Hand configuration on macOS cannot be made safe through the UI alone.

@thi

A campus-only network using TTLS instead of PEAP. It needs the device to be registered first, and you receive separate credentials for it. See Ethernet: 802.1X and device registration for the registration process; the same form covers Wi-Fi.

There is little reason to prefer it over eduroam unless something specifically requires it. eduroam needs no registration and works everywhere.

The same two certificate settings apply, with 802-1x.eap ttls.

Verify

wifi-verify.sh Download

Reports whether your profiles actually validate the authentication server

curl -fsSLO https://hutzelmann.github.io/thi-linux-macos-setup/scripts/wifi-verify.sh
less wifi-verify.sh   # read it first
sh wifi-verify.sh --dry-run

Runs on its own. The documented values and helpers are built in, no clone needed. --dry-run prints what it would do and changes nothing.

The important part of the output is not whether you are connected. It is whether the profile validates the server. By hand:

nmcli -f 802-1x.ca-cert,802-1x.domain-suffix-match connection show eduroam

Both fields must be non-empty, and the second must read rz.fh-ingolstadt.de. An empty domain-suffix-match is the single most common problem, and it is invisible: the network works perfectly either way.

nmcli -f 802-1x.ca-cert,802-1x.domain-suffix-match connection show eduroam

Both fields must be non-empty, and the second must read rz.fh-ingolstadt.de. An empty domain-suffix-match is the single most common problem, and it is invisible: the network works perfectly either way.

security find-certificate -c "HARICA TLS RSA Root CA 2021" /Library/Keychains/System.keychain

This says the authority is present, not that your profile matches a server name against it. macOS keeps that inside the profile, so the answer is whether the profile came from the configuration assistant: System Settings → General → VPN & Device Management.

Known quirks

thi-onboard is not a network you stay on. It exists for the official onboarding client.

That client supports Windows and macOS, and its Linux support is very limited. Register the device instead: Ethernet: 802.1X and MAC registration.

That client supports Windows and macOS, and its Linux support is very limited. Register the device instead: Ethernet: 802.1X and MAC registration.

That client supports macOS, so this network is the route it uses. Registering the device by hand works too: Ethernet: 802.1X and MAC registration.

Roaming between buildings can drop the session on some drivers. Usually a wpa_supplicant matter rather than anything campus-specific.

The identity has a realm, the username does not. eduroam wants <kennung>@thi.de; @thi wants the bare login. Mixing them up gives an authentication failure with no useful message.