Views: 2
OpenPeppolプロバイダーは「47日証明書時代」とどう向き合うか
2025-11-19
前提整理：2つの「PKIの世界」
本稿で扱うPKIは、大きく次の2つに分かれます。
-
世界A：OpenPeppol専用PKI
-
世界B：公開Web PKI（ブラウザ信頼のTLS証明書）
-
https://smp.example.orgやAP管理ポータルのTLS終端などで使う、DigiCertやLet’s Encrypt発行の公開サーバ証明書。
-
ここで重要なのは、
47日制限の対象は「世界B」の公開Web TLS証明書であり、
「世界A」のOpenPeppol専用PKIのAP/SMP証明書ではない
という点です。
両方にDigiCertが関わっているため混同しがちなので、以降もこの区別を軸に説明します。
47日ルールの正体：公開Web TLSのみが対象
CA/B Forum Baseline Requirements の改訂や DigiCert の解説では、47日制限の対象を一貫して public TLS certificate としています。[3][4][5]
ここでいう public とは、
-
一般ブラウザやOSにプリインストールされた公開ルートCAに鎖がつながり
-
公開Webサイト向けに利用されるサーバ証明書（www.example.com など）
を指します。
一方で、OpenPeppolのように
-
独自ポリシーを持つプライベートPKI
-
そのPKI専用のルート／中間CA
-
ネットワーク参加者だけが信頼する会員証明書
は、CA/B Forum の public TLS 有効期間制限の対象外です。
OpenPeppol PKI 2025：専用PKIチェーンのG3移行（世界A）
-
旧：DigiCert Managed PKI v8（MPKI8）上のG2チェーン
-
新：DigiCert One Trust Lifecycle（DOTL）上のG3チェーン
へ、OpenPeppol専用PKIのインフラを載せ替えるプロジェクトです。
ポイントは次のとおりです。
-
ルート／中間CAの運用基盤を DigiCert が提供しているが、
-
AP/SMP証明書はあくまで「Peppol専用の会員証明書」であり、public TLS とは別物。
-
-
有効期間はOpenPeppolのポリシーで決まり、47日制限の適用対象ではない。
-
AP/SMPプロバイダーは、旧G2と新G3の二重対応テストと、期限までの切替完了が求められる。
SMP HTTPS化・NAPTR移行：公開Web PKI側の話（世界B）
一方、「世界B」で起きているのが、
です。
SMPソリューションのHTTPS運用ガイド[8] で整理されているように、ここでは次の証明書が登場します。
-
https://smp.example.org/…;の SMP HTTPSサーバ証明書（公開Web PKI） -
AP管理ポータルやダッシュボードなど、ブラウザアクセス用のTLS証明書
これらは典型的な public TLS であり、将来的には 47日サイクルでの更新を前提に運用設計する必要があります。
2つの世界が交差するポイント
OpenPeppolプロバイダーにとって、世界A／世界Bが交差するのは主に次の場面です。
-
APは、SML→SMP解決で取得した HTTPSのSMPエンドポイントに接続する
-
その際、
-
SMPメタデータの署名検証は「世界A」の Peppol PKI（AP/SMP証明書）
-
HTTPS接続の証明書検証は「世界B」の公開Web PKI
-
という二重の検証が行われます。[6]
このため、
-
AP/SMPプロバイダーは 2系統の証明書運用（Peppol PKI と 公開Web PKI）を明確に分離しつつ
-
テスト計画や監視設計では両方を同時に考慮する
必要があります。
Testbed・Directoryの制約と「二段階アプローチ」
Peppol PKI 2025 の説明スライドでは、Testbed／Directoryについて次の注意書きがあります（要旨）。[1]
-
Peppol Testbed
-
PKI移行テストと CNAME→NAPTR 移行テストを混在させないこと。
-
Testbed は現時点では SMP が HTTP のみで到達可能であることを前提としている。
-
-
Peppol Directory
-
テスト用 Peppol Directory はまだ G3 証明書を扱えない（対応作業中）。
-
この制約を踏まえると、実務的には次の 二段階アプローチ が安全です。
-
第1段階：OpenPeppol PKI（世界A）のG3移行を完了させる
-
AP/SMP証明書チェーンをG3に切り替え、Testbedや相互接続テストで検証。
-
このフェーズでは SMP は従来どおり HTTP ベースでもよく、CNAME→NAPTR 移行はまだ行わない。
-
-
第2段階：SMPのHTTPS化と CNAME→NAPTR への切替（世界B）
-
DNS（NAPTR）、URL構成、ロードバランサ／WAFを含めてHTTPS化を実施。
-
この段階で初めて、公開Web PKI側の 47日サイクル（将来）を意識した運用設計が必要になる。
-
こうして、まずはG3移行（世界A）→その後にHTTPS＋NAPTR移行（世界B）という順序を守ることで、Testbed／Directoryの対応状況と衝突せずに移行作業を進められます。
すでにNAPTR/HTTPS移行に着手している場合
「もう CNAME→NAPTR や SMP の HTTPS 化を始めてしまった」事業者でも、
本番構成をロールバックする必要はありません。
やるべきことは次の2点です。
-
PKI G3 移行テスト用に、Testbed から到達可能な HTTP のみの SMP エンドポイント を別途用意する。
-
（テスト専用のSMPインスタンスでも可）
-
-
NAPTR/HTTPS 側の構成は当面「現状維持」とし、大規模な構成変更は PKI G3 移行が安定するまで一時凍結する。
これにより、
-
Testbed：HTTP ベースの SMP に対して G3移行テストに専念
-
本番ネットワーク：すでに進めた NAPTR/HTTPS 構成を維持しつつ、監視と自動更新の整備を継続
という“二重トラック”が実現できます。
PKI移行（世界A）と NAPTR/HTTPS移行（世界B）のフェーズを論理的に分離することが重要です。
47日証明書時代に向けた運用設計（世界B）
1. TLS証明書の自動更新
-
ACME（Let’s Encrypt 等）か、商用CA API による自動更新を前提にする。
-
証明書取得～デプロイまでのパイプラインをコード化（IaC, GitOps 等）し、人手作業を排除。
2. ドメイン・インフラ設計
-
smp.example.org・ap.example.orgなどのサブドメイン設計。-
ワイルドカード証明書でまとめるか、サービスごとに分離するかを検討。
-
-
ロードバランサ／リバースプロキシ／WAF での TLS 終端位置を明確化。
3. 監視とアラート
-
証明書期限（残り日数）監視＋閾値アラート。
-
中間CA・ルートCAローテーション時の影響検知。
-
NAPTR移行期間中の HTTP→HTTPS リダイレクトの状態監視。[9]
4. クライアント（AP側）実装の注意
-
SMP HTTPS 証明書が頻繁に変わる前提で、
-
証明書ピンニングへの過度な依存を避ける
-
OS/ランタイム標準の信頼ストアに検証を委ねる
-
-
Peppol Transport Security Policy に沿ったホスト名検証・チェーン検証・OCSP/CRL確認。[6]
OpenPeppol PKI（世界A）側でのやるべきこと
まとめ：二つの世界を混同しない
最後に、主張を一文でまとめるとこうなります。
47日になるのは「公開Web TLS（世界B）」であって、
OpenPeppol専用PKI（世界A）のAP/SMP証明書ではない。
そのうえで、OpenPeppolプロバイダーがとるべき全体戦略は次の通りです。
-
まずは世界A：Peppol PKI 2025 のG3移行を安全に完了させる。
-
次に世界B：SMPのHTTPS化・NAPTR移行・将来の47日サイクルを見据えたTLS運用自動化に着手する。
この二段階アプローチを前提に、
-
Peppol PKI（会員証明書）と
-
公開Web PKI（HTTPSサーバ証明書）
の運用をきちんと分離しつつ、
監視・自動更新・テスト体制を整えることが、OpenPeppolプロバイダーにとっての「47日証明書時代」の現実的な対応方針になります。
コメントを残す