SHARPのAndroid端末で802.1X認証のWi-Fi接続を行う際の挙動を世代別にまとめてみた

SHARP製のAndroid端末で802.1X認証のWi-Fi接続を行う際に、RADIUSサーバのサーバ証明書の検証を強制されるため、これを発行した認証局（CA）のルート証明書（以下、CA証明書）の端末へのインストールが必要となる場合がある。
サーバ証明書の検証は本来、「しなければならない」(MUST)ではないはずだが、SHARPはかねてから端末に独自仕様を実装しているため、このような動き（CA証明書をインストールして、サーバ証明書の検証を行うことが必須）となっている。*1

このため、例えば認証に802.1X（多くはEAP-PEAP）を使用している国際無線LAN ローミング基盤 eduroam (http://www.eduroam.jp/) を整備している大学等では、SHARPのAndroid機の接続について、個別に注意喚起を行っている。
eduroam.jpの案内
 神戸大学の案内
 北海道大学の案内

しかし最近、SHARP製のAndroid機においても、CA証明書の端末へのインストール無しに、802.1x(EAP-PEAP)認証の無線LANへ接続できるクライアントが存在している。
このため、できるだけ多くのSHARP製Android機種を集め、挙動をまとめてみることにした。

※　個人の理解を深めることを目的としたまとめです。誤りや、用語の使い方がおかしい点などありましたらご指摘いただければ幸いです。　

10/17追記　@hgot07 先生にありがたいつっこみをいただいた。
@hgot07 ありがとうございます！何でそうなのか勉強してから修正します。他にもお気付きのことがあればつっこんでいただければ幸せです
— Hiroyuki H (@pirosap) 2015, 10月 15

ので、今更だけど勉強しなおしてみた。
EAP-PEAP と書いていたが、PEAP　は Protected Extensible Authentication Protocol　
つまり　Protected EAP なので、頭にEAP-とつけてるのは「馬から落馬」みたいな表現になるのかな？
「正しいEAP-PEAPのID、パスワードを入力しても〜」というのは、直すとすると「正しい　PEAP-MSCHAP v2のID、パスワードを入力しても〜」かな？
しばらく恥を忍んで、修正しないでおきます。
用語の使い方って大事だと思う。

■EAP-TLS　（RADIUSサーバとクライアントの相互で証明書による認証を行う）
○EAP-TLS　　　　
TLSって何 = Transport Layer Security
　　　　　　　　　　⇒　慶應義塾大学のワイヤレスネットワーク　「keiomobile2」
　　　　　　　　　　　　http://www.mita.itc.keio.ac.jp/ja/net_connect_keiomobile2.html
　　　　　　　　　　　　慶應ID（共通認証システム）を基盤として発行された証明書　をEAP-TLS認証に利用している。（2011年頃〜）

■TTLS （クライアント側は証明書を発行せず、その代わりにユーザ名とパスワードを用いて認証を行う）
TTLSって何 = Tunneled TLS
EAP-TLSの拡張版がTTLS。
サーバ側にのみ電子証明書を準備してサーバ認証済みのTLS通信路を構築し、その暗号化通信路を通してクライアントを認証する。
暗号化通信路を通るので認証プロトコル(Inner Authentication)は平文でもいい。
RFC5281 では Inner Authentication プロトコルとして PAP, CHAP, MSCHAP, MSCHAPv2 あるいは EAP が列挙されている。
TTLSのInner AuthenticationにEAPを使ったのがPEAPってこと？？
○TTLS (PAP)
PAPって何 = Password Authentication Protocol （パスワード認証）
　　　　　　　　　　⇒　OCN モバイル ONEの期間限定トライアルで提供されているWi-Fiスポット
　　　　　　　　　　　　「0001_Secured_Wifi」
　　　　　　　　　　　　https://support.ntt.com/mobile-one/faq/detail/pid23000005jw
○TTLS (MS-CHAPv2)
MS-CHAPv2って何 = Microsoft CHAP version 2
CHAPって何 = Challenge-Handshake Authentication Protocol (チャレンジ/レスポンス認証）
　　　　　　　　　　⇒　eduroam 代理認証システム　から発行されたアカウントは　この方式でも認証できた。
　　　　　　　　　　　　eduroam の技術情報　FreeRADIUS3の導入　（　http://www.eduroam.jp/docs/conf-freeradius3.html　）
　　　　　　　　　　　
■PEAP （PEAP で使用する EAP の種類（認証の種類）は、EAP-MS-CHAP v2 と EAP-TLS が選択できる）
サーバ側にのみ電子証明書を準備してサーバ認証済みのTLS通信路を構築し、その暗号化通信路を通してさらにEAP通信を行い、クライアントを認証する。
⇒　TTLSと何が違うの
　　PEAP と TTLS の違いは、暗号トンネル上のプロトコルとして TTLS が RADIUS/Diameter の枠組みを使っているのに対し、PEAP は EAP を使っている
○PEAP-MSCHAP v2
EAP-MS-CHAP v2 を使用する PEAP。
PEAP-MSCHAP v2　では、認証に証明書とユーザー名／パスワードを使用。
RADIUSサーバーがクライアントを認証する時はユーザー名／パスワードを使用。
ユーザー名／パスワードの情報は、EAP-MSCHAP v2で暗号化。
クライアントがRADIUSサーバーを認証するときは証明書を使用。
　　　　　　　　　　⇒　本検証で構築した方式。RADIUSサーバにはプライベートCAから発行した証明書を用いた。
　　　　　　　　　　⇒　世界のeduroamでは、PEAPによるID/パスワード認証方式が広く用いられている。
　　　　　　　　　　⇒　EAP-TLSの例として挙げた　慶應義塾大学のワイヤレスネットワーク　「keiomobile2」
　　　　　　　　　　　　http://www.mita.itc.keio.ac.jp/ja/net_connect_keiomobile2_peap.html
　　　　　　　　　　　　慶應ID（共通認証システム）を利用できない人、または証明書方式が利用できない機器向けに
　　　　　　　　　　　　PEAP-MSCHAP v2 でも認証できるようにしたようだ（2014/3〜）
　　　　　　　　　　　　http://www.mita.itc.keio.ac.jp/ja/feature_2013_2.html
　　　　　　　　　　⇒　NTT Docomoの公衆無線LANサービス（0001docomo）は、最近の機種ではEAP-SIM（SIMカードによる認証）に
　　　　　　　　　　　　対応しているが、PEAPも利用可能である。
　　　　　　　　　　　　https://www.nttdocomo.co.jp/binary/pdf/service/data/docomo_wifi/usage/other/windows7_auto_login.pdf
○PEAP-TLS
EAP-TLS を使用する PEAP。
https://www.fmworld.net/biz/fmv/product/hard/network/manual/security/manual/chap100009.html
PEAP-TLS　では、EAP-TLSと同様に、RADIUSサーバーとクライアントの相互で証明書による認証を行う。
PEAP-TLS　では暗号化情報がカプセル化されるため、EAP-TLSよりセキュリティレベルが高くなる。
https://technet.microsoft.com/ja-jp/library/cc754179.aspx
Active Directory 証明書サービス (AD CS) で公開キー基盤 (PKI) を展開する場合は、EAP-TLS を使用する PEAP (PEAP-TLS) を使用できます。
　　　　　　　　　　⇒　社内の無線LANとか？身の回りに環境がない。

本検証環境について

本検証では、FreeRADIUS 3.0.9に自己署名のプライベート認証局より発行したサーバ証明書を設定した上で、EAP-PEAP認証で構築した無線LAN環境で行っている（いずれもSHA-1）。
あらかじめプライベートCA証明書を、一度Windowsに読み込み（証明書ストアは「信頼されたルート証明機関」を選択）、certmgr.mscから「信頼されたルート証明機関」に配置された当該証明書を、「Base 64 encoded X.509 (.CER)」としてエクスポートし、拡張子を .crt に変更したものを用意した。
このプライベートCA証明書へのリンクを検証機からアクセス可能なWEBサーバ上に設置し、検証機からキャリア回線または802.1Xではない無線LANを使用した。
（※CA証明書を事前にPC等でカードリーダを使用してMicroSDに保存しておき、端末で読み込むことも可能であり、実際の運用では証明書の安全な配布という点からはそのような方法が推奨される。あくまで本検証はSHARPのAndroid機の挙動の調査が目的であるため、このような方法を取った。）

■そもそも、AndroidでユーザがWi-Fi用にインストールしたCA証明書はどこに保存されるのか？

インストールするCA証明書が、パブリックCAであるか、プライベートCAであるかで挙動が異なるようだ。
(Android 4.1.2、4.4.2、5.0で確認）

パブリックCA

SECOM TrustのSecurity Communication RootCA1の例
1. SECOM TrustのSecurity Communication RootCA1は、最初から「設定→ロックとセキュリティ→安全な認証情報の使用（信頼できるCA証明書を表示する）→システム」には存在する。
2. SCRoot1caをインストールしないと、警告（"正しいサーバに接続されているか検証されません〜"）が出るものの接続可。
3. SCRoot1caをインストールしていないと、802.1Xの接続設定で証明書を選択できない。
4. SCRoot1caを"SCRoot1ca"として保存しても、「安全な認証情報の使用→ユーザ」　にはインストールした証明書が表示されない。
5. 802.1Xの接続設定のCA証明書の選択プルダウンには、ユーザがつけた名前で表示される。
　（SCRoot1caを"puyo"として保存すると、プルダウンには"puyo"として表示される。）
6. インストールしたパブリックCA証明書を確認できる画面がなく、個別に削除する方法がない。
「認証ストレージの消去」で認証ストレージごと消すと802.1Xの接続設定でCA証明書を選択できなくなる。
7. 「安全な認証情報の使用→システム」に最初からインストールされているSecurity Communication RootCA1は、個別に無効にすることができるが、無効にしても802.1Xの設定からは引き続き参照できる。

Android 5.0を搭載したDocomo SC-01Fでも同様の動きをした。
念のため、SCRoot1caのインストール方法をブラウザからではなく、MicroSDにPCで保存したものを読み込む方法に変えてみたが、挙動に変化は無かった。
Nexusのヘルプには、上記のような挙動については書かれていないが、SHARP機特有の挙動、という訳ではないようだ。
Add & remove certificates - Nexus Help

System displays certificate authority (CA) certificates that are permanently installed in the ROM of your phone.
User displays any CA certificates that you have installed yourself, for example in the process of installing a client certificate.

プライベートCA

プライベートCA局（hogeCA）の例
1. 当然「安全な認証情報の使用→システム」には存在しない。
2. hogeCAをインストールしないと、警告（"正しいサーバに接続されているか検証されません〜"）が出るものの接続可。
3. hogeCAをインストールしていないと、802.1Xの接続設定で証明書を選択できない。
4. hogeCAを"hogeCA"として保存すると、「安全な認証情報の使用→ユーザ」　にインストールした証明書が表示される。
5. 802.1Xの接続設定のCA証明書の選択プルダウンには、ユーザがつけた名前で表示される。
　（hogeCAを"puyo"として保存すると、プルダウンには"puyo"として表示される。）
6. インストールした自己署名CA証明書は、「安全な認証情報の使用→ユーザ」から選択して個別に削除できるが、削除しても802.1Xの設定からは引き続きhogaCAが選択できる。
「認証ストレージの消去」認証ストレージごと消すと802.1Xの接続設定でCA証明書を選択できなくなる。

本検証の最大の疑問。どっかにWi-Fi用の認証情報ストレージ的なものが独立してある？　詳しい方がいたら教えてほしい。

検証まとめ

大まかに分けて、2.x系、4.0系〜4.2系、4.4系で挙動が異なる。SHARPのAndroid端末においては、4.4系で大きく挙動が変わったようだ。（Android的には4.3から？）
5.x系（Docomo SH-03Gなど）、6.x系（今後SH-01H等にアップデート配信予定）は未検証。

Androidバージョン	検証機の型名	検証機の発売開始日	CA証明書インストール	制限事項
2.2.2	Docomo SH-03C (Build 02.01.04)	2010/12/3	必須　(インストールにMicroSDは必須ではない）	いったん接続完了後に端末を再起動すると、自動で再接続されない。 SSIDを選択して接続を手動で行う際に「認証情報ストレージ」のパスワード入力が求められる。
2.3.5	AU IS14SH (Build 01.00.06)	2011/12/23
4.0.4	SoftBank 102SH (Build S1040)	2011/12/16 (2012/9/6 4.0.4アップデート開始)		いったん接続完了後に端末を再起動すると、自動で再接続されない。画面ロック解除後に接続状態を確認すると「認証に問題」となっている。 SSIDを選択して手動で接続を行うと再接続される。「画面のロック」が「パターン」「ロックNo.」「パスワード」のいずれかのみに制限される。「なし」「スライド」(SH-02Eは「スライドまたはタッチ」）「顔認証」は使用不可となる。
4.1.2	Docomo SH-02E*2 (Build. 02.00.06)	2012/11/29
4.2.2	Docomo SH-06E*3 (Build 01.00.10)	2013/5/24
4.4.2	Docomo SH-04F*4 (Build 01.01.08)	2014/5/23	必須ではない　 (インストールしないと初回接続時に警告表示）	CA証明書をインストールしない場合、インストールした場合のいずれにおいても接続中の状態で端末を再起動すると、画面ロック中の状態であっても自動で再接続される。 CA証明書をインストールしない場合、一旦接続が確立した状態から「切断」を実行すると、再度手動で接続を行った際にCA証明書が指定されていない旨の警告が改めて表示される。プライベートCAのCA証明書をインストールすると、通知領域に信頼できる認証情報が端末にインストールされている旨の警告が表示される。
4.4.2	AU SHL25 (Build )	2014/6/13	必須ではない　 (インストールしないと初回接続時に警告表示）

世代別の接続方法

■CA証明書の入手
CA証明書のインストールが必要な場合、そのCA証明書は所属機関が案内しているものを使用する。

例えばeduroamの場合、各機関が独自にRADIUSサーバを構築してeduroamに接続している場合は、後述のSCRoot1caおよびSCRoot2caではないCA証明書が必要な場合があるので、各々の機関の案内に従って適切なCA証明書を入手する。

※　この場合、RADIUSサーバのサーバ証明書が大学のプライベート認証局から発行されているケースと、パブリック認証局から発行されているケースがある。
例えばUPKI電子証明書発行サービス*5では、既存パブリック認証局の下位認証局 *6をNIIが構築しており、サービス利用機関は機関の登録担当者を通じてそこからサーバ証明書を発行してもらうことができる。）
今回のテーマとは違ってくるので深く触れないが、下記を一読することをお勧めする。
高木浩光＠自宅の日記 - PKIよくある勘違い(2)「安全に配布すればルート証明書を入れさせてよい」, PKIよくある勘違い(3)「プライベート認証局が妥当なら..

大学のプライベートCA
損害も社内で閉じる場合には、プライベート認証局で運用することが全く妥当となる場合がある。では、大学ではどうだろうか。

所属機関がeduroam代理認証システムを使用している場合、サーバ証明書のCN (Common Name)は tanelon3.rd.cc.tohoku.ac.jp である。
このCAは　2015/10/12時点では下記の通り　Security Communication RootCA1　である。
http://www.eduroam.jp/docs/supplicant/android/
リポジトリは下記であり、CA証明書は下記で公開されている。
https://repository.secomtrust.net/SC-Root1/

一方、所属機関が学認に参加しており、eduroam仮名アカウント発行システムを利用している場合、サーバ証明書のCN (Common Name)は upkirad1.kuins.kyoto-u.ac.jp　である。
このCAは2015/10/12時点では下記の通り　Security Communication RootCA2 である。
http://www.iimc.kyoto-u.ac.jp/ja/whatsnew/information/detail/150619053028.html
リポジトリは下記であり、CA証明書は下記で公開されている。
https://repository.secomtrust.net/SC-Root2/

Security Communication RootCA1およびSecurity Communication RootCA2のCA証明書は、多くのAndroid端末にプレインストールされているが、(SHARP製のAndroid機に限らず）システム領域にインストールされているCA証明書は、今回検証に利用した端末ではいずれも802.1X認証の無線LAN接続設定からは参照できなかった。
802.1X認証の無線LAN接続設定が参照できるのは、ユーザがWi-Fi用に謎の領域にインストールした~~ユーザ領域（認証情報ストレージ）にインストールされた~~CA証明書のみではないかと思われる。
　（SH-02Eの「システム」領域にプレインストールされているCA証明書の例）

参考：

@ahash ちょっと補足します．端末内にもとからあるWebとか用のCA証明書をEAP用に使えなくて別途インストールしないといけないのが Android の謎仕様．CA証明書設定しなくても接続できるはずのところを必須にするのがシャープによる魔改造です．
— 八槇博史　Hirofumi Yamaki (@yamaki3634) 2015, 1月 21

参考２　(2015/10/19追記）：
http://forum.xda-developers.com/aquos-crystal/help/wi-fi-issues-t2909127/page3

I figured out the network I connect to uses VeriSign Root Certificate Authority (CA) on its RADIUS server. It specifically uses the "VeriSign Class 3 Public Primary Certification Authority - G5" root CA. Android already has this as a trusted credential, but it's not working on the Sharp AQUOS Crystal for whatever reason.

いずれの場合も、リポジトリからダウンロードしたCA証明書はそのままではAndroidにインストールできないことがあるため、事前に変換が必要な場合があることに留意する。
（CA証明書を、一度Windowsに読み込み（証明書ストアは「信頼されたルート証明機関」を選択）、certmgr.mscから「信頼されたルート証明機関」に配置された当該証明書を、「Base 64 encoded X.509 (.CER)」としてエクスポートし、拡張子を .crt に変更するのが確実で簡単。）

参考：

証明書の追加と削除 - Nexus ヘルプ
 Android では、DER エンコードの X.509 証明書のうち、拡張子 .crt または .cer の付いたファイルに保存されたものをサポートしています。証明書ファイルの拡張子が .der などの場合は、.crt または .cer に変更しないとインストールできません。

同様に、各種公衆無線LANサービスにおいてもSHARPのAndroid機ではCA証明書のインストールが必要なケースがあるし、CA証明書入れてもどうもならないケースもある。
以下は、NTT Communicationsが試験提供しているWi-Fiスポットサービス　0001_Secured_Wi-Fi　の事例である。

https://sh-dev.sharp.co.jp/android/modules/d3forum/index.php?topic_id=313
ご質問頂きました件に関して弊社にて調査致しました結果、御連絡頂いた接続先のサーバー証明書に中間証明書が含まれていない為に、弊社端末SH-06Eでは証明書チェーンが辿れず接続できない状況となっている事が判りました。
本件の解決には、証明書サーバー側でサーバ証明書に<<中間CA証明書>>を含めて頂く必要がございます。
尚、証明書サーバー側でサーバ証明書に中間CA証明書を含めるには、証明書サーバーの管理者に設定等の変更をしていただく必要がございます。
従いまして、証明書サーバーの管理者、またはWi-Fi接続サービスのサービス事業者にお問い合わせ頂きますようにお願い致します。

お、おぅ。。。
（実際にSH-02E (4.1.2)で上記確認してみた。確かにCA証明書入れてもつながらない。）

10/17追記
んじゃ、中間CA証明書をCA証明書として指定しちゃえば繋がるんじゃないか？と思ってごにょごにょやってみたが、そうはいかないようだ。

以下、機種別の検証結果。

Android 2.2.2 を搭載するDocomo SH-03C

■事前準備（推奨）
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「位置情報とセキュリティ」→「認証情報ストレージ」から「パスワードの設定」をクリックしてパスワードを設定しておく。画面ロックは設定しなくてもよい。あらかじめ有効にしておかない場合、設定中にパスワードの設定が促される。

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「切断されました」等と表示され、接続が完了しない。

■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
（この際、リンクを長押ししてしまうとダウンロードとなり、MicroSDカードがマウントされていないとのメッセージが表示されるので注意）
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、適当に名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。

事前準備の通り「認証情報ストレージ」のパスワードが設定されていないと、この時点でパスワードを設定するようダイアログが表示される。

2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。

3. EAP-PEAPのID、パスワードを入力し、接続。

■制限事項
端末を再起動すると、自動で再接続されない。SSIDを選択して接続する際に、「認証情報ストレージ」のパスワード入力を求められる。

Android 2.3.5 を搭載するAU IS14SH

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「切断されました」等と表示され、接続が完了しない。

■制限事項
端末を再起動すると、自動で再接続されない。SSIDを選択して接続する際に、「認証情報ストレージ」のパスワード入力を求められる。

Android 4.0.4 を搭載するSoftBank 102SH

■事前準備
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「その他の設定」→「ロックとセキュリティ」→「画面のロック」を「パターン」「ロックNo.」「パスワード」のいずれかにする。「なし」「スライド」「顔認証」は使用不可。あらかじめ有効にしておかない場合、設定中にロック方式を変更し、認証情報ストレージを有効にするよう促される。

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。

■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、適当に名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。

事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。

2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。

3. EAP-PEAPのID、パスワードを入力し、接続。

■制限事項
いったん接続完了後に端末を再起動すると、自動で再接続されない。
画面ロック解除後に接続状態を確認すると「認証に問題」となっている。
SSIDを選択して手動で接続を行うと再接続される。

Android 4.1.2 を搭載するDocomo SH-02E

■事前準備
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「その他の設定」→「ロックとセキュリティ」→「画面のロック」を「パターン」「ロックNo.」「パスワード」のいずれかにする。「なし」「スライドまたはタッチ」「顔認証」は使用不可。あらかじめ有効にしておかない場合、設定中にロック方式を変更し、認証情報ストレージを有効にするよう促される。

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。

Android 4.2.2 を搭載するDocomo SH-06E

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。

■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、英字と数字のみの名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。

事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。

2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。

3. EAP-PEAPのID、パスワードを入力し、接続。

ここから挙動が大きく変わった世代

Android 4.4.2 を搭載するDocomo SH-04F/AU SHL25（画面はSH-04F）

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力して接続を試みると、下記ダイアログが表示される。

？確認
CA証明書が指定されていません。
CA証明書が指定されていない場合、正しいサーバに接続されているか検証されません。現在の設定で接続しますか？
　「いいえ」「はい」

「はい」をクリックすると、CA証明書のインストールなしに接続が完了する。

■CA証明書をインストールする場合の設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、英字と数字のみの名前を入力する。
「認証情報の使用」を初期値の「VPNとアプリ」から「WiFi」に変更する。
「OK」をクリックし、インストールされたダイアログが表示されることを確認する。

事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。

2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。

3. EAP-PEAPのID、パスワードを入力し、接続。

■制限事項
CA証明書をインストールしない場合、インストールした場合のいずれにおいても、接続中の状態で端末を再起動すると、画面ロック中の状態であっても自動で再接続される。
CA証明書をインストールしない場合、一旦接続が確立した状態から「切断」を実行すると、再度手動で接続を行った際にCA証明書が指定されていない旨の警告が改めて表示される。
プライベートCA局のCA証明書をインストールした場合、通知領域に下記の警告が表示される。
（SCRoot1ca等のパブリックCAについては警告が表示されなかった）

！　ネットワーク監視
第三者があなたのネットワークアクティビティ（メール、アプリ、保護されたウェブサイトなど）を監視できます。
これは、信頼できる認証情報が端末にインストールされているためです。
「信頼できる認証情報を確認」

■どないせいっちゅうねん？

プライベートCA局のCA証明書を本検証で用いた方法でインストールする限り、この~~うざい~~警告については消す方法が無い（証明書をアンインストールする以外には）。
パブリックCA局のCA証明書でも同様の表示がされる、とのフォーラムの投稿が散見されるが、今回の検証ではSCRoot1ca, SCRoot2caについてはそのような挙動は発生しなかった。

ログイン - Google アカウント

Installing a private CA certificate for use with vpn or private web site encryption and or authentication results in the alert "network may be monitored" under the settings pull down. The following message is also displayed on boot "network may be monitored by an unknown third party". Although this doesn't appear to be limiting the phones functionality that I have seen so far the alert is bogus.

#3
Same problem when adding a CA for EAP-TLS authentication. This is a problem as it will incite users to remove the CA, thus lowering the corporate wifi security.

ログイン - Google アカウント

#16
For Wifi networks, even if you use a public CA, you still have to install the CA certificate, because Android doesn't reference those certificates for Wifi. So, even in that case, you would still get the annoying warning, which goes back to my point that I think the intent here is good, but the implementation is bad.

"even in that case, you would still get the annoying warning" が当方の検証と一致しないが。。。

異国のeduroamの中の人のコメント。
Android 4.3以上であれば、EnterpriseWifi APIを使用してCA証明書をWi-Fiストアにインストールすれば警告表示を回避できるとの書き込み。
実際に海外のeduroam加入機関の一部では　https://cat.eduroam.org　を運用しているようだ。

The situation is even a bit more absurd than the thread here suggests.
There is an API in Android 18+ (i.e. 4.3 and above), the EnterpriseWifi API. It has its own mechanisms to install CAs into the Wi-Fi store, and using that API will *not* trigger the warning and works completely UI-less.
Any manual installation of the CA by the user does though.
That's the extra hilarious thing: if the user consciously decides he wants to install something and clicks his way through very explicit UI, then that's bad and he will forever be warned. If an app sneaks the CA into his device without asking, it can do so without triggering any UI and Android will remain silent about it.
At least for our legitimate purposes, we the eduroam roaming consortium have developed such an app, the eduroam CAT app (Configuration Assistant Tool). You can install the app from Play Store, grab a config file matching your university from https://cat.eduroam.org and get a secure config, with CA and even server name matching. All this with no UI warnings about unknown certificates.
This doesn't invalidate this bug report though. If a user *decided* he *wants* a CA in his trust store, it is totally inadequate to warn them. Especially if the chosen trust store is the Wi-Fi store, which cannot be used to eavesdrop on the connection. The warning text is totally wrong in that case.
Anyway, not sure why I'm writing this. This bug report (and many others regarding Enterprise Wi-Fi features) continue to get ignored it seems. Way to go.

#46
I'm currently training my users to ignore certificate warnings so the can use our WPA-EAP secured network. This is plain wrong. Fix this.

ごもっともな気が。

クロアチアのeduroam installer。http://installer.eduroam.hr/

The eduroam installer enables simple and reliable configuration of end-user devices (computers, laptops, smart phones) for eduroam access.
Besides configuration for wireless access, installer can also be used for wired network access (if wired network access is compliant with eduroam standard, e.g. StuDOM network access).
To start configuring your device click on the button "Get configurations". If you have additional questions about installer service or problems with using this service please click on "Frequently asked question" button.

警告が出るのがプライベートCAだけなのか、パブリックCAでも同様に警告がでる場合があるのか、プライベートCAにパブリックオプションがついているとどうなるのか、パブリックCAだけど新しくて端末に最初から搭載されていない場合どうなるのか、いろいろとはっきりしない。

http://wiki.cacert.org/FAQ/ImportRootCert#Android_Phones_.26_Tablets

Starting from Android 4.0 (Android ICS/'Ice Cream Sandwich', Android 4.3 'Jelly Bean' & Android 4.4 'KitKat'), system trusted certificates are on the (read-only) system partition in the folder '/system/etc/security/' as individual files. However, users can now easily add their own 'user' certificates which will be stored in '/data/misc/keychain/certs-added'.
System-installed certificates can be managed on the Android device in the Settings -> Security -> Certificates -> 'System'-section, whereas the user trusted certificates are manged in the 'User'-section there. When using user trusted certificates, Android will force the user of the Android device to implement additional safety measures: the use of a PIN-code, a pattern-lock or a password to unlock the device are mandatory when user-supplied certificates are used.
Installing CAcert certificates as 'user trusted'-certificates is very easy. Installing new certificates as 'system trusted'-certificates requires more work (and requires root access), but it has the advantage of avoiding the Android lockscreen requirement.