「Azure AD（Microsoft Entra ID）のSCIMアプリでLet’s Encryptを使いたいのに、ISRG Root X1の証明書だと本当にダメなの？」という疑問は、ここ数年ずっと現場で繰り返し出ているテーマです。本記事では、最新の公式ドキュメントとQ&Aを踏まえつつ、「何がダメで」「どう回避すればよいのか」を、設計パターンレベルまで踏み込んで整理します。
SCIMアプリとLet’s Encryptの関係をざっくり整理
前提となるシナリオ
まず、今回の話の前提を整理しておきます。
- IdPとして Microsoft Entra ID（旧 Azure AD） を利用している。
- 自前のアプリケーションが SCIM 2.0 エンドポイント を公開しており、ユーザー／グループを自動プロビジョニングしたい。
- Entra 側では「非ギャラリーアプリ（Non‑Gallery Application）」として SCIM を設定している。
- SCIMエンドポイントの HTTPS サーバー証明書に、Let’s Encrypt（ISRG Root X1）発行の証明書 を使いたい。
多くのSaaS／社内Webアプリは、コストや自動更新のしやすさから Let’s Encrypt を採用しています。その延長で「SCIMエンドポイントもそのまま Let’s Encrypt でいけるのでは？」と考えるのは自然です。
ところが、Microsoft Entra のプロビジョニングサービス（SCIMクライアント）は、TLSサーバー証明書の“ルートCA”にかなり厳しい制限を設けているため、ここでつまずきやすくなっています。
結論：ISRG Root X1 の Let’s Encrypt 証明書は SCIM 用途では「非対応」扱い
Microsoft 公式ドキュメント「Tutorial: Develop and plan provisioning for a SCIM endpoint in Microsoft Entra ID」の「Building a custom SCIM endpoint」セクションには、次のような要件が明記されています。
SCIMエンドポイントが提示するサーバー証明書のルート認証局名は、以下のいずれかでなければならない：
| ルートCA名 | 補足 |
|---|---|
| CNNIC | China Internet Network Information Center |
| Comodo | 現 Sectigo 系列のブランド |
| CyberTrust | 旧来からあるグローバルCA |
| DigiCert | 企業向けTLSでメジャーなCA |
| GeoTrust | DigiCert 傘下のブランド |
| GlobalSign | 日本国内でも利用例が多いCA |
| Go Daddy | レンタルサーバー系でよく見かけるCA |
| VeriSign | 現在は Symantec／DigiCert 系に統合 |
| WoSign | 中国系のCA（ブラウザ側では制限も多い） |
| DST Root CA X3 | Let’s Encrypt が過去に利用していたルート（既に失効済み） |
この記事の最終更新日は 2025-10-06 と表示されており、現時点でもこのリストに ISRG Root X1 は含まれていません。
さらに、2022年の Microsoft Q&A では、Let’s Encrypt の新ルート（ISRG Root X1）がサポートされるかという質問に対し、Microsoft の担当者が次のように回答しています。
- 「ドキュメントに記載されているルートCAのみがサポート対象であり、現時点でこのリストを拡張する予定はない。」
以上から、少なくとも 2025年秋時点では、ISRG Root X1 の Let’s Encrypt 証明書は “公式にはサポートされない” と判断するのが妥当です。
実運用上も、ISRG Root X1 で発行した証明書をそのまま SCIM エンドポイントに設定すると、Entra 管理センターでの [Test connection] が TLS エラーで失敗し、プロビジョニングジョブも起動しません（証明書検証で弾かれるため）。
この制限は「SCIM の TLS 検証」専用の話
ここでよくある誤解が「Azure は Let’s Encrypt を信頼しているはずだから、SCIM でも動くのでは？」というものです。
実際には次のように考えると整理しやすくなります。
| 観点 | 通常の Azure サービス | Entra SCIM プロビジョニングサービス |
|---|---|---|
| 信頼ストア | OS / ブラウザの一般的なルートストア | SCIM 用に固定されたルートCAリスト |
| Let’s Encrypt (ISRG Root X1) | 多くのシナリオで利用可能 | リスト外のため、TLS検証で不合格 |
| 管理者によるCA追加 | 一部のサービスでは可能 | SCIMクライアント側のルートCAを管理者が増やすことは不可 |
つまり、Azure 内の一般的な HTTPS 通信で Let’s Encrypt が問題なく使えているとしても、SCIM だけは「別ルール」で動いていると捉えるのがポイントです。
Let’s Encrypt と DST Root CA X3 の歴史的事情
DST Root CA X3 失効と Let’s Encrypt の移行
Let’s Encrypt は、初期には IdentTrust の DST Root CA X3 からクロス署名を受ける形で信頼を確立していました。しかし、このルート証明書は 2021年9月30日 に失効しています。
失効後も古い Android 端末向けに特別なクロス署名チェーンを提供するといった工夫はありましたが、現在の主流は ISRG Root X1 をルートとするチェーン です。
一方で、Microsoft Entra の SCIM ドキュメントには今も DST Root CA X3 が「許可されたルートCA名」として列挙されたままになっています。
しかし、ここで重要なのは次の2点です。
- DST Root CA X3 自体は有効期限切れであり、新規に「安全な運用」を行う前提としては使うべきではない。
- Let’s Encrypt も既に ISRG Root X1 への移行を完了しており、「SCIMのためだけにDST Root CA X3チェーンに戻す」という運用は非現実的。
したがって、「ドキュメントに DST Root CA X3 と書いてあるから、Let’s Encrypt を無理やり旧チェーンで使う」というのは避けるべきです。
実務的な対処パターン（おすすめ順）
パターン1：対応ルートCAの証明書に切り替える（王道）
最もシンプルで再現性も高い解は、SCIMエンドポイントが提示するサーバー証明書だけ、対応ルートCAで発行されたものに切り替える方法です。
例えば以下のようなCAから商用サーバー証明書を取得し、SCIMエンドポイント用のホスト名に割り当てます。
- DigiCert
- GlobalSign
- GeoTrust / Go Daddy など
手順のイメージは次の通りです。
| ステップ | 作業内容 | ポイント |
|---|---|---|
| 1. 対象ホスト名の決定 | scim.example.com のように、SCIM専用のFQDNを決める。 | 将来の移設やプロキシ挟み込みを考え、アプリ本体とは別名にしておくと柔軟。 |
| 2. CSRの作成 | アプリサーバー、リバプロ、または証明書管理基盤でCSRを作成。 | SAN にも SCIMエンドポイントのFQDNが含まれていることを確認。 |
| 3. CAからの発行 | 上記リストにある対応ルートCAでサーバー証明書を発行。 | チェーン証明書（中間証明書）も必ず入手しておく。 |
| 4. SCIMエンドポイントに適用 | アプリケーションのWebサーバー（IIS / Nginx / Apache / Kestrelなど）に証明書を適用。 | TLS 1.2 以上を有効化し、古いプロトコルを無効化するのが望ましい。 |
| 5. Entra 側で[Test connection] | Entra 管理センターで SCIM の「Tenant URL」と「Secret Token」を設定し、[Test connection] ボタンで疎通を確認。 | ここで成功すれば、証明書要件はクリアしたとみなせる。 |
商用証明書のコストは発生しますが、「余計な仕掛けを増やさない」という意味では最もシンプルです。マルチテナントSaaSなど、長期運用が前提のサービスではこのパターンを第一候補として検討する価値があります。
パターン2：リバースプロキシ／CDNでTLSを終端する
既にアプリ全体で Let’s Encrypt をガッツリ使っている場合、「SCIMのためだけにアプリ側の証明書を全部変える」のは現実的でないケースも多いでしょう。その場合に有効なのが、前段にリバースプロキシまたはCDNを置いて、そこで対応ルートCAの証明書だけを提示させる方式です。
Microsoft Entra (SCIMクライアント)
|
v
[リバースプロキシ / CDN]
├─ TLS終端：DigiCert等の対応ルートCA
└─ バックエンド：Let’s Encrypt / 社内CA など自由
|
v
[SCIMアプリケーション]
代表的な実装パターンとしては、以下のような構成が考えられます。
- Azure Application Gateway (+ WAF)
- Azure Front Door
- Nginx / Apache / Envoy などのリバプロをIaaSやコンテナで配置
この場合、Entra から見えるのはあくまで「プロキシの証明書」だけなので、プロキシにだけ対応ルートCAの証明書を載せればよい点がメリットです。バックエンドとの通信は、以下のいずれでも構いません。
- HTTP（VNet内・専用ネットワーク内限定であれば現実的）
- HTTPS（ここでは Let’s Encrypt や社内CAを使ってもよい）
このパターンのメリット／デメリットを整理すると次の通りです。
| 項目 | メリット | 注意点 |
|---|---|---|
| 証明書管理 | 対応ルートCA証明書はプロキシ1か所に集約できる。 | プロキシ側の証明書更新を自動化する仕組み（Key Vault連携など）を用意したい。 |
| アプリの変更範囲 | SCIMアプリ本体の証明書設定はそのまま維持可能。 | 新しいFQDNをプロキシに割り当て、DNSとEntra設定を更新する必要がある。 |
| ネットワーク構成 | WAF・レート制限・IP制限などを一箇所で実装できる。 | 構成が一段複雑になるため、監視とログ設計を意識する。 |
既存の Web アプリに後付けで SCIM を追加するようなケースでは、この「前段TLS終端」パターンが最も現実的な落としどころになることが多いです。
パターン3：DST Root CA X3 への回帰は「非現実的」
「ドキュメントに DST Root CA X3 と書いてあるし、Let’s Encrypt の昔のチェーンを使えばいいのでは？」という発想も出がちですが、これはセキュリティと運用の両面からおすすめできません。
- DST Root CA X3 は 2021年9月30日に正式に失効しており、最新のクライアントでは信頼されません。
- Let’s Encrypt 自身も、ISRG Root X1 への移行を完了した上で、古い環境との互換性確保のために限定的なクロス署名を提供していただけであり、「新規構成でDSTチェーンに戻す」ことは想定していません。
- 仮に一部クライアントで動いたとしても、他のサービスやツールとの互換性を自ら壊しにいく形になるため、長期運用はほぼ不可能です。
したがって、「SCIMがDST Root CA X3しか認めていないから、Let’s Encryptも旧チェーンに戻す」という選択肢は、現代の運用では“なし”と考えるべきです。
パターン4：事前に自己診断＋SCIM Validatorでの検証
証明書まわりの設定に自信がない場合は、Entra 側で[Test connection]する前に、自分でチェックできるポイントを押さえておきましょう。
証明書とTLSのセルフチェック項目
| チェック項目 | 内容 | 確認のポイント |
|---|---|---|
| 証明書チェーン | 中間証明書を含む完全なチェーンが正しく配信されているか。 | ブラウザや openssl s_client -showcerts などで確認。ルートまで途切れず繋がっているか。 |
| FQDNの一致 | 証明書の CN / SAN に、SCIMエンドポイントのFQDNが含まれているか。 | https://scim.example.com/ に対して、少なくとも SAN に scim.example.com があること。 |
| TLSバージョン | TLS 1.2 以上が有効か。 | 古い TLS 1.0 / 1.1 は無効化し、TLS 1.2 / 1.3 を優先。 |
| 有効期限 | 証明書の NotBefore / NotAfter が妥当か。 | 期限切れ・未来日すぎるもの（まだ有効になっていない）に注意。 |
| 失効確認 | CRL / OCSP へのアクセスが阻害されていないか。 | オンプレ環境では、プロキシ越しで失効確認が失敗することもあるため注意。 |
Microsoft Entra SCIM Validator の活用
証明書が問題なさそうに見える場合は、SCIMのプロトコル実装自体に問題がないかも併せて確認しておくと安心です。
Microsoft は 「Microsoft Entra SCIM Validator」 という無償ツールを提供しており、ブラウザから SCIM エンドポイントの互換性を検証できます。
- SCIMエンドポイントの URL とトークンを入力するだけで、
POST /UsersやPATCH /Usersなど代表的な操作のテストが実行される。 - どのリクエストが成功／失敗したか、レスポンスJSONのどこに問題があるかが一覧で確認できる。
- User / Group / Schema の3パターンでの検証が可能。
Entra 側の[Test connection]に進む前に、SCIM Validatorで一度フルテストを回しておくと、問題の切り分けがグッと楽になります。
よくある疑問・勘違いポイント
Q1. 「Azure では Let’s Encrypt が普通に動いているのに、なぜ SCIM だけダメなの？」
前述の通り、SCIM プロビジョニングサービスは「独自の固定ルートCAリスト」を使ってTLS検証を行っていると考えられます。
- 通常のWebアプリ接続：ブラウザ／OSのルートストア & 一般的なクラウド基盤の信頼リストを利用。
- SCIMプロビジョニング：ドキュメントに明示された CA 名だけを許可する、より限定的なリストを使用。
この違いにより、「ブラウザからは問題なく開けるけど、SCIMの[Test connection]だけ失敗する」という状況が起こります。
Q2. 「ISRG Root X1 は Microsoft Trusted Root Program にも入っているのに？」
Microsoft の Trusted Root Program の参加 CA 一覧には、さまざまなルート証明書が含まれますが、それとSCIMの制限は別問題です。
SCIM の場合は、「SCIMクライアント＝Microsoft Entra プロビジョニングサービス」がどの CA を受け入れるかを、個別に決めていると考えるべきであり、一般的な OS / ブラウザのトラストストアとは一致していません。
Q3. 「ルートCA名の文字列だけ合わせれば、ISRG Root X1 でも通るのでは？」
証明書の Subject を無理やり書き換えたり、怪しい中間証明書を噛ませたりして、「見かけ上の名前だけ合っていればよいのでは？」という発想は、セキュリティ的に完全にアウトです。
- CAのポリシーにも違反しますし、クライアント側の検証でも整合性が取れません。
- 証明書偽装行為として、最悪の場合不正アクセスや中間者攻撃の温床になります。
SCIMエンドポイントでは、正規のCAから正しい手順で発行された証明書を使うことが大前提です。
設計パターン別：どの解決策を選ぶべきか
ここまでの内容を踏まえて、代表的なシステム構成ごとに、どのパターンが向いているかをまとめます。
| シナリオ | 向いている解決策 | 理由 |
|---|---|---|
| 新規SaaSをゼロから設計 | パターン1（対応ルートCAの証明書を直接適用） | 最初から SCIM を前提に設計できるため、証明書を1本用意しておく方がシンプル。 |
| 既存Webアプリに後付けでSCIM追加 | パターン2（リバースプロキシ終端） | 既存の Let’s Encrypt 構成を崩さずに、SCIM用の入り口だけ別証明書にできる。 |
| 社内オンプレ＋VPN経由で接続 | パターン2 or パターン1 | 外部公開するのがプロキシだけの構成にしておくと、ファイアウォール設計も簡単。 |
| 短期間のPoCや検証環境 | パターン1（安価なDV証明書）＋SCIM Validator | PoC段階なら1枚の商用証明書で十分。SCIM Validatorで動作確認しやすい。 |
今後のアップデートにどう備えるか
2022年のQ&A回答では「リスト拡張の予定なし」とされていましたが、その後も Let’s Encrypt の普及は続いており、2025年にも「再検討してほしい」というコメントが付いています。
ただし、2025年11月時点で公開されている公式ドキュメントには、依然として ISRG Root X1 追加の記載はありません。
そのため、現実的な方針としては次のようになります。
- 本番運用：「現在の制約を前提にした設計（対応ルートCA or リバースプロキシ）」を行う。
- 中長期：Entra SCIM のドキュメント更新と Q&A を定期的にウォッチし、ルートCAリストに変更が入ったタイミングで再評価する。
もし将来、ISRG Root X1 が正式にサポートリストに追加されれば、そのとき初めて 「SCIMエンドポイントも Let’s Encrypt 一色に統一する」という選択肢を検討できます。それまでは、SCIMだけ例外的に“有料証明書＋またはプロキシ”で運用するのが安全です。
まとめ：安全・安定なSCIM連携のための実務指針
- ISRG Root X1 による Let’s Encrypt 証明書は、Microsoft Entra の SCIMエンドポイント用途としては「非対応」扱い。（公式ドキュメントのルートCA固定リストに含まれていない）
- この制約は SCIM プロビジョニングサービスの TLS 検証に固有のもので、Azure 全体の一般的な信頼リストとは別物。
- 最もシンプルな解決策は、対応ルートCA（DigiCert / GlobalSign など）の証明書に切り替えること。
- 既存の Let’s Encrypt ベース構成を崩したくない場合は、前段のリバースプロキシ／CDNで対応ルートCA証明書を提示して TLS を終端する構成が有力。
- DST Root CA X3 への回帰は、ルートの失効と互換性の観点から事実上「NG」。
- 接続前には、証明書チェーン・FQDN・TLSバージョン・有効期限などのセルフチェックを行い、Microsoft Entra SCIM Validator でプロトコル準拠も含めて検証しておくとトラブルシュートが容易になる。
この方針で設計しておけば、「本番直前になって[Test connection]が通らない」「ルートCAの要件を見落としていた」といった事故を防ぎつつ、Microsoft Entra ID と自前アプリの間で、安定したSCIMプロビジョニング基盤を構築できます。
コメント