
かつて山市良と呼ばれたおじさんのブログ
セイテクエンジニアのブログ かつて山市良と呼ばれたおじさんのブログ vol.140 HTTPSコンテンツ配信への対応|Microsoft Connected Cache for E/E 完全導入ガイド(9)
2025年09月25日配信
執筆者:山内 和朗
「Microsoft Connected Cache for Enterprise & Education(以下、Microsoft Connected Cache for E/E)」はMicrosoft CDNのHTTPソースの代替ソースとして機能します。Microsoft Connected Cache for E/Eの一般提供(GA)バージョンでは、新たにHTTPSのサポートが追加され、保護されたコンテンツ配信に対応しました。HTTPSサポートの追加により、コンテンツ配信の進化や変化に適応できるようになり、今後予定されている新しいコンテンツの種類の拡張に対応することができます。なお、HTTPSのサポートはMicrosoft Connected Cache for E/Eの新機能であり、Microsoft Configuration Managerに搭載されているMicrosoft Connected Cache機能には実装されていません(今後対応予定)。
Microsoft 接続キャッシュの HTTPS サポートの概要|Windows(Microsoft Learn)
現在、Microsoft Connected Cache for E/Eでサポートされているコンテンツの種類は、TCPポート「80」を使用するMicrosoft CDNの配信コンテンツ(HTTPソース)であり、LinuxおよびWindowsキャッシュノードを展開すると、既定でHTTPソースの代替ソースとして機能します。
以下のドキュメントにあるコンテンツの種類とサービスエンドポイントの一覧でHTTPS(443)を使用するものをサポートするためには、Microsoft Connected Cache for E/EのキャッシュノードでHTTPSのサポートを構成する必要があります。
Microsoft Connected Cache コンテンツとサービス エンドポイント|Windows(Microsoft Learn)
Intune Win32アプリはHTTPソースとしてキャッシュされますが、Microsoftは2025年11月6日以降、HTTPSのみによる配信に切り替える予定です。そのため、現在、HTTPSのサポートが構成されていないキャッシュノードは、2025年11月6日以降、CDN配信にフォールバックされるようになり、キャッシュの恩恵を受けることができなくなります。また、Microsoft Connected Cache for E/Eで今後サポートが予定されている(一覧のTBD)Microsoft TeamsとMicrosoft Outlook向けのHTTPSコンテンツのキャッシュに対応するためにはキャッシュノードでHTTPSをサポートする必要があります。
Microsoft Connected Cache for E/EのキャッシュノードでHTTPSサポートを有効にするには、キャッシュノードのホストコンピューターで証明書要求(CSR)を作成し、パブリックな証明機関(CA)やエンタープライズPKIのCAで署名し、署名された証明書をホストコンピューターにインポートするという手順が必要になります。MicrosoftはLinuxおよびWindowsキャッシュノードのそれぞれ向けに、HTTPSサポートの有効化手順とスクリプトを用意しています。どちらも同じことを行っているのですが、Linuxキャッシュノードではシェルスクリプト(.sh)を実行して直接的に作業するのに対して、WindowsキャッシュノードではWindowsマシン側でPowerShellスクリプト(.ps1)を実行して、WSL 2上のLinuxディストリビューションに適用する形になります。
Linux 上の Microsoft Connected Cache の HTTPS サポートを有効にする|Windows(Microsoft Learn)
Windows で Microsoft Connected Cache の HTTPS サポートを有効にする|Windows(Microsoft Learn)
上記のドキュメントには前提条件として、“[移行済み(Migrated)] 列に [はい(Yes)] が表示されていることを確認して、ノード が移行されたことを 確認します”と書いてありますが、これはGAバージョンがリリースされる前に展開されたキャッシュノードで必要なGAバージョンへの移行完了の確認ことです(移行されていない場合、Migrated列はNo)。GAバージョンリリース以後に展開されたキャッシュノードには適用されません(Migrated列はN/A)。
HTTPSのサポートを使用するためには、商用(DigiCert、GlobalSign、Entrustなど、有料)または非商用(Let's Encryptなど、無料または有料)のパブリックCAを使用するか、企業内に導入するエンタープライズPKIの環境が必要です。検証用のActive Directoryドメイン(mylab.test)に、Active Directory証明書サービス(AD CS)で構築したエンタープライズPKI環境があるため、この環境を利用して、Windowsキャッシュノードにセットアップしてみました。なお、Windowsキャッシュノードとしては、ドメインメンバーであるWindows 11バージョン24H2マシン(FQDN win11ent01.mylab.test、IPアドレス 192.168.10.106)を、Microsoft Connected Cache for E/Eの実行アカウントとしてドメインユーザーアカウント(mylab¥mccrunact、Windowsマシンに「パッチジョブとしてログオン」のユーザー権利を割り当て)を使用してセットアップ済みです(画面1)。Windowsキャッシュノードのセットアップ手順については、以下の記事を参照してください。
vol.136 Windowsキャッシュノードの導入(前)|Microsoft Connected Cache for E/E 完全導入ガイド(5)
vol.137 Windowsキャッシュノードの導入(後)|Microsoft Connected Cache for E/E 完全導入ガイド(6)
画面1 ドメインメンバーのWindows 11マシン(win11ent01.mylab.test)に、実行アカウント「mylab\mccrunact」でMicrosoft Connected Cache for E/EのWindowsキャッシュノードを展開
WindowsキャッシュノードのWindowsマシンでPowerShell(管理者)ウィンドウを開き、以下のコマンドラインを実行します(画面2)。実行アカウント名、DNS名、IPアドレスは環境に合わせて変更してください。
PS C:¥> $User = "mylab\mccrunact" PS C:¥> $myLocalAccountCredential = Get-Credential $user PS C:¥> cd (deliveryoptimization-cli mcc-get-scripts-path) PS C:¥・・・deliveryoptimization-cli> .\generateCsr.ps1 -RunTimeAccountName $user ` -LocalAccountCredential $myLocalAccountCredential ` -algo RSA -keySize 2048 -csrName "myservercsr" ` -subjectCountry "JP" ` -subjectState "Tokyo" ` -subjectOrg "MyLab" ` -subjectCommonName "localhost" ` -sanDns "localhost,win11ent01.mylab.test" ` -sanIp "127.0.0.1,192.168.1.106" |
画面2 証明書要求(CSR)ファイルを生成する
「インストール先フォルダー(既定はC:¥mccwsl01)¥Certificates¥certs」フォルダーにCSRファイル(拡張子.csr)が生成されるので、AD CSのWindows Serverマシンにコピーします。
AD CSのWindows ServerマシンのコマンドプロンプトまたはPowerShell(管理者)ウィンドウを開き、CSRファイルをコピーしたディレクトリに移動して、次のコマンドラインを実行し、「Webサーバー(WebServer)」証明書テンプレート(またはその複製から作成したテンプレート)を使用して証明書要求に署名して、X.509証明書(拡張子.cer)を発行します。
C:\> certreq -submit -attrib "CertificateTemplate:WebServer" 証明書要求ファイル名.csr mycert.cer |
画面3 AD CSのWindows Serverマシンにログオンし、CSRに署名して証明書(CER)を発行する
Windowsマシンに戻り、発行された証明書(CERファイル)をWindowsマシンのCSRファイルと同じ場所にコピーし、ファイルの拡張子を.crt(mycert.crt)に変更します。PowerShell(管理者)ウィンドウを開き、次のコマンドラインを実行して、証明書をインポートします。
PS C:¥> $User = "mylab\mccrunact" PS C:¥> $myLocalAccountCredential = Get-Credential $user PS C:¥> cd (deliveryoptimization-cli mcc-get-scripts-path) PS C:¥・・・deliveryoptimization-cli> .\importCert.ps1 -RunTimeAccountName $User ` -LocalAccountCredential $myLocalAccountCredential ` -certName "mycert" |
Windowsマシンに対するTCPポート443への着信を、Microsoft Connected Cache for E/EのLinuxディストリビューションにポート転送するように構成し、Windowsファイアウォールでポート443への着信を許可します。それには、PowerShell(管理者)ウィンドウで次のコマンドラインを実行します(画面4)。
PS C:¥> $ipFilePath = Join-Path ([System.Environment]::GetEnvironmentVariable("MCC_INSTALLATION_FOLDER", "Machine")) "wslIp.txt" PS C:¥> [void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "443") PS C:¥> [void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Outbound -Action Allow -Protocol TCP -LocalPort "443") |
画面4 エンタープライズPKIのルートCAで署名、発行された証明書をインポートし、ポート転送とファイアウォールのポート許可を構成する
コマンドプロンプトまたはPowerShellで以下のコマンドラインを実行し、HTTPSとHTTPの両方のプロトコルを使用して、エラーなしでダウンロードが完了することを確認します(画面5)。なお、「swda01-mscdn.manage.microsoft.com」は、Intune Win32アプリのためのCDNのエンドポイントであり、現在はHTTPとHTTPSの両方のプロトコルに対応しています(2025年11月6日以降はHTTPSのみになる予定)。
C:\> curl.exe -v -o NUL "https://<キャッシュノードのIPアドレスまたはFQDN>/ee344de8-d177-4720-86c1-a076581766f9/070a8fd4-79a7-42c8-b7c8-9883253bb01a/c7b1b825-88b2-4e66-9b15-ff5fe0374bc6.appxbundle.bin" --include -H "host:swda01-mscdn.manage.microsoft.com" C:\> curl.exe -v -o NUL "http://<キャッシュノードのIPアドレスまたはFQDN>/ee344de8-d177-4720-86c1-a076581766f9/070a8fd4-79a7-42c8-b7c8-9883253bb01a/c7b1b825-88b2-4e66-9b15-ff5fe0374bc6.appxbundle.bin" --include -H "host:swda01-mscdn.manage.microsoft.com" |
画面5 curl.exeを使用して、HTTPSおよびHTTPの両方のプロトコルでMicrosoft CDN(swda01-mscdn.manage.microsoft.com
からのダウンロードをテストする
Microsoftのコンテンツ配信は進化します。HTTPSのサポートが現在は不要であっても、今後は対応が重要になってくるはずです。Microsoft Connected Cache for E/Eを運用環境に導入する場合は、HTTPSのサポートを有効にすることを前提として導入することをお勧めします。そのためには、パブリックCAを使用するのか、エンタープライズPKIを使用するのかを計画しておく必要があります。また、証明書には有効期限があるため*1、期限切れの証明書を更新するメンテナンス作業が定期的に発生することにも注意が必要です。
*1 パブリックCAのWebサイト用証明書の有効期限は1年前後が一般的です。例えば、無料のLet’s Encryptは90日ですが、今年1月に6日間の短期証明書の提供が発表されています。エンタープライズPKIでは数年単位の長期の有効期限を設定できます。
Microsoft Connected Cache for E/E 完全導入ガイド(1)|(2)|(3)|(4)|(5)|(6)|(7)|(8)|(9)|(10)