Azure Stack Edge Pro GPU の証明書とは

適用対象: はい (Pro GPU SKU の場合)Azure Stack Edge Pro - GPUはい (Pro 2 SKU の場合)Azure Stack Edge Pro 2はい (Pro R SKU の場合)Azure Stack Edge Pro Rはい (Mini R SKU の場合)Azure Stack Edge Mini R

この記事では、Azure Stack Edge Pro GPU デバイスにインストールできる証明書の種類について説明します。 この記事には、各証明書の種類の詳細も記載します。

証明書について

証明書は、公開キーと、信頼されたサード パーティ (証明機関など) が署名 (検証) したエンティティ (ドメイン名など) を結び付けるものです。 証明書は、信頼された公開暗号化キーを配布するための便利な方法を提供します。 証明書によって、通信が信頼できるものであること、暗号化された情報を正しいサーバーに送信していることが確認されます。

デバイスへの証明書のデプロイ

Azure Stack Edge デバイスでは、自己署名証明書を使用するか、独自の証明書を取り込むことができます。

証明書の種類

デバイスに導入できるさまざまな種類の証明書は、次のとおりです。

  • 署名証明書

    • ルート CA
    • 中級
  • ノード証明書

  • エンドポイント証明書

    • Azure Resource Manager 証明書
    • BLOB ストレージ証明書
  • ローカル UI 証明書

  • IoT デバイス証明書

  • Kubernetes 証明書

    • Edge コンテナー レジストリ証明書
    • Kubernetes ダッシュボード証明書
  • Wi-Fi 証明書

  • VPN 証明書

  • 暗号化証明書

    • サポート セッション証明書

各種の証明書については、次のセクションで詳しく説明します。

署名チェーン証明書

証明書に署名する機関または署名証明機関の証明書です。

種類

これに該当する証明書は、ルート証明書または中間証明書です。 ルート証明書は常に自己署名されています (つまり、それ自体によって署名されています)。 中間証明書は自己署名ではなく、署名機関によって署名されています。

注意事項

  • ルート証明書は、署名チェーン証明書である必要があります。
  • ルート証明書は、次の形式でデバイスにアップロードできます。
    • DER.cer ファイル拡張子として使用できます。
    • Base-64 エンコード.cer ファイル拡張子として使用できます。
    • P7b – この形式は、ルート証明書と中間証明書を含む署名チェーン証明書に対してのみ使用されます。
  • 署名チェーン証明書は常に、他の証明書をアップロードする前にアップロードされます。

ノード証明書

デバイス内のすべてのノードは常に相互に通信しているため、信頼関係が必要です。 ノード証明書は、その信頼を確立する手段を提供します。 https 経由のリモート PowerShell セッションを使用してデバイス ノードに接続するときにも、ノード証明書が関与します。

注意事項

  • ノード証明書は、エクスポート可能な秘密キーを含む .pfx 形式で提供する必要があります。

  • 1 つのワイルドカード ノード証明書または 4 つの個別ノード証明書を作成してアップロードできます。

  • DNS ドメインが変更されたが、デバイス名は変わらない場合は、ノード証明書を変更する必要があります。 独自のノード証明書を導入する場合、デバイスのシリアル番号は変更できず、ドメイン名のみ変更できます。

  • ノード証明書を作成する場合、次の表を参考にしてください。

    Type サブジェクト名 (SN) サブジェクトの別名 (SAN) サブジェクト名の例
    Node <NodeSerialNo>.<DnsDomain> *.<DnsDomain>

    <NodeSerialNo>.<DnsDomain>
    mydevice1.microsoftdatabox.com

エンドポイント証明書

デバイスが公開するエンドポイントでは、信頼された通信のために証明書が必要です。 エンドポイント証明書には、REST API を使用して Azure Resource Manager および BLOB ストレージにアクセスするときに必要なものが含まれています。

独自の署名入り証明書を導入する場合は、証明書の対応する署名チェーンも必要です。 署名チェーン、Azure Resource Manager、デバイスの BLOB 証明書については、デバイスを認証して通信するために、クライアント マシンにも対応する証明書が必要になります。

注意事項

  • エンドポイント証明書は、秘密キーを使用した .pfx 形式である必要があります。 署名チェーンは DER 形式 (.cer ファイル拡張子) である必要があります。

  • 独自のエンドポイント証明書を導入する場合、個々の証明書またはマルチドメイン証明書にすることができます。

  • 署名チェーンを導入する場合、エンドポイント証明書をアップロードする前に署名チェーン証明書をアップロードする必要があります。

  • デバイス名または DNS ドメイン名が変更された場合、これらの証明書を変更する必要があります。

  • ワイルドカード エンドポイント証明書を使用できます。

  • エンドポイント証明書のプロパティは、一般的な SSL 証明書のプロパティに似ています。

  • エンドポイント証明書を作成するときは、次の表を使用します。

    Type サブジェクト名 (SN) サブジェクトの別名 (SAN) サブジェクト名の例
    Azure Resource Manager management.<Device name>.<Dns Domain> login.<Device name>.<Dns Domain>
    management.<Device name>.<Dns Domain>
    management.mydevice1.microsoftdatabox.com
    BLOB ストレージ *.blob.<Device name>.<Dns Domain> *.blob.< Device name>.<Dns Domain> *.blob.mydevice1.microsoftdatabox.com
    両方のエンドポイントに対する単一のマルチ SAN 証明書 <Device name>.<dnsdomain> <Device name>.<dnsdomain>
    login.<Device name>.<Dns Domain>
    management.<Device name>.<Dns Domain>
    *.blob.<Device name>.<Dns Domain>
    mydevice1.microsoftdatabox.com

ローカル UI 証明書

ブラウザーを使用して、デバイスのローカル Web UI にアクセスできます。 この通信をセキュリティで確実に保護するために、独自の証明書をアップロードできます。

注意事項

  • ローカル UI 証明書も、エクスポート可能な秘密キーを含む .pfx 形式でアップロードします。

  • ローカル UI 証明書をアップロードした後、ブラウザーを再起動してキャッシュをクリアする必要があります。 お使いのブラウザーの具体的な手順を参照してください。

    Type サブジェクト名 (SN) サブジェクトの別名 (SAN) サブジェクト名の例
    ローカル UI <Device name>.<DnsDomain> <Device name>.<DnsDomain> mydevice1.microsoftdatabox.com

IoT Edge デバイス証明書

デバイスも IoT デバイスの一種であり、IoT Edge デバイスが接続されていることにより、コンピューティングが有効になっています。 この IoT Edge デバイスと、それに接続可能なダウンストリーム デバイスの間でセキュリティで保護された通信を行うために、IoT Edge 証明書をアップロードすることもできます。

このデバイスには、デバイスでコンピューティング シナリオのみ使用する場合に使用できる自己署名証明書が備わっています。 ただし、デバイスがダウンストリーム デバイスに接続されている場合は、独自の証明書を導入する必要があります。

この信頼関係を有効にするために、次の 3 つの IoT Edge 証明書をインストールする必要があります。

  • ルート証明機関または所有者証明機関
  • デバイス証明機関
  • デバイス キー証明書

注意事項

  • IoT Edge 証明書は .pem 形式でアップロードします。

IoT Edge 証明書の詳細については、Azure IoT Edge 証明書の詳細および IoT Edge 運用証明書の作成に関するページを参照してください。

Kubernetes 証明書

次の Kubernetes 証明書を、お使いの Azure Stack Edge デバイスで使用できます。

  • Edge コンテナー レジストリ証明書: デバイスに Edge コンテナー レジストリがある場合は、デバイス上のレジストリにアクセスしているクライアントとのセキュリティ保護された通信のために、Edge Container Registry 証明書が必要です。
  • ダッシュボード エンドポイント証明書: デバイス上の Kubernetes ダッシュボードにアクセスするには、ダッシュボード エンドポイント証明書が必要です。

注意事項

  • Edge コンテナー レジストリ証明書は次である必要があります。

    • PEM 形式の証明書である。
    • 型 (*.<endpoint suffix> または ecr.<endpoint suffix>) のサブジェクト代替名 (SAN) または CName (CN) のいずれかを含む。 例: *.dbe-1d6phq2.microsoftdatabox.com OR ecr.dbe-1d6phq2.microsoftdatabox.com
  • ダッシュボード証明書は次である必要があります。

    • PEM 形式の証明書である。
    • 型 (*.<endpoint-suffix> または kubernetes-dashboard.<endpoint-suffix>) のサブジェクト代替名 (SAN) または CName (CN) のいずれかを含む。 たとえば、*.dbe-1d6phq2.microsoftdatabox.comkubernetes-dashboard.dbe-1d6phq2.microsoftdatabox.com などです。

VPN 証明書

デバイスで VPN (ポイント対サイト) が構成されている場合は、独自の VPN 証明書を導入して、通信が信頼されていることを確認できます。 ルート証明書は Azure VPN Gateway にインストールされ、クライアント証明書はポイント対サイトを使用して仮想ネットワークに接続する各クライアント コンピューターにインストールされます。

注意事項

  • VPN 証明書は、プライベート キーを使用して .pfx 形式としてアップロードする必要があります。
  • VPN 証明書は、デバイス名、デバイス シリアル番号、またはデバイス構成に依存しません。 外部 FQDN だけが必要です。
  • クライアント OID が設定されていることを確認します。

詳細については、「PowerShell を使用したポイント対サイトの証明書の生成とエクスポート」を参照してください。

Wi-Fi 証明書

デバイスが WPA2-Enterprise ワイヤレス ネットワーク上で動作するように構成されている場合、ワイヤレス ネットワーク経由で行われるすべての通信に Wi-Fi 証明書も必要になります。

注意事項

  • Wi-Fi 証明書は、プライベート キーを使用して .pfx 形式としてアップロードする必要があります。
  • クライアント OID が設定されていることを確認します。

サポート セッション証明書

デバイスで問題が発生した場合、それらの問題のトラブルシューティングを行うために、デバイスでリモート PowerShell サポート セッションを開くことができます。 セキュリティで保護された暗号化通信をこのサポート セッションで有効にするために、証明書をアップロードできます。

注意事項

  • 暗号化解除ツールを使用して、対応する .pfx 証明書および秘密キーがクライアント コンピューターにインストールされていることを確認してください。

  • 証明書の [キー使用法] フィールドが [証明書の署名] ではないことを確認します。 これを確認するには、証明書を右クリックし、 [開く] を選択し、 [詳細] タブで [キー使用法] を見つけます。

  • サポート セッション証明書は、.cer 拡張子を持つ DER 形式で用意する必要があります。

次のステップ

証明書の要件を確認します。