クライアント証明書を見分けやすくするには、独自の秘密鍵と CSR を生成し、証明書リクエストに組み込む情報を入力できます。これが実質的に クライアント証明書へのラベル付け になります。
クライアント証明書を使う特定のデバイスから、過剰なトラフィック、異常なトラフィック（不自然なリクエスト列）、攻撃試行の多発が見られる場合は、それらの証明書を 失効 させるのが適切です。
あわせて、失効済み のクライアント証明書をブロックする WAF カスタムルール を用意してください。利用できる cf.tls_* フィールドを確認してください。
アクションをブロックにした WAF カスタムルールの例:
(cf.tls_client_auth.cert_revoked)未検証または失効済みのクライアント証明書を確認する方が、より良い場合もあります。
(not cf.tls_client_auth.cert_verified) or cf.tls_client_auth.cert_revoked一般に、クライアント証明書は定期的かつ安全にローテーションし、漏洩リスクを下げてください。
オリジンサーバーへ クライアント証明書を転送する 方法は複数あります。
すでに mTLS を導入済みで、デバイスにクライアント証明書がインストールされており、独自の認証局（CA）を使いたい場合は、mTLS 向けに独自の CA を持ち込む ことができます。
アップロードした CA は、ダッシュボードまたは Replace Hostname Associations API エンドポイント で、特定のホスト名に関連付けできます。
デバイスへクライアント証明書を安全に配布する方法はいくつかあります。
よく使われる方法は、クライアント証明書をアプリケーションに 埋め込み、ユーザーデバイスがそのアプリをダウンロードしてインストールできるようにすること、モバイルデバイス管理（MDM）でデバイスに証明書を配布すること、ユーザーデバイスがクライアント証明書を直接ダウンロードしてデバイスの証明書ストアにインストールすることです。
証明書の発行は重要な手順なので、可能であればクライアントの検証を十分に行ってください。
複雑なマイクロサービス環境では、Service Mesh を使って mTLS を大規模に自動化・強制できます。たとえば、外部トラフィックのセキュリティは Cloudflare のサービスが担い、ネットワーク内の east-west トラフィックには Service Mesh が mTLS を強制します。外部トラフィックは Cloudflare で保護し、内部のマイクロサービス間通信は Service Mesh 経由の mTLS で保護できます。
Cloudflare の Edge Certificates では、暗号スイートのカスタマイズ を推奨します。これは Edge Certificates にだけ適用され、クライアント証明書には適用されません。
mTLS で推奨する TLS バージョンは次のとおりです。
- TLS 1.2: 互換性が広く、現在も安全です。
- TLS 1.3: セキュリティと効率が向上しているため、新規導入ではこちらを優先します。
TLS 1.0 や 1.1 などの古いバージョンは、既知の脆弱性があるため推奨しません。
ワイルドカード の Edge Certificate があるドメインにブラウザーが接続したあと、同じドメインの mTLS サブドメインへ接続すると、TLS Session Resumption（Connection Resumption とも呼ばれます）が原因で認証が行われないことがあります。
一般に、ワイルドカード証明書の利用は推奨しません。
詳細は トラブルシューティングのドキュメント を参照してください。
再ネゴシエーションで TLS ハンドシェイク後にクライアント証明書を使う必要がある場合は、TLS 1.3 より前のバージョンを使う必要があります。TLS 1.3 は再ネゴシエーションに対応していないためです。
たとえば、mTLS を使い、オリジンサーバー上の全コンテンツではなく、リクエストの URL パスに基づいて特定フォルダーへのリクエストだけを制限する場合、TLS の再ネゴシエーションが発生することがあります。TLS 1.3 の接続は再ネゴシエーションに対応していません。
お客様がクライアント証明書を作成し、use my private key and CSR を選びます。エンドカスタマーが用意した CSR を使い、エンドカスタマーへ渡すクライアント証明書を生成します。ただし、エンドカスタマーが証明書チェーンを求めた場合は、Cloudflare のアカウントチームが共有できることがあります。
詳細はアカウントチームに問い合わせてください。
Cloudflare で mTLS を効果的に導入するには、Cloudflare WAF を適切に設定することを強く推奨します。利用できる cf.tls_* フィールドを確認してください。
アクションをブロックにした WAF カスタムルールの例:
(http.host in {"mtls.example.com" "mtls2.example.com"} and (not cf.tls_client_auth.cert_verified or cf.tls_client_auth.cert_revoked))この式は、リクエストがいずれかのホスト名から来ているかを確認し、クライアント証明書が未検証または失効済みの場合にリクエストをブロックします。
特定のクライアント証明書に対して、cf.tls_client_auth.cert_fingerprint_sha256 フィールドを使った、アクションをブロックにする WAF カスタムルールの別例です（ADD_STRING_OF_CLIENT_CERT_SHA256_FINGERPRINT を置き換えてください）。
(http.request.uri.path in {"/headers"} and http.host in {"mtls.example.com" "mtls2.example.com"} and not cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_fingerprint_sha256 ne "ADD_STRING_OF_CLIENT_CERT_SHA256_FINGERPRINT")シリアル番号をホスト名に関連付ける WAF カスタムルールの別例です。
(http.host in {"mtls.example.com" "mtls2.example.com"} and cf.tls_client_auth.cert_serial ne "ADD_STRING_OF_CLIENT_CERT_SERIAL")この式は、特定のホスト名に紐づく特定の クライアント証明書のシリアル番号 を確認し、より細かい制御ができます。
Cloudflare API 経由で 証明書の転送 を有効にすると、mTLS 接続の各リクエストに次のヘッダーが含まれます。
Cf-Client-Cert-Der-Base64（DER 形式の生証明書を base64 でエンコードしたもの）Cf-Client-Cert-Sha256（証明書の SHA256 フィンガープリント）
ヘッダー Cf-Client-Cert-Sha256 は、レート制限の特性 の「Header value of」で使えます。
レート制限ルール の例:
(http.host in {"mtls.example.com" "mtls2.example.com"} and cf.tls_client_auth.cert_verified)
With the same characteristics...
"Header value of": "Cf-Client-Cert-Sha256"mTLS に加えて、API Discovery、API Routing、Volumetric Abuse Detection、Sequence Mitigation、JWT Validation、Schema Validation などの API Shield 機能を購入できます。
Cloudflare Workers は、クライアントやオリジンサーバーへヘッダーで情報を返すなど、クライアント証明書に関する詳細を提供できます。詳細は次の Workers での mTLS を参照してください。