【2026年最新版】Wi-Fi RADIUS共有秘密鍵形式不正の原因と対処法【完全ガイド】

公開日：2026/04/15　更新日：2026/04/15　

※本ページにはプロモーション(広告)が含まれています

Wi-Fi RADIUS認証で共有秘密鍵の形式不正エラーが発生する問題とは

企業や学校のWi-Fiネットワークで802.1X認証（WPA2/WPA3 Enterprise）を設定しているとき、「RADIUS共有秘密鍵の形式が不正です」「Shared Secretが無効です」というエラーが表示されて認証が通らないケースがあります。特に新しいRADIUSサーバー（FreeRADIUS、ClearPass、ISEなど）を導入した直後や、設定を移行した後に多く発生します。

共有秘密鍵（Shared Secret）はRADIUSサーバーとアクセスポイント（AP）の間で通信を暗号化・認証するための鍵であり、この設定が一致していなければ認証は一切通りません。本記事では形式不正エラーの原因と対処法を体系的に解説します。

この記事でわかること

RADIUS共有秘密鍵（Shared Secret）の仕組みと役割
「形式不正」エラーが起きる原因と見落としやすい落とし穴
対処法（APの設定確認からRADIUSサーバー設定まで）
共有秘密鍵の安全な管理方法
エラー診断に使えるログの読み方

RADIUS認証の基礎知識

RADIUS（Remote Authentication Dial-In User Service）とは

RADIUSはネットワーク機器（アクセスポイント、スイッチ、VPNゲートウェイなど）がユーザーの認証・認可・課金（AAA）をサーバーに委託するためのプロトコルです（RFC 2865）。企業のWi-Fiでは「誰がネットワークに接続できるか」を一元管理するために使われます。

802.1X認証の流れ

Wi-Fiで802.1X認証が行われる場合の通信フローは次の通りです。

クライアント（スマートフォン・PCなど）がAPにアソシエート要求を送信
APがクライアントにEAP（Extensible Authentication Protocol）認証を要求
クライアントがID・証明書・パスワードなどをAPに送信
APがRADIUSサーバーにAccess-Requestパケットを転送（共有秘密鍵で保護）
RADIUSサーバーが認証結果（Access-Accept / Access-Reject）をAPに返信
APが結果に応じてクライアントの接続を許可または拒否

共有秘密鍵（Shared Secret）の役割

APとRADIUSサーバー間のRADIUSパケットは、共有秘密鍵を使ったMD5ベースのメッセージ認証コード（HMAC）で保護されています。この鍵がAPとRADIUSサーバーで一致していない場合、RADIUSサーバーはAccess-Requestを不正として拒否します。

形式不正エラーの6つの原因

原因1：APとRADIUSサーバーで秘密鍵が一致していない（最多原因）

単純な入力ミスが最も多いです。大文字・小文字の違い（MySecret / mysecret）、スペース・タブの混入、コピー時の前後の空白が代表的な例です。特にGUIのパスワードフィールドは入力値が「●●●」でマスクされるため、ミスに気づきにくいです。

原因2：使用できない特殊文字の混入

RADIUSの共有秘密鍵に使用できる文字はRFCでは特に制限されていませんが、機器の実装によっては一部の特殊文字を処理できないことがあります。問題が起きやすい文字は次の通りです。

文字	問題が発生しやすい機器・状況
@ # $ % ^ &	古いCisco APや業務用ルーター
スペース（空白）	多くの実装で使用不可または挙動が不安定
日本語文字（全角）	文字コードの扱いが機器により異なる
ダブルクォート（”）	設定ファイルの記述形式によりエスケープが必要
バックスラッシュ（\）	エスケープ文字として解釈され次の文字が変化する

原因3：文字数制限の超過

RFC 2865では共有秘密鍵の最大長を定めていませんが、多くのRADIUSサーバーや機器の実装では最大127バイト（FreeRADIUS）または128バイトまでに制限されています。また古い機器では64バイト以下しか受け付けないものもあります。

原因4：NAS-IP-Addressの不一致

RADIUSサーバーは送信元のIPアドレス（NAS-IP-Address）と登録されているクライアント（AP）のIPアドレスを照合し、一致するクライアントのShared Secretを適用します。APのIPアドレスが変更されたのにRADIUSサーバー側の登録が更新されていない場合、別のクライアントの（または存在しない）Shared Secretが適用されてエラーになります。

原因5：RADIUSパケットの暗号化バージョンの不一致

WPA3 Enterpriseでは「PEAP over TLS 1.3」などの最新暗号スイートが要求されることがあります。古いRADIUSサーバーがTLS 1.3に対応していない場合、ハンドシェイク失敗がShared Secretの形式不正エラーとして報告されることがあります。

原因6：設定ファイルのエンコーディング問題

FreeRADIUSなどのサーバーはテキストファイル（clients.conf / users）で設定を管理します。エディターがUTF-8 BOM付きで保存した場合や、Windows環境で編集してCRLF（改行コード）が混入した場合に、秘密鍵の文字列が正しく解釈されないことがあります。

対処法：段階別の確認・修正手順

対処法1：AP設定とRADIUSサーバー設定を突き合わせて確認する

Shared Secretは両側の設定が一致していることが大前提です。以下の手順で確認します。

APの管理画面にログインし、「セキュリティ」→「RADIUS設定」を開く
Shared Secretをメモ帳に貼り付ける（マスクを解除できる機器は解除して確認）
RADIUSサーバーの設定（FreeRADIUSならclients.conf）を開き、該当APのsecretを確認
2つの文字列を目視ではなくdiffツールやハッシュ値で比較する

文字列を目視で比較すると見落としが起きやすいため、必ずツールを使って確認することを推奨します。Linux/Macの場合は次のコマンドで確認できます。

echo -n "YourSharedSecret" | md5sum

対処法2：特殊文字を含まないシンプルな秘密鍵に変更する

特殊文字が問題の可能性がある場合、英数字（A-Z、a-z、0-9）のみで構成された新しい秘密鍵に変更して試します。推奨する秘密鍵の形式は次の通りです。

文字種：英大文字・英小文字・数字のみ
長さ：32〜64文字（セキュリティと互換性のバランス）
例：ランダムな32文字の英数字文字列

対処法3：FreeRADIUSのログでエラー詳細を確認する

FreeRADIUSを使用している場合、デバッグモードでより詳細なエラー情報を取得できます。

RADIUSサーバーにSSHまたはコンソールでログイン
FreeRADIUSサービスを停止する: sudo systemctl stop freeradius
デバッグモードで起動する: sudo freeradius -X
問題のAPから認証を試みてログを確認する
「Message-Authenticator」や「Bad Authenticator」のメッセージがあればShared Secret不一致の証拠

対処法4：NAS-IP-AddressとRADIUSクライアントIPを一致させる

APの管理IPアドレスを確認する
FreeRADIUSのclients.confで該当APのエントリを確認する
IPアドレスが変わっていた場合はclients.confを更新してRADIUSを再起動する

対処法5：設定ファイルの文字コードを確認する（FreeRADIUS）

clients.confをLinuxのfileコマンドで確認: file /etc/freeradius/3.0/clients.conf
「UTF-8 Unicode (with BOM)」と表示された場合はBOMを除去する
VSCodeやnanoでBOMなしUTF-8として保存し直す
改行コードがCRLFになっている場合はLFに変換する: dos2unix clients.conf

秘密鍵の安全な管理方法

管理項目	推奨対応
鍵の保管場所	パスワードマネージャーまたは暗号化されたドキュメント
鍵の共有方法	メール禁止・暗号化チャンネルまたは対面で共有
定期的な更新	最低でも年1回、担当者変更時は即時更新
鍵の長さ	32文字以上（短い鍵はブルートフォース攻撃に弱い）
複数APへの使い回し	推奨しない（APごとに異なる鍵を使用する）