この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、登録やその他の公開キー インフラストラクチャ(PKI)の操作で使用されるプロトコルである Simple Certificate Enrollment Protocol(SCEP)について説明します。
最初は Cisco が SCEP を開発し、Internet Engineering Task Force(IETF)のドラフトに文書化されています。
主な特徴は次のとおりです。
通常、SCEP の登録および使用は次のワーク フローに従っています。
CSR のメッセージ交換を保護するため、SCEP は CA 証明書を使用します。その結果、CA 証明書のコピーを取得する必要があります。GetCACert オペレーションが使用されます。
要求は HTTP GET 要求として送信されます。要求のパケット キャプチャは次のようになります。
GET /cgi-bin/pkiclient.exe?operation=GetCACert
応答は、バイナリエンコードされた CA 証明書(X.509)に似ています。 クライアントは、フィンガープリント/ハッシュの検査により CA 証明書が信頼できることを検証する必要があります。これはアウトオブバンド方式(システム管理者への電話またはトラストポイント内でのフィンガープリントの事前設定)で実行する必要があります。
登録要求はHTTP GET要求として送信されます。要求のパケットキャプチャは次のようになります。
/cgi-bin/pkiclient.exe?operation=PKIOperation&message=
MIIHCgYJKoZIhvcNAQcCoIIG%2BzCCBvcCAQExDjA......<snip>
SCEP 登録要求への応答は、次の 3 つのタイプのいずれかです。
証明書の期限が切れる前に、クライアントは新しい証明書を取得する必要があります。更新とロールオーバーの動作にはわずかな違いがあります。更新はクライアントの ID 証明書の期限が近づくと発生し、その有効期限は、CA 証明書の有効期限と同じではありません(それよりも前になります)。ロールオーバーは ID 証明書の期限が近づくと発生し、その有効期限は CA の証明書有効期限と同じです。
ID 証明書の有効期限が近づくにしたがい、SCEP クライアントは新しい証明書を取得することが必要になる場合があります。クライアントは CSR を生成し、登録プロセスを(以前に定義したとおりに)実行します。 現在の証明書は、SignedData PKCS#7に署名するために使用され、CAにIDが証明されます。新しい証明書が受信されると、クライアントは現在の証明書を即座に削除し、新しい証明書に置き換えます。この証明書の有効性は、すぐに開始されます。
ロールオーバーは、CA 証明書の期限が切れ、新しい CA 証明書が生成される特殊なケースです。CA が新しい CA 証明書を生成し、現在の CA 証明書の期限が切れた時点でその証明書が有効になります。通常、CA はこの「シャドー CA」証明書をロールオーバーのタイミングよりも前に生成します。これは、クライアントの「シャドー ID」証明書を生成するために必要であるからです。
SCEP クライアント の ID 証明書の期限が近づくと、SCEP クライアントは CA に「シャドー CA」証明書について問い合わせます。これは、次に示すように、GetNextCACert オペレーションで実行されます。
GET /cgi-bin/pkiclient.exe?operation=GetNextCACert
SCEPクライアントが「シャドウCA」証明書を取得すると、通常の登録手順の後で「シャドウID」証明書を要求します。CA は「シャドー CA」証明書を使用して「シャドー ID」証明書に署名します。通常の更新要求とは異なり、返された「シャドー ID」証明書は CA 証明書の有効期限が切れた時点で有効になります(ロールオーバー)。 その結果、クライアントは CA 証明書と ID 証明書の両方について、ロールオーバーの前と後の証明書のコピーを保管する必要があります。CA 証明書の期限が切れた(ロールオーバー)時点で、SCEP クライアントは現在の CA 証明書と ID 証明書を削除し、それらを「シャドー」コピーに置き換えます。
次の構造が SCEP の構成要素として使用されます。
注:PKCS#7 と PKCS#10 は SCEP 固有ではありません。
PKCS#7 は、データを署名または暗号化できるように定義されたデータ形式です。このデータ形式には、元のデータと暗号化操作の実行に必要な関連メタデータが含まれています。
署名済みエンベロープは、データを搬送し、カプセル化されたデータがデジタル署名を通じて送信中に変更されていないことを確認する形式です。内容は次のとおりです。
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
カプセル化されたデータは暗号化も難読化もされません。この形式は、変更されているメッセージに対する保護のみを提供します。
エンベロープ データ形式は暗号化されたデータを搬送し、指定された受信者のみが復号できます。 内容は次のとおりです。
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
PKCS#10 は CSR の形式を説明します。CSR には、クライアントが証明書内に含めるように要求した情報が含まれています。
次に、CSR の例を示します。
Certificate Request:
Data:
Version: 0 (0x0)
Subject: CN=scepclient
Subject Public Key Info:
Public Key Algorithm: rsaEncryption Public-Key: (1024 bit)
Modulus:
00:cd:46:5b:e2:13:f9:bf:14:11:25:6d:ff:2f:43:
64:75:89:77:f6:8a:98:46:97:13:ca:50:83:bb:10:
cf:73:a4:bc:c1:b0:4b:5c:8b:58:25:38:d1:19:00:
a2:35:73:ef:9e:30:72:27:02:b1:64:41:f8:f6:94:
7b:90:c4:04:28:a1:02:c2:20:a2:14:da:b6:42:6f:
e6:cb:bb:33:c4:a3:64:de:4b:3a:7d:4c:a0:d4:e1:
b8:d8:71:cc:c7:59:89:88:43:24:f1:a4:56:66:3f:
10:25:41:69:af:e0:e2:b8:c8:a4:22:89:55:e1:cb:
00:95:31:3f:af:51:3f:53:ad
Exponent: 65537 (0x10001)
Attributes:
challengePassword :
Requested Extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:webserver.example.com
Signature Algorithm: sha1WithRSAEncryption
8c:d6:4c:52:4e:c0:d0:28:ca:cf:dc:c1:67:93:aa:4a:93:d0:
d1:92:d9:66:d0:99:f5:ad:b4:79:a5:da:2d:6a:f0:39:63:8f:
e4:02:b9:bb:39:9d:a0:7a:6e:77:bf:d2:49:22:08:e2:dc:67:
ea:59:45:8f:77:45:60:62:67:64:1d:fe:c7:d6:a0:c3:06:85:
e8:f8:11:54:c5:94:9e:fd:42:69:be:e6:73:40:dc:11:a5:9a:
f5:18:a0:47:33:65:22:d3:45:9f:f0:fd:1d:f4:6f:38:75:c7:
a6:8b:3a:33:07:09:12:f3:f1:af:ba:b7:cf:a6:af:67:cf:47: 60:fc
要求は次の形式の HTTP GET を使用して送信されます。
GET CGI-path/pkiclient.exe?operation=operation&message=message HTTP/version
場所:
GETメソッドを使用すると、メッセージ部分は、プレーンテキストまたはDistinguished Encoding Rules (DER)でエンコードされたPKCS#7でBase64に変換されます。POSTメソッドがサポートされている場合、GETで送信される内容はバイナリ形式です。
operation の可能な値とそれらの関連 message の値は次のとおりです。
SCEP 応答は、元の要求と返されるデータのタイプに応じて Content-Type で標準的な HTTP コンテンツとして返されます。DER コンテンツは(要求と同じ Base64 ではなく)バイナリとして返されます。PKCS#7 コンテンツには、暗号化/署名済みエンベロープ データが含まれていることも、含まれていないこともあります。含まれていない(一連の証明書のみが含まれている)場合は、劣化 PKCS#7 と呼ばれます。
Content-Type の可能な値
application/x-pki-message:
application/x-x509-ca-cert:
application/x-x509-ca-ra-cert:
application/x-x509-next-ca-cert:
2.16.840.1.113733.1.9.2 scep-messageType
2.16.840.1.113733.1.9.3 scep-pkiStatus
2.16.840.1.113733.1.9.4 scep-failInfo
2.16.840.1.113733.1.9.5 scep-senderNonce
2.16.840.1.113733.1.9.6 scep-recipientNonce
2.16.840.1.113733.1.9.7 scep-transId
2.16.840.1.113733.1.9.8 scep-extensionReq