【証明書入門 第9回】社内PKIとクラウド ― AD CSの設計と守り方、ACM・Private CA、LBでのTLS終端、vSphere

証明書・PKI
スポンサーリンク
スポンサーリンク

「社内CAは、とりあえずドメインコントローラーに入れておけばいいですよね？」
「ALBの裏のサーバー、自己署名証明書のままでも動いているから大丈夫です」

社内PKIとクラウドの証明書には、公開CAとは違う落とし穴があります。社内CAは、設定を1つ誤るだけで一般ユーザーがドメイン管理者になれてしまう攻撃の入口になりますし、クラウドのロードバランサーには、証明書を検証しないものもあります。

第8回では、ACMEによる自動化を見ました。第9回では、社内PKI（AD CS）の設計と守り方、クラウドの証明書サービス（ACM・Private CA・Azure）、ロードバランサーでのTLS終端、そしてvSphereの証明書を扱います。

AD CSの設計：2層構成

AD CS（Active Directory 証明書サービス）で社内PKIを作るときの基本形は、オフラインのルートCAとオンラインの発行CAの2層構成です。

ドメインに参加しないスタンドアロンのルートCAを電源オフで保管して年に数回だけ起動し、ADドメインのエンタープライズCAの発行CAに署名し、発行CAがテンプレートと自動登録でPC・サーバー・ユーザーに発行し、CRLとCA証明書はWebで引ける状態に保つことを示す図
  • ルートCA：ドメインに参加させないスタンドアロンCAとして構築し、発行CAの証明書に署名したら電源を切って保管する。ルートCAの秘密鍵が漏れると、社内のすべての証明書が信用できなくなり、作り直しと全端末への再配布が必要になるため
  • 発行CA：日々の発行は、ドメインに参加したエンタープライズCAに担わせる。エンタープライズCAはADと連携し、証明書テンプレートと自動登録を使える

ルートCAがそのまま発行する1層構成は手軽ですが、ルートの鍵を常にネットワークに置くことになるため、検証環境向けです。3層構成は、拠点や用途ごとに方針を分けたい大規模な組織の選択肢です。

CRL・AIAの公開場所と有効期間

項目ルートCA（オフライン）発行CA（オンライン）注意
CA 証明書の有効期間例：20年例：10年CA は自分の期限を超える証明書を出せない。期間の半分で更新するのが推奨
CRL の有効期間例：6か月〜1年。デルタCRL は使わない既定：ベースCRL 1週間、デルタCRL 1日次回更新（NextUpdate）を過ぎると、配下の証明書の検証が失敗する
CRL の公開起動して手動で発行し、Web サーバーへ手でコピー自動で発行し、Web サーバーと AD に公開ルートの CRL 更新は年間の作業予定に入れる
CDP・AIA の URLHTTP（例：http://pki.corp.example.jp/）を先頭に同じく HTTP を先頭に。LDAP は AD 参加の端末向け発行前に決める。後で変えても発行済みの証明書は古い URL のまま
CA 証明書の更新（再署名）同じ鍵で再署名するか、新しい鍵で作り直す更新の要求をルートへ運び、署名してもらう新しい鍵のルートは全端末への再配布が必要
C:\> certutil -setreg CA\CRLPeriodUnits 52       # ルートCA：CRL の有効期間を52週に
C:\> certutil -setreg CA\CRLPeriod "Weeks"
C:\> certutil -setreg CA\CRLDeltaPeriodUnits 0   # デルタCRL を使わない
C:\> net stop certsvc & net start certsvc
C:\> certutil -CRL                               # CRL を発行（CertEnroll フォルダーに出力）

オフラインのルートCAで見落としがちなのが、ルートのCRLの更新です。電源を切って保管しているルートCAのCRLが期限（NextUpdate）を過ぎると、配下のすべての証明書の検証が失敗します。年間の作業予定に必ず入れておきましょう。Microsoftは、オフラインのルートCAではデルタCRLを使わないこと、Windows以外の端末のためにHTTPのCDPを用意することを勧めています。OCSP（オンラインレスポンダー）は任意です（第5回）。

発行CAをDCに立てない理由

冒頭の「社内CAはDCに入れておけばいい」への答えです。発行CAは、ドメインコントローラー（DC）に立てません。Microsoftも、DC上でCAを動かすことを推奨していません。

DCにCAとIIS（Web登録）を同居させると、CAを消すまでDCを降格できず、CAの管理者にDCのログオン権限が必要になり、NTLM中継（ESC8）の的がDCそのものになるのに対し、推奨は専用の発行CAをTier 0として守り、CRL・AIAを配るWebサーバーは別の台にすることを示す図
  • 理由① 運用の自由度：CAが入ったDCは降格できず、先にCAの役割を削除する必要がある。DCの入れ替えのたびにCAの移行が必要になり、CAを入れたサーバーの名前は変えられない（変えると発行済みの証明書が使えなくなる）
  • 理由② 権限の分離：CAの管理者にDCへのログオン権限を与えることになり、PKIの担当とドメインの管理者を分けられない
  • 理由③ 攻撃の的：DCにWeb登録（IIS）を入れると、NTLMの中継攻撃（ESC8、後述）の的がDCそのものになる

ただし、発行CAはDCと同じ重要度で守ります。発行CAを乗っ取られると、ドメイン管理者を含む任意のユーザーの証明書を発行でき、DCを乗っ取られたのと同じだからです。Microsoftの区分ではTier 0（最重要の資産）として扱います。

推奨構成は、発行CAを専用のメンバーサーバーに置き、CRLを配るWebサーバーは別にすることです。ルート証明書はGPOで配布し、CAの鍵はHSMか、暗号化したバックアップで保管します。分けるのは運用と権限のため。守る重さはDCと変わりません。

証明書テンプレートと自動登録

テンプレートは、発行する証明書の型です。用途（EKU）、鍵の種類と長さ、有効期間、サブジェクトの作り方、誰が申請できるかを決めます。既定のテンプレートはコピーし、名前を付けて使います。

管理者がテンプレートを作成してグループに自動登録を許可し、GPOで自動登録を有効化すると、PC・サーバーがCSRを送り、発行CAがテンプレートどおりに発行して証明書ストアに入り、期限が近づくと自動で繰り返すことを示す図
  • サブジェクトは「Active Directoryの情報から構築する」を基本にする。「要求に含まれる」（申請者が名前を指定できる）は、Webサーバー用など必要なものに限り、CA管理者の承認を必須にする（ESC1の対策）
  • 自動登録：テンプレートのセキュリティで、対象のグループに「読み取り」「登録」「自動登録」を許可し、GPOで自動登録を有効にする
コンピューターの構成 > ポリシー > Windows の設定 > セキュリティの設定
  > 公開キーのポリシー > 証明書サービス クライアント - 自動登録
  （構成モデル：有効／期限切れの証明書の書き換え・更新にチェック）
PS> certutil -pulse                               # 自動登録をすぐに実行
PS> Get-ChildItem Cert:\LocalMachine\My | Format-Table Subject, NotAfter, Thumbprint
PS> Get-Certificate -Template CorpWebServer -DnsName app01.corp.example.jp `
      -CertStoreLocation Cert:\LocalMachine\My    # 手動で申請する場合

自動登録された証明書は、期限が近づくと自動で更新されるため、期限切れの事故を防げます。人の作業は設定だけで、発行と更新は端末とCAの間で回ります。Linuxや機器は自動登録を使えないため、ACMEなどを検討します（第8回）。

AD CSの脆弱性（ESC1〜ESC8など）

AD CSは、設定の誤りがそのままドメインの乗っ取りにつながることで知られています。

一般ユーザーの社員AがSAN＝administratorのCSRを送ると、申請者が名前を指定でき・クライアント認証に使え・Domain Usersが登録できるテンプレートでは管理者名義の証明書がそのまま発行され、PKINITでDCから管理者のKerberosチケットを得てドメインを乗っ取れるESC1の流れを示す図
番号設定の誤り悪用されると対策
ESC1申請者が SAN を指定でき、クライアント認証に使え、一般ユーザーが登録できるテンプレート管理者の名前の証明書を取り、管理者としてログオンサブジェクトを AD から構築。承認を必須に。登録権限を絞る
ESC2・ESC3用途が「すべての目的」や用途なし、登録エージェントのテンプレート何にでも使える証明書、他人の代理での申請用途を最小に。登録エージェントに制限を設定
ESC4・ESC5テンプレートや PKI のオブジェクト（CA のコンピューター、コンテナー）に書き込み権限テンプレートを ESC1 の形に書き換えるACL を棚卸しし、Tier 0 の管理者だけに
ESC6CA のフラグ EDITF_ATTRIBUTESUBJECTALTNAME2どのテンプレートでも SAN を指定できるフラグを外す
ESC7CA の管理（ManageCA・証明書の管理）の権限が広いCA の設定変更、保留中の申請の承認CA の管理者を最小限に
ESC8Web 登録（HTTP）が NTLM 認証を受け付けるDC の NTLM 認証を中継し、DC の証明書を取得HTTPS と拡張保護（EPA）、NTLM の無効化、不要なら Web 登録を削除
ESC9〜ESC16SID 拡張の無効化、弱いマッピング、RPC への中継、バージョン1のテンプレート（ESC15：CVE-2024-49019）など同上更新プログラムの適用と強力なマッピング

特にESC1は要注意です。「申請者が名前を指定できる」「クライアント認証に使える」「一般ユーザーが登録できる」の3つの条件がそろったテンプレートが1つあれば、一般ユーザーが管理者になれます。

ESCは、SpecterOpsが2021年の論文「Certified Pre-Owned」で整理した攻撃の分類で、その後も番号が増えています。Certipy・Locksmithなどのツールや、Microsoft Defender for Identityで検出できます。点検は、自社が管理し許可を得た環境だけで行ってください。

Certifriedと強力な証明書マッピング

2022年5月に修正されたCertifried（CVE-2022-26923）は、一般ユーザーが作れるコンピューターアカウントのDNS名をDCと同じにし、DC名義の証明書を取れてしまう脆弱性でした。

弱いマッピングでは攻撃者が作ったコンピューターのDNS名をdc01にした証明書をKDCが名前だけでDC01として認証してしまうが、強力なマッピング（KB5014754）ではSID拡張をDC01のSIDと照合して一致しないので拒否することと、2022年5月の互換モードから2025年9月の完全な強制までの経緯を示す図
  • 原因は、DCのKDC（Kerberosの認証サービス）が、証明書の名前だけでアカウントを結び付けていた（弱いマッピング）こと
  • Microsoftは、証明書に申請者のSIDを入れる拡張と、SIDや明示的な対応付け（発行者とシリアル番号など）で確かめる強力なマッピングを導入した（KB5014754）
  • 2025年2月に強制モードが既定になり、2025年9月の更新で互換モードに戻す手段もなくなった

SIDの無い古い証明書や他社CAの証明書に頼る認証（スマートカード、802.1X、VPNなど）は、再発行か明示的な対応付けが必要です。今は、SIDも明示的な対応付けも無い証明書では、認証が通りません。

AD CSを守る運用とWindows Server 2025

CAのフラグ（ESC6）、テンプレートの一覧と権限（ESC1〜4）、監査ログ（4886要求・4887発行）、Web登録のHTTPS＋EPA（ESC8）、鍵とDBのバックアップと復元の5つの点検項目と、Windows Server 2025の2026年5月の更新からのML-DSAのCA（検証用）を示す図

定期点検では、CAのフラグ（ESC6）、発行中のテンプレート、テンプレートとCAの権限を確認します。

C:\> certutil -getreg policy\EditFlags     # EDITF_ATTRIBUTESUBJECTALTNAME2 が無いこと
C:\> certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
C:\> certutil -CATemplates                 # 発行中のテンプレートの一覧
C:\> certutil -setreg CA\AuditFilter 127   # CA の監査を有効化（要求 4886・発行 4887 など）
  • 使っていないテンプレートは発行の対象から外す。バージョン1のテンプレート（既定の「Webサーバー」など）は、コピーしてバージョン2以上にする（ESC15の対策）
  • Web登録（/certsrv）はHTTPSと拡張保護を必須にし、使っていなければ削除する（ESC8の対策）
  • CAの鍵とデータベースを定期的にバックアップし、復元の手順を試しておく（certutil -backup、Backup-CARoleService）

設定の点検と、気づく仕組み（監査ログ）と、戻す手段（バックアップ）の3つをそろえるのがポイントです。

Windows Server 2025では、2026年5月のセキュリティ更新（KB5087539）以降、AD CSで耐量子計算機暗号の署名ML-DSA（FIPS 204）のCAとテンプレートを作れるようになりました（第1段階。ML-KEMや複合署名は今後の予定）。クライアントはWindows 11 24H2／25H2の2025年10月以降の更新が必要で、ほかのOSやブラウザーの対応は限られるため、当面は検証用です。また、Windows Server 2025では、TLSのサーバー認証に2048ビット未満のRSAの証明書を使えません。

ACM（AWS Certificate Manager）

ここからはクラウドです。まずはAWSのACMです。

Route 53のCNAMEで検証したACMの証明書を、ALB・CloudFront・API GatewayなどAWSのサービスに無料で置いて自動更新する方法、有料でエクスポートしてEC2やオンプレで使う方法、2026年7月からのACMEで発行・更新する方法の3つを示す図
項目内容（2026年9月時点）注意
発行元と料金Amazon Trust Services。AWS のサービスで使う公開証明書は無料CAA を使うなら amazon.com などを許可する
有効期間と更新198日（2026年2月18日以降の発行・更新）。期限の45日前に自動更新有効期間の短縮（第6回）に合わせて395日から変更
ドメインの検証DNS 検証（CNAME）、メール検証、HTTP 検証（CloudFront）DNS 検証の CNAME を消すと自動更新が止まる。メール検証は更新のたびに承認が必要
置き場所ELB、CloudFront（us-east-1 で発行）、API Gateway など秘密鍵は取り出せず、AWS の中で管理される
エクスポート可能な公開証明書2025年6月から。秘密鍵ごと取り出し、EC2 やオンプレで使える（198日版は FQDN あたり7ドル、ワイルドカード79ドル）取り出した鍵の保護と、更新後の再配置は自分で行う
ACME への対応2026年7月から。certbot、cert-manager などの ACME クライアントで発行・更新できる料金は ACM の料金ページで確認
インポートした証明書他の CA の証明書を ELB などで使える自動更新されない。期限を自分で監視する

ACMが期限の前に更新できないときは、AWS HealthとEventBridgeに30日前から通知されます（ACM の全体像は連載「クラウド入門」第9回）。置き場所で鍵の扱いが決まります。AWSのサービスに置く方法なら、鍵がAWSの外に出ません。

見落としがちな落とし穴は、DNS検証のCNAMEを消すと自動更新が止まることと、インポートした証明書は自動更新されないことです。

AWS Private CAとAzureの対応

役割AWSAzure違い・注意
公開証明書の発行と自動更新ACMApp Service・Front Door のマネージド証明書Azure には ACM と同じ汎用のサービスは無い
証明書と鍵の保管ACM（インポート）Key Vault（証明書）Key Vault は DigiCert・GlobalSign と連携して自動更新できる
社内CAAWS Private CA（汎用モード 月400ドル／CA、短期証明書モード 月50ドル／CA）汎用の CA サービスは無い。端末向けは Intune の Microsoft Cloud PKI、ほかは VM 上の AD CS短期証明書モードは最長7日の証明書だけを発行
AD の端末への自動登録Private CA の Connector for ADMicrosoft Cloud PKI（Intune の SCEP で配布）どちらもルートの配布は別に必要
ロードバランサーでの終端ALB・NLB（ACM の証明書）Application Gateway・Front Door（Key Vault の証明書）考え方は同じ
AWSとAzureの証明書サービスを、公開証明書・保管・社内CA・ADの端末・LBでの終端の役割ごとに対応させ、社内CAだけは1対1にならないことを示す図

AWSはACMとPrivate CA、AzureはKey Vaultが中心です。社内CAだけは1対1になりません。AWS Private CAは、ルートと下位CAの階層を作れ、証明書ごとにも料金がかかります（汎用モードは月1,000枚まで1枚0.75ドル）。社内のWebサーバー、コンテナー間のmTLS（第7回）、IoT機器の証明書に向いています。AD CSから移る場合は、Connector for ADで自動登録を引き継げます。

ロードバランサーでのTLS終端と再暗号化

方式証明書と鍵の置き場所ロードバランサーでできること向くケース
終端（LB で復号し、先は HTTP）LB に公開証明書1枚パスやホスト名での振り分け、Cookie でのセッション維持、WAFLB と Web サーバーの間が信頼できるネットワーク
終端＋再暗号化LB に公開証明書、Web サーバーに社内向けの証明書上と同じ。経路上も暗号化される規程で「経路上すべて暗号化」が求められる
パススルー（TCP のまま転送）各 Web サーバーに公開証明書と鍵TCP の分散だけ（中身は見られない）端から端までの暗号化が必須、STARTTLS を使うメールなど
LBで復号して先はHTTPにする終端、LBで復号して社内CAの証明書で再度暗号化する再暗号化、TCPのまま転送して同じ鍵がWebの台数分必要になるパススルーの3つの方式を示す図
  • 証明書の枚数は、台数ではなく名前で数えます。パススルーでは、同じ鍵がWebサーバーの台数分に増える
  • 再暗号化では、LBがWebサーバーの証明書を検証するかを確認する。AWSのALBはターゲットの証明書を検証しないため、自己署名や期限切れでも通信できる

冒頭の「ALBの裏は自己署名でも動いている」は、まさにこれです。動いているのは、ALBが検証していないからであって、安全だからではありません。鍵の置き場所が増えるほど、漏えいの危険と更新の手間が増えます。

vSphereの証明書の仕組み

最後に、インフラでよく出会うvSphereの証明書です。

vSphere Clientで接続するとvCenter Server内のVECSにあるMachine SSL証明書（443番）が見え、vCenter内蔵のVMCA（ルート10年）が署名し、ESXiは追加時に1825日の証明書を自動発行されることを示す図
  • vCenter Serverには、VMCA（VMware Certificate Authority）というCAが組み込まれている。vSphere 7以降はPSCがvCenterに統合されたため、今はvCenterのVMCAのこと
  • 利用者のブラウザーに見えるのは、443番で使うMachine SSL証明書
  • ESXiはvCenterに追加されると、VMCAが署名した証明書を自動で受け取る。有効期間は既定で1825日（5年）。VMCAのルートは既定で10年で、VMCAが署名する証明書はルートの期限を超えない
  • vCenter 8.0 Update 3h以降は、VMCAのMachine SSL証明書を期限の5日前に自動更新する

既定では発行元がすべてVMCAなので、信頼させるにはVMCAのルートを配る必要があります。

VMCAの使い方の選択肢

方式社内CA などからもらう証明書管理の手間向くケース
VMCA をそのまま使う（既定）なし。VMCA のルートを管理者の端末に配る最小。ESXi の追加・更新は自動小規模。管理者だけが使う環境
ハイブリッドvCenter の Machine SSL だけ、社内CA の Web サーバー用証明書を1枚小。ESXi は VMCA のままCA を下に作れない方針で、vSphere Client の警告を消したい
VMCA を中間CA にする「下位の証明機関」用の証明書を1枚（Web サーバー用では動かない）小。以後は VMCA が社内CA のチェーンで自動発行社内PKI にそろえたい中〜大規模。ESXi を追加する前に行う
カスタムvCenter と ESXi の台数分（例：1＋8枚）大。発行も更新も台数分の手作業規程で VMCA を使えない場合だけ
社内CAからもらう枚数が、既定は0枚、ハイブリッドは1枚、VMCAを中間CAにする方式は1枚、カスタムはvCenterとESXi 8台で9枚になり、その枚数がそのまま手作業の量になることを示す図

Broadcomは1つの方式を推奨せず、「小規模はハイブリッド、大規模は中間CAが多く、カスタムは手間に見合わないことが多い」としています。ワイルドカード証明書は使えません。手順はBroadcom TechDocsで版ごとに確認します。社内CAからもらう枚数が、そのまま手作業の量になります。第11回の演習（問5）で、この選び方を考えます。

考えてみよう

  1. 社内のAD CSは何層構成で、ルートCAの秘密鍵はどこにありますか。ルートCAのCRLが次に切れるのはいつですか。
  2. 発行中のテンプレートの中に、「申請者が名前を指定できる」「クライアント認証に使える」「一般ユーザーが登録できる」の3つがそろったものはありますか。
  3. 社内のロードバランサーの配下で、公開証明書の秘密鍵が置かれている場所はいくつありますか。それを1か所に減らせますか。

ヒント：1問目はcertutil -dump ルートCA.crlのNextUpdate（次の更新）、2問目は「証明書テンプレート」と「ESC1」、3問目は「ロードバランサーでのTLS終端」の3つの方式から考えてみてください。

まとめ

  • AD CSはオフラインのルートCA＋エンタープライズの発行CAの2層。ルートのCRL更新を忘れない
  • 発行CAはDCに立てないが、Tier 0としてDCと同じ重さで守る
  • テンプレートのサブジェクトはADから構築。ESC1の3条件がそろったテンプレートを作らない
  • 強力な証明書マッピングは2025年9月に完全に強制。SIDの無い古い証明書に注意
  • ACMは198日・45日前に自動更新。DNS検証のCNAMEを消さない。インポートは自動更新されない
  • ALBはターゲットの証明書を検証しない。vSphereはハイブリッドか中間CAが現実的

次回は、証明書のエラーが起きたときに、原因を切り分ける手順をまとめます。

連載「証明書入門」全11回

  1. なぜ証明書が必要か
  2. 暗号の基礎
  3. openssl・PowerShellで試す
  4. X.509証明書の中身
  5. PKIと信頼の仕組み
  6. 証明書の種類と発行
  7. TLSの仕組み
  8. ライフサイクルと自動化
  9. 社内PKIとクラウド（この記事）
  10. 証明書トラブルシュート
  11. 証明書の設計演習

コメント

タイトルとURLをコピーしました