DS-216JのVPN（L2TP/IPsec）サービス稼働

ヤマハのNVR-500でPPTPによるVPNサーバを稼働していたが、脆弱性問題で停止していた。最近発売されたNVR-510には、L2TP/IPsecのVPN機能がサポートされているらしい。NVR-500は、2011年10月から快調に稼働している（2017年10月30日 Rev. 11.0.36でL2TP/IPSec機能が追加された-喜ばしい！）。
PR-S300SE（NTTフレッツひかり）は、VPN機能が無い。PR-400以降は、L2TP/IPsecのVPN機能が使えるらしいが、PR-S300SEが元気なので変更してもらえそうに無い。。。
DS-216J NAS（ファイルサーバー）を導入した。このDS-216Jには、VPNサービスが提供されている（PPTP, OpenVPN, L2TP/IPsec）。L2TP/IPsecによるVPNを稼働してみることにした。
DS-216JへのL2TP/IPsec VPNサーバー導入方法に詳しく書かれている。

稼働後のCPU負荷状況もそれほど高く無いようだ。VPN接続後、接続端末に付与されるIPは、「10.2.0.1 - 10.2.0.254」の内の一つとなり、DS-216Jでルーティングされることになる。DS-216JのVPN設定は、解説通りの設定で動作確認できた（ホームネットワークのにWiFi接続し、IP指定でiPhoneのL2TP接続で確認）。
ネットワーク構成とL2TP/IPsecパケット通信の流れを図示する。

インターネト上のiPhoneからL2TPでVPN接続を行うと、ヤマハ提供のネットボランチDDNSで名前解決し、ぷらら（ISP）の接続IP（グローバルIP）へ接続する。ぷららへの接続は、ヤマハNVR-500からPPPoEで接続されている。フレッツひかりルータPR-S300SEは、NTT東地域IP網へ接続されおり、ひかり電話とフレッツTVサービスを受けている。ホームネットワーク内の機器やDS-216JのVPNへは、NVR-500でFirewall遮断されている。
iPhoneからDS-216Jまでどのようなパケットが通過するか確認すると

NVR-500上では、ぷららからPPPoE接続で、pp（ポイント・ツー・ポイント インターフェース）にIPsecパケットが渡されることになり、そのまま、DS-216Jへ転送すれば良いことになる。ppとLAN間には、「NAT Descriptor」「In/Out Filter」が存在し、「1:N」（NAPT接続 - ヤマハでは、masquerade）で接続転送する必要がある。L2TP/IPsecのVPNであるが、NVR-500上では、IPsec通信として設定する。
（１）NAT Descriptor（NAPT）設定
NVR-500の標準設定状態では、pp1（ぷららPPPoE接続）は、「masquerade」が設定されている。
IPSec鍵交換のために、IKE（500/udp）をDS-216Jへstatic natする。
IPsec NAT Traversal が必要な接続のために、 IKE NAT-T（4500/udp）をDS-216Jへstatic natする。
ESP（Encapsulated Security Payload）プロトコルをDS-216Jへstatic natする。


（２）セキュリティ・フィルタの設定
pp1のIN方向フィルタに、
IKE（500/udp）を全てのアドレスからDS-216Jへ許可する。
IKE NAT-T（4500/udp）を全てのアドレスからDS-216Jへ許可する。
ESP（プロトコル 50）を全てのアドレスからDS-216Jへ許可する。


NVR-500のconfigファイルは、


iPhone6S iOS11 L2TP/IPsecで接続（VPNをONにする）


L2TP/IPsec接続される（端末IPは、10.2.0.1が付与される）


構成プロファイルで「On Demand」接続を試みる予定

iPhoneにインストールされた期限切れ電子証明書

iPhone構成ユーティリティのシミュレートで使用したデバイス証明書の有効期限が切れた。

iPhoneがどのように振る舞うか確認した。
・「設定」「一般」「プロファイル」の一覧表示で表示名が「赤文字」に変わる。
・証明書のタイトル下に赤文字で「期限切れ：（期限日付表示）」が表示される。

機能的な変化は、無いようだ。opensslで期限切れの証明書で暗号化も署名も可能だ。
iPhoneが期限切れ証明書で暗号化や署名が可能か確認できない（SMIMEメールでも設定されていれば確認可能）が、問題は無いと推定される。
------------
p.s.
iPhone構成ユーティリティの電子証明書は、「IPCU-CA」が２年。デバイス証明書は、1年。
期限が切れた場合は、IPCU-CAは、iPhone構成ユーティリティの再インストールで2年間のIPCU-CA証明書が再生成される。
デバイスは、「ライブラリ」「デバイス」で期限切れデバイスプロファイルを削除後に再接続すれば、再生成されるのでは無いかと思うが、未確認。

「iPhone構成ユーティリティ」のシミュレート

iPhone4(2010年6月）の発売と同じ頃、「iPhone構成ユーティリティ」の存在を知った。
Windows用とMac用が提供されていた。2014年12月中頃からダウンロードができなくなった。Mac版は、3.5も利用していたが、OSのアップデートの後、Launchpadからアイコンが消えていた。Windows版は、3.6が最終であったが、これもいつしか起動できなくなった。
現在は、appleサイトからMac用の古い2.2版がダウンロードできるだけである。この古い版のパッケージ署名は2012年3月24日で期限切れとなっており更新されていない。
Windows版の起動については、「iPhone構成ユーティリティVer3.5 for Windowsの起動」でiTunesでもアップデートされる「Apple Mobile Device Support」のバージョンによって起動が出来なくなることが紹介されていた。手持ちで確保してあった「iPhoneConfigUtilitySetup.exe（45,546,424bytes）」をiTunesのインストールされていないWindows7にインストール、起動、実行が可能だった。

「iPhone構成ユーティリティ」は、構成プロファイルリファレンスに基づき構成プロファイルを生成管理すると共に署名、暗号化して配布するツールだ。この構成プロファイルは、iOSのバージョンアップと共にプロファイルキーも更新されていくので古いiPhone構成ユーティリティでは、対応できない場合や構成プロファイルそのものがエラーとなりインストール出来ない場合もあった。構成プロファイルについては、APNペイロードがsim free iPhoneや脱獄iPhoneと共に語られている事が多かったように記憶している。

「WiFi」「メール」「VPN」などの設定を一括記載した構成プロファイルを作成したり、機器操作では出来ない「WiFiのEAP-TLS設定」「SMIMEメール設定」「VPNのOnDemand接続」「HTTPSクライアント認証用証明書配布」など企業用途も考慮されていた。SoftBank、Au、DoCoMoなどは、キャリアメール設定にOTA配布の構成プロファイルを利用している。

AuからAEON（MVNO）にMNPする際に、各種設定を構成プロファイルを利用した。構成プロファイルには、アカウントのパスワード記載が平文であるため、iPhone構成ユーティリティと同様に「暗号化した構成プロプロファイル」をツールで作成したのでメモしておくことにした。

「iPhone構成ユーティリティ」は、起動時に「認証機関（CA）」用の自己署名証明書を生成する。iPhone/iPadを接続すると機器固有の証明書を「SCEP」（多分 - OSXサーバのProfile managerがSCEP）のような手法で生成する。


機器には、秘密鍵と署名要求（CSR）。署名要求をユーティリティへ転送。ユーティリティの認証機関（CA）でCSRに署名しデバイス証明書として生成。ユーティリティに保管と同時にデバイスに返送する。WindowsのSCEPサーバとiPhoneのSCEP機能でデバイス認証が確保できそうである。

生成されたCA鍵は、windowsの「certmgr.msc」で確認できる。秘密鍵のexportは出来ない（秘密鍵は、IPCU.exeのアプリケーションデータとして保存されているようだ）。




テスト用に作成した「WEB CLIPペイロード」の構成プロファイル「testclip.mobileconfig」をインポートしてみる


インポート後の構成プロファイル表示「一般ペイロード部」


「Web クリップ ペイロード部」


インポートした構成プロファイルに署名してみた（CAの秘密鍵で署名される）「ipcu-sign-testclip.mobileconfig」で保存。メメニューバーの「書き出す」ダイアログボックス「セキュリティ」「構成プロファイルに署名」で「エクスポート」


暗号化は、配布する機器の証明書が必要なため証明書選択画面が表示される

一覧に証明書が無いのは、一度も機器の接続が無いため「デバイス証明書」が登録されていない。

署名された「ipcu-sign-testclip.mobileconfig」をMacのopensslで検証（windowsのopenssl/binaryでも可）してみた。検証後、署名が取り外された「ipcu-verify-testclip.mobileconfig」ファイルを生成。生成されたファイルは、「testclip.mobileconfig」と同等と成る。署名者の公開鍵「ipcu-ca-tool-cert.pem」は、certmng.mscで「IPCA/証明書」にある公開鍵を書き出す。ファイル名「ipcu-ca-tool-cert」で書き出す。「.p7b」ファイルなので、X509のpemファイルに変換する。

--- pkcs7 to x509
openssl pkcs7 -print_certs -inform der -in ipcu-ca-tool-cert.p7b -out ipcu-ca-tool-cert.pem

--- X509か確認
openssl x509 -text -in ipcu-ca-tool-cert.pem

--- 署名チェック結果
openssl smime -verify -inform der -in ipcu-sign-testclip.mobileconfig -certfile ipcu-ca-tool-cert.pem -CAfile ipcu-ca-tool-cert.pem -out ipcu-verify-testclip.mobileconfig



--- diffでtestclip.mobileconfigとipcu-verify-testclip.mobileconfigの比較確認
diff testclip.mobileconfig ipcu-verify-textclip.mobileconfig



iPhone構成ユーティリティ（IPCU）をシミュレートするには
・(1)IPCU同様にデバイス証明書に署名ができるCA機能を持つ認証機関としての証明書（公開鍵と秘密鍵）
・(2)iPhone毎に固有な(1)発行のデバイス証明書（公開鍵と秘密鍵）
・(3)iPhone設定用の構成プロファイル（テキスト - 文字コード UTF-8/行末 LF+CR/BOM無し）
が必要となる。(2)については、SCEPなどを使い、デバイス証明書の秘密鍵がiPhone内で生成され、取り出せないようにし、デバイス固有性の確保が必要であるが、企業ユースでないので、固有性をiPhone保持者が確保することにする。また、(1)の認証機関証明書用秘密鍵パスフレーズの管理、(2)の秘密鍵パスフレーズの管理や(3)の平文でアカウント名やパスワードが記載された構成プロファイル管理については、専用暗号化USBメモリなどでセキュリティ管理が必要かも。

(1)認証機関CA用公開鍵と秘密鍵の生成
証明書の作成は、Macのopensslを使用した（Windowsのopensslでも同じだ-インストールが必要）。
opensslのconfigファイル（req.cfg）を示す


CAの公開鍵（ipcu-ca-pub.pem）と秘密鍵（ipcu-ca-key.pem）を生成する
openssl req -config req.cfg -extensions v3_ca -x509 -newkey rsa:2048 -days 730 -set_serial 1 -subj "/CN=iPCU CA 5797a8de-d4e7-4ee9-bb06-cae0efc48cc3/x500UniqueIdentifier=5797a8de-d4e7-4ee9-bb06-cae0efc48cc3" -keyout ipcu-ca-key.pem -out ipcu-ca-pub.pem


テスト用なのでCA証明書の有効期間は、2年=730日としたが、CAなので10年とか20年程の有効期限があれば、iphone10世代から20世代ほど使える。個人管理なので一生期間100年でも良いのかも。。。シリアル番号は、「1」とした。
DN（Subject）は、IPCUと同様にしているが、subj指定しなければ、req.cfgに指定された「CN=/OU=/O=/L=/C=」、「-config req.cfg」を指定せず、openssl標準のopenssl.cfgで、「eMail=/CN=/OU=/O=/L=/ST=/C=」でも良い。何れにしてもCAのDNがユニークとなるよう決める必要がある。IPCUでは、ユニークな名称をUUIDとしている。
MacでUUIDを決めるには、ターミナルで「uuidgen」とする。uuidgenは、コマンド実行毎に異なるUUIDを出力するので、コピペ使用する。

Windowsでは、「powershell -Command "[Guid]::NewGuid()"」

Macのopensslコマンドは。ハッシュ関数の標準が「sha-1」。sha-2が推奨されている。Microsoftもsha-1廃止の意向である。テストでは、IPCUをシュミレートするため、「sha-1」で生成した。
sha-2(sha256,sha384,sha512）で生成するには
openssl req -config req.cfg -extensions v3_ca -x509 -newkey rsa:2048 -days 730 -set_serial 1 -subj "/CN=iPCU CA 5797a8de-d4e7-4ee9-bb06-cae0efc48cc3/x500UniqueIdentifier=5797a8de-d4e7-4ee9-bb06-cae0efc48cc3" -sha256 -keyout ipcu-ca-key.pem -out ipcu-ca-pub.pem

生成されたCA公開鍵[自己署名]（ipcu-ca-pub.pem）


生成されたCA秘密鍵（ipcu-ca-key.pem）

証明書の内容についての参考サイト
CA証明書が生成されたので、iPhone構成ユーティリティと同様に「testclip.mobileconfig」に署名と検証を行ってみる

署名
openssl smime -sign -inform der -in testclip.mobileconfig -signer ipcu-ca-pub.pem -inkey ipcu-ca-key.pem -outform der -out testclip-sign.mobileconfig -nodetach

署名検証
openssl smime -verify -inform der -in testclip-sign.mobileconfig -certfile ipcu-ca-pub.pem -CAfile ipcu-ca-pub.pem -out testclip-sign-verify.mobileconfig



オリジナルとの比較
diff -ib testclip.mobileconfig testclip-sign-verify.mobileconfig




(2) iPhone用固有デバイス証明書の生成
デバイス固有の公開鍵（dev-pub.pem）と秘密鍵（dev-key.pem）を生成
DN(Subj）は、「/CN=」でデバイス毎に固有となるようCN=UUIDとしたが、openssl標準の「/eMail=/CN=/OU=/O=/L=/ST=/C=」でも「/CN=/OU=/O=/L=/C=」でも良い。CNをiPhoneホスト名とするのも良いかと思う。eMailを含めるとSMIME用途にも使用できるが、デバイス用途と個人アカウント用途を分離しておく方がより好ましいと思う。公開鍵は、CSR（dev-req.pem）を生成し、CAで署名をして公開鍵とする。証明書は、テスト用なので、有効期間を30日とした。実際の有効期限は、iPhone機器の寿命程度とするのが良いかと思うが、機種変更を想定すると2年か2年6か月位が適切だと思う。

CSR（dev-req.pem）を生成する
openssl req -config req.cfg -newkey rsa:2048 -subj "/CN=e23962fc-421e-476c-a321-dd6493bbd7fa" -keyout dev-key.pem -out dev-req.pem

CSRにCAで署名する（SHA-1）
openssl ca -config req.cfg -in dev-req.pem -out dev-pub.pem -cert ipcu-ca-pub.pem -keyfile ipcu-ca-key.pem -days 30 -policy policy_anything -batch

CSRにCAで署名する（SHA-2）
openssl ca -config req.cfg -in dev-req.pem -out dev-pub.pem -cert ipcu-ca-pub.pem -keyfile ipcu-ca-key.pem -days 30 -md sha256 -policy policy_anything -batch

opensslのcaコマンド時に使用される「CAディレクトリ」

「index.txt」がCAが発行した証明書のデータベースで、opensslの標準では、DN（subj）が同一なCSRを複数署名することが出来ない設定になっている。テストでは、複数署名ができるよう「req.cfg」で「unique_subject = no」を設定している。
この情報は、CAディレクトリの「index.txt.attr」にも記載されており、configファイルの変更だけでは、有効にならない場合がある。変更時は、configファイル内と「index.txt.attr」ファイル内の両方を変更しておく必要がある。opensslの標準状態は「unique_subject = yes」である。
「index.txt」の第一カラムは、発行した証明書の有効性を示すフラグで、「V=Valid」「R=Revoked」「E=Expired」である。タブで区切られた第二カラムは有効期限。有効期限が過ぎても自動的にフラグは変わらない。「R」フラグは、「openssl ca -revoke シリアル番号.pem」でRevoke処理することでフラグが変更される。「シリアル番号.pem」ファイルは、「CA/newcerts」フォルダに存在する。Revoke処理された証明書の有効期限が過ぎても、「R」フラグが「E」フラグに変更されない。CRLは、「openssl ca -gencrl -out crl.pem」で生成される。「R」フラグ付いた証明書情報がリストされるが、有効期限が過ぎた「R」フラグ情報も一緒にリストされる。定期的に、「index.txt」内の有効期限とフラグの整合性を合わせておく必要がある。

iPhoneには、CAの公開鍵「ipcu-ca-pub.pem」と固有のデバイス証明書公開鍵（dev-pub.pem）、秘密鍵（dev-key.pem）をインストールする必要がある。これら３個の証明書をpkcs12でまとめることができるが、構成プロファイルでpkcs12ファイルを配布する場合は、公開鍵と秘密鍵のペアだけが格納されている必要があり、余分な証明書が格納されているとエラーになる。

CA証明書を含んだpkcs12は
openssl pkcs12 -export -in dev-pub.pem -inkey dev-key.pem -name "device cert" -certfile ipcu-ca-pub.pem -caname "ipcu ca" -out dev-cert-w-ca.p12

CA証明書を含まないpkcs12は、
openssl pkcs12 -export -in dev-pub.pem -inkey dev-key.pem -name "device cert" -out dev-cert.p12

で生成する。pkcs12に格納された証明書確認は、
openssl pkcs12 -in dev-cert.p12
で確認する。

CA公開鍵、デバイス公開鍵、デバイス秘密鍵をiPhoneへインストールする
CA公開鍵「ipcu-ca-pub.pem」をバイナリファイルに変更する
openssl x509 -in ipcu-ca-pub.pem -outform der -out ipcu-ca-pub.der
（構成プロファイル リファレンスのcertificate payloadにpemタイプの定義がある。以前は、定義されていなかったような気がする。追加されたのかもしれない。記憶が曖昧である。ipcu-ca-pub.pemをiPhoneへ送り、インストール可能なことが確認できた。バイナリに変換する必要はないかもしれない。）

CA公開鍵「ipcu-ca-pub.der」とデバイス証明書「dev-cert.p12」をメールに添付して目的のiPhoneへ送付する。Macであれば、iMessageでも可。iOS11では、「ファイル」（iCloud drive）を使い、「証明書」フォルダを作り、証明書ファイルをWindows（iCloudのインストールが必要）やMacから配置してインストールするのが便利である。若干同期に時間が掛かる場合もあるが、便利だ。


iPhone上で一番目に「ipcu-ca-pub.der」をタップしてインストール。
インストール時に、iPhoneのロック用パスコードが求められる。


二番目に「dev-cert.p12」をタップしてインストールする。pkcs12ファイル格納用パスフレーズが求められる（このファイルには秘密鍵が暗号化され保存されているので強固なパスフレーズ設定が必要）。

インストールを実行すると「iPhone用のロックパスコード」、次に「pkcs12のパスコード」が求められる。


インストール完了後、iPhoneの「設定」「一般」「プロファイル」で確認する。


これで、「iPhone構成ユーティリティ」に「iPhone」を接続したのと同等状態になる（「暗号化された構成プロファイル」を扱える状態）。iPhone構成ユーティリティとの接続では、iPhoneの「設定」「一般」「プロファイル」の一覧にデバイス証明書が表示されない。この点がシミュレートと異なる点。

CAの公開鍵、デバイス証明書（pkcs12）を一つの構成ファイルとして配布することができる。
ipcu-ca-pub.derとdev-cert.p12を一つの構成プロファイルにしてインストールしてみる。


インストール時には、便利である。削除時も一体で削除される。デバイス証明書の更新時も一体で更新する必要がある。
ipcu-ca-pubの「pem」とdev-cert.p12を一体化した構成プロファイルをインストールすると「おかしな状態」になる。


ipcu-ca-pubのpemを一つだけ構成プロファイルにしてインストールすると問題なくインストールされる。
構成プロファイルに設定する証明書は、pemでなく、derのbase64で扱うのが良さそうである。

(3) 構成プロファイルの暗号化
iPhone構成ユーティリティで「一般」と「資格情報」にデバイス証明書「dev-cert.p12」を追加し、pkcs12用のパスワードを設定して、「セキュリティ」なしで「書き出す」（Windowsでは、dev-cert.p12証明書を「PFXのインストール」で秘密鍵を取出せる設定でインストールしておく必要がある）
構成プロファイルに「pkcs12用パスワード」を含めると、インストール時にpkcs12のパスワード入力を省ける。
書き出された構成ファイルは、UTF-8を扱えるエディターで編集できる。
「CertFile.mobileconfig」名で若干の修正を加えた。


1行目： XML宣言部で文字コードは、「UTF-8」が指定されている。
2行目： DOCTYPE宣言部。ルートは、「plist」キー定義は、URLで参照。
3行目のから42行目のの内容が「一般」部で5行目ので6行目と27行目間に「資格情報」が7行目と26行目で定義されている。
pkcs12用のパスワードは、8行目「Password」及び9行目で平文設定されているので暗号化が必要になる。
複数の資格情報が追加されると、7行目と26行目と同様のデータが6行目と27行目間に追加される。「PayloadIdentifier」と「PayloadUUID」とが独自値に設定される。「pkcs12」や「pem」「der」により「PayloadType」が設定される。詳細については、プロファイルリファレンスのCertificateペイロードに従う。
このプロファイルをインストールすると


「設定」「一般」「プロファイル」の一覧で、38行目「PayloadDisplayName」と40行目「PayloadOrganization」が表示される。一覧で「IPCU発行証明書/IPCUテスト」を選択すると、36行目「PayloadDescription」の内容が「説明」部に表示される。「詳細」をタップすると、38行目「PayloadDisplayName」をタイトルとし、16行目の「PayloadDisplayName」が一覧で表示される。複数の「資格情報」が定義されていると、定義された数の証明書が一覧表示される。「資格情報」以外のペイロードが定義されていると、それぞれの「PayloadType 」毎に数と共に一覧表示される。例示した構成プロファイルは、必須キーとiPhoneのインストール済みプロファイルで表示されるキーだけを定義してある。iPhone構成ユーティリティでは、表示されないキーもペイロードの内容を示す値として含まれている。
プロファイルリファレンスのCertificateペイロードの「PayloadContent」値について「Base64表現（行の長さ52）」と指定されているが、「openssl base64 」でエンコードされる「行の長さ64」でも処理される。

デバイス証明書dev-cert.p12とIPCU CA公開鍵ipcu-ca-pub.der（複数の証明書）を一つにし、「pkcs12-ca-pub-der.mobileconfig」とした構成プロファイル

この構成プロファイルをインストール後、16,17,40,41行目のPayloadDescription内容は表示されないが、構成プロファイルを編集管理する場合に便利なため追加してある。

暗号化する場合は、プロファイルリファレンスの暗号化プロファイルの記載に従い5行目「PayloadContent」の６行目「array」から27行目「/array」までが対象となる（複数の証明書が定義された構成プロファイルの暗号化対象データは、6行目から53行目までである）。

新規構成ファイルの作成について
新規に構成ファイルを生成するには、「テンプレート」を基にするのが良い。
前述の資格情報を含む構成プロファイルをテンプレートとして新規に構成ファイルを生成する場合のポイントを記載する。

（１）「/plist/dict」直下の「key」部を変更する（一般部ペイロード）
・PayloadType：Configureで固定
・PayloadDisplayName：構成プロファイル全体を表現する名称
・PayloadDescription：複数ペイロードの場合、ペイロード名、生成日時など
・PayloadOrganization：必要に応じて記載
・PayloadUUID：新規に生成したUUID値
・PayloadIdentifier：逆DNS形式の識別子
この識別子は、構成ファイル ユーティリティでも設定が必要。「jp.ipcu.ca.profiles」とか「ipcu.ca.certs」など独自値としたルート「PayloadIdentifier」とする。「PayloadContent」以下に定義されるペイロード内の「PayloadIdentifier」は、ルート「PayloadIdentifier」に要素を追加して識別子とする。この値が同じだと、上書きインストールとなり、異なると追加インストールになる。

（２）PayloadContentに定義される「資格情報」などのペイロード部
・PayloadType：「com.apple.security.pkcs12」など特有ペイロード機能を指定
メール設定、VPN設定、WEBクリップ設定、WiFi設定、APN設定など特有値を設定する
・PayloadDisplayName：特有ペイロードの名称
・PayloadDescription：特有ペイロードの内容など必要があればメモに使う
・PayloadUUID：新規に生成したUUID値
・PayloadIdentifier：逆DNS形式の識別子でルートに要素を追加した識別子
例えば、「ipcu.ca.certs.credential1」や「jp.ipcu.ca.profiles.webclip1」など。メールなどの個人アカウントの場合、メールアドレスを追加して識別しにしても良い（「jp.ipcu.ca.profiles.someone.goo.ne.jp」）。

目的とする構成プロファイルの編集が終了したら、iPhoneなどにインストールしてエラーが無いか確認する。

dev-cert.p12等のバイナリファイルをbase64エンコードしてPayloadContentのに設定する。

Macで行52文字でbase64にするには、
/usr/bin/base64 -b52 -i dev-cert.p12 -o dev-cert.b64
行64文字でbase64（openssl base64と同じ）にするには、
/usr/bin/base64 -b64 -i dev-cert.p12 -o dev-cert.b64
/usr/bin/openssl base64 -in dev-cert.p12 -out dev-cert.b64

Windowsでは、
openssl base64 -in dev-cert.p12 -out dev-cert.b64


UUIDを生成するには、
Macでは
/usr/bin/uuidgen

Windowsでは
powershell -Command "[Guid]::NewGuid()"

暗号化する構成プロファイル「CertFile.mobileconfig」「pkcs12-ca-pub-der.mobileconfig」から暗号化対象部分を取り出すには、

Macでは、
/usr/bin/xmllint --xpath "/plist/dict/array" CertFile.mobileconfig > CertFile-CryptBody.mobileconfig

Windowsでは、
powershell -Command "[xml]$xml=(gc CertFile.mobileconfig -Encoding utf8);$xmln=$xml.createnavigator();$xmln.select(¥"/plist/dict/array¥")|%{$_.OuterXml}" > CertFile-CryptBody.mobileconfig

暗号化するには、
openssl smime -encrypt -inform der -in CertFile-CryptBody.mobileconfig -outform der -CAfile ipcu-ca-pub.pem dev-pub.pem | openssl base64 -out CertFile-CryptBody-Crypted.b64

暗号化したデータを非暗号化して確認するには、
openssl base64 -d -in CertFile-CryptBody-Crypted.b64 | openssl smime -decrypt -inform der -CAfile ipcu-ca-pub.pem -inkey dev-key.pem -out CertFile-CryptBody-Crypted-decrypt.txt

暗号化したデータ「CertFile-CryptBody-Crypted.b64」の内容を「CertFile.mobileconfig」のPayloadContentの部とで挟み置き換える。
PayloadContentは、EncryptedPayloadContentに変更する。
編集後のファイルを「CertFile-Crypted.mobileconfig」とする。


暗号化した構成プロファイルに署名する
openssl smime -sign -inform der -in CertFile-Crypted.mobileconfig -signer ipcu-ca-pub.pem -inkey ipcu-ca-key.pem -outform der -out CertFile-Crypted-signed.mobileconfig -nodetach

File（iOS11）/iCloud drive(iOS10)に配置した暗号化構成プロファイル「CertFile-Crypted-signed.mobileconfig」をiPhoneにインストールする（メールやiMessageで配布しても良い）


「設定」「一般」「プロファイル」で確認する


デバイス証明書の有効期限が2017年10月28日(JST=2017年10月27日 GMT+9)までなので、2週間位前から赤字表記される。有効期限が過ぎてもアラートが表示されるがデータは有効（だったと思う）。
デバイス証明書が既にインストールされているのは、このデバイスの公開鍵で暗号化しているため、デバイス証明書の秘密鍵がインストールされていないと、暗号化構成プロファイルをインストール出来ないため。インストール後、デバイス証明書が二つインストールされた状態。
デバイス証明書を構成プロファイルで配布する時は、「pkcs12の格納パスワード」は、設定せず非暗号化で配布するのが良いと思う。インストール時は、「pkcs12」ファイルを直接インストールする時と同様に、「pkcs12の格納パスワード」が求められる。SMIMEやEAP-TLSなどに使用される、個人アカウント用の電子証明書を構成プロファイルで配布する場合は、「pkcs12の格納パスワード」を設定し、暗号化した更生プロファイルを使うのが良いと思う。


構成プロファイルのテンプレート

一般

テンプレート内のREPLACEコメント部を新規ファイルの生成「一般」を参考に置き換える。
「REPLACE-DISPLAY NAME」：　
「REPLACE-UUID」：　
「REPLACE-ipcu.ca.profile」：　
「REPLACE-ORGANIZATION」：　必要な場合、組織名など
「REPLACE-DESCRIPTION」：　必要な場合、この構成プロファイルの内容や日付などを記載
「REPLACE-SPECIFIED PAYLOAD」:　ここに「mail」や「wifi」などのペイロード部を挿入する

WiFiペイロード

テンプレート内のREPLACEコメント部を新規ファイルの生成「資格情報」ペイロードを参考に置き換える。
EncryptionTypeは、WPA2固定にしているが、WEP,WPA,Any,Noneなども定義可能。構成プロファイルリファレンスのWiFiペイロードを参照
「REPLACE-SSID」：
「REPLACE-PASSWORD」：
「REPLACE-ipcu.ca.profile.wifi1」：　「一般」のREPLACE-ipcu.ca.profile + wifi1
複数のWiFiペイロードを定義する場合は、wifi1, wifi2など識別できるように設定する

Mailペイロード

メールは、「EmailAccountType=EmailTypeIMAP」で「IMAP」アクセス用。構成プロファイルリファレンスのEmailペイロードを参照。
「REPLACE-ipcu.ca.profile.mail1」：「一般」のREPLACE-ipcu.ca.profile + mail1
「REPLACE-account name」：　メールアドレス保有者名など「設定」「アカウントとパスワード」
「REPLACE-account description」「アカウント」の「名前」部（iOS11）に表示される。
「REPLACE-account description」：　「メールボックス」一覧に表示される名称
「REPLACE-mail address」：　メールアドレス
「REPLACE-receive mail server」：　メール受信サーバ名
「REPLACE-receive mail server port」：　メール受信サーバポート
「REPLACE-user name」：メールサーバのアカウントID
「REPLACE-password」：　メールサーバのアカウント・パスワード
「REPLACE-sending mail server」：メール送信サーバ名
「REPLACE-sending mail server port」：　メール送信サーバポート

EmailAccountTypeは、IMAP（EmailTypeIMAP）かPOP（EmailTypePOP）が指定できる。
Incoming/OutgoingMailServerPortは、Incoming/OutgoingMailServerUseSSLによって変わる。

IncomingMailServerPort

IncomingMailServerUseSSL	false	true
	None	OverSSL	startTLS
POP	110	995	110
IMAP	143	993	143

 

OutgoingMailServerPort

OutgoingMailServerUseSSL	false	true
	None	OverSSL	startTLS
SMTP	25	465	25
Submission SMTP	587	-	587

多くのメールアカウントは、受信「IMAP over SSL」送信「SMTP submission port/startTLS」が多い。plalaのメールサーバは、「OutgoingMailServerUseSSL=true」とするとメールサイズにより応答がなくなり、送信できなくなる（2017/10現在）。 「Incoming/OutgoingMailServerAuthentication」は、「EmailAuthPassword」が指定してある。サーバアカウントの条件により、構成プロファイルリファレンスのEmailペイロードを参照して適切な値に書き換える。

 

 

DoCoMoのプロファイルは、ここを参照してダウンロード DoCoMoメール プロファイル

DoCoMoのメールサーバアカウントは、「My docomo」アカウントのIDとパスワード。
My docomo（お客様サポート）ページにログインして「プロファイル設定」。「メッセージR/S利用設定」「ドコモメール利用設定」からダウンロード。アカウントIDやパスワードは、設定済みでダウンロードされる。メッセージR/Sは、プロトコルPOPでダウンロード毎に「パスワードが変更され」ダウンロードされる。

 

DoCoMo メッセージR/S

メッセージR/Sプロファイルは、「dメニュー」「dマーケット」「サポート」の３個の「WEBクリップ ペイロード」が一緒についてくる。不要な場合は、３個の「WEBクリップデータ」を削除すると良い。

プリウスPHV H2V controller 無線LAN不具合

プリウスPHV（ZVW35）と同時に導入したH2V managerのcontrollerがおかしくなった。
車の充電が終わったかどうかiPhoneのH2Vmanagerで確認していたが、iOS11でiPhone版が起動しない。パソコンからH2V managerサイトに接続して確認指定みると


10月10日からデータがアップロードされていない。H2V managerとcontrollerは、WiFi接続（802.11b）で、計測データをmanagerにアップし、センターに送っている。２つあるWiFiアクセスポイントの一つを停止し、他のアクセスポイントに接続させようと、NEC WR8700の電源を落とした。


controllerのWiFi接続が切り替わらない。


controllerのWiFi設定情報の不具合かと思い、再度設定を試みた。
・H2V managerをcontrollerの直近に移動する
・H2V managerのWPS設定を起動する
・controllerの通信ボタンを長押し、controllerのWPSを起動させる（オレンジランプの2回点灯の点滅開始）
・controllerのオレンジランプ点灯を待つが、点滅に移行
・controllerを再起動し、再度WPS設定を試みたが、オレンジランプ点滅

H2V managerサポートセンタに連絡したが、上記と同じ「切り分け作業」を実施ご、調査して再度連絡をくれることに（10月14日 土曜日だったので、詳しいスタッフがいなかったのだろう）。

NEC WR8700の電源を再度、投入したが、電源ランプが点灯するだけで、起動しない。
何回か繰り返したが、起動しない。
ネットワークからの設定接続もできない。
壊れたようだ。。。。。廃棄決定。。。。

iPhone SE（AEON sim）でezwebメールにアクセス

ezwebメールは、au携帯電話、auスマートフォンからだけでなく、インターネットからPCや他社スマートフォンでアクセスが出来るようだ。下記のような接続イメージだ。

接続用のアカウント名やパスワードは、SMSで取得が出来るらしい。記載されているように携帯電話のCメールで本文「1234」で「#5000」宛に送信したが、レスポンスが得られなかった。下記のサイトの情報を確認してみた。
@ezweb.ne.jp宛のメールをパソコンで受信する方法
普通のIMAPメールとしてezwebメールをPCで使う方法
ezweb.ne.jp なメール
auのezweb.ne.jpな電子メールアドレスをmewから使う

メール設定情報は、キャリアネットワーク内にあるhttpサーバのリクエストページから要求するとCメールなどのSMSメールで通知される場合、iPhone用メール設定リンクから「構成ファイル」としてダウンロードとインストールを実施する場合があるようだ。また、メール設定情報は、iPhone(au sim)上のSafariからの接続かどうか確認され、ダウンロードページのリンクが表示されるようだ。この方式は、auだけでなくDoCoMoやSoftBankでも同じだ。

メール設定情報を取得するのにiPhone(au sim)のtethering

で取得する記載があるが、WiFi接続がチェックされ（Bluetoothは確認していない）、リンク情報が表示されない場合がある。このような場合は、USBライトニングケーブルでPCをtetheringする必要がある。
au携帯電話機の場合は、モデム接続でau.NETのPacketWIN接続する。


auのネットワークに接続後、ブラウザの「user agent」を下記のようにiPhone Safariと同等にしてiPhone用メール設定情報のSMSメール通知要求リンクや「構成ファイル」ダウンロードとインストールリンクを選択する。「構成ファイル」は、保存（username-ezweb.mobileconfig）することでファイルとして得られる。

MacのOSXでは、Safariの「環境設定」「詳細」ページで「メニューバーに"開発"メニューを表示」にチェックを入れ、「開発」「ユーザエージェント」で「Safari-iOS10.3-iPhone」を設定する。
InternetExplorerでは、「ツール」「F12開発者ツール」「エミュレーション」で「ユーザエージェント文字列」を「Apple Safari(iPad)」か「カスタム」「Mozilla/5.0 (iPhone; CPU iPhone OS 10_0_1 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Mobile/14A403 Safari/602.1」などとする。

メール設定情報リンクから保存した「構成ファイル」がこれ
「username」は、実メールアドレスのユーザパート
「USERACCOUNT」「USERPASSWORD」は、アクセス毎（この構成ファイルをダウンロードする毎）に新しい値が設定される

メールサーバ（受信）： IncommingMailServerHostName=imap.ezweb.ne.jp:993 (IMAP4 over SSL)
メールサーバ（送信）： OutgoingMailServerHostName=smtp.ezweb.ne.jp:587 (Submission startTLS)
送受信のアカウント認証： CRAMMD5

このファイルを保管する場合、記載された「USERACCOUNT」や「USERPASSWORD」の漏洩に注意が必要だ。暗号化して保管するのが良い方法だと思う。Appleの「iPhone構成ユーティリティ」では、暗号化して配布する選択肢が用意されている。
３キャリアが暗号化せずに配布しているのは、上記のような取得を前提にしておらず、各キャリアの専用ネットワーク内にあるサーバに直接接続できる「iPhone」にOTA（Over-The-Air）で直接インストールされる事を前提（保存される事を前提としていない）にしているからだ。「iPhone構成ユーティリティ」の配布が停止されたため、「構成ファイルの暗号化」をアプリで行う事が困難となっている（暗号化ついてもメモしておく予定）。

取得した「username-ezweb.mobileconfig」をメール添付でiPhoneSEへ送り、添付ファイルをタップしてインストールを行う。au以外のsimでアクティベートされたiPhoneから容易にezwebメールを扱う事ができるようになる。
ちなみに、sim free iPhoneのキャリアメール相当は、「iCloud」メールが良い。再インストール時も、「iCloud」アカウントにログインすると同時にこのメールが使えるようになるからだ。また、３キャリアのキャリアメールに比較し、sim契約を代えても契約を廃止しても「iCloud」のメールアカウントは、廃止されない。

au携帯電話のPacketWinによる「username-ezweb.mobileconfig」ファイルの取得には、多額のパケット通信料がかかってしまった。PacketWIN使用月の月額料金が¥500円。1パケット0.1円。たいした金額にならないつもりであったが、保守サポートページの目的のページへ行きつくために複数ページのアクセスが必要なこと。各ページは、リッチな粧で画像が沢山張り付いている。結果、最小限のリンクを辿っても、71,062パケットの使用となり、トータル¥7,050円が請求される事となってしまった。さっさと解約料を払った方が安かったと。。。。。
アクススしたページのスクリーンキャプチャがあったのだが、保管していたPCのクラッシュで消滅した。

2016年7月頃から1年ちょっとau 3G携帯電話機のキャリアメール@ezweb.ne.jpをiPhoneSE+AEON simで使用してきた。
無事、メールアドレスの変更通知、アドレス帳の変換（kddiがツールを提供している）、iPhone操作の習熟も済み、2017年10月2日「さようならau by KDDI」となりました。

---- iPhone6SでUSB tethering + MacBook pro + Safari でドコモのiPhoneメール設定用構成ファイルのダウンロードリンクページへのアクセス例がこれ
iPhone tethering設定


DoCoMo保守サポートページにあるiPhoneキャリアメール用構成ファイルのダウンロードリンクページ
Macbook proのSafariでuser agentをiPhoneとしてアクセスしている


この「構成ファイル」には、メール設定以外にWebリンクをホーム画面に貼り付けるための情報が多数含まれている。
不要なWebリンクは、エディターで編集削除し、使用している。