はじめに
DuoKey PKI におけるロールと権限、サポートされるアルゴリズムと証明書タイプ、証明書ライフサイクル。
概要
DuoKey PKI を使い始めるには、3 つのことを理解する必要があります。PKI 操作を制御するロールと権限、プラットフォームがサポートするアルゴリズムと証明書タイプ、そしてリクエストから発行までのライフサイクルです。このページではこれら 3 つすべてを扱います。その後は証明書の作成のウォークスルーで、最初の証明書を発行する手順を説明します。
前提条件
- アクティブな DuoKey Cockpit アカウント
- 関連する PKI 権限（または管理者ロール）
- CA 署名鍵用に設定された vault
- 発行元となる CA（新規作成するか、外部発行者を接続する）
ロールと権限
PKI 操作は、きめ細かなテナントスコープのロールベース権限によって認可されます。典型的な職務分掌では、次のように責任を分割します。
| 責任 | 典型的なロール |
|---|---|
| 証明書のリクエスト | 証明書リクエスター |
| リクエストの承認/却下 | 証明書承認者 |
| 認証局の管理 | CA 管理者 |
| 証明書の失効 | 証明書オペレーター |
| 失効データ（CRL）の管理 | CA 管理者 |
| 読み取り専用の可視性 | 監査担当者/閲覧者 |
操作によって必要な権限が異なる場合があります。権限エラーが発生した場合は、そのアクションに必要な PKI 権限を確認し、管理者に付与を依頼してください。
必要な情報
証明書を作成する前に、サブジェクトの詳細を用意してください。
| フィールド | 例 | 説明 |
|---|---|---|
| コモンネーム（CN） | www.example.com | 主要な識別子（TLS の場合は FQDN。ワイルドカードも可） |
| 組織（O） | Acme Corporation | 法人組織名 |
| 組織単位（OU） | IT | 部署（任意） |
| 国（C） | US, CH, GB | 2 文字の国コード |
| 都道府県（ST） | Vaud | 都道府県のフルネーム |
| 市区町村（L） | Lausanne | 市区町村名 |
| サブジェクト代替名 | api.example.com, 10.0.0.1 | 追加の DNS / IP / メール / URI 識別子 |
証明書タイプ
プラットフォームは、それぞれ適切な拡張鍵用途にマッピングされた、異なる目的のための証明書を発行します。
| タイプ | 目的 | 拡張鍵用途 |
|---|---|---|
| サーバー（TLS/SSL） | HTTPS および TLS 終端サービス | ServerAuth |
| クライアント（mTLS） | 相互 TLS クライアント認証 | ClientAuth |
| コード署名 | ソフトウェアおよび成果物の署名 | CodeSigning |
| メール（S/MIME） | メールの署名と暗号化 | EmailProtection |
| CA | ルートおよび中間の署名証明書 | 証明書署名 |
サブジェクト代替名はDNS、IP、メール、URIのいずれかです。すべての第一階層サブドメインを保護するには、*.example.com のようなワイルドカードのコモンネームを使用し、必要に応じて特定のホスト向けの追加 SAN エントリを組み合わせます。
鍵アルゴリズム
鍵アルゴリズムはリクエスト時に選択します。クラシックおよび耐量子のオプションが利用できます。
| アルゴリズム | カテゴリ | 使用する場面 |
|---|---|---|
RSA-2048 | クラシック（RSA） | 汎用、広い互換性 |
RSA-4096 | クラシック（RSA） | より高い保証レベルの RSA |
EC-P256 | クラシック（ECC） | 現代的な TLS 向けの効率的なデフォルト |
EC-P384 | クラシック（ECC） | より高い保証レベルの ECC |
ML-DSA-44 / 65 / 87 | 耐量子（FIPS 204） | 量子耐性のある署名 |
SLH-DSA-128F / 128S | 耐量子（FIPS 205） | ハッシュベースの量子耐性署名 |
ML-DSA-65 + ECDSA-P256 | ハイブリッド/複合 | 1 枚の証明書で量子耐性とクラシックな保証を両立 |
RSA-3072、EC-P521、8192 ビット RSA オプションはありません。認識されないアルゴリズム指定は EC-P256 にフォールバックするため、必ず上記リストから明示的に選択してください。耐量子鍵とハイブリッド鍵はvault に常駐します（発行 CA は vault で保護されている必要があります）。
証明書ライフサイクル
リクエストの作成
リクエスターがサブジェクトの詳細、タイプ、鍵アルゴリズム、SAN を添えて証明書リクエストを送信します。リクエストは保留中の状態になります。
承認または却下
承認者がリクエストをレビューし、承認または却下します。コメントは監査証跡として記録されます。
発行
発行時に CA が証明書に署名します。管理対象鍵の場合は鍵ペアが生成されて vault に保持され、CSR で鍵が提供された場合は提出された公開鍵が証明されます。リクエストは発行済みに移行します。
運用
有効な証明書は、表示、（公開部分の）エクスポート、対象へのデプロイ、OCSP / CRL による監視が可能です。
更新または失効
有効期限前に更新する（リクエストまたは発行者経由で再発行する）か、RFC 5280 の理由コードとともに失効させます。失効は CA の CRL と OCSP 応答に反映されます。
手動のリクエストワークフローに加えて、デバイスやワークロードは ACME、EST、SCEP、CMP、Kubernetes cert-manager、または KMIP を介して自動的にエンロールできます。詳細は概要を参照してください。