check_mpic.sh は、指定されたFQDN（完全修飾ドメイン名）に対して、証明書発行に必要となる CAAレコード と関連する CNAMEレコード の設定状況をDNSを遡りながら確認し、さらに複数のパブリックDNSからの名前解決結果を照合することで MPIC (Multi-Perspective Issuance Corroboration) の要件を満たしているかを自動的にチェックするシェルスクリプトです。
各種SSL/TLSサーバー証明書の発行に際して、CAAレコードの不備や意図しないCNAMEチェーン、GeoIP制限やスプリットホライズン等に起因するMPIC検証エラー（海外からの名前解決失敗など）のトラブルシューティング・事前確認に役立ちます。
-
基本のレコード確認 対象のFQDNについて、
CAAレコードとCNAMEレコードを引き、その内容を出力します。- CAAレコードが見つからない場合は「CAAレコードがありません」と出力されます。
- CNAMEレコードが見つからない場合は「CNAMEレコードがありません」と出力されます。
-
CNAMEの自動追跡（チェーン解決） 対象のFQDNにCNAMEレコードが設定されている場合、その**参照先（CNAME先のFQDN）**に対しても自動的にCAAとCNAMEの確認を行います。 この処理は、最終的にCNAMEの参照先がなくなる（Aレコード等の実体ドメインに落ち着く）まで繰り返されます。 (※ 無限ループを防ぐため、一度確認したFQDNに再度アクセスした場合はループを自動で検知し追跡を停止します)
-
名前解決の可否判定
digコマンドでNXDOMAIN（ドメインが存在しない）またはSERVFAIL（DNSサーバー側のエラー）が返ってきた場合、名前解決ができない旨を出力し、そのFQDNの確認を中断します。 この2つは発行方式への影響が異なるため、分けて説明を出力します。NXDOMAIN… ACMEは発行不可、CSRは上位ADN次第（後述「発行方式（CSR / ACME）による違い」を参照）SERVFAIL… CAAレコードの確認結果も不明になるため、どちらの方式でも発行不可
-
特定CA（認証局）の許可チェック（階層ごとの参考表示） 確認した各階層（対象FQDN・CNAME先・遡り先の親ドメイン）で取得したCAAレコードの内容に
secomtrust.netという文字列が含まれていない場合、「CAAレコードが存在しますが、 secomtrust.net が含まれません。」という警告を出力します。- ※ これは各階層単独の情報表示であり、そのCAAが実際に証明書発行へ影響するか（＝実効CAAかどうか）は後述の「実効CAAレコードの判定」およびMPIC判定結果を参照してください。
-
実効CAAレコードの判定（MPIC判定に使用） CAAレコードの仕様（RFC 8659）に沿い、対象FQDNから見て「CNAME先 → （見つからなければ）eTLD+1までの親ドメイン」の順に探索し、最初に見つかった空でないCAAレコードセットのみを実効CAAとして採用します。実効CAAが見つかった時点でそれより上位のドメインのCAAは参照しません。 実効CAAに
secomtrust.netが含まれない場合にのみ、MPIC判定結果を不合格とします（＝対象FQDN自身に許可CAAがあれば、無関係な親ドメインの制限的なCAAによって誤って不合格になることはありません）。 -
eTLD+1への遡り（Public Suffix List連携） 各種レコードの有無にかかわらず、サブドメイン（例:
sub.example.co.jp）が指定された場合、そのドメインの所属するゾーンの頂点・ベースドメイン（eTLD+1 相当、例:example.co.jp）に到達するまで、ドメインラベルを1つずつ削りながら親ドメイン側へと遡って確認を繰り返します。- ※ 遡りの終点（eTLD+1）を正確に判定するため、初回実行時に Mozilla の Public Suffix List (
public_suffix_list.dat) を公式から自動でダウンロードします。
- ※ 遡りの終点（eTLD+1）を正確に判定するため、初回実行時に Mozilla の Public Suffix List (
-
代替DNSサーバー（8.8.8.8 / 1.1.1.1）での確認とMPIC判定 ローカル（デフォルト）のDNSサーバーでの一連の確認（遡り処理含む）が完了した後、指定された最初の「ターゲットFQDN」に対してのみ、以下のパブリックDNSサーバーを用いた検証を再度単独で実行します。
- Google Public DNS (
8.8.8.8) - Cloudflare DNS (
1.1.1.1) これにより、DNSキャッシュの浸透状況や、GeoIP制限（海外からの名前解決失敗）、スプリットホライズン（内部/外部でのレコード不一致）などを検出し、MPICの要件を満たすかどうかを自動判定します。
- Google Public DNS (
-
発行方式（CSR / ACME）による違いの分類 検出した不備ごとに、それが CSRによる申請 と ACMEによる発行 のそれぞれでどう効いてくるかを
[CSR申請の場合]/[ACME発行の場合]（両者で挙動が同じ場合は[CSR申請/ACME発行に共通]）のラベル付きで出力します。 判定結果の末尾には 【発行方式別の見通し】 として方式ごとの可否（✅ /⚠️ / ❌）と、方式差をまとめた凡例が表示されます。
MPIC（Multi-Perspective Issuance Corroboration、BR 3.2.2.9）は BR 3.2.2.4 のすべての DCV 方式に適用されます。CAAレコードの参照も MPIC の対象です（CAAルックアップに対する BGP ハイジャックで発行制限を迂回されるのを防ぐため）。 したがってセコムが DNS/HTTP で DCV を行う限り、CSR経由の発行でも MPIC はかかっています。ACME だけの話に見えるのは、MPIC が走るタイミングが違うためです。
MPIC のリモート観測点の要件は段階的に引き上げられています。
| 時期 | 要件 |
|---|---|
| 2025-03-15 | 2リモート観測点（監視モード。結果に関わらず発行可） |
| 2025-09-15 | quorum 要件の遵守が必須に（不足で発行停止） |
| 2026-03-15 | 3リモート観測点 |
| 2026-06-15 | 4リモート観測点（現行。うち3点以上が主観測点と一致し、かつ2つ以上のRIR地域からの観測が必要） |
| 2026-12-15 | 5リモート観測点 |
BR の DCV は、申請された FQDN そのものではなく、そこから左側のラベルを削って導出した ADN（Authorization Domain Name）に対する管理権限を確認する設計です（Ballot SC-101v2 が明文化）。検証データの再利用も ADN 単位で機能します。
- CSR申請 …
example.ac.jpに対して一度 DCV を済ませてあれば、nonexistent.example.ac.jpのような NXDOMAIN の FQDN でも、CAAチェックさえ通れば発行され得ます。 「上位まで遡ってCAAが適切なら発行できた」という従来の観測は正確ですが、その理由はCAAではなく、ADNレベルで完了済みのDCVが再利用されていたことにあります。 - ACME発行 … RFC 8555 の dns-01 はチャレンジを identifier そのものの
_acme-challenge.<FQDN>に置くと定義されており、http-01 / tls-alpn-01 は当該FQDNの A/AAAA 解決が前提です。つまり ACMEでは実質的に ADN が申請FQDNに固定されます。さらに RFC 8020 の解釈下では FQDN が NXDOMAIN ならその配下も存在しないため_acme-challengeも引けません。 ACMEで発行が抑制されるのは MPIC のせいというより、この ADN 固定の帰結です。
| 役割 | 確認タイミング | 上位への遡り | |
|---|---|---|---|
| CAA（RFC 8659） | どのCAが発行してよいかの許可リスト | 発行の8時間以内（ACMEでは finalize 時） | 仕様どおりの正常動作。NXDOMAINは障害にならない |
| DCV（BR 3.2.2.4） | 申請者が本当にそのドメインを管理しているかの証明 | 方式による（下表） | ADN単位で実施・再利用される |
| CSRによる申請 | ACMEによる発行 | |
|---|---|---|
| 検証のタイミング | UPKI(NII)へ申請した後、CA側でまとめて実施 | order（証明書要求）ごとにその都度実施 |
| エラーの現れ方 | 「エラー338」としてUPKI側に記録され、申請が発行に至らない | エラー338は発生しない。ACMEクライアント側のエラーとして返る |
| 対象FQDNがNXDOMAIN | 上位ADNでDCV済み＋CAA適切なら発行され得る | 発行できない |
| 気付きやすさ | 申請が通らないため必ず気付く | 自動更新では失敗が表面化しにくく、気付かないまま証明書が期限切れになる恐れがある |
SC-081v3 により、証明書有効期間と DCV 再利用期間が段階的に短縮されます。
| 時期 | 証明書有効期間 | DCV再利用期間 |
|---|---|---|
| （従来） | 398日 | 398日 |
| 2026-03-15 | 200日 | 200日 |
| 2027-03-15 | 100日 | 100日 |
| 2029-03-15 | 47日 | 10日 |
CSRフローで「機関ドメインを一度確認して1年使い回す」運用は 2026-03-15 以降すでに成立していません。2029年に10日になった時点で、CSRフローは申請のたびに実質再検証が必要になります。
- SC-090（2026-01-14採択）… メール／電話ベースのDCV方式を、SC-085 の発効日（2026-03-15）以降 非推奨に。
- SC-085v2（2026-03-15）… DNSSEC 検証が必須に。
- SC-098（2026-06-16に BR v2.2.8 へ反映、発効予定 2027-03-15）… RFC 8657 の CAA パラメータ（
accounturi/validationmethods）の処理。 - SC-101v2（適用期限 2026-11-15）… 新しい ADN 導出アルゴリズム。CNAME追跡とラベル削除の順序が厳格化されるため、CDN配下や CNAME を多用する機関で挙動が変わる可能性があります。 （従来の解釈では、CNAME を1つ以上たどって得たFQDNをADNとして使えると読め、CNAME先の運用者が任意のサブドメインの証明書を発行させられる余地がありました）
- OS: Linux / macOS などのUNIX系OS
- 必須コマンド:
bash,dig(bind-utils/dnsutils),curl,awk,grep,sed - ネットワーク接続: DNSクエリ（ポート53）、および初回のみPSLダウンロードのためのインターネット接続（HTTPS）
ドメインは単純に「最後のドットから数個」だけで頂点を判断することができません（例: .com は1つ前が頂点だが、.co.jp や .ac.jp は2つ前が頂点になるため）。
本スクリプトは正確な判定を行うため、スクリプトと同じディレクトリに public_suffix_list.dat というリストファイルを要求します。存在しない場合は curl で自動的にダウンロードして使用します。
ターミナルを開き、スクリプトに対して実行権限を付与します。
chmod +x check_mpic.sh引数として、確認したい対象のFQDNを指定して実行します。
./check_mpic.sh <FQDN>./check_mpic.sh certs.nii.ac.jp実行すると、以下のような形式で情報が順に出力されます。実行過程でどのように判定を行っているかがログとして表示されます。
--> Public Suffix Listを元に算出された頂点ドメイン(eTLD+1): nii.ac.jp
==================================================
対象FQDNと上位ドメイン(デフォルトDNS)の確認
==================================================
※ ここで遡る上位ドメインは、CSR方式でDCVの対象となりうるADN(Authorization Domain Name)の候補でもあります。
=== [certs.nii.ac.jp] の確認 ===
CAAレコードがありません (certs.nii.ac.jp)
CNAMEレコードがありません (certs.nii.ac.jp)
--- 上位FQDN (nii.ac.jp) へ遡ります ---
=== [nii.ac.jp] の確認 ===
CAAレコードがありません (nii.ac.jp)
CNAMEレコードがありません (nii.ac.jp)
--> 頂点ドメイン(eTLD+1: nii.ac.jp) に到達しました。上位への遡りを終了します。
==================================================
指定DNSでの確認 (8.8.8.8)
==================================================
=== [certs.nii.ac.jp] をDNSサーバ 8.8.8.8 で確認 ===
CAAレコードがありません (certs.nii.ac.jp)
CNAMEレコードがありません (certs.nii.ac.jp)
==================================================
指定DNSでの確認 (1.1.1.1)
==================================================
=== [certs.nii.ac.jp] をDNSサーバ 1.1.1.1 で確認 ===
CAAレコードがありません (certs.nii.ac.jp)
CNAMEレコードがありません (certs.nii.ac.jp)
==================================================
【MPIC判定結果】 (Multi-Perspective Issuance Corroboration)
==================================================
判定結果: ✅ パスする可能性が高いです。
複数のDNS拠点からの応答（ステータス、CAA、CNAME）が一致しています。
--------------------------------------------------
【発行方式別の見通し】
CSR申請 : ✅ DNS/CAA面で発行を妨げる問題は見つかりませんでした。
ACME発行 : ✅ DNS/CAA面で発行を妨げる問題は見つかりませんでした。(dns-01では別途 _acme-challenge.certs.nii.ac.jp のTXT設置が必要です)
--------------------------------------------------
不備が検出された場合は、原因ごとに [CSR申請の場合] / [ACME発行の場合] の影響が併記され、末尾に方式別の見通しが表示されます。
以下は対象FQDNが NXDOMAIN で、ACMEでは発行できないが CSR では上位ADN次第というケースの例です。
==================================================
【MPIC判定結果】 (Multi-Perspective Issuance Corroboration)
==================================================
判定結果: ❌ パスしない（エラーになる）可能性が高いです。
以下の原因が考えられます：
・すべてのDNSサーバーでNXDOMAIN（名前解決失敗）となりました。
[ACME発行の場合] 発行できません。dns-01のチャレンジは _acme-challenge.nonexistent-test-zzz.nii.ac.jp に置く必要がありますが、
RFC 8020によりNXDOMAINのFQDN配下の名前も存在しないため参照できません。http-01/tls-alpn-01もA/AAAAが必要です。
[CSR申請の場合] 直ちに発行不可とは限りません。DCVは対象FQDNではなくADN(上位ドメイン)に対して行われるため、
上位ADNでDCV済みかつCAAが適切であれば、対象FQDNがNXDOMAINでも発行され得ます。
ただしDCVの再利用可能期間は2026-03-15以降200日に短縮されており(2027-03-15に100日、2029-03-15に10日)、
再検証のタイミングでは上位ADN側が解決できる必要があります。
--------------------------------------------------
【発行方式別の見通し】
CSR申請 : ⚠️ 上位ADNでDCV済み(200日以内)かつCAAが適切であれば発行され得ます。UPKI/CAへの確認を推奨します。
ACME発行 : ❌ 発行できません。
--------------------------------------------------
※【発行方式(CSR / ACME)による違い】
・MPICはACME固有の仕組みではなく、BR 3.2.2.4のすべてのDCV方式(CAAの参照を含む)に適用されます。
そのためCAAの不備・観測点間の不一致・SERVFAILは、CSR/ACMEどちらの方式でも発行を抑制します。
・両者で挙動が分かれるのは「対象FQDN自体が引けない(NXDOMAIN)」ケースです。
- CSR申請 : DCVは対象FQDNではなくADN(上位ドメイン)に対して行われ再利用されるため、
上位ADNでDCV済み＋CAAが適切であれば、NXDOMAINのFQDNでも発行され得ます。
- ACME発行: dns-01は _acme-challenge.<FQDN>、http-01/tls-alpn-01はA/AAAAを必要とし、
ADNが対象FQDNに固定されるため発行できません。
・エラーの現れ方も異なります。CSR申請では不備が「エラー338」としてUPKI側に記録されますが、
ACME発行ではエラー338は発生せず、order(証明書要求)ごとにACMEクライアント側のエラーとして返ります。
自動更新では失敗が表面化しにくいため、気付かないまま証明書が期限切れになる恐れがあります。
・DCVの再利用可能期間は2026-03-15以降200日(2027-03-15に100日、2029-03-15に10日)に短縮されており、
CSR方式で上位ADNのDCV結果を長期間使い回す運用は成立しなくなります。
エラーや警告が出た場合は、DNS側の設定（CAAレコードの追加修正やCNAMEの記述ミス）を見直してください。