Enterprise エディション

署名証明書の Certificate Transparency ポリシー

概要

NextPDF Enterprise は、署名ワークフローが署名前に署名証明書の Certificate Transparency (CT) の状態を考慮できるようにします。CT は、誤発行を検出可能にするために証明書が記録される公開ログのエコシステムです。CT にログされた証明書は、1 つ以上の Signed Certificate Timestamp (SCT) を保持します。NextPDF Enterprise は、証明書の CT の状態を結果値として表現し — SCT 拡張が存在するか、いくつの SCT が存在し有効か、そしてどのログがそれらを発行したか — 最小 SCT しきい値チェックを提供します。このページは挙動レベルの内容です。結果が何を保持するか、しきい値チェックがどう機能するか、そして NextPDF が何を決定し何を決定しないかを記載します。

NextPDF Enterprise は CT 結果を表現してしきい値チェックを行うものであり、CT ログ、ログ監査者、またはモニターではありません。その境界はセキュリティとコンプライアンスに記載しています。

前提条件はフロントマターに記載されており、前提条件で繰り返します。

提供状況とライセンス

この機能は NextPDF Enterprise (nextpdf/enterprise) に同梱され、Enterprise ティアのライセンスエンベロープで有効化されます。その資格を持たないデプロイでは、この機能のクラスはロードされません。エディションを比較してライセンスを取得。

この機能が行うこと

CT にログされた証明書は SCT を保持します。SCT は、RFC 6962 §3.1 に従い、バージョン、ログ識別子、タイムスタンプ、および証明書エントリに対するログの署名を保持します。ログは、証明書を追記専用ログに組み込むという約束として SCT を返し、依拠者は有効な SCT を欠く証明書を拒否します — RFC 6962 §3。Certificate Transparency バージョン 2.0 は同じモデルを維持します。ログは送信時に SCT を返し、送信者はそれに依拠する前に検証します — RFC 9162 §3。

NextPDF Enterprise は、証明書の CT の状態を次を保持する結果値として表現します。

証明書が SCT 拡張を含むかどうか。
見つかった SCT の総数。
署名が有効な SCT の数。
SCT を発行したログのログ識別子 — SHA-256 ハッシュ。

結果は、最小 SCT しきい値チェックを公開します。有効な SCT の数が必須の最小値以上であるかどうかを報告します。最小値は、お客様のポリシーに合わせて設定します。一般的なポリシーでは、有効期間の短い証明書には異なるログからの少なくとも 2 つの SCT を、有効期間の長いものにはより多くを期待しますが、しきい値はお客様が選択するものです。

しきい値チェックは、署名ワークフローのゲートとして使用してください。署名前に CT ログ済みの証明書 (有効な SCT が十分な数あること) を要求し、そうでなければ拒否します。

この設計の理由

Certificate Transparency は狭い問いに答えます。すなわち、この証明書は公開ログに記録されているか、そしていくつの独立したログによってか、です。NextPDF Enterprise はその答えを判定 (verdict) ではなく素朴な結果値としてモデル化します。結果は SCT 拡張フラグ、SCT の数、および発行ログ識別子を報告し、そこで止まります。その状態が十分に良いかどうかは決定しません。信頼しきい値は依拠者のポリシーであり、証明書の有効期間やリスクによって異なるためです。したがって最小 SCT 数はお客様が設定するものであり、NextPDF はログ運用者、監査者、モニターの役割から距離を置きます。Certificate Transparency は健全な署名判断における複数のチェックの 1 つであり、このページはそれを署名者が構築される前の明示的なゲートにします。

設計の背景: 署名を正しく検証する。

前提条件

NextPDF Core と Enterprise パッケージをインストールし、有効な Enterprise ライセンスを保持します。
CT の状態を強制したい署名証明書を、お客様の環境がそこから抽出する SCT データとともに用意します。
お客様のポリシーが必要とする最小 SCT しきい値を決定します。

構成

最小 SCT しきい値 — 証明書がお客様のポリシーに合格するために保持しなければならない有効な SCT の数。しきい値チェックに渡してください。
ポリシーの配置 — ゲートが署名ワークフローのどこで実行されるかを決定します。署名者を構築する前にすることで、ログ不足の証明書が署名操作に決して到達しないようにします。

ステップバイステップ

署名証明書の CT 結果を取得します。SCT 拡張フラグ、SCT の総数と有効数、およびログ識別子を保持しています。
お客様のポリシーの最小 SCT しきい値を決定します。
しきい値チェックを実行します。合格は「CT ポリシー満足」、不合格は「この証明書での署名を拒否」として扱います。
署名者が構築される前に、結果に基づいて署名ワークフローをゲートします。

<?php

declare(strict_types=1);

require_once __DIR__ . '/../../vendor/autoload.php';

use NextPDF\Enterprise\Security\CertificateTransparency\CtValidationResult;
use Psr\Log\LoggerInterface;

final readonly class CtSigningPolicy
{
    /**
     * @param int<1, max> $minimumScts The minimum count of valid SCTs your policy requires.
     */
    public function __construct(
        private int $minimumScts,
        private LoggerInterface $logger,
    ) {}

    /**
     * Decide whether a certificate's CT posture satisfies the policy.
     *
     * The gate runs before the signer is constructed, so an under-logged
     * certificate never reaches a signing operation. A missing SCT extension
     * is treated as a policy failure, not an exception.
     *
     * @param CtValidationResult $result The CT posture of the signing certificate.
     *
     * @return bool True when the certificate meets the minimum-SCT threshold.
     */
    public function isAcceptable(CtValidationResult $result): bool
    {
        if (! $result->hasSctsExtension) {
            $this->logger->warning('Signing certificate carries no SCT extension; CT policy not met.');

            return false;
        }

        $acceptable = $result->meetsPolicy($this->minimumScts);

        if (! $acceptable) {
            $this->logger->warning('Signing certificate has too few valid SCTs for the CT policy.', [
                'validScts'   => $result->validScts,
                'minimumScts' => $this->minimumScts,
            ]);
        }

        return $acceptable;
    }
}

検証

SCT 拡張が存在し、有効な SCT 数がしきい値ちょうどの結果を構築し、しきい値チェックが合格することを確認します。
しきい値より 1 つ下の結果を構築し、チェックが不合格になることを確認します。
SCT 拡張が存在しない結果を構築し、数に関係なくゲートが拒否することを確認します。
ゲートが拒否したとき、お客様の署名ワークフローが署名者を構築しないことを確認します。

セキュリティとコンプライアンス

NextPDF は表現してしきい値チェックを行いますが、ログを運用しません。 NextPDF Enterprise は CT の状態と最小 SCT チェックを表面化します。CT ログ、監査者、またはモニターではなく、証明書をログに送信することもありません。
しきい値はお客様のポリシーです。 最小 SCT 値はお客様が設定するものです。NextPDF は数を課しません。SCT 拡張の欠如は明確なポリシー失敗です。
署名前にゲートします。 署名者を構築する前にチェックを実行し、ログ不足の証明書が署名操作に決して到達しないようにします。
SCT のセマンティクスは標準に従います。 SCT は、依拠者が存在し有効であることを期待するログの約束です (RFC 6962 §3。§3.1 構造。CT v2 RFC 9162 §3)。

このページは証明書の信頼に関わる内容です。すべての規範的なソースはパラフレーズであり、規範的なテキストは複製されていません。

障害処理

SCT 拡張なし。 SCT 拡張のない結果はポリシー失敗として扱い、署名を拒否します。
有効な SCT が少なすぎる。 しきい値を下回る有効な SCT 数はチェックに不合格となります。署名を拒否します。
ポリシーの配置。 署名者が構築される前にゲートを実行します。署名後に実行される遅いチェックは、生成されたドキュメントを保護しません。

公開の境界

このページは、外部から観測可能な挙動とサポートされる公開 API サーフェスのみを記載します。内部の名前空間パス、ヘルパークラス、メカニズムテーブル、ランブックのファイル名、およびチケットプレフィックスは対象外です。