デバイス接続のための mTLS ベストプラクティス
相互 TLS(mTLS)はクライアントとサーバーの双方が互いの証明書を認証する仕組みであり、有効な証明書を持たないデバイスの接続を根本的に防止します。暗号化ポートでのパスワード認証を無効化することと組み合わせることで、デバイスはユーザー名やパスワードを提供せずに接続でき、認証はTLSクライアント証明書のみに依存します。
完全な構成は以下の3ステップで行います。
- クライアント証明書の発行:各デバイスに固有のクライアント証明書を発行し、証明書のCNフィールドにデバイスの固有識別子を記載します。
- EMQX CloudでのmTLS設定:サーバー証明書とクライアントCAをアップロードし、双方向認証を有効化、証明書のCNフィールドをUsernameまたはClientIDにマッピングします。
- 暗号化ポートでのパスワード認証を無効化:暗号化ポートでパスワード認証を無効にすると、デバイスはクライアント証明書のみで接続します。
証明書フィールドのマッピング
EMQX Cloudはクライアント証明書の特定フィールドをMQTT接続のUsernameまたはClientIDに自動的にマッピングできます。有効化すると、デバイスは接続時に認証情報を提供する必要がなくなり、EMQXが証明書から直接値を読み取ります。マッピングされた値はACLルールの基準として利用可能です。
サポートされているフィールドはCN、DN、CRTであり、デプロイ設定で選択できます。本ガイドではCN(Common Name)フィールドを例に説明します。CNにはデバイスのシリアル番号、MACアドレス、UUIDなどを使用することを推奨します。各デバイスのCNはグローバルに一意でなければならず、同じ証明書を複数のデバイスで共有してはいけません。
証明書の準備
mTLSには以下の2種類の証明書が必要です。
- サーバー証明書:EMQX Cloudにアップロードし、クライアントがサーバーの正当性を検証できるようにします。生成手順はサーバー側CA証明書の生成を参照してください。
- クライアント証明書:各デバイスに配布し、サーバーがデバイスの正当性を検証できるようにします。生成手順は以下に記載します。
クライアント証明書の発行
クライアントCAの生成
クライアントCAは各デバイスのクライアント証明書を発行するために使用し、一度生成すれば繰り返し使えます。事前にOpenSSLがインストールされていることを確認してください。
openssl req \
-new \
-newkey rsa:2048 \
-days 3650 \
-nodes \
-x509 \
-subj "/C=CN/O=EMQX Technologies Co., Ltd/CN=EMQ CA" \
-keyout client-ca.key \
-out client-ca.crt生成された client-ca.crt は後のステップでEMQX Cloudにアップロードします。
各デバイスの証明書発行
以下の手順を各デバイスごとに繰り返し、device-001 を実際のデバイス識別子に置き換えてください。
デバイスの秘密鍵を生成します。
bashopenssl genrsa -out device-001.key 2048デバイスの固有識別子をCNフィールドに含む証明書署名要求(CSR)を生成します。
bashopenssl req -new -key device-001.key -out device-001.csr \ -subj "/CN=device-001"クライアントCAで署名し、デバイス証明書を生成します。
bashopenssl x509 -req -days 3650 -sha256 \ -in device-001.csr \ -CA client-ca.crt \ -CAkey client-ca.key \ -CAcreateserial \ -out device-001.crt証明書を検証します。
bashopenssl verify -CAfile client-ca.crt device-001.crt
EMQX CloudでのmTLS設定
双方向TLSの有効化
デプロイメントのTLS/SSL設定パネルでサーバー証明書、秘密鍵、クライアントCA証明書をアップロードします。詳細な手順は専用および専用FlexデプロイメントでのTLS/SSL設定を参照してください。
CNをUsernameにマッピング
CNフィールドをMQTT接続のUsernameにマッピングします。これによりACLルールをUsernameに基づいて適用可能です。
注意
この機能はEMQX 5.10.3以降を実行している専用および専用Flexデプロイメントで利用可能です。Cloudコンソールに表示されない場合は、チケットを提出してアップグレードやサポートを依頼してください。
- デプロイメント詳細に移動し、左メニューのDeployment Settingsをクリック、次にMQTT Settingsタブを選択します。
- Use Peer Certificate as Usernameのドロップダウンで
cnを選択します。 - Updateをクリックします。
CNをClientIDにマッピング
システムでClientIDによるデバイス管理が必要な場合は、CNをClientIDにマッピングすることも可能です。
注意
この機能はEMQX 5.10.3以降を実行している専用および専用Flexデプロイメントで利用可能です。Cloudコンソールに表示されない場合は、チケットを提出してアップグレードやサポートを依頼してください。
- デプロイメント詳細に移動し、左メニューのDeployment Settingsをクリック、次にMQTT Settingsタブを選択します。
- Use Peer Certificate as ClientIDのドロップダウンで
cnを選択します。 - Updateをクリックします。
注意
CNをClientIDにマッピングする場合、すべてのデバイスのCNがグローバルに一意であることを必ず確認してください。同じCNを複数のデバイスが共有すると、ClientIDの競合により接続が相互に切断されます。
暗号化ポートでのパスワード認証の無効化
上記の設定が完了したら、暗号化ポートでのパスワード認証を無効化できます。これにより、デバイスはユーザー名やパスワードを提供せず、クライアント証明書のみで接続可能になります。
注意
パスワード認証を無効化する前に、すべてのクライアントが有効なクライアント証明書を持ち、エンドツーエンドの接続テストが成功していることを必ず確認してください。ライブデバイスの接続に影響を与えないためです。また、平文ポート(1883)を閉じ、暗号化ポート(8883 / 8084)のみを公開することを推奨します。
V5専用デプロイメントではコンソール上で直接操作可能です。手順はポート管理 - 暗号化ポートのクライアント認証管理を参照してください。
その他のデプロイメントタイプの場合は、サポートチケットを提出してください。SREチームがデプロイメントの8883および8084ポートでのクライアント認証無効化を支援します。
クライアント接続例
MQTTXの例
MQTTXを使用してmTLS接続をテストする手順:
新しい接続を作成し、接続名を入力します。Client IDはランダム生成でも構いません。
ホストを選択し、デプロイメントの接続アドレスとポートを入力します:
- TLS接続の場合:
mqtts://を選択し、ポートは8883。 - TLS上のWebSocketの場合:
wss://を選択し、ポートは8084。
- TLS接続の場合:
パスワード認証が無効化されている場合は、UsernameとPasswordは空欄のままにします。
SSL/TLSを有効にし、Self signedを選択します。
以下の証明書ファイルを指定します:
- CA File:サーバーCA証明書(
server-ca.crt)。 - Client Certificate File:デバイスのクライアント証明書(
device-001.crt)。 - Client Key File:デバイスのクライアント秘密鍵(
device-001.key)。
- CA File:サーバーCA証明書(
右上のConnectをクリックします。
FAQ
ClientIDの競合によるデバイス切断が発生する場合
症状: 2台のデバイスが同じClientIDまたは同じクライアント証明書を共有している。後から接続したデバイスが先に接続していたデバイスを切断する。
原因: MQTTプロトコルでは、同一のClientIDを持つ接続はブローカー上に1つだけ存在可能です。
対策: 各デバイスに一意の証明書と一意のCNを持たせてください。CNをUsernameにマッピングする設定を併用すると、ClientID競合のリスクをさらに減らせます。
証明書が漏洩した場合の対処方法
- CNをUsernameにマッピングしている場合は、漏洩したデバイスのCNに対応するUsernameをブラックリストに即座に追加し、再接続を防止します。
- 対象デバイスに新しい証明書を発行し、デバイス側の証明書設定を更新します。
- ブラックリストの登録が有効な間は、漏洩した証明書での接続はできません。
パスワード認証を無効化した後に追加の認証は必要ですか?
暗号化ポートでパスワード認証を無効化すると、認証はTLSクライアント証明書のみに依存し、ユーザー名/パスワード認証よりも強固なセキュリティを提供します。クライアント証明書を一時的に使用できないデバイスがある場合は、移行期間中はパスワード認証を有効のままにし、すべてのデバイスが証明書認証に移行後に無効化することを推奨します。