TLS 相互認証を設定する

D1 Transitサーバーによって公開されるすべてのAPIは、TLS相互認証を必要とします。これは、D1 Transitサーバーへの受信APIコールと、D1 Transitサーバーからの送信APIコールの両方に有効です。

D1 Transit APIの利用者として、あなたは「イシュア」として認識され、そのため イシュア識別子 がD1プラットフォーム内で割り当てられます。この識別子は重要です。なぜなら、TLS接続は各 イシュア識別子.

D1には、互いに分離されたプリプロダクション環境と本番環境の2つの環境があります。それぞれについて明示的にTLS接続を確立する必要があります。

Transit イシュアからThalesへのフロー

一般要件:

1. 相互認証
2. TLS 1.2以上（TLS 1.3を推奨）
3. インターネット経由

ThalesはIPホワイトリスティングを適用します

1. ThalesサーバーCA: Amazon CAによって署名
2. Transitイシュアのクライアント証明書: Thales CAによって署名

クライアント証明書

D1 Transit APIにアクセスするには、Thales CAにTLSクライアント証明書への署名を依頼する必要があります。そのためには、署名用に証明書署名要求（CSR）をThales担当者に提供する必要があります。

一般要件:

1. アルゴリズム: ECDSA P-256鍵およびSHA256ハッシュ。
2. コモンネーム（CN）: 形式と値はThalesによって強制および確認されます。値は以下に説明するパターンに従う必要があります。

CSR生成例

• CSR用の新しいECDSAタイプの鍵ペアを生成します。

以下のOpenSSLコマンドでECDSA P-256鍵ペアを作成できます:

openssl ecparam -name prime256v1 -genkey -noout -out d1-mtls-client-cert.key
openssl req -new \
-key d1-mtls-client-cert.key \
-out d1-mtls-client-cert.csr \
-subj "/C=<country>/ST=<state>/L=<locality>/O=<イシュア組織>/OU=<イシュア組織単位>/CN=TLSMA-ECDSA\/<issuerId>\/TSH/TRANSIT.<env>"

各項目:

• 組織名 はイシュア組織名である必要があります。
• 組織単位 はイシュア組織単位である必要があります。
• CN はコモンネームを意味します。
• issuerId はThales担当者から提供されるIDです。
• env はこの証明書の対象環境です。テスト環境の場合: REL/QA1、プリプロダクションの場合: PPR、本番環境の場合: PRD

Transitイシュアのバックエンドは、Thales D1ドメイン名およびそのサブドメインを常に名前解決する必要があります。Thales D1プラットフォームは長期間の固定IPをサポートしていないため、Thalesの顧客は、ドメインネームサーバーによって返されるTime To Liveを超える期間について、IPアドレスを設定、ハードコード、またはキャッシュしてはなりません。

ThalesからTransit イシュアへのフロー

一般要件:

1. 相互認証
2. TLS 1.2以上（TLS 1.3推奨）
3. インターネット経由

ThalesはIPホワイトリスティングを適用します

1. Thales D1プラットフォームによって提示されるMTLSクライアント証明書を認証するために、Thales Client CAを信頼する必要があります（Thales Client CAはオンボーディングプロセス中に共有されます）。または、オンボーディングプロセス中にあなたのクライアントCAチェーンを提供する必要があります
2. Thales D1プラットフォームはあなたのサーバー証明書を信頼します。このため、オンボーディングプロセス中にあなたのサーバーCAチェーンを提供する必要があります。