ネットワークエンジニアの皆さん、日々のインフラ運用やセキュリティ担保、本当にお疲れ様です。
現場でバリバリと無線LAN設計に携わっていると、一度は頭を悩ませるのが「認証方式の選定」ではないでしょうか。共用パスワードで一網打尽に接続させるプレシェアードキー（WPA3-Personal）の気軽さも捨てがたいですが、モダンな企業ネットワークやゼロトラストアーキテクチャの文脈において、デバイス単位での強固なアイデンティティ証明が求められる場面では、やはり EAP-TLS（Extensible Authentication Protocol-Transport Layer Security） が最強のカードとなります。
今回は、数々の現場で泥臭いトラブルシューティングを乗り越えてきたシニアエンジニアの視点から、無線LANにおけるエンタープライズ認証の最高峰「EAP-TLS」の内部挙動、厳格な相互認証のシーケンス、そして実務運用で絶対にハマる落とし穴について、実用的な設定例を交えて徹底的に解説していきます。
—
なぜ今、EAP-TLSなのか？（WPA3-Enterpriseとの関係性）
まず大前提として整理しておきたいのが、EAP-TLSの位置づけです。よく「WPA3-EnterpriseとEAP-TLSは何が違うのか？」という質問を受けますが、これはレイヤーが異なります。
- WPA3-Enterprise: 無線区間の暗号化フレームワークの規格。
- EAP-TLS: その枠組みの中で使われる「認証プロトコル（EAP）」の一つ。
WPA3-Enterprise自体は、ID/パスワードを使う PEAP や EAP-TTLS といったレガシーな認証方式もサポートしています。しかし、パスワード認証は「パスワードスプレー攻撃」や「フィッシング（偽AP）」に対して構造的に脆弱です。
そこで登場するのが、クライアントとRADIUSサーバ（認証サーバ）の双方が電子証明書を持ち寄り、暗号学的に身元を証明し合う EAP-TLS です。鍵のやり取りには公開鍵暗号基盤（PKI）が使われ、無線空間にパスワードが流れることは一切ありません。企業の情シス部門が「マネージドデバイス以外お断り」と胸を張るための、いわばパスポートのような役割を果たします。
—
EAP-TLSの裏側：TLSハンドシェイクと相互認証の全貌
パケットキャプチャ（Wiresharkなど）を覗くと、EAP-TLSが裏でどれほど厳格なやり取りをしているかがよく分かります。まずは、クライアント（サプリカント）とアクセスポイント（AP）、そしてRADIUSサーバの間で行われる通信の全体像をシーケンスとして押さえましょう。
[Client/Supplicant] [Access Point] [RADIUS Server]
| | |
|--- (1) Association ----->| |
| (802.11 接続) | |
| |--- (2) EAP-Request ---->|
| | (Identity) |
|<-- (3) EAP-Request ------| |
| (Identity) | |
|--- (4) EAP-Response ---->| |
| (Identity / ユーザーID) |--- (5) Access-Request ->|
| | |
| |<-- (6) EAP-TLS Start ---|
|<-- (7) EAP-TLS Start ----| |
| | |
|=== (8) TLS ハンドシェイク・セッション確立 (相互認証) ===|
| - Client Hello | |
| - Server Hello | |
| - Certificate (S) | |
| - Certificate (C) | |
| - Key Exchange | |
| | |
|<-- (9) EAP-Success ------|<-- Access-Accept -------|
| | |
|=== (10) 4-Way Handshake (無線区間の暗号鍵導出) ===|ポイントは、ステップ8のTLSハンドシェイクで「相互認証（Mutual Authentication）」が行われる点です。
1. サーバ認証: クライアントはRADIUSサーバから提示された証明書を検証し、「本当に社内の正当な認証局（CA）が発行したサーバか？」を確認します。これにより、悪意ある偽APやローグRADIUSサーバを完全にシャットアウトできます。
2. クライアント認証: RADIUSサーバはクライアントから提示された証明書を検証し、「社内で管理された正当な端末か？」を確認します。
3. マスターキーの導出: TLSトンネルが確立されると、そのセッション鍵から無線暗号化（WPA2/WPA3）に必要なプライベートキー（PMK: Pairwise Master Key）が安全に導出されます。
—
運用で絶対に直面する「証明書ライフサイクル」の現実
EAP-TLSの設計において、技術的な難易度よりもはるかに頭を悩ませるのは「証明書の有効期限切れ」と「失効管理（CRL / OCSP）」です。
1. 証明書の有効期限管理
従業員のデバイスに1年有効な証明書を配布した場合、1年後には全社規模で証明書の更新（ローテーション）が必要になります。これを手動で行うのはヘルプデスクの悲劇を招くため、必ず SCEP（Simple Certificate Enrollment Protocol）や ACME、あるいはMDM（Microsoft IntuneやJamf Proなど）を連携させた自動プロビジョニングの仕組みをセットで設計しなければなりません。
2. 失効管理の落とし穴
退職者の端末や、社外で紛失したPCからのアクセスを遮断するため、失効リスト（CRL: Certificate Revocation List）の参照や、OCSP（Online Certificate Status Protocol）によるリアルタイム検証が不可欠です。
ここでインフラエンジニアがハマりやすいのが、「無線接続認証の最中に、RADIUSサーバから外部のCRL配布サーバー（HTTP/LDAP）へ名前解決・通信ができず、認証がタイムアウトする」というトラブルです。RADIUSサーバのルーティングやファイアウォール設定、あるいはCRLのローカルキャッシュ設定は、本番稼働前に必ずストレステストを行ってください。
—
実務で使える設定例・検証サンプル
ここからは、実務的なアプローチとして、FreeRADIUSなどのオープンソースRADIUSサーバや、一般的なエンタープライズ無線環境を想定した設定・確認の勘所をコードベースで紹介します。
1. FreeRADIUS (eap 設定ファイル) でのTLS設定例
LinuxベースのRADIUSサーバ（例: FreeRADIUS）でEAP-TLSを有効化する場合、/etc/freeradius/3.0/mods-available/eap 内の tls セクションを適切にチューニングします。
# /etc/freeradius/3.0/mods-available/eap の抜粋
tls {
# サーバ証明書を発行したCAのルート証明書
ca_file = ${certdir}/ca.pem
# RADIUSサーバ自身の証明書
certificate_file = ${certdir}/server.pem
# RADIUSサーバの秘密鍵
private_key_file = ${certdir}/server.key
# 秘密鍵のパスフレーズ（保護されている場合）
private_key_password = "your_secure_passphrase"
# クライアント証明書の検証を厳格に行う（必須）
check_cert_issuer = "${certdir}/ca.pem"
# 失効チェック（CRL）を有効化する場合の設定
check_cert_revoke = yes
# 強固なTLS Cipher Suiteの指定（古い脆弱な暗号を排除）
cipher_list = "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
# TLS 1.3のサポート（モダンな環境では推奨）
tls_min_version = "1.2"
tls_max_version = "1.3"
}2. クライアント側の接続確認（ログ・デバッグの視点）
例えば、Linuxクライアント（wpa_supplicant）から手動でEAP-TLSの動作検証やデバッグを行いたい場合、以下の設定ファイルをベースにフォアグラウンドでプロセスを起動すると、ハンドシェイクのどこで失敗しているかが手に取るように分かります。
# wpa_supplicant.conf の設定例
ctrl_interface=/var/run/wpa_supplicant
update_config=1
network={
ssid="Corporate-Secure-Wi-Fi"
key_mgmt=WPA-EAP
eap=TLS
identity="device-001@example.internal"
ca_cert="/etc/ssl/certs/ca.pem"
client_cert="/etc/ssl/certs/client.pem"
private_key="/etc/ssl/certs/client.key"
private_key_passwd="client_cert_password"
}この設定でデバッグ出力を有効にして接続コマンドを叩きます。
# デバッグモード（-d）でwpa_supplicantをフォアグラウンド実行し、パケットとハンドシェイクのログを監視
sudo wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -dコンソールにずらりと流れるログの中で、TLS: Handshake finished や EAP-Key-Name が正常に取得できているかを確認するのが、現場エンジニアの腕の見せ所です。もし TLSV1_ALERT_UNKNOWN_CA や certificate verify failed が出たら、CA証明書のインポート漏れか、RADIUSサーバ側の信頼ストアの設定ミスを疑いましょう。
—
シニアからの実務アドバイス：トラブルシューティングの極意
最後に、現場で実際に起りがちな「EAP-TLS導入時のハマりポイント」をいくつか共有しておきます。
1. 時刻同期（NTP）のズレ:
証明書には有効期間（Not Before / Not After）が存在します。アクセスポイント、RADIUSサーバ、そしてクライアント端末の時刻が数分ずれているだけで、「証明書がまだ有効ではない」または「有効期限切れ」と判定され、認証が容赦なく弾かれます。インフラ構築時はまずNTPの稼働状況を確認するのが鉄則です。
2. SAN（Subject Alternative Name）の確認:
最近の厳格なTLSクライアント（特にiOSやmacOSの最新バージョン）では、サーバ証明書にCN（Common Name）だけでなく、SAN（DNS名やIPアドレス）が正しく含まれていないと、信頼できない証明書として弾く挙動が強まっています。証明書を内製（OpenSSL等）で発行する場合は、拡張領域（v3_extなど）の記述に細心の注意を払いましょう。
EAP-TLSは設計と初期構築のハードルがやや高い技術ですが、一度しっかりとインフラ基盤を組み上げてしまえば、パスワード漏洩のリスクとは無縁の、極めてセキュアでモダンな無線ネットワーク空間を手に入れることができます。
日々の運用でパケットと格闘しているエンジニアの皆さん、ぜひこの堅牢な認証方式をマスターして、セキュアで快適なネットワーク環境を構築してください！
コメント