Secure Mail の S/MIME
Secure Mail は Secure/Multipurpose Internet Mail Extensions (S/MIME) をサポートしており、ユーザーはメッセージに署名したり暗号化したりすることで、セキュリティを強化できます。署名により、受信者はメッセージがなりすましではなく、識別された送信者によって送信されたことを確認できます。暗号化により、互換性のある証明書を持つ受信者のみがメッセージを開くことができます。
S/MIME の詳細については、Microsoft TechNet を参照してください。
以下の表で、X は Secure Mail がデバイス OS で S/MIME 機能をサポートしていることを示します。
| S/MIME 機能 | iOS | Android |
|---|---|---|
| デジタル ID プロバイダーとの統合: Secure Mail をサポートされているサードパーティのデジタル ID プロバイダーと統合できます。ID プロバイダーホストは、ユーザーデバイス上の ID プロバイダーアプリに証明書を供給します。そのアプリは、機密性の高いアプリデータの安全な保管場所である Endpoint Management 共有ボールトに証明書を送信します。Secure Mail は共有ボールトから証明書を取得します。詳細については、「デジタル ID プロバイダーとの統合」セクションを参照してください。 | X | |
| 派生資格情報のサポート | Secure Mail は、証明書ソースとして派生資格情報の使用をサポートしています。派生資格情報の詳細については、Citrix Endpoint Management ドキュメントの「iOS 用派生資格情報」の記事を参照してください。 | |
| メールによる証明書の配布: メールで証明書を配布するには、証明書テンプレートを作成し、それらのテンプレートを使用してユーザー証明書を要求する必要があります。証明書をインストールして検証した後、ユーザー証明書をエクスポートし、ユーザーにメールで送信します。ユーザーは Secure Mail でメールを開き、証明書をインポートします。詳細については、「メールによる証明書の配布」セクションを参照してください。 | X | X |
| 単一目的証明書の自動インポート: Secure Mail は、証明書が署名または暗号化のみを目的としているかどうかを検出し、証明書を自動的にインポートしてユーザーに通知します。証明書が両方の目的で使用される場合、ユーザーはインポートを求められます。 | X |
デジタル ID プロバイダーとの統合
次の図は、デジタル ID プロバイダーホストから Secure Mail への証明書のパスを示しています。これは、Secure Mail をサポートされているサードパーティのデジタル ID プロバイダーと統合するときに発生します。
- 
- MDX 共有ボールトは、証明書などの機密性の高いアプリデータを安全に保管する領域です。Endpoint Management によって有効化されたアプリのみが共有ボールトにアクセスできます。
前提条件
- Secure Mail は Entrust IdentityGuard との統合をサポートしています。
統合の構成
- ID プロバイダーアプリを準備し、ユーザーに提供します。
- Entrust に連絡して、ラップする .ipa を入手します。
-
MDX Toolkit を使用してアプリをラップします。
このアプリを Endpoint Management 環境外で既にアプリのバージョンを持っているユーザーに展開する場合は、このアプリに一意のアプリ ID を使用してください。このアプリと Secure Mail には同じプロビジョニングプロファイルを使用してください。
- アプリを Endpoint Management に追加し、Endpoint Management アプリストアに公開します。
-
ユーザーに、Secure Hub から ID プロバイダーアプリをインストールする必要があることを伝えます。必要に応じて、インストール後の手順についてガイダンスを提供します。
次の手順で Secure Mail の S/MIME ポリシーを構成する方法によっては、Secure Mail がユーザーに証明書のインストールを促したり、Secure Mail 設定で S/MIME を有効にするよう促したりする場合があります。これらの両方の手順については、「iOS 用 Secure Mail での S/MIME の有効化」を参照してください。
-
- Secure Mail を Endpoint Management に追加するときは、以下のポリシーを必ず構成してください。
-
S/MIME 証明書ソースポリシーを 共有ボールト に設定します。この設定は、Secure Mail がデジタル ID プロバイダーによって共有ボールトに保存されている証明書を使用することを意味します。
-
Secure Mail の初回起動時に S/MIME を有効にするには、[Secure Mail の初回起動時に S/MIME を有効にする] ポリシーを構成します。このポリシーは、共有ボールトに証明書がある場合に Secure Mail が S/MIME を有効にするかどうかを決定します。証明書が利用できない場合、Secure Mail はユーザーに証明書のインポートを促します。ポリシーが有効になっていない場合、ユーザーは Secure Mail 設定で S/MIME を有効にできます。デフォルトでは、Secure Mail は S/MIME を有効にしないため、ユーザーは Secure Mail 設定を通じて S/MIME を有効にする必要があります。
派生資格情報の使用
デジタル ID プロバイダーと統合する代わりに、派生資格情報の使用を許可できます。
- Secure Mail を Endpoint Management に追加するときは、S/MIME 証明書ソースポリシーを **派生資格情報** に構成します。派生資格情報の詳細については、「[iOS 用派生資格情報](/ja-jp/citrix-endpoint-management/authentication/derived-credentials.html)」を参照してください。
メールによる証明書の配布
デジタル ID プロバイダーと統合したり、派生資格情報を使用したりする代わりに、メールでユーザーに証明書を配布できます。このオプションには、このセクションで詳述する以下の一般的な手順が必要です。
-
サーバーマネージャーを使用して、Microsoft Certificate Services の Web 登録を有効にし、IIS の認証設定を確認します。
-
- メールメッセージの署名と暗号化のための証明書テンプレートを作成します。これらのテンプレートを使用してユーザー証明書を要求します。
-
-
証明書をインストールして検証し、ユーザー証明書をエクスポートしてユーザーにメールで送信します。
-
ユーザーは Secure Mail でメールを開き、証明書をインポートします。これにより、証明書は Secure Mail のみで利用可能になります。S/MIME の iOS プロファイルには表示されません。
前提条件
このセクションの手順は、以下のコンポーネントに基づいています。
- XenMobile® Server 10 以降
- Citrix Gateway (旧 NetScaler® Gateway) のサポートされているバージョン
- iOS 用 Secure Mail (最小バージョン 10.8.10)、Android デバイス用 Secure Mail (最小バージョン 10.8.10)
- Microsoft Certificate Services がルート証明機関 (CA) として機能する Microsoft Windows Server 2008 R2 以降
- Microsoft Exchange:
- Exchange Server 2016 Cumulative Update 4
- Exchange Server 2013 Cumulative Update 15
- Exchange Server 2010 SP3 Update Rollup 16
S/MIME を構成する前に、以下の前提条件を完了してください。
- ルート証明書と中間証明書を、手動で、または Endpoint Management の資格情報デバイスポリシーを通じてモバイルデバイスに配信します。詳細については、「[資格情報デバイスポリシー](/ja-jp/citrix-endpoint-management/policies/credentials-policy.html)」を参照してください。
- プライベートサーバー証明書を使用して ActiveSync トラフィックを Exchange Server に保護している場合は、以下の手順を実行してください。すべてのルート証明書と中間証明書をモバイルデバイスにインストールします。
Microsoft Certificate Services の Web 登録の有効化
- 管理ツール に移動し、サーバーマネージャー を選択します。
- Active Directory 証明書サービス の下で、証明機関 Web 登録 がインストールされているかどうかを確認します。
- 必要に応じて、役割サービスの追加 を選択して証明機関 Web 登録をインストールします。
-
- 証明機関 Web 登録 をチェックし、次へ をクリックします。
-
- インストールが完了したら、閉じる または 完了 をクリックします。
-
IIS での認証設定の確認
- ユーザー証明書の要求に使用される Web 登録サイト (例: `https://ad.domain.com/certsrv/`) が HTTPS サーバー証明書 (プライベートまたはパブリック) で保護されていることを確認します。
- Web 登録サイトは HTTPS 経由でアクセスする必要があります。
-
管理ツール に移動し、サーバーマネージャー を選択します。
- Web Server (IIS) で、役割サービスを確認します。クライアント証明書マッピング認証と IIS クライアント証明書マッピング認証がインストールされていることを確認します。インストールされていない場合は、これらの役割サービスをインストールします。
-
管理ツールに移動し、インターネットインフォメーションサービス (IIS) マネージャーを選択します。
-
- IIS マネージャーウィンドウの左ペインで、Web登録用の IIS インスタンスを実行しているサーバーを選択します。
-
- 認証をクリックします。
-
- Active Directory クライアント証明書認証が有効になっていることを確認します。
-
- 右ペインで、サイト > Microsoft インターネットインフォメーションサービス の既定のサイト > バインドをクリックします。
-
- HTTPS バインドが存在しない場合は、追加します。
- 既定の Web サイトのホームに移動します。
- SSL 設定をクリックし、次にクライアント証明書を受け入れるをクリックします。
新しい証明書テンプレートの作成
メールメッセージの署名と暗号化を行うには、Microsoft Active Directory 証明書サービスで証明書を作成することを Citrix は推奨します。両方の目的で同じ証明書を使用し、暗号化証明書をアーカイブすると、署名証明書を回復してなりすましを許可することが可能になります。
次の手順では、証明機関 (CA) サーバー上の証明書テンプレートを複製します。
- Exchange 署名のみ (署名用)
- Exchange ユーザー (暗号化用)
-
証明機関スナップインを開きます。
-
CA を展開し、証明書テンプレートに移動します。
-
右クリックして、管理をクリックします。
-
Exchange Signature Only テンプレートを検索し、テンプレートを右クリックして、テンプレートの複製をクリックします。
-
任意の名前を割り当てます。
-
Active Directory で証明書を発行するチェックボックスをオンにします。
注:
Active Directory で証明書を発行するチェックボックスをオンにしない場合、ユーザーはユーザー証明書 (署名用および暗号化用) を手動で発行する必要があります。これは、Outlook メールクライアント > トラストセンター > 電子メールのセキュリティ > GAL (グローバルアドレス一覧) に発行から実行できます。
-
要求処理タブをクリックし、次のパラメーターを設定します。
- 目的: 署名
- 最小キーサイズ: 2048
- 秘密キーのエクスポートを許可するチェックボックス: オン
- ユーザー入力なしでサブジェクトを登録するチェックボックス: オン
-
セキュリティタブをクリックし、グループ名またはユーザー名の下で、認証済みユーザー (または任意のドメインセキュリティグループ) が追加されていることを確認します。また、認証済みユーザーのアクセス許可の下で、許可に対して読み取りおよび登録チェックボックスがオンになっていることを確認します。
-
その他のすべてのタブと設定については、デフォルト設定のままにします。
-
証明書テンプレートで、Exchange Userをクリックし、手順 4 から 9 を繰り返します。
新しい Exchange User テンプレートには、元のテンプレートと同じデフォルト設定を使用します。
-
要求処理タブをクリックし、次のパラメーターを設定します。
- 目的: 暗号化
- 最小キーサイズ: 2048
- 秘密キーのエクスポートを許可するチェックボックス: オン
-
ユーザー入力なしでサブジェクトを登録するチェックボックス: オン
-
両方のテンプレートが作成されたら、両方の証明書テンプレートを発行してください。新規をクリックし、発行する証明書テンプレートをクリックします。
ユーザー証明書のリクエスト
この手順では、「user1」を使用して Web 登録ページ (例: https://ad.domain.com/certsrv/) に移動します。この手順では、セキュアメール用の新しいユーザー証明書を 2 つ要求します。1 つは署名用、もう 1 つは暗号化用です。Secure Mail を介して S/MIME の使用を必要とする他のドメインユーザーに対しても、同じ手順を繰り返すことができます。
Microsoft Certificate Services の Web 登録サイト (例: https://ad.domain.com/certsrv/) を介して手動登録を使用し、署名用および暗号化用のユーザー証明書を生成します。別の方法として、この機能を使用するユーザーグループに対してグループポリシーを介して自動登録を構成することもできます。
-
Windows ベースのコンピューターで、Internet Explorer を開き、Web 登録サイトにアクセスして新しいユーザー証明書を要求します。
注:
証明書を要求するには、正しいドメインユーザーでログオンしていることを確認してください。
-
ログオンしたら、証明書の要求をクリックします。
-
高度な証明書の要求をクリックします。
-
この CA に要求を作成して送信するをクリックします。
-
署名用のユーザー証明書を生成します。適切なテンプレート名を選択し、ユーザー設定を入力してから、要求形式の横でPKCS10を選択します。
要求が送信されました。
-
この証明書をインストールするをクリックします。
-
証明書が正常にインストールされたことを確認します。
-
同じ手順を繰り返しますが、今度は電子メールメッセージの暗号化用です。同じユーザーで Web 登録サイトにログオンした状態で、ホームリンクに移動して新しい証明書を要求します。
-
暗号化用の新しいテンプレートを選択し、手順 5 で入力したのと同じユーザー設定を入力します。
-
証明書が正常にインストールされていることを確認し、別のドメインユーザー用のユーザー証明書のペアを生成するために同じ手順を繰り返します。この例では、同じ手順に従って「User2」用の証明書のペアを生成します。
注記:
- > - > この手順では、「User2」用の2番目の証明書のペアを要求するために、同じWindowsベースのコンピューターを使用します。
公開済み証明書の検証
-
証明書がドメインユーザープロファイルに適切にインストールされていることを確認するには、Active Directoryユーザーとコンピューター > 表示 > 高度な機能に移動します。
-
ユーザー（この例ではUser1）のプロパティに移動し、公開済み証明書タブをクリックします。両方の証明書が利用可能であることを確認します。各証明書に特定の用途があることも確認できます。
この図は、電子メールメッセージを暗号化するための証明書を示しています。
この図は、電子メールメッセージに署名するための証明書を示しています。
正しい暗号化証明書がユーザーに割り当てられていることを確認します。この情報は、Active Directoryユーザーとコンピューター > ユーザープロパティで確認できます。
Secure Mailは、LDAPクエリを介してuserCertificateユーザーオブジェクト属性をチェックすることで機能します。この値は、属性エディタータブで読み取ることができます。このフィールドが空であるか、暗号化用のユーザー証明書が正しくない場合、Secure Mailはメッセージを暗号化（または復号化）できません。
ユーザー証明書のエクスポート
この手順では、「User1」と「User2」の両方のペア証明書を秘密キーとともに.PFX (PKCS#12) 形式でエクスポートします。エクスポートされた証明書は、Outlook Web Access (OWA) を使用して電子メールでユーザーに送信されます。
-
MMCコンソールを開き、証明書 - 現在のユーザーのスナップインに移動します。「User1」と「User2」の両方の証明書のペアが表示されます。
-
証明書を右クリックし、すべてのタスク > エクスポートをクリックします。
-
はい、秘密キーをエクスポートします。を選択して秘密キーをエクスポートします。
-
可能であれば、証明のパスにあるすべての証明書を含めるとすべての拡張プロパティをエクスポートするチェックボックスを選択します。
-
最初の証明書をエクスポートしたら、残りのユーザー証明書についても同じ手順を繰り返します。
注記:
どの証明書が署名証明書で、どの証明書が暗号化証明書であるかを明確にラベル付けします。この例では、証明書はuserX-sign.pfxおよびuserX-enc.pfxとしてラベル付けされています。
電子メールによる証明書の送信
すべての証明書がPFX形式でエクスポートされたら、Outlook Web Access (OWA) を使用して電子メールで送信できます。この例のログオン名はUser1で、送信された電子メールには両方の証明書が含まれています。
User2またはドメイン内の他のユーザーについても同じ手順を繰り返します。
iOSおよびAndroid版Secure MailでのS/MIMEの有効化
電子メールが配信されたら、次のステップはSecure Mailを使用してメッセージを開き、署名と暗号化に適した証明書でS/MIMEを有効にすることです。
個別の署名証明書と暗号化証明書でS/MIMEを有効にするには
-
Secure Mailを開き、S/MIME証明書を含む電子メールに移動します。
-
署名証明書をタップしてダウンロードおよびインポートします。
-
署名証明書がサーバーからエクスポートされたときに秘密キーに割り当てられたパスワードを入力します。
証明書がインポートされました。
-
署名をオンにするをタップします。
-
または、設定 > S/MIME に移動し、S/MIME をタップして署名証明書をオンにすることができます。
-
署名画面で、正しい署名証明書がインポートされていることを確認します。
-
メールに戻り、暗号化証明書をタップしてダウンロードおよびインポートします。
-
暗号化証明書がサーバーからエクスポートされたときに秘密キーに割り当てられたパスワードを入力します。
証明書がインポートされました。
-
暗号化をオンにするをタップします。
-
または、設定 > S/MIME に移動し、S/MIME をタップしてデフォルトで暗号化を有効にすることができます。
-
暗号化画面で、正しい暗号化証明書がインポートされていることを確認します。
注：
-
S/MIME でデジタル署名され、添付ファイルがあり、受信者が S/MIME を有効にしていない場合、添付ファイルは受信されません。この動作は Active Sync の制限です。S/MIME メッセージを効果的に受信するには、Secure Mail 設定で S/MIME をオンにします。
-
デフォルトで暗号化オプションを使用すると、メールを暗号化するために必要な手順を最小限に抑えることができます。この機能がオンの場合、メールは作成中に暗号化された状態になります。この機能がオフの場合、メールは作成中に暗号化されていない状態になり、ロックアイコンをタップして暗号化する必要があります。
-
単一の署名および暗号化証明書によるS/MIMEの有効化
-
Secure Mail を開き、S/MIME 証明書を含むメールに移動します。
-
S/MIME 証明書をタップしてダウンロードおよびインポートします。
-
証明書がサーバーからエクスポートされたときに秘密キーに割り当てられたパスワードを入力します。
-
表示される証明書オプションから、署名証明書または暗号化証明書をインポートするための適切なオプションをタップします。 証明書の詳細を表示するには、証明書を開くをタップします。
証明書がインポートされました。
インポートされた証明書は、設定 > S/MIME に移動して表示できます。
iOSおよびAndroidでのS/MIMEのテスト
前のセクションに記載されている手順を実行すると、受信者は署名および暗号化されたメールを読み取ることができます。
次の画像は、受信者が読み取った暗号化されたメッセージの例を示しています。
次の画像は、署名された信頼済み証明書の検証の例を示しています。
Secure Mail は、受信者の公開暗号化証明書について Active Directory ドメインを検索します。ユーザーが有効な公開暗号化キーを持たない受信者に暗号化されたメッセージを送信した場合、メッセージは暗号化されずに送信されます。グループメッセージでは、1 人の受信者でも有効なキーを持っていない場合、メッセージはすべての受信者に暗号化されずに送信されます。
公開証明書ソースの構成
S/MIME 公開証明書を使用するには、S/MIME 公開証明書ソース、LDAP サーバーアドレス、LDAP ベース DN、および LDAP に匿名でアクセスするポリシーを構成します。
アプリポリシーに加えて、以下を実行します。
- LDAP サーバーが公開されている場合は、トラフィックが LDAP サーバーに直接送信されるようにします。そのためには、Secure Mail のネットワークポリシーを内部ネットワークにトンネルするように構成し、Citrix ADC のスプリット DNS を構成します。
- LDAP サーバーが内部ネットワーク上にある場合は、以下を実行します。
- iOS の場合、バックグラウンドネットワークサービスゲートウェイポリシーを構成しないようにします。ポリシーを構成すると、ユーザーは頻繁な認証プロンプトを受け取ります。
- Android の場合、バックグラウンドネットワークサービスゲートウェイポリシーのリストにLDAP サーバー URLを追加するようにします。