インターネットアクセスが有効な ApsaraMQ for Kafka インスタンスは、クライアントとブローカー間の通信を暗号化するために SSL 証明書を使用します。デフォルトでは、SSL 証明書のキーサイズは 1,024 ビットです。セキュリティを強化するために、キーサイズを 4,096 ビットにアップグレードできます。
アップグレードは 2 つのフェーズで構成されます。まずすべてのクライアントで証明書を置き換え、次にコンソールでキーサイズを変更します。
サーバーレスインスタンスは、デフォルトで 4,096 ビットのキーサイズを使用します。この値は変更できません。以下の手順は、サーバーレス以外のインスタンスにのみ適用されます。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
インターネットアクセスが有効な ApsaraMQ for Kafka インスタンスが購入、デプロイされており、[実行中] の状態であること
ApsaraMQ for Kafka コンソール へアクセス権があること
仕組み
ApsaraMQ for Kafka インスタンスでインターネットアクセスを有効にすると、システムは SSL 関連のポートを初期化し、SSL 証明書を割り当てます。現在のキーサイズは、[インスタンス詳細] ページの [設定情報] セクションで確認できます。
1,024 ビットから 4,096 ビットへのアップグレードには、2 つのフェーズがあります。
クライアント側:1,024 ビットと 4,096 ビットの両方の証明書を含む移行証明書をダウンロードし、各クライアントにデプロイして、クライアントを再起動します。
サーバー側:コンソールで [SSL 証明書キーサイズ (ビット)] パラメーターを 4096 に変更します。
移行証明書 (Java の場合は mix.4096.client.truststore.jks、その他の言語の場合は mix-4096-ca-cert) は、両方のキーサイズに対応しています。つまり、コンソールの表示が 1,024 のままでも、すでに 4,096 に切り替わっていても、クライアントは接続を維持できます。
ステップ 1: SSL 証明書のダウンロード
デプロイ状態とプログラミング言語に合った証明書ファイルを選択します。
Java クライアント
現在の状態 | 証明書ファイル | 説明 |
新規インスタンス (未デプロイ) | 4,096 ビット証明書のみ | |
1,024 ビットキーでデプロイ済みのインスタンス | 1,024 ビット証明書 | |
1,024 ビットから 4,096 ビットへのアップグレード中 | 1,024 ビットと 4,096 ビットの両方の証明書 |
Java 以外のクライアント
現在の状態 | 証明書ファイル | 説明 |
新規インスタンス (未デプロイ) |
| 4,096 ビット証明書のみ |
1,024 ビットキーでデプロイ済みのインスタンス |
| 1,024 ビット証明書 |
1,024 ビットから 4,096 ビットへのアップグレード中 |
| 1,024 ビットと 4,096 ビットの両方の証明書 |
Java 以外の証明書のダウンロードリンクについては、「概要」の「SDK」セクションをご参照ください。
キーサイズのアップグレードには、mix 証明書を使用してください。この証明書は 1,024 ビットと 4,096 ビットの両方のキーサイズに対応しているため、移行期間中もクライアントは接続を維持できます。
ステップ 2: 証明書の置き換えとクライアントの再起動
ダウンロードした証明書ファイルを、クライアントの SSL 証明書ディレクトリにコピーします。
新しい証明書ファイルを参照するようにクライアント設定を更新します。 Java クライアントは、Kafka クライアント設定で
ssl.truststore.locationプロパティを設定します。 Java 以外のクライアント (例えば、confluent-kafkaを使用する Python クライアント) は、新しい CA 証明書ファイルを指定します。ssl.truststore.location=/path/to/mix.4096.client.truststore.jksconf = { 'bootstrap.servers': '<your-endpoint>', 'security.protocol': 'SSL', 'ssl.ca.location': '/path/to/mix-4096-ca-cert', }クライアントを再起動して、新しい証明書を読み込みます。
インターネット経由でインスタンスに接続するすべてのクライアントに対して、ステップ 1 から 3 を繰り返します。
再起動後、各クライアントがメッセージをプロデュースおよびコンシュームできることを確認してください。ステップ 3 に進む前に、すべてのクライアントが正常に動作していることを確認してください。
ステップ 3: コンソールでのキーサイズの変更
すべてのクライアントが新しい証明書を使用するようになったら、次の操作を実行します。
ApsaraMQ for Kafka コンソールにログインします。
インスタンスの [インスタンス詳細] ページを開きます。
[設定情報] セクションで、[SSL 証明書キーサイズ (ビット)] の値を [4096] に変更します。詳細な手順については、「メッセージ設定の変更」をご参照ください。
ステップ 4: 更新の確認
[インスタンス詳細] ページの [設定情報] セクションで、[SSL 証明書キーサイズ (ビット)] の値が [4096] であることを確認します。
すべてのクライアントがエラーなくメッセージをプロデュースおよびコンシュームできることを確認します。
(オプション)
mix移行証明書を使用した場合は、only.4096.client.truststore.jks(Java) またはonly-4096-ca-cert(Java 以外) 証明書に置き換えて、クライアントからレガシーの 1,024 ビット証明書を削除できます。
SSL 接続エラーのトラブルシューティング
ハンドシェイクの失敗
SSL 経由で ApsaraMQ for Kafka インスタンスに接続する際に、handshake failed エラー、または nodename nor servname provided などのエラーが発生した場合は、次のように問題をトラブルシューティングします。
証明書のキーサイズがインスタンス設定と一致していることを確認します。ApsaraMQ for Kafka コンソール の [インスタンス詳細] ページで、[設定情報] セクションの Configurations の値を確認し、このキーサイズに一致する CA 証明書をダウンロードします。
クライアントが ApsaraMQ for Kafka インスタンスの CA 証明書を信頼していることを確認します。コンソールから CA 証明書をダウンロードするか、次のコマンドを実行してエクスポートします。
openssl s_client -connect <endpoint>:9093 -showcerts
証明書の検証失敗 (ホスト名の不一致)
SSL 経由で接続する際に certificate verify failed エラー、またはホスト名の不一致エラーが発生した場合、原因は SSL エンドポイントが IP アドレスであるのに対し、インスタンス証明書ではコモンネーム (CN) として AliKafka が使用されていることです。その結果、IP アドレスが証明書と一致しなくなります。
クライアント設定でホスト名の検証を無効にします。
Java クライアント (kafka-clients):
ssl.endpoint.identification.algorithmを空文字列に設定します。Python クライアント (kafka-python):
ssl_check_hostname=Falseを設定します。Python
sslモジュール:context.check_hostname=Falseに設定します。
confluent-kafka (librdkafka) は、ssl.endpoint.identification.algorithm を直接設定することをサポートしていません。代わりに、カスタム SSL コンテキストを使用してホスト名の検証を無効にします。