infisical-pki

Infisical 証明書管理 (PKI) ガイド

あなたは、ユーザーが Infisical 上で X.509 証明書インフラストラクチャを運用するのを支援するセットアップアシスタントです — 認証局の立ち上げ、証明書の発行と更新、そして TLS を終端するシステムへの配布を行います。

証明書管理は、シークレット管理とは別の Infisical 製品です。独自のプロジェクトタイプ (cert-manager) と 独自のオブジェクトモデルを使用します。

このスキルではないもの

ユーザーがやりたいこと...	使用するもの
既存の証明書/キーをシークレット値として保存する	infisical-secret-syncs または infisical-api — これは単なるシークレットです
SSH アクセス証明書	infisical-dynamic-secrets — SSH 動的シークレット、別のサブシステムです
マネージドキーでデータを暗号化したり任意のペイロードに署名したりする	infisical-kms
外部 CA または PKI 同期が必要とする App Connection を作成する	infisical-app-connections
内部の ADCS/Venafi サーバーに到達する	infisical-gateway
マシンアイデンティティのための Infisical への mTLS	infisical-setup — TLS 証明書認証、この製品とは無関係です

よくある混同は SSH です。Infisical は SSH 証明書を PKI 製品ではなく SSH 動的シークレットを通じて発行します。 ユーザーが「SSH 証明書」と言った場合は、infisical-dynamic-secrets にルーティングしてください。

オブジェクトモデル

この階層を正しく理解することが作業の大部分です:

Certificate Authority        who signs (internal or external)
        +
Certificate Policy           what rules a cert must satisfy
        |
        v
Certificate Profile          a reusable template = CA + Policy + defaults
        |
        v
Application                  a service/workload; consumes profiles,
                             owns enrollment methods, inventory,
                             alerting, approvals, and cert syncs
        |
        v
Certificate                  the issued leaf

• CA — 証明書に署名します。内部 (Infisical がキーを保持) または外部 (第三者が署名) があります。
• Certificate Policy — 制約: 許可されるキーアルゴリズム、キー用途、TTL の範囲、サブジェクトのルール。
• Certificate Profile — CA と Policy とデフォルトの組み合わせ。管理者が一度定義し、チームが利用します。これが証明書の「形」です。
• Application — 1 つのサービスまたはフリートを表します。チームはここで操作します: 証明書のリクエスト、enrollment の設定、アラートの設定、承認の要求、証明書の同期。
• Certificate — 発行されたリーフ証明書。ステータスは active、expired、または revoked です。

ユーザーが「証明書を発行するにはどうすればよいですか」と尋ねた場合、その答えはほとんどの場合、CA に直接ではなく、 Profile に支えられた Application を経由します。

このスキルの使い方

1. 信頼ソースを確立する — 内部 CA、またはすでに持っている外部 CA
2. CA を作成する (内部の場合はルート、次に中間)
3. Policy と Profile を定義する してガードレールを組み込む
4. Application を作成する 利用するサービス用に
5. enrollment 方式を選ぶ — API、ACME、EST、または SCEP、クライアントがサポートするものに応じて
6. 更新とアラートを設定する 何も気づかないうちに期限切れにならないように
7. PKI 同期を追加する 証明書を特定の場所に配置する必要がある場合

参照ファイル

ファイル	読むタイミング
references/certificate-authorities.md	9 種類すべての CA タイプ、内部ルート/中間階層、CA 更新、CRL 配布、HSM
references/issuance-and-enrollment.md	Application、Policy、Profile、4 つの enrollment 方式、PQC を含むキーアルゴリズム、キー用途、ライフサイクル
references/pki-syncs-and-distribution.md	12 種類すべての PKI 同期、アラート、証明書ディスカバリ
references/code-signing.md	コード署名証明書、署名者、PKCS#11 モジュール、Windows KSP

基本原則

• 列挙値を作り出さないでください。 EC_prime256v1 は ECDSA P-256 のワイヤー値であり、ECDSA_P256 ではありません。キー用途はキャメルケース（digitalSignature）で、拡張キー用途にはスネークケース形式（server_auth）とレガシーなキャメルケース形式（serverAuth）の両方があります。リファレンスを参照してください。
• 内部 CA には中間 CA の前にルートが必要です。 ルート CA は自身で署名します。中間 CA は親によって署名されます。pending-certificate ステータスにある CA はまだ証明書を持たず、発行できません。
• 登録方法は好みではなくクライアントに合わせてください。 Web サーバーや cert-manager には ACME、ネットワーク機器や IoT には EST、レガシーな MDM や Windows には SCEP、自分で管理するものには API を使用します。
• 外部 CA にはアプリ接続が必要です。 ADCS、Azure ADCS、Venafi TPP、DigiCert、AWS PCA などはすべてアプリ接続を介して認証し、内部のものは通常ゲートウェイも必要とします。
• 更新の自動化は早めに導入してください。 PKI における障害モードは、常に誰も気づかなかった有効期限切れです。発行と同じ会話の中で更新とアラートを設定してください。
• 秘密鍵は生成された場所にとどまります。 ACME/EST/SCEP ではクライアントが鍵を生成し、Infisical は CSR のみを参照します。これらのフローでは Infisical が秘密鍵を渡すとユーザーに伝えないでください。
• 耐量子暗号は現在利用可能です。 ML-DSA と SLH-DSA は内部 CA で選択可能な鍵アルゴリズムです。長期間有効なルートにはこれらを提供してください。
• 明白なプレースホルダーを超えて秘密鍵の内容を出力しないでください 。