共有Wi-Fiパスワードの運用は、組織の規模が20〜30名を超えたあたりで破綻し始めます。従業員の退職やノートPCの紛失が発生した際、IT担当者は頭の痛い二者択一を迫られます。80台ものワークステーション、ハンディスキャナー、スマートフォンをすべて手作業で設定し、事前共有鍵(PSK)を変更するか。
あるいは、古いパスワードをそのまま放置してセキュリティリスクを受け入れるかです。802.1Xエンタープライズ認証への移行はこの運用上の混乱を解消しますが、従来のPEAP-MSCHAPv2などの方式はActive Directoryのパスワードに依存しています。これでは、hostapd-manaなどのツールを悪用した不正アクセスポイント(Rogue AP)に対してクライアントの認証情報が露呈してしまいます。
EAP-TLSは、認証プロセスからパスワードを完全に排除することでこの課題を解決します。エンドポイントとRADIUSサーバーの双方がX.509デジタル証明書を用いて相互認証を実施します。さらにWPA3-Enterpriseと組み合わせることで、前方秘匿性(Forward Secrecy)の確保、管理フレームの改ざん防止、そして悪意ある偽装AP(Evil Twin)による認証情報窃取リスクの完全な排除が実現します。
クイックスタート:5分で立ち上げるFreeRADIUS
以下は、Ubuntu 22.04または24.04 LTS環境向けの最小構成手順です。本番環境のアクセスポイントを設定する前に、FreeRADIUSサーバーと証明書チェーンの動作検証を行うために活用してください。
1. FreeRADIUSのインストール
sudo apt update
sudo apt install -y freeradius freeradius-utils openssl
2. ブートストラップ証明書の生成
FreeRADIUSの設定ディレクトリには、Makefileユーティリティが用意されています。これを使用することで、テスト用の認証局(CA)とサンプルとなるサーバー/クライアントのキーペアを迅速に生成できます。
cd /etc/freeradius/3.0/certs/
sudo ./bootstrap
# 生成されたファイル: ca.pem, server.pem, server.key, client.pem, client.p12
3. アクセスポイントクライアントの登録
ワイヤレスコントローラーまたはテスト用アクセスポイント(AP)からのRADIUSリクエストを許可するようFreeRADIUSに設定します。/etc/freeradius/3.0/clients.confの末尾に次のブロックを追加します。
sudo tee -a /etc/freeradius/3.0/clients.conf << 'EOF'
client corporate-ap {
ipaddr = 192.168.10.50
secret = SuperSecretRadiusSharedKey2026
shortname = Office-AP-01
}
EOF
4. デバッグモードでのFreeRADIUS起動
バックグラウンドで動作しているsystemdサービスを停止し、デバッグを有効にしてデーモンをフォアグラウンドで実行します。
sudo systemctl stop freeradius
sudo freeradius -X
出力ログを確認してください。暗号スイートや証明書がエラーなく読み込まれれば、コンソールの末尾にReady to process requests.と表示されます。
FreeRADIUSとEAP-TLSの連携の仕組み
802.1Xワイヤレスアーキテクチャは、次の3つの独立したコンポーネントで構成されます。
- サプリカント(Supplicant):ネットワーク接続を要求するクライアントエンドポイント(MacBook、ThinkPad、iPhoneなど)。
- オーセンティケーター(Authenticator):物理アクセスポイントまたは無線LANコントローラー(WLC)。ネットワークのゲートキーパーとして機能し、生の802.11 EAPパケットをUDP RADIUSパケットにカプセル化して中継します。
- 認証サーバー(Authentication Server):FreeRADIUSデーモン。証明書の検証、有効期限の確認、失効リストの照合を行い、ネットワークアクセスの認可を判定します。
Mutual TLS(相互TLS)ハンドシェイク
標準的なHTTPS通信ではWebサーバー側のみが身元を証明しますが、EAP-TLSでは双方向の検証が必須となります。
- クライアントがSSIDに関連付け(Associate)を行い、
EAP-Response/Identityを送信します。 - FreeRADIUSが自身のサーバー証明書を提示します。クライアントは、ローカルに信頼された企業内ルートCAに対してこの証明書を検証し、サーバーのホスト名を確認します。
- クライアントが自身のデバイス証明書を送信します。FreeRADIUSはCAに対する暗号署名を検証し、有効期限および失効ステータスをチェックします。
- 双方の検証が成功すると、FreeRADIUSはマスターセッションキー(MSK)を生成します。これをPairwise Master Key(PMK)に変換し、
RADIUS Access-Acceptパケット内に格納してAPへ送信します。 - APとクライアントがWPA3の4ウェイハンドシェイクを実行し、802.11w管理フレームで保護された暗号化セッションを確立します。
FreeRADIUSにおけるEAP-TLSの設定
/etc/freeradius/3.0/mods-available/eapを開きます。tls-config tls-commonブロックを探し、セキュアな推奨設定に更新します。
tls-config tls-common {
# server.keyにパスワードが設定されていない場合は空のままにします
private_key_password = ""
private_key_file = ${certdir}/server.key
certificate_file = ${certdir}/server.pem
ca_file = ${certdir}/ca.pem
dh_file = ${certdir}/dh
# 最新のTLS標準を強制
tls_min_version = "1.2"
tls_max_version = "1.3"
# TLS 1.2フォールバック用のセキュアな暗号スイートの選定
cipher_list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DEFAULT"
check_cert_issuer = yes
check_cert_cn = no
}
次に、同じファイル内のメインのeapスタンザまでスクロールし、デフォルトの認証方式をTLSに指定します。
eap {
default_eap_type = tls
timer_expire = 60
ignore_unknown_eap_types = no
}
本番環境向けのセキュリティ強化と自動化
OpenSSLを用いたクライアント証明書の生成
本番ユーザーに対してテスト用のブートストラップスクリプトを流用してはなりません。専用のルートCAまたは中間CAを運用し、各エンドポイント向けに個別のECDSAまたはRSA証明書を発行してください。
# 1. ECDSA秘密鍵とCSRの生成
openssl ecparam -name prime256v1 -genkey -noout -out laptop-finance01.key
openssl req -new -key laptop-finance01.key \
-out laptop-finance01.csr \
-subj "/C=US/ST=CA/O=Corp/CN=laptop-finance01.internal"
# 2. 社内CAによるCSRの署名
# 注意: ECDSAではdigitalSignatureのみを使用するため、keyEnciphermentは除外します
openssl x509 -req -in laptop-finance01.csr \
-CA ca.pem -CAkey ca.key -CAcreateserial \
-out laptop-finance01.crt -days 365 \
-extfile <(printf "extendedKeyUsage = clientAuth\nkeyUsage = digitalSignature")
# 3. クライアント配布用PKCS#12バンドルへのエクスポート
openssl pkcs12 -export -in laptop-finance01.crt \
-inkey laptop-finance01.key -certfile ca.pem \
-out laptop-finance01.p12 -name "Corp Wi-Fi Client"
# 出力フレンドリ名: "社内Wi-Fiクライアント"
証明書失効リスト(CRL)の適用
RADIUSサーバー側で失効チェックを行っていない場合、Active Directoryからユーザーを削除してもアクティブなWi-Fiセッションは切断されません。/etc/freeradius/3.0/mods-available/eap内でCRL検証を有効化します。
tls-config tls-common {
check_crl = yes
ca_path = ${cadir}
crl_file = ${certdir}/crl.pem
}
systemdタイマーやcronジョブを設定して、PKIサーバーから最新のcrl.pemを30分ごとに取得し、systemctl reload freeradiusを実行するように構成します。
CLIからのEAP-TLSハンドシェイクのシミュレーション
ノートPCを持ってオフィス内を歩き回るような煩わしい接続テストは不要です。freeradius-utilsまたはwpasupplicantパッケージに含まれるeapol_testを使用すれば、コマンドラインから直接テストが可能です。
cat << 'EOF' > test-eap-tls.conf
network={
ssid="Corp-Secure"
key_mgmt=WPA-EAP
eap=TLS
identity="laptop-finance01.internal"
ca_cert="/etc/freeradius/3.0/certs/ca.pem"
client_cert="/etc/freeradius/3.0/certs/laptop-finance01.crt"
private_key="/etc/freeradius/3.0/certs/laptop-finance01.key"
}
EOF
# ローカルホストに対するテスト(clients.confのデフォルトシークレット testing123 を使用)
eapol_test -c test-eap-tls.conf -a 127.0.0.1 -p 1812 -s testing123
ハンドシェイクが正常に完了すると、生成されたマスターセッションキーとともにEAP-SUCCESSが出力されます。
実運用で陥りやすい実践的な落とし穴
ラボ環境のテストだけでエッジケースをすべて洗い出すことは困難です。組織全体に802.1X認証を展開する前に、以下の4つの運用上の注意点を確認してください。
1. RADIUS MTUのフラグメンテーションとUDPパケットの破棄
標準イーサネットのフレームサイズは1500バイトに制限されていますが、複数階層の証明書チェーンは容易に3KBを超過します。この際、RADIUSはポート1812上でペイロードデータを複数のUDPパケットに分割(フラグメント化)します。経路上のファイアウォールやVPNトンネル(MTU 1400バイトのIPsecなど)がフラグメント化されたUDPパケットを破棄すると、デバイスは「接続中…」のまま永久に応答しなくなります。これを防ぐには、/etc/freeradius/3.0/mods-available/eapでEAPフラグメントサイズを小さく設定します。
tls-config tls-common {
fragment_size = 1024
}
2. クロックドリフトとNTPの不一致
証明書の評価はシステムの正確な時刻に依存しています。エンドポイントやAPの時刻が証明書のnotBefore(有効期間開始)またはnotAfter(有効期限)の境界から数秒以上ズレていると、認証はログも残さず静かに失敗し、ユーザー画面には一般的な接続エラーのみが表示されます。すべてのFreeRADIUSサーバー、ドメインコントローラー、およびワイヤレスAPを、内部NTPプール(またはtime.cloudflare.comなどの外部Stratum-1ソース)と常時同期させてください。
3. 管理フレーム保護(PMF)の必須化
WPA2-Enterpriseでは管理フレームが暗号化されていなかったため、攻撃者は偽装した認証解除(Deauthentication)パケットを送信して、端末を強制切断することが可能でした。WPA3ではProtected Management Frames(802.11w)の適用を義務付けることでこれを防止しています。ワイヤレスコントローラーやAPの管理画面で、802.1X SSIDのセキュリティプロファイルをWPA3-Enterpriseに設定し、PMFを「必須(Required)」に指定してください。レガシーな802.11n機器のサポートが必須な場合を除き、「任意(Optional)」は使用しないでください。
4. MDMによる自動プロビジョニング
200台ものノートPCに対して手作業でPKCS#12証明書を設定するのは現実的ではありません。SCEPやACME、あるいはMDM(Microsoft Intune、Jamf Pro、Kandjiなど)を活用して、ルートCAと各デバイス固有の証明書を自動配布してください。Wi-FiプロファイルにはFreeRADIUSサーバーのCommon Name(CN)をあらかじめ設定しておきます。これにより、「信頼されていないサーバー証明書」の警告画面が表示されなくなり、従業員が無意識にセキュリティ警告を承認してしまうリスクを防止できます。

