初期値は「CA証明書：選択してください」
→「検証しない」を状況に応じて選択しないと、ID/パスワードを入力してもWi-Fiの「接続」が押せない
（あるいは、「システム証明書を使用」を選択 ※ドメインを指定する必要がある）
初期値は「CA証明書：（設定なし）」
他の選択肢は表示されない
初期値は「CA証明書：（指定なし）」
他の選択肢として、「システム証明書を使用」「検証しない」
※キャプチャには他の検証で使用した証明書があるので隠した
初期値は「CA証明書：（指定なし）」
他の選択肢は表示されない
※CA証明書：指定なしで接続するとSHARP端末固有の警告表示 (SHARPのAndroid端末で802.1X認証のWi-Fi接続を行う際の挙動を世代別にまとめてみた - pirosapの備忘録)
Android7.1.1のNexus5Xで試したら謎のファイルが落ちてきた pic.twitter.com/oi7Y2rsSkB
— Hiroyuki (@pirosap) 2017年2月16日
passpoint.config (blog用に一部修正）
Q29udGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7IGJvdW5kYXJ5PXtib3VuZGFyeX0KQ29udGVu dC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0CgotLXtib3VuZGFyeX0KQ29udGVudC1UeXBlOiBh cHBsaWNhdGlvbi94LXBhc3Nwb2ludC1wcm9maWxlCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6 IGJhc2U2NAoKUEUxbmJYUlVjbVZsSUhodGJHNXpQU0p6ZVc1amJXdzZaRzFrWkdZeExqSWlQZ29n SUR4V1pYSkVWRVErTVM0eVBDOVdaWEpFVkVRKwpDaUFnUEU1dlpHVStDaUFnSUNBOFRtOWtaVTVo YldVK1VHVnlVSEp2ZG1sa1pYSlRkV0p6WTNKcGNIUnBiMjQ4TDA1dlpHVk9ZVzFsClBnb2dJQ0Fn UEZKVVVISnZjR1Z5ZEdsbGN6NEtJQ0FnSUNBZ1BGUjVjR1UrQ2lBZ0lDQWdJQ0FnUEVSRVJrNWhi V1UrZFhKdU9uZG0KWVRwdGJ6cG9iM1J6Y0c5ME1tUnZkREF0Y0dWeWNISnZkbWxrWlhKemRXSnpZ M0pwY0hScGIyNDZNUzR3UEM5RVJFWk9ZVzFsUGdvZwpJQ0FnSUNBOEwxUjVjR1UrQ2lBZ0lDQThM MUpVVUhKdmNHVnlkR2xsY3o0S0lDQWdJRHhPYjJSbFBnb2dJQ0FnSUNBOFRtOWtaVTVoCmJXVStX REU4TDA1dlpHVk9ZVzFsUGdvZ0lDQWdJQ0E4VG05a1pUNEtJQ0FnSUNBZ0lDQThUbTlrWlU1aGJX VStRM0psWkdWdWRHbGgKYkR3dlRtOWtaVTVoYldVK0NpQWdJQ0FnSUNBZ1BFNXZaR1UrQ2lBZ0lD QWdJQ0FnSUNBOFRtOWtaVTVoYldVK1EzSmxZWFJwYjI1RQpZWFJsUEM5T2IyUmxUbUZ0WlQ0S0lD QWdJQ0FnSUNBZ0lEeFdZV3gxWlQ0eU1ERTNMVEF5TFRFMlZERTBPakl4T2pNMldqd3ZWbUZzCmRX VStDaUFnSUNBZ0lDQWdQQzlPYjJSbFBnb2dJQ0FnSUNBZ0lEeE9iMlJsUGdvZ0lDQWdJQ0FnSUNB Z1BFNXZaR1ZPWVcxbFBsVnoKWlhKdVlXMWxVR0Z6YzNkdmNtUThMMDV2WkdWT1lXMWxQZ29nSUNB Z0lDQWdJQ0FnUEU1dlpHVStDaUFnSUNBZ0lDQWdJQ0FnSUR4TwpiMlJsVG1GdFpUNU5ZV05vYVc1 bFRXRnVZV2RsWkR3dlRtOWtaVTVoYldVK0NpQWdJQ0FnSUNBZ0lDQWdJRHhXWVd4MVpUNTBjblZs ClBDOVdZV3gxWlQ0S0lDQWdJQ0FnSUNBZ0lEd3ZUbTlrWlQ0S0lDQWdJQ0FnSUNBZ0lEeE9iMlJs UGdvZ0lDQWdJQ0FnSUNBZ0lDQTgKVG05a1pVNWhiV1UrUlVGUVRXVjBhRzlrUEM5T2IyUmxUbUZ0 WlQ0S0lDQWdJQ0FnSUNBZ0lDQWdQRTV2WkdVK0NpQWdJQ0FnSUNBZwpJQ0FnSUNBZ1BFNXZaR1ZP WVcxbFBrVkJVRlI1Y0dVOEwwNXZaR1ZPWVcxbFBnb2dJQ0FnSUNBZ0lDQWdJQ0FnSUR4V1lXeDFa VDR5Ck1Ud3ZWbUZzZFdVK0NpQWdJQ0FnSUNBZ0lDQWdJRHd2VG05a1pUNEtJQ0FnSUNBZ0lDQWdJ Q0FnUEU1dlpHVStDaUFnSUNBZ0lDQWcKSUNBZ0lDQWdQRTV2WkdWT1lXMWxQa2x1Ym1WeVRXVjBh RzlrUEM5T2IyUmxUbUZ0WlQ0S0lDQWdJQ0FnSUNBZ0lDQWdJQ0E4Vm1GcwpkV1UrVFZNdFEwaEJV QzFXTWp3dlZtRnNkV1UrQ2lBZ0lDQWdJQ0FnSUNBZ0lEd3ZUbTlrWlQ0S0lDQWdJQ0FnSUNBZ0lE d3ZUbTlrClpUNEtJQ0FnSUNBZ0lDQWdJRHhPYjJSbFBnb2dJQ0FnSUNBZ0lDQWdJQ0E4VG05a1pV NWhiV1UrVlhObGNtNWhiV1U4TDA1dlpHVk8KWVcxbFBnb2dJQ0FnSUNBZ0lDQWdJQ0E4Vm1Gc2RX VSthRzluWlVCbGVHRnRjR3hsTG01bGREd3ZWbUZzZFdVK0NpQWdJQ0FnSUNBZwpJQ0E4TDA1dlpH VStDaUFnSUNBZ0lDQWdJQ0E4VG05a1pUNEtJQ0FnSUNBZ0lDQWdJQ0FnUEU1dlpHVk9ZVzFsUGxC aGMzTjNiM0prClBDOU9iMlJsVG1GdFpUNEtJQ0FnSUNBZ0lDQWdJQ0FnUEZaaGJIVmxQbWh2WjJW d1lYTnpQQzlXWVd4MVpUNEtJQ0FnSUNBZ0lDQWcKSUR3dlRtOWtaVDRLSUNBZ0lDQWdJQ0E4TDA1 dlpHVStDaUFnSUNBZ0lDQWdQRTV2WkdVK0NpQWdJQ0FnSUNBZ0lDQThUbTlrWlU1aApiV1UrVW1W aGJHMDhMMDV2WkdWT1lXMWxQZ29nSUNBZ0lDQWdJQ0FnUEZaaGJIVmxQbTlrZVhOemVYTXVibVYw UEM5V1lXeDFaVDRLCklDQWdJQ0FnSUNBOEwwNXZaR1UrQ2lBZ0lDQWdJRHd2VG05a1pUNEtJQ0Fn SUNBZ1BFNXZaR1UrQ2lBZ0lDQWdJQ0FnUEU1dlpHVk8KWVcxbFBraHZiV1ZUVUR3dlRtOWtaVTVo YldVK0NpQWdJQ0FnSUNBZ1BFNXZaR1UrQ2lBZ0lDQWdJQ0FnSUNBOFRtOWtaVTVoYldVKwpSbkpw Wlc1a2JIbE9ZVzFsUEM5T2IyUmxUbUZ0WlQ0S0lDQWdJQ0FnSUNBZ0lEeFdZV3gxWlQ1WGFVWnBJ RkJ2ZDJWeVpXUWdZbmtnClQyUjVjM041YytLRW9qd3ZWbUZzZFdVK0NpQWdJQ0FnSUNBZ1BDOU9i MlJsUGdvZ0lDQWdJQ0FnSUR4T2IyUmxQZ29nSUNBZ0lDQWcKSUNBZ1BFNXZaR1ZPWVcxbFBrWlJS RTQ4TDA1dlpHVk9ZVzFsUGdvZ0lDQWdJQ0FnSUNBZ1BGWmhiSFZsUG05a2VYTnplWE11Ym1WMApQ QzlXWVd4MVpUNEtJQ0FnSUNBZ0lDQThMMDV2WkdVK0NpQWdJQ0FnSUR3dlRtOWtaVDRLSUNBZ0lE d3ZUbTlrWlQ0S0lDQThMMDV2ClpHVStDand2VFdkdGRGUnlaV1UrQ2c9PQotLXtib3VuZGFyeX0K Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXg1MDktY2EtY2VydApDb250ZW50LVRyYW5zZmVy LUVuY29kaW5nOiBiYXNlNjQKCk1JSURkVENDQWwyZ0F3SUJBZ0lMQkFBQUFBQUJGVXRhdzVRd0RR WUpLb1pJaHZjTkFRRUZCUUF3VnpFTE1Ba0dBMVVFQmhNQ1FrVXgKR1RBWEJnTlZCQW9URUVkc2Iy SmhiRk5wWjI0Z2JuWXRjMkV4RURBT0JnTlZCQXNUQjFKdmIzUWdRMEV4R3pBWkJnTlZCQU1URWtk cwpiMkpoYkZOcFoyNGdVbTl2ZENCRFFUQWVGdzA1T0RBNU1ERXhNakF3TURCYUZ3MHlPREF4TWpn eE1qQXdNREJhTUZjeEN6QUpCZ05WCkJBWVRBa0pGTVJrd0Z3WURWUVFLRXhCSGJHOWlZV3hUYVdk dUlHNTJMWE5oTVJBd0RnWURWUVFMRXdkU2IyOTBJRU5CTVJzd0dRWUQKVlFRREV4SkhiRzlpWVd4 VGFXZHVJRkp2YjNRZ1EwRXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lC QVFEYQpEdWFaamM2ajQwK0tmdnZ4aTRNbGErcElIL0Vxc0xtVkVRUzk4R1BSNG1kbXp4emR6eHRJ Sys2TmlZNmFyeW1BWmF2cHh5MFN5NnNjClRIQUhvVDBLTU0wVmpVLzQzZFNNVUJVYzcxRHV4Qzcz L09sUzhwRjk0RzNWTlRDT1hrTno4a0hwMVdyanNvazZWams0YndZOGlHbGIKS2szRnAxUzRiSW5N bS9rOHl1WDlpZlVTUEpKNGx0YmNkRzZUUkdIUmpjZEdzblVPaHVnWml0VnRiTlY0RnBXaTZjZ0tP T3Z5SkJOUApjMVNURTRVNkc3d2VOTFdMQll5NWQ0dXgyeDhna2FzSlUyNlF6bnMzZExsd1I1RWlV V01XZWE2eHJrRW1DTWdaSzlGR3FraldaQ3JYCmd6VC9MQ3JCYkJsRFNnZUY1OU44OWlGbzcrcnlV cDkvazVEUEFnTUJBQUdqUWpCQU1BNEdBMVVkRHdFQi93UUVBd0lCQmpBUEJnTlYKSFJNQkFmOEVC VEFEQVFIL01CMEdBMVVkRGdRV0JCUmdlMllhUlEyWHlvbFFMMzBFelRTby8vejlTekFOQmdrcWhr aUc5dzBCQVFVRgpBQU9DQVFFQTFuUG5mRTkyMEkyLzdMcWl2alRGS0RLMWZQeHNuQ3dydlFtZVU3 OXJYcW9SU0xibENLT3p5ajFoVGROR0NiTSt3NkRqClkxVWI4cnJ2clRuaFE3azRvK1l2aWlZNzc2 QlFWdm5HQ3YwNHpjUUxjRkdVbDVnRTM4TmZsTlVWeVJSQm5NUmRkV1FWRGY5Vk1PeUcKai84Tjd5 eTVZMGIycXZ6ZnZHbjlMaEpJWkpyZ2xmQ203eW1QQWJFVnRRd2RwZjVwTEdra2VCNnpweHh4WXU3 S3lKZXNGMTJLd3ZoSApobTRxeEZZeGxkQm5pWVVyK1d5bVhVYWRES3FDNUpsUjNYQzMyMVk5WWVS cTRWelc5djQ5M2tITUI2NWpVcjlUVS9RcjZjZjl0dmVDClg0WFNRUmpiZ2JNRUhNVWZwSUJ2RlNE SjNneUlDaDNXWmxYaS9FakpLU1pwNEE9PQotLXtib3VuZGFyeX0tLQoK
結論から言えば、これはBASE64でエンコードされたファイルである。
デコードしてみる。
$ base64 -d passpoint.config
Content-Type: multipart/mixed; boundary={boundary}
Content-Transfer-Encoding: base64
--{boundary}
Content-Type: application/x-passpoint-profile
Content-Transfer-Encoding: base64
PE1nbXRUcmVlIHhtbG5zPSJzeW5jbWw6ZG1kZGYxLjIiPgogIDxWZXJEVEQ+MS4yPC9WZXJEVEQ+
CiAgPE5vZGU+CiAgICA8Tm9kZU5hbWU+UGVyUHJvdmlkZXJTdWJzY3JpcHRpb248L05vZGVOYW1l
PgogICAgPFJUUHJvcGVydGllcz4KICAgICAgPFR5cGU+CiAgICAgICAgPERERk5hbWU+dXJuOndm
YTptbzpob3RzcG90MmRvdDAtcGVycHJvdmlkZXJzdWJzY3JpcHRpb246MS4wPC9EREZOYW1lPgog
ICAgICA8L1R5cGU+CiAgICA8L1JUUHJvcGVydGllcz4KICAgIDxOb2RlPgogICAgICA8Tm9kZU5h
bWU+WDE8L05vZGVOYW1lPgogICAgICA8Tm9kZT4KICAgICAgICA8Tm9kZU5hbWU+Q3JlZGVudGlh
bDwvTm9kZU5hbWU+CiAgICAgICAgPE5vZGU+CiAgICAgICAgICA8Tm9kZU5hbWU+Q3JlYXRpb25E
YXRlPC9Ob2RlTmFtZT4KICAgICAgICAgIDxWYWx1ZT4yMDE3LTAyLTE2VDE0OjIxOjM2WjwvVmFs
dWU+CiAgICAgICAgPC9Ob2RlPgogICAgICAgIDxOb2RlPgogICAgICAgICAgPE5vZGVOYW1lPlVz
ZXJuYW1lUGFzc3dvcmQ8L05vZGVOYW1lPgogICAgICAgICAgPE5vZGU+CiAgICAgICAgICAgIDxO
b2RlTmFtZT5NYWNoaW5lTWFuYWdlZDwvTm9kZU5hbWU+CiAgICAgICAgICAgIDxWYWx1ZT50cnVl
PC9WYWx1ZT4KICAgICAgICAgIDwvTm9kZT4KICAgICAgICAgIDxOb2RlPgogICAgICAgICAgICA8
Tm9kZU5hbWU+RUFQTWV0aG9kPC9Ob2RlTmFtZT4KICAgICAgICAgICAgPE5vZGU+CiAgICAgICAg
ICAgICAgPE5vZGVOYW1lPkVBUFR5cGU8L05vZGVOYW1lPgogICAgICAgICAgICAgIDxWYWx1ZT4y
MTwvVmFsdWU+CiAgICAgICAgICAgIDwvTm9kZT4KICAgICAgICAgICAgPE5vZGU+CiAgICAgICAg
ICAgICAgPE5vZGVOYW1lPklubmVyTWV0aG9kPC9Ob2RlTmFtZT4KICAgICAgICAgICAgICA8VmFs
dWU+TVMtQ0hBUC1WMjwvVmFsdWU+CiAgICAgICAgICAgIDwvTm9kZT4KICAgICAgICAgIDwvTm9k
ZT4KICAgICAgICAgIDxOb2RlPgogICAgICAgICAgICA8Tm9kZU5hbWU+VXNlcm5hbWU8L05vZGVO
YW1lPgogICAgICAgICAgICA8VmFsdWU+aG9nZUBleGFtcGxlLm5ldDwvVmFsdWU+CiAgICAgICAg
ICA8L05vZGU+CiAgICAgICAgICA8Tm9kZT4KICAgICAgICAgICAgPE5vZGVOYW1lPlBhc3N3b3Jk
PC9Ob2RlTmFtZT4KICAgICAgICAgICAgPFZhbHVlPmhvZ2VwYXNzPC9WYWx1ZT4KICAgICAgICAg
IDwvTm9kZT4KICAgICAgICA8L05vZGU+CiAgICAgICAgPE5vZGU+CiAgICAgICAgICA8Tm9kZU5h
bWU+UmVhbG08L05vZGVOYW1lPgogICAgICAgICAgPFZhbHVlPm9keXNzeXMubmV0PC9WYWx1ZT4K
ICAgICAgICA8L05vZGU+CiAgICAgIDwvTm9kZT4KICAgICAgPE5vZGU+CiAgICAgICAgPE5vZGVO
YW1lPkhvbWVTUDwvTm9kZU5hbWU+CiAgICAgICAgPE5vZGU+CiAgICAgICAgICA8Tm9kZU5hbWU+
RnJpZW5kbHlOYW1lPC9Ob2RlTmFtZT4KICAgICAgICAgIDxWYWx1ZT5XaUZpIFBvd2VyZWQgYnkg
T2R5c3N5c+KEojwvVmFsdWU+CiAgICAgICAgPC9Ob2RlPgogICAgICAgIDxOb2RlPgogICAgICAg
ICAgPE5vZGVOYW1lPkZRRE48L05vZGVOYW1lPgogICAgICAgICAgPFZhbHVlPm9keXNzeXMubmV0
PC9WYWx1ZT4KICAgICAgICA8L05vZGU+CiAgICAgIDwvTm9kZT4KICAgIDwvTm9kZT4KICA8L05v
ZGU+CjwvTWdtdFRyZWU+Cg==
--{boundary}
Content-Type: application/x-x509-ca-cert
Content-Transfer-Encoding: base64
MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCQkUx
GTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkds
b2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAwMDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNV
BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYD
VQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDa
DuaZjc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavpxy0Sy6sc
THAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp1Wrjsok6Vjk4bwY8iGlb
Kk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdGsnUOhugZitVtbNV4FpWi6cgKOOvyJBNP
c1STE4U6G7weNLWLBYy5d4ux2x8gkasJU26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrX
gzT/LCrBbBlDSgeF59N89iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUF
AAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOzyj1hTdNGCbM+w6Dj
Y1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE38NflNUVyRRBnMRddWQVDf9VMOyG
j/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymPAbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhH
hm4qxFYxldBniYUr+WymXUadDKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveC
X4XSQRjbgbMEHMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A==
--{boundary}--こうなった。
更に、x-passpoint-profile部分を抜き出してデコードしてみる。
<MgmtTree xmlns="syncml:dmddf1.2">
<VerDTD>1.2</VerDTD>
<Node>
<NodeName>PerProviderSubscription</NodeName>
<RTProperties>
<Type>
<DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
</Type>
</RTProperties>
<Node>
<NodeName>X1</NodeName>
<Node>
<NodeName>Credential</NodeName>
<Node>
<NodeName>CreationDate</NodeName>
<Value>2017-02-16T14:21:36Z</Value>
</Node>
<Node>
<NodeName>UsernamePassword</NodeName>
<Node>
<NodeName>MachineManaged</NodeName>
<Value>true</Value>
</Node>
<Node>
<NodeName>EAPMethod</NodeName>
<Node>
<NodeName>EAPType</NodeName>
<Value>21</Value>
</Node>
<Node>
<NodeName>InnerMethod</NodeName>
<Value>MS-CHAP-V2</Value>
</Node>
</Node>
<Node>
<NodeName>Username</NodeName>
<Value>hoge@example.net</Value>
</Node>
<Node>
<NodeName>Password</NodeName>
<Value>パスワードがBase64でデコードされたやつ</Value>
</Node>
</Node>
<Node>
<NodeName>Realm</NodeName>
<Value>odyssys.net</Value>
</Node>
</Node>
<Node>
<NodeName>HomeSP</NodeName>
<Node>
<NodeName>FriendlyName</NodeName>
<Value>WiFi Powered by Odyssys™</Value>
</Node>
<Node>
<NodeName>FQDN</NodeName>
<Value>odyssys.net</Value>
</Node>
</Node>
</Node>
</Node>
</MgmtTree>なるほど。
NTTドコモが配信する「メッセージR/S」*1といったメッセージは、ドコモが販売するAndroidスマートフォン（「ドコモメール」アプリを使用）、あるいはiPhone/iPad（メールアカウント情報が含まれた専用のプロファイルをダウンロードしてインストール）でしか受信ができない。
（所謂キャリアメールは「ドコモメール」として適切な設定を行えばIMAPメールクライアントからdocomo ID/パスワードで認証して利用可能。）
このうち、Android用の「ドコモメール」については、docomo Application Manager*2が必要であり、NTTドコモから販売されているNexus 5Xについては対応機種に含まれていない*3ため、ダウンロード・インストールすることができない。
SIMフリーのAndroid機でも同様である。
当然、Windows Phone 8.1 UpdateやWindows 10 Mobileを搭載するMADOSMAでも通常の方法ではメッセージR/Sは受信ができない。
ほとんどがどうでもいい内容のメッセージRであるが、稀に機種変更に使えるクーポンや、ドコモショップからの連絡などが来る場合があるのでなんとなく受信できるようにしておきたい。
「メッセージR/S」は、ドコモのみが配送を許された専用のメールボックスに配信されたメールを、ユーザがPOP3で受信するサービスである。
しかしながら、POP3のパスワードはユーザに公開されておらず、また複雑な仕組みで動的に自動生成される非常に長いものであるため、ユーザは任意のPOP3クライアントで「メッセージR/S」を受信することは困難である。
このため、iPhoneを別途用意し、メッセージRを受信したい回線のSIMを挿した状態で「iPhone初期設定」のプロファイルをダウンロードする。
Safariでプロファイルをダウンロードすると、自動的にプロファイルのインストールに進んでしまい、プロファイルの内容を解析することができないため、他の手段でファイルとしてプロファイルをダウンロードする。
2015/12/1現在、最も簡単な方法は下記のとおり。
1) App StoreからLS Appsの「Downloads Free」をiPhoneにインストールする。
2) Downloads Freeを使用して「iPhone初期設定」のプロファイルをファイルとしてダウンロードし、その後保存したプロファイルをメールでPCに転送する。
3) PCでテキストエディタを使用してプロファイルを開く。xmlで上から順に「ドコモメール」「メッセージR/S」「ドコモのサービスへのショートカットアイコン」と並んでいるので、メッセージR/SのIncomingPasswordを抜き取る。サーバ設定はプロファイルに書いてある通り。
このようにして抽出した「メッセージR/S」のアカウント情報を、MADOSMAに設定してみると下記のようにメッセージRが受信できるようになる。
SIMを入れ替えてプロファイル抽出の手順を繰り返して設定することにより、複数回線のドコモメール、メッセージR/Sをすべて1台のMADOSMAで受信することも可能で、タイルアイコンが非常にわかりやすくて便利である。
メッセージR/Sのパスワードは動的に生成されるが、プロファイルダウンロード後に変更されたパターン・変更されないパターンは下記の通り。
■プロファイルをSPモード接続したiPhoneからダウンロードする
パスワードが変更されないパターン
→ 当該回線のSIMを、そのままSPモード接続したiPhoneに挿したまま通信
→ 当該回線のSIMを、moperaに接続したMADOSMAに挿して通信
→ 当該回線のSIMを、SPモード接続したSIMフリールーター（MR04LN）に挿して通信
パスワードが変更されたパターン（プロファイルから抽出したパスワードが通らなくなる）
→ 当該回線のSIMを、SPモード接続したMADOSMAに挿して通信（moperaに戻したら旧パスワードで認証通った。ラグがある？）
→ 当該回線のSIMを、SPモード接続したNexus 5Xに挿して通信
→ 当該回線のSIMを、SPモード接続したXperiaに挿して通信
Fire TV Stickが届いた。
けっこう嵌ったので、うろ覚えだけどメモ。
■はまる条件
amazon.co.jp と amazon.com に同じメールアドレスでアカウントを持っている場合。
今回の事象では、amazon.co.jp に pirosap@example.com (パスワード hoge_us）でアカウントがあり、
かつ amazon.com にも pirosap@example.com（パスワード hoge_jp）でアカウントがあり、
両方にクレジットカードを登録していた。
パスワードを変えていたのはたまたま。
■はまった事例
FireTVを起動し、初期セットアップ。
Amazonアカウントでサインインしな、と言うので パスワード hoge_us でサインインした。（※第１の誤り）
後で気づいたが、ここでUS版にログインしてしまっていた。
いきなり英語のアニメーションが始まり、全編英語でFire TV Stickの使い方を説明してくれた。
みんなこれで使い方わかるのかな？？？ってなった。（この時点ではまだ気づいていない）
Prime会員になったら楽しいよ、今なら30日Free Trialだよ、と出るので、「いや俺プライム会員のはずだけどな？」と思いながらFree Trialを押した（※第２の誤り）
"Pirosap Hoge"さんのアカウントにFire TVを紐づけますか？的なメッセージが出たので、よろしく！とやった（※第３の誤り ２と３は逆だったかもしれない。）
UIは日本語なんだけど、表示される映画がほとんどみたことないものばかり。日本語コンテンツが無い。
これは知ってるなー、とBack to the Futureを見つけたが、視聴しようとすると
INVALID_GEO_IP
というエラーが出て何も視聴できない。
唯一Back to the Futureの予告編が英語で見れたぐらい。
何かおかしいなー？と思いつつ、INVALID_GEO_IPってことはうちのIPアドレスが日本と思われてないのか・・・？って考えているうちに
ふと去年USのAmazonからお取り寄せをしたことがあるのを思い出した。
PCでamazon.co.jpにログインしてみると、Fire TV Stickに入力したパスワードとそういえば違ってhoge_jpだった。
ここで気づいて、amazon.comにhoge_usでログインしてみるとログインできた。
■結論
Fire TV Stickを使うときに、amazon.comにもアカウントある人は事前にamazon.comとamazon.co.jpのパスワードを変えておく。
Fire TV Stickは恐らく内部で、まずamazon.comに認証しにいって、認証失敗すると次にamazon.co.jpに認証を試みるのではないかと思われる。
amazon.co.jpのパスワードを使ってサインインすると、ちゃんと日本版にログインできて、見たことがあるコンテンツがいっぱいでハッピーになれる。
誤ってUS版にログインしてしまっても、IPアドレスから地域を判別しているので視聴可能区域外と判定されて何も見れない。
■あとしまつ
上記にはまっちゃった人は、一旦Fire TVからamazonアカウントの紐づけを解除した上で、amazon.co.jpのパスワードでサインインしなおす。
■ドジっこのあとしまつ
第２の誤りで、US版のPrime会員のFree Trialをポチってしまっていて、かつ有効なクレジットカードが登録されているので、30日経過すると課金される。
amazon.comにログインして、Prime会員の継続を"Do not continue"で止めておくこと。
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.pdfhttps://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 HelpSystem 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証明書をインストールすると、通知領域に信頼できる認証情報が端末にインストールされている旨の警告が表示される。 |
|
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証明書として指定しちゃえば繋がるんじゃないか？と思ってごにょごにょやってみたが、そうはいかないようだ。
■事前準備（推奨）
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「位置情報とセキュリティ」→「認証情報ストレージ」から「パスワードの設定」をクリックしてパスワードを設定しておく。画面ロックは設定しなくてもよい。あらかじめ有効にしておかない場合、設定中にパスワードの設定が促される。
■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「切断されました」等と表示され、接続が完了しない。
■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
（この際、リンクを長押ししてしまうとダウンロードとなり、MicroSDカードがマウントされていないとのメッセージが表示されるので注意）
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、適当に名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。
事前準備の通り「認証情報ストレージ」のパスワードが設定されていないと、この時点でパスワードを設定するようダイアログが表示される。
2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。
3. EAP-PEAPのID、パスワードを入力し、接続。
■制限事項
端末を再起動すると、自動で再接続されない。SSIDを選択して接続する際に、「認証情報ストレージ」のパスワード入力を求められる。
■事前準備（推奨）
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「位置情報とセキュリティ」→「認証情報ストレージ」から「パスワードの設定」をクリックしてパスワードを設定しておく。画面ロックは設定しなくてもよい。あらかじめ有効にしておかない場合、設定中にパスワードの設定が促される。
■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「切断されました」等と表示され、接続が完了しない。
■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
（この際、リンクを長押ししてしまうとダウンロードとなり、MicroSDカードがマウントされていないとのメッセージが表示されるので注意）
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、適当に名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。
事前準備の通り「認証情報ストレージ」のパスワードが設定されていないと、この時点でパスワードを設定するようダイアログが表示される。
2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。
3. EAP-PEAPのID、パスワードを入力し、接続。
■制限事項
端末を再起動すると、自動で再接続されない。SSIDを選択して接続する際に、「認証情報ストレージ」のパスワード入力を求められる。
■事前準備
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「その他の設定」→「ロックとセキュリティ」→「画面のロック」を「パターン」「ロックNo.」「パスワード」のいずれかにする。「なし」「スライド」「顔認証」は使用不可。あらかじめ有効にしておかない場合、設定中にロック方式を変更し、認証情報ストレージを有効にするよう促される。
■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。
■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、適当に名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。
事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。
2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。
3. EAP-PEAPのID、パスワードを入力し、接続。
■制限事項
いったん接続完了後に端末を再起動すると、自動で再接続されない。
画面ロック解除後に接続状態を確認すると「認証に問題」となっている。
SSIDを選択して手動で接続を行うと再接続される。
■事前準備
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「その他の設定」→「ロックとセキュリティ」→「画面のロック」を「パターン」「ロックNo.」「パスワード」のいずれかにする。「なし」「スライドまたはタッチ」「顔認証」は使用不可。あらかじめ有効にしておかない場合、設定中にロック方式を変更し、認証情報ストレージを有効にするよう促される。
■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。
■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、適当に名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。
事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。
2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。
3. EAP-PEAPのID、パスワードを入力し、接続。
■制限事項
いったん接続完了後に端末を再起動すると、自動で再接続されない。
画面ロック解除後に接続状態を確認すると「認証に問題」となっている。
SSIDを選択して手動で接続を行うと再接続される。
■事前準備
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「その他の設定」→「ロックとセキュリティ」→「画面のロック」を「パターン」「ロックNo.」「パスワード」のいずれかにする。「なし」「スライドまたはタッチ」「顔認証」は使用不可。あらかじめ有効にしておかない場合、設定中にロック方式を変更し、認証情報ストレージを有効にするよう促される。
■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。
■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、英字と数字のみの名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。
事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。
2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。
3. EAP-PEAPのID、パスワードを入力し、接続。
■制限事項
いったん接続完了後に端末を再起動すると、自動で再接続されない。
画面ロック解除後に接続状態を確認すると「認証に問題」となっている。
SSIDを選択して手動で接続を行うと再接続される。
■事前準備
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「その他の設定」→「ロックとセキュリティ」→「画面のロック」を「パターン」「ロックNo.」「パスワード」のいずれかにする。「なし」「スライドまたはタッチ」「顔認証」は使用不可。あらかじめ有効にしておかない場合、設定中にロック方式を変更し、認証情報ストレージを有効にするよう促される。
■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についてはそのような挙動は発生しなかった。
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.
#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.
いろいろと疑問は残っているのだが、一度ここらへんで公開してみる。
随時加筆します。
MADOSMAを使い出して3か月経った。
インストールしてみて気に入ったストアアプリを書き連ねてみる。
各アプリへのリンクは、MADOSMAでダウンロード履歴から「共有」でOneNoteにリンク書き出して、PC上でhatenaにペーストしているので、Windows Phoneでクリックするとストアに飛ぶ（たぶん）。
■ソーシャル系
公式サイト http://aristea.cc/
ありすてあ。Twitterクライアント。使ってすぐに気に入ったので他のクライアントは試していない。
特徴はいろいろあるけれど、Windows Phone 8.1によくマッチしている操作性だと思う。
某クーポンの使い道に困っているならまず購入して損はないと思う。
Olympus製のミラーレス一眼などに搭載されているWi-Fiに接続して、カメラに保存されている写真をプレビューしながらWindows Phoneのカメラロールに写真をダウンロードできる（JPEGのみ、RAWは未対応）。
アプリの説明にはE-M1, PEN E-P5, Stylus-1のみ記載されているが、当方ではE-M10との接続・写真転送を確認できた。
無線LAN機能付きSDカード「FlashAir」にWi-Fiで接続して、カードに保存されている写真をプレビューしながらWindows Phoneのカメラロールに写真をダウンロードできる。
E-PL6など、Wi-Fiが内蔵されていないカメラを使うのに便利。
■MS謹製
ハイパーラプス（≠タイムラプス）動画が作成できるアプリ。
動画撮影してスライダーで速度調整するだけでハイパーラプス動画が作成できる。
窓の杜のレビューがわかりやすい。
【レビュー】Windows Phone端末のカメラで簡単に“タイムラプス”動画を作成「Hyperlapse Mobile」 - 窓の杜
リモートデスクトップクライアント。IPv6でもさくっとWindows PCに接続できる。
画面はMADOSMAだとちっちゃいけど、自宅に接続できるようにしておくと意外となんでもできる。
2015/8/13追記 本脆弱性(CVE-2015-3760)は、OS X 10.10.5で修正されています。 https://support.apple.com/ja-jp/HT205031
2015/7/26追記 SektionEinsのStefan Esserさんから、SUIDGuardを起動時に自動読み込みできるようpkg化したSUIDGuardNGが公開されました。
https://github.com/sektioneins/SUIDGuard/releases/download/1.0.0d1/SUIDGuardNG.pkg
https://twitter.com/i0n1c/status/624501679237517312:twitter:detail:left
当該pkgを管理者権限を利用可能なユーザでインストールし再起動すると、下記の通りOS X起動時にSUIDGuardNGがロードされます。
（脆弱性が存在するSUIDGuardによる対策を行っていなかった10.10.4にて検証）
利用は自己責任で。
bash-3.2# kextstat | grep SUID
58 0 0xffffff7f80a3e000 0x3000 0x3000 com.sektioneins.driver.SUIDGuardNG (1) <7 4 3 2 1>
bash-3.2# dmesg | grep SUID
Security policy loaded: SUID Guard Kernel Extension (suidguard)
SUIDGuardNG.pkgでインストールされるのはこんな感じ。
$ pkgutil --pkgs=.*SUIDGuardNG.*
com.sektioneins.driver.SUIDGuardNG$ pkgutil --files com.sektioneins.driver.SUIDGuardNG
Library
Library/Extensions
Library/Extensions/SUIDGuardNG.kext
Library/Extensions/SUIDGuardNG.kext/Contents
Library/Extensions/SUIDGuardNG.kext/Contents/Info.plist
Library/Extensions/SUIDGuardNG.kext/Contents/MacOS
Library/Extensions/SUIDGuardNG.kext/Contents/MacOS/SUIDGuardNG
Library/Extensions/SUIDGuardNG.kext/Contents/_CodeSignature
Library/Extensions/SUIDGuardNG.kext/Contents/_CodeSignature/CodeResources
注意▪️twitter等でワンライナーで広まっているDYLD_PRINT_TO_FILE脆弱性を試してrootを取得した場合、/etc/sudoersが書き換えられます。
/etc/sudoersを元に戻すのはSUIDGuard/SUIDGuardNGの役目ではありませんので、必ず/etc/sudoersの内容が元に戻っているかどうか確認してください。
https://twitter.com/i0n1c/status/624644608526577664:twitter:detail:left
https://twitter.com/i0n1c/status/624653431526019072:twitter:detail:left
※追記ここまで-------------------------------
騒がれているOS X Yosemiteにて一般ユーザがroot権限を奪取できる脆弱性について、ちょっと気になったのでメモ。
当該脆弱性は、7/7にドイツのSektionEins GmbHが、下記で公開したものである。
「OS X 10.10 DYLD_PRINT_TO_FILE Local Privilege Escalation Vulnerability」
https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_file_lpe.html
日本では、下記あたりから認識が広まったようだ。
https://twitter.com/applechinfo/status/623996009824190464:twitter:detail:left
合わせて、当該脆弱性に対処するためのSUIDGuard がSektionEins GmbHより先日公開された。
https://github.com/sektioneins/SUIDGuard
これを受けて、@applechinfo さんが
https://twitter.com/applechinfo/status/624071261950357504:twitter:detail:left
で実際にSUIDGuardを試されている。
が、
「 "SUIDGurd.kext"は約300行もないCコードでSektionEinsの署名付き、使い方は"/System/Library/Extensions"へコピーするだけで、管理者権限での認証が必要ですが、認識されればSUID/SGID rootバイナリが環境変数” DYLD_*”から保護されるようになっています。」
と書かれているが、若干説明が不足しているように思う。
まず、10.10以降はkextへの署名が必須になった。このため、署名のないkextをロードすることが標準ではできないので、SektionEinsが署名したうえで公開してくれているのはとても意味がある。
kextへの署名は、通常のアプリへの署名とは異なり、Appleに個別に権限リクエストが必要であり、Appleが許可をして初めてCertificationCenterからkext用署名のリクエストができるようになる、というめんどくさい流れになっている。
（参考：http://qiita.com/gamako/items/9980a08a24916f9f98b2）
このため、SektionEinsがgithubで公開してくれているソースコードを、自らXcodeでBuildしても、Yosemiteではロードに失敗する。
よって、下記にあるSektionEinsが署名済のSUIDGuard.kextを使用する必要がある。
https://github.com/sektioneins/SUIDGuard/releases
そして、上記applechinfoさんの検証記事に記載されているスクリーンショットでは、確かにSUIDGuardは確認済の開発元として署名されていることは確認できるものの、SUIDGuardは「読み込み済：いいえ」「読み込み可能：いいえ」となってしまっている。
大学など、不特定多数の人間が一般ユーザで利用する環境において、当該脆弱性を回避するならば、SUIDGuardを起動時にロードさせる必要があるので、手順を簡単に書くと下記の通りとなる。
※root権限を使用できるユーザで作業する
※SUIDGuard.kext.tar.bz2 をダウンロードしておく
$ sudo -s Password: # # chown root:wheel SUIDGuard.kext.tar.bz2 # tar -xvzf SUIDGuard.kext.tar.bz2 x SUIDGuard.kext/ x SUIDGuard.kext/Contents/ x SUIDGuard.kext/Contents/_CodeSignature/ x SUIDGuard.kext/Contents/Info.plist x SUIDGuard.kext/Contents/MacOS/ x SUIDGuard.kext/Contents/MacOS/SUIDGuard x SUIDGuard.kext/Contents/_CodeSignature/CodeResources # mv SUIDGuard.kext /System/Library/Extensions # kextutil -b com.sektioneins.SUIDGuard # cd /Library/LaunchDaemons # vi jp.ac.example.SUIDGuard.plist
jp.ac.example.SUIDGuard.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeepAlive</key>
<false/>
<key>Label</key>
<string>jp.ac.example.SUIDGuard</string>
<key>ProgramArguments</key>
<array>
<string>/sbin/kextload</string>
<string>/System/Library/Extensions/SUIDGuard.kext</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/dev/null</string>
<key>StandardOutPath</key>
<string>/dev/null</string>
<key>UserName</key>
<string>root</string>
</dict>
</plist>続き
# plutil -lint jp.ac.example.SUIDGuard.plist
jp.ac.example.SUIDGuard.plist: OK
# launchctl load -w jp.ac.example.SUIDGuard.plist
# launchctl list | grep SUID
- 0 jp.ac.example.SUIDGuard
# kextstat | grep SUID
131 0 0xffffff7f82a38000 0x2000 0x2000 com.sektioneins.SUIDGuard (1) <7 4 2 1>
# dmesg | grep SUID
Security policy loaded: SUID Guard Kernel Extension (suidguard)再起動し、起動時に正常にSUIDGuardが読み込まれているか確認する。
