TuringSign

CSR ベースのエンロールメントと非同期のドメイン検証を備えた、注文ベースの商用 CA 発行者です。

適用対象:

DuoKey Cockpit v2TuringSign トラストサービス非同期検証を伴う注文ベースの発行

概要

TuringSign は、Cockpit の PKI モジュールに発行者タイプとして登録されています。コネクタは TuringSign プラットフォームに対して証明書の注文を行い、証明書が準備できるまで注文をポーリングします — 事前検証済みの製品では即座に、それ以外の場合はプロバイダー側でドメイン制御検証が完了した後になります。

TuringSign コネクタのアーキテクチャ

DuoKey CockpitPKI 発行者コネクタ — TuringSign

API ID + API Key → ベアラートークン

TuringSign / CertifyID プラットフォーム注文の発行、製品/サブスクライバー/連絡先のカタログ

発行 CA検証が完了すると証明書に署名します

コネクタは API ID と API Key で認証し、TuringSign プラットフォームに対して注文の発行とポーリングを行います。

プロパティ	値
発行者タイプ	turing-sign
発行モデル	注文ベース: 注文を行い、発行された証明書をポーリングで取得します
CSR の要件	すべての注文で PKCS#10 CSR が必須です（リクエストで指定されない場合、Cockpit が自動的に生成します）
鍵の保管	既定では呼び出し元/CSR ベース — TuringSign 自体が秘密鍵を返すことはありません。リクエストで CSR が省略された場合、Cockpit が鍵ペアを生成し、内部 CA のマネージド鍵による発行と同様に、秘密鍵を一度だけ返します
既定の API エンドポイント	TuringSign のデモ環境。{api_base_url} が空欄のままの場合にのみ使用されます

本番用の API エンドポイントを設定する

空欄のままにすると、コネクタの API ベース URL は既定で TuringSign のデモ環境になります。本番環境へ導入する場合は、発行者を登録する際に {api_base_url} に TuringSign / リセラーの本番エンドポイントを明示的に設定してください。

設定

TuringSign の発行者ウィザードは、2 種類の情報を収集します。機密ではない設定項目と、暗号化される認証情報です。

設定フィールド

フィールド	目的
api_base_url	任意。TuringSign の API ベース URL。空欄にするとデモ環境が使用されます。
product_id	注文する SSL 製品の数値識別子。アカウントの製品カタログから参照されます。
signing_ca_type	署名 CA の選択: automatic（既定）、rsa、ecc のいずれか。
subscriber_id	注文の登録先となる、RA によってプロビジョニングされたサブスクライバー。
contact_id	選択したサブスクライバーの連絡先から選ぶ、注文の連絡先。
default_validity_days	リクエストで指定されない場合に適用される証明書の有効期間（既定は 365）。

製品、サブスクライバー、連絡先の参照

発行者ウィザードでは、API ID と API Key を入力すると、製品、サブスクライバー、連絡先のドロップダウンが TuringSign アカウントからライブで取得されます。そのため、これらの値は入力するのではなく選択します。

認証情報

フィールド	目的
app_id	アカウントに発行された API ID（TuringSign への認証に使用されます）。
secret	API ID と対になる API Key。

API ID と API Key は、操作のたびに短命なベアラートークンと交換されます。これらは保存時に暗号化され、プラットフォームから返されることはありません。

発行者の登録

1

API ID と API Key を入力する

TuringSign の API ID と API Key を指定します。ウィザードはこれらを使って認証し、製品、サブスクライバー、連絡先のドロップダウンを設定します。

2

製品、サブスクライバー、連絡先を選択する

注文の対象となる SSL 製品、注文を登録するサブスクライバー、そして注文の連絡先を選択します。

3

署名 CA タイプと既定の有効期間を設定する

CA の選択として automatic、rsa、ecc のいずれかを選び、既定の証明書有効期間を設定します。

4

接続をテストする

接続テストを実行し、API ID/Key で認証できること、および製品カタログに到達できることを確認します。

5

発行者を通じて発行する

発行者に対して証明書をリクエストします。Cockpit は注文ごとに CSR、DNS 名、有効期間を指定（または生成）します。

Cockpit が鍵ペアを生成する場合

CSR の送信は任意です。リクエストで CSR が省略された場合、Cockpit が代わりに鍵ペアと CSR を生成し（TuringSign の注文エンドポイントはすべての注文で CSR を必要とします）、発行された証明書とともに秘密鍵を一度だけ返します。後から取得することはできないため、発行時に取得して保管してください。独自の CSR を提供する場合、秘密鍵は手元に残り、TuringSign がそれを見ることはありません。

発行フロー

TuringSign は、このカタログの中で唯一、真に非同期な発行者コネクタです。注文を行っても必ずしもすぐに証明書が返るわけではないため、コネクタはポーリングを行ったうえで、結果を即座に返すか、保留中の注文として返すかを判断します。

注文の発行とポーリング

1. 認証するAPI ID + API Key を短命なベアラートークンと交換します

2. 注文を行う選択した製品に対して CSR、サブスクライバー、連絡先を送信します。TuringSign は注文リファレンスを返します

数秒間隔で注文を数回ポーリングする

3. 発行をポーリングする各ポーリングで証明書が発行済みかどうかを確認します

4a. ウィンドウ内で発行された証明書とチェーンが即座に返されます

4b. まだ検証中注文リファレンスをキーとして、保留中として返されます

TuringSign ポータルでドメイン制御検証が完了する

5. 後から完了する後続の更新処理が同じ注文リファレンスを再照会し、発行された証明書を取得します

短い同期ポーリングで事前検証済みの製品はカバーされます。ドメイン制御検証を待っているものは保留中として返され、後から同じ注文リファレンスに対して完了します。

サポートされる操作

操作	サポート	備考
test-connection	はい	認証を行い、製品カタログに到達できることを確認します。
issue	はい	注文を行い、即時発行されるかどうかを短時間ポーリングします。非同期の経路については以下を参照してください。
renew	はい	ネイティブの更新フローはありません — 更新は同じリクエストで新しい注文を行います。
revoke	はい	発行時に取得した注文リファレンスを使って、その注文の証明書を失効させます。理由とコメントは任意で指定できます。

非同期のドメイン検証

一部の製品（通常はドメイン検証済み証明書）は即座には発行されません。TuringSign が先にドメイン制御検証を完了する必要があるためです。注文を行ってから短い同期ウィンドウ内に準備が整わない場合でも、Cockpit はリクエストを失敗させません。証明書を TuringSign の注文リファレンスをキーとして保留中として記録し、TuringSign が検証を完了した時点で完了させます。

ヒント

保留中の注文については、TuringSign ポータルで未完了のドメイン制御検証を完了してください。検証が成功すると、Cockpit の更新/ポーリング処理が同じ注文リファレンスに対して発行済みの証明書を取得します。リクエストを再送信する必要はありません。

本番利用の前にプロビジョニングを確認する

TuringSign コネクタは、プロバイダーが公開している API 契約に基づいて構築されています。本番環境の実稼働 TuringSign テナントに対しては、まだ検証されていません。本番の発行に依存する前に、サブスクライバー、連絡先、製品の各レコードが TuringSign ポータルで正しくプロビジョニングされていることを確認し、まず非本番の発行者で発行/失効の一連のサイクルを検証してください。

関連項目

• 発行者の概要
• エンロールメントプロトコル
• 失効
• Keyfactor