セキュリティと VPN : Public Key Infrastructure(PKI)

Simple Certificate Enrollment Protocol の概要

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

このドキュメントでは、登録およびその他の Public Key Infrastructure(PKI)操作に使用するプロトコルである Simple Certificate Enrollment Protocol(SCEP)を説明示します。

担当者 Jay Young と Alexandre Honore、Cisco TAC エンジニア。

背景説明

SCEP はもともとはシスコで開発され、Internet Engineering Task Force(IETF)のドラフトで文書化されています。

その主な特徴は次のとおりです。

  • リクエスト/応答モデルは、HTTP(GET メソッド、 オプションで POST メソッドをサポート)に基づく
  • RSA ベースの暗号化のみサポート
  • 証明書リクエスト形式として使用 PKCS#10 を使用
  • 暗号キー/暗号化されたメッセージを伝えるために PKCS#7 を使用
  • 要求者による定期ポーリングを使った、サーバでの非同期の許可をサポート
  • 制限付の証明書失効リスト(CRL)取得サポートがある(拡張性のために推奨される方法は Cisco Discovery Protocol(CDP)クエリーを経由することです)
  • オンライン証明書失効はサポートしない(他の手段によってオフラインにする必要があります)
  • サーバと要求者の間だけで共有する必要がある、証明書署名要求(CSR)内のチャレンジ パスワード フィールドの使用が必要

SCEP の登録と使用方法は一般に次のワークフローに従ってください。

  1. 認証局(CA)の証明書のコピーを取得し、検証します。
  2. CSR を生成し、CA に安全に送信します。
  3. 証明書が署名されたかを確認するために、SCEP サーバをポーリングします。
  4. 現在の証明書の有効期限前に新しい証明書を取得するために必要に応じて再登録します。
  5. 必要に応じて CRL を再度取得します。

CA 認証

SCEP は、CSR のメッセージ交換を安全に行うために CA 証明書を使用します。 その結果、CA 証明書のコピーを取得する必要があります。 GetCACert アクションが使用されます。

要求

要求は、HTTP GET リクエストとして送信されます。 リクエストのパケット キャプチャは次のようになります。

GET /cgi-bin/pkiclient.exe?operation=GetCACert 

シスコの対応

応答は単純な 2 進数エンコード CA 証明書(X.509)です。 クライアントは、CA 証明書がフィンガープリントとハッシュのテストを介して信頼されているか検証する必要があります。 これはアウトオブバンド方式(システム管理者への電話またはトラストポイント内でのフィンガープリントの事前設定)によって行う必要があります。

クライアントの登録

要求

登録の要求は、HTTP GET リクエストとして送信されます。 リクエストのパケット キャプチャは次のようになります。

/cgi-bin/pkiclient.exe?operation=PKIOperation&message=
MIIHCgYJKoZIhvcNAQcCoIIG%2BzCCBvcCAQExDjA......<snip>
  1. 「message=」の後のテキストは、GET リクエストの文字列から抽出された URL エンコードされた文字列です。
  2. 次に、テキストは ASCII のテキスト文字列に URL デコードされます。 この文字列は、Base64 エンコードされた SignedData PKCS#7 です。
  3. SignedData PKCS#7 は、次の証明書の 1 つを使ってクライアントによって署名されます。 これは、クライアントがこれを送信し、転送中に変更されていないことを証明するために使用されます。
    • 自己署名証明書(最初の登録に使用)
    • 製造元でインストールされる証明書(MIC)
    • すぐに期限切れになる現在の証明書(再登録)
  4. SignedData PKCS#7 の「署名されたデータ」の部分は EnvelopedData PKCS#7 です。
  5. EnvelopedData PKCS#7 は「暗号化データ」および「復号化キー」を含むコンテナです。 復号化キーは受信者の公開キーで暗号化されます。 このような特別な場合、結果的に 受信者は CA です。 実質、CA だけが「暗号化データ」を復号化できます。
  6. Enveloped PKCS#7 の「暗号化データ」部分は、CSR(PKCS#10)です。

シスコの対応

SCEP の登録の要求に対する応答は次の 3 種類の 1 つです。

  • REJECT:要求は、次のようないくつかの理由で管理者によって拒否されます。
    • 無効なキーのサイズ
    • 無効なチャレンジ パスワード
    • CA は要求を検証できませんでした
    • 要求で、CA が承認していない属性を要求した
    • 要求が、CA が信頼しないアイデンティティによって署名された
  • Pending:CA 管理者はまだ要求を確認していません。
  • Success:要求が受け入れられ、署名付き証明書が含まれています。 署名付き証明書は、「Degenerate Certificates-Only(劣化証明書専用)PKCS#7」と呼ばれる PKCS#7 の特殊なタイプで、1 つ以上の X.509 または CRL を保持できますが署名付きまたは暗号化データのペイロードを含まない特殊なコンテナです。

クライアントの再登録

証明書の期限前に、クライアントは新しい証明書を取得する必要があります。 更新とロールオーバーにはわずかな動作の違いがあります。 クライアントの ID 証明書が期限切れに近づき、有効期限が CA 証明書の有効期限と同じではない(よりも前)の場合に、更新が発生します。 ロールオーバーは、ID 証明書が期限切れに近づき、有効期限が CA 証明書の有効期限と同じ場合に発生します。

Renewal

ID 証明書の有効期限が近づくと、SCEP のクライアントは新しい証明書を取得する可能性があります。 クライアントは CSR を生成して、登録プロセスを実行します(前述のとおり)。 現在の証明書は SignedData PKCS#7 に署名するために使用され、これが CA にアイデンティティを提供します。新しい証明書を受信すると、クライアントはすぐに現在の証明書を削除し、検証がすぐに始まる新しい証明書と置き換えます。

ロールオーバー

ロールオーバーは特別なケースで、CA 証明書が有効期限を過ぎて新しい CA 証明書が生成される場合です。 CA は、現在の CA 証明書が有効期限になると有効になる新しい CA 証明書を生成します。 CA は、クライアントに「シャドウ ID」の証明書を生成するのに必要なため、通常この「シャドウ CA」の証明書をときどきロールオーバーの前に生成します。

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

PKCS#7 は、データが署名し暗号化されるようにできる定義済みデータ形式です。 このデータ形式には、暗号化操作の実行に必要な元のデータおよび関連するメタデータが含まれます。

署名されたエンベロープ(SignedData)

署名されたエンベロープは、データを伝送しカプセル化されたデータがデジタル署名によって送信中に変化していないことを確認する形式です。 内容は次のとおりです。

SignedData &colon;:= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
  • バージョン番号:SCEP で使用、バージョン 1 が使用されます。
  • 使用されるダイジェスト アルゴリズムのリスト:SCEP で使用。署名者が 1 人だけとハッシュ アルゴリズムが 1 つだけあります。
  • 署名される実際のデータ:SCEP で使用、これは PKCS#7 エンベロープ データ形式(暗号化されたエンベロープ)です。
  • 署名者証明書のリスト:SCEP で使用、最初の登録の自己署名証明書、または再登録している場合は現在の証明書です。
  • 署名者と各署名者によって生成されたフィンガープリントのリスト:SCEP で使用、署名者は 1 人だけです。

カプセル化されたデータは、暗号化または難読化されません。 この形式は、メッセージが変更されることに対する保護を提供します。

エンベロープ データ(EnvelopedData)

エンベロープ データ形式は暗号化されたデータを転送し、指定された受信者によってだけ復号化できます。 内容は次のとおりです。

EnvelopedData &colon;:= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
  • バージョン番号:SCEP で使用、バージョン 0 が使用されます。
  • 各受信者と関連する暗号化されたデータ暗号化キーのリスト:SCEP で使用、受信者(対要求: CA サーバ、 対応答: クライアント)は 1 人だけです。
  • 暗号化データ:これは、ランダムに生成されたキーで暗号化されます(受信者の公開キーを使用して暗号化されます)。

PKCS#10

PKCS#10 は、CSR のフォーマットを説明しています。 CSR は、クライアント要求によっては、証明書に含まれる次の情報を含んでいます。

  • Subject Name
  • 公開キーのコピー
  • チャレンジ パスワード(任意選択)
  • 要求された認証拡張など
    • キー使用状況(KU)
    • 拡張キー使用状況(EKU)
    • 情報カテゴリ代替名(SAN)
    • ユニバーサル プリンシパル名(UPN)
  • 要求フィンガープリント

CSR の例を次に示します。

Certificate Request:
Data&colon;
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

関連情報

付録

SCEP リクエスト

リクエスト メッセージの形式

リクエストは次の形式の HTTP GET を送信します。

GET CGI-path/pkiclient.exe?operation=operation&message=message HTTP/version

各記号の意味は次のとおりです。

  • CGI-path はサーバによって異なり、SCEP リクエストを処理する Common Gateway Interface(CGI)プログラムを指します。
    • Cisco IOS® CA は空のパスの文字列を使用します。
    • Microsoft CA は、MSCEP/ネットワーク デバイス登録サービス(NDES)IIS サービスを指す /certsrv/mscep/mscep.dll を使用します。
  • Operation は実行されるアクションを指定します。
  • Message は、このアクション用の追加のデータを含みます(および、実際のデータが要求されていない場合は空にできます)。

GET メソッドを使用すると、message part はプレーン テキストまたは Distinguished Encoding Rule(DER)(Base64 に変換される符号化された PKCS#7)のどちらかです。 POST メソッドがサポートされている場合、GET で Base64 エンコードで送信されたコンテンツは、代わりに POST を使用してバイナリ形式で送信されることがあります。

概略図

operations で可能な値およびそれに関連する message の値を次に示します。

  • operation = PKIOperation:
    • message は、PKCS#7 に基づき、DER および Base64 で符号化された SCEP の pkiMessage 構造です。
    • pkiMessage の構造には次のタイプがあります。
      • PKCSReq: PKCS#10 CSR
      • GetCertInitial: CSR 許可状態のポーリング
      • GetCert または GetCRL: 証明書または CRL の取得
  • operation = GetCACertGetNextCACert、または(任意選択)GetCACaps
    • message は省略することも、CA を識別する名前に設定することもできます。

SCEP 応答

応答メッセージ フォーマット

SCEP 応答は、元の要求と返されるデータのタイプによって異なる Content-Type を持つ標準 HTTP の内容として返信されます。 DER の内容は 2 進数として返されます(リクエストに対応する Base64 ではありません)。 PKCS#7 の内容は、暗号化/署名付きのエンベロープ データを含む場合と含まない場合があります。 含まない場合(証明書を 1 式だけ含む)は、劣化 PKCS#7 呼ばれます。

コンテンツ タイプ

Content-Type に指定可能な値を次に示します。

application/x-pki-message:

  • PKIOperation 動作への応答で、次のタイプの pkiMessage を使います。 PKCSReq、GetCertInitial、GetCert、または GetCRL
  • 応答の本文は、次のタイプの pkiMessage です。 CertRep

application/x-x509-ca-cert:

  • GetCACert 動作への応答
  • 応答の本文は DER-encoded binary X.509 CA 証明書

application/x-x509-ca-ra-cert:

  • GetCACert 動作への応答
  • 応答の本文は、CA 証明書および RA の証明書を含む DER-encoded の劣化 PKCS#7 です。

application/x-x509-next-ca-cert:

  • GetNextCACert 動作への応答
  • 応答の本文は、次の pkiMessage のタイプの変形です。 CertRep

pkiMessage の構造

SCEP OID

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

SCEP pkiMessage

  • PKCS#7 SignedData
  • PKCS#7 EnvelopedData(pkcsPKIEnvelope と呼ばれる、 任意の選択、メッセージ受信者への暗号化)
    • messageData (CSR, cert, CRL, ...)
  • authenticatedAttributes を使った SignerInfo
    • transactionIDmessageTypesenderNonce
    • pkiStatusrecipientNonce(応答のみ)
    • failInfo(応答 + 失敗時のみ)

SCEP messageType

  • request:
    • PKCSReq(19): PKCS#10 CSR
    • GetCertInitial(20): 証明書登録ポーリング
    • GetCert(21): 証明書取得
    • GetCRL(22): CRL 取得
  • response:
    • CertRep(3): 証明書または CRL リクエストに対する応答

SCEP pkiStatus

  • SUCCESS(0): 許可されたリクエスト(pkcsPKIEnvelope の応答)
  • FAILURE(2): 拒否されたリクエスト(failInfo 属性に詳細情報)
  • PENDING(3): リクエストは手動認可待ち

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 116167