SCEP（Simple Certificate Enrollment Protocol）
SCEP（Simple Certificate Enrollment Protocol）は、X.509 証明書の申請管理に広く採用されているプロトコルです。元々は Cisco 社によって開発され、のちに RFC 8894 で文書化されました。公開鍵基盤（PKI）環境における証明書のリクエストと更新のために、合理化・標準化されたアプローチを提供します。
SCEP は、認証と暗号化の機能を必要とする IoT デバイスに電子証明書をプロビジョニングする実用的なソリューションを提供します。証明書の申請を自動化することによって、SCEP は手作業を減らし、大規模なデプロイメントを効果的にサポートします。
SCEP の主な特徴
クライアント/サーバーアーキテクチャ: SCEP は、IoT デバイス（クライアント）が SCEP サーバーと通信するクライアント/サーバーモデルに従います。サーバーは通常、登録局（RA）または認証局（CA）として機能します。
HTTP/HTTPS 上のセキュアトランスポート: メッセージは HTTP または HTTPS で交換されるため、既存のネットワークインフラとの互換性が保たれています。
PKCS#10 ベースの証明書リクエスト: クライアントは鍵ペアを生成し、PKCS#10 形式で証明書署名要求（CSR）を提出することで、業界標準の遵守を保証します。
認証に必要な共有シークレット: 不正な証明書リクエストを防ぐために、SCEP は、申請要求に含める必要のある共有シークレット（チャレンジパスワード）と、クライアントの ID を検証する方法になる証明書ベースの認証を利用しています。
証明書の自動申請: デバイスは自動的に証明書を要求してインストールできるため、大規模な IoT デプロイメントにおける管理者のオーバーヘッドを削減できます。
RSA 鍵サポートのみ: SCEP は RSA 鍵ペアのみをサポートし、他の鍵タイプはサポートしません。
SCEP のユースケース
SCEP は、IoT などの自動化された環境で使用されるのが一般的です。次のような例がありますが、これだけではありません。
IoT デバイス認証: ネットワークやクラウドプラットフォームに接続する IoT デバイスのセキュアな ID 管理を実現します。
企業ネットワークのセキュリティ: ルーター、スイッチ、ファイアウォールなどのエンドポイントへの証明書の配布を自動化します。
証明書の大規模なデプロイメント: 数千台、数百万台というデバイスが存在する環境でもセキュアな証明書発行が可能です。
SCEP オペレーション
SCEP は、証明書ライフサイクル管理のための重要な操作を定義します。
申請要求（PKCS#10 の提出）:
クライアントは鍵ペアと PKCS#10 CSR を生成します。
CSR はクライアントの秘密鍵によって署名され、認証に必要なチャレンジパスワードとともに SCEP サーバーに提出されます。
SCEP サーバーはリクエストを検証し、処理のために CA に転送します。
CA が証明書を発行すると、その証明書は保管されて、検索できるようになります。
証明書の更新:
証明書の有効期限が近づくと、クライアントは既存の証明書によって署名された新しい PKCS#10 CSR を提出します。
SCEP サーバーは更新要求を検証し、新しいチャレンジパスワードを要求せずに新しい証明書を発行します。
SCEP クライアント/サーバー通信プロセス
SCEP クライアントとサーバーの間の通信は、構造化された通信プロセスに従います。
サーバー鍵のプロビジョニング:
SCEP サーバーが、発行 CA の公開鍵をクライアントに提供します。
証明書の申請要求:
クライアントが RSA 鍵ペアを生成し、PKCS#10 CSR を作成します。
CSR は秘密鍵を使って署名され、発行 CA の公開鍵を使って暗号化されます。
暗号化された CSR が、チャレンジパスワード（必要な場合）とともに SCEP サーバーに送信されます。
リクエストの検証と認証:
SCEP サーバーがクライアントの認証クレデンシャルを検証します。
暗号化された CSR が、復号化と処理のために CA に転送されます。
証明書の発行と保管:
CA が要求を処理し、証明書を発行します。
署名された証明書が SCEP サーバーに返されます。
SCEP サーバーが証明書を保存し、検索できるようにします。
ポーリングと証明書の検索:
クライアントが、発行された証明書について定期的に SCEP サーバーに問い合わせます。
利用可能になると、クライアントは証明書をダウンロードしてインストールします。
課題と考慮事項
セキュリティへの懸念: SCEP は認証を共有シークレットに依存しているため、相互 TLS のような最新の認証メカニズムと比べると、安全とは言えません。
エクステンションが限定的: CMPv2 や EST などのプロトコルとは異なり、SCEP ではカスタム証明書の属性やエクステンションのサポートが制限されています。
ポーリングメカニズム: クライアントは発行された証明書を定期的に確認する必要があるため、大規模なデプロイメントでは非効率になる可能性があります。
PKI との統合: 証明書の発行とライフサイクル管理を円滑に進めるには、CA との適切な構成条件が必要です。
RSA 鍵サポートのみ: SCEP は RSA 鍵ペアのみをサポートし、ECC など他の鍵タイプはサポートしません。
所有証明のメカニズム: SCEP は相互 TLS（mTLS）を使用しないため、以下の方法で所有証明（PoP）を検証します。
クライアントは、秘密鍵を用いて PKCS#10 CSR に署名し、秘密鍵の所有権を証明します。
クライアントを認証するために、リクエストには共有シークレット（チャレンジパスワード）が含まれます。
更新するとき、クライアントは既存の証明書によって署名された CSR を提出できますが、これは必ずしも新しい秘密鍵の所有を証明するものではないため、鍵の再利用を許してしまう可能性があります。
まとめ
SCEP は、X.509 証明書の登録と管理のための、自動化されたシンプルな方法を提供するため、IoT デバイスなどの大規模なデプロイメントに実用的な選択肢です。セキュリティとエクステンションの面で制限がいくつかあるものの、SCEP は、使いやすさと自動化が優先される制約のある環境で、電子証明書のプロビジョニングに広く使用されているプロトコルです。