クライアント SSL 証明書を設定して埋め込んだあともクエリがエラーを返す場合は、次の設定を確認します。
ターミナルで次のコマンドを使い、クライアントと API エンドポイントの間で SSL/TLS 接続を確立できるか確認します。
curl --verbose --cert /path/to/certificate.pem --key /path/to/key.pem https://your-api-endpoint.comSSL/TLS ハンドシェイクを完了できない場合は、証明書と秘密鍵が正しいかを確認します。 ハンドシェイクは完了するがリクエストがブロックされる場合は、Cloudflare がクライアント証明書を検証しているかを確認します。
正しいホストで mTLS が有効になっているか を確認します。ホストは、保護したい API エンドポイントと一致している必要があります。
mTLS ルールを確認するには、次の手順を使います。詳細は カスタムルール を参照してください。
-
Cloudflare ダッシュボードで、Security rules ページに移動します。
Security rules を開く ↗ -
対象のルールで Edit を選びます。
-
そのルールで、次を確認します。
-
Expression Preview が正しいこと。
-
ホスト名を定義している場合、API エンドポイントと一致していること。たとえば、API エンドポイントが
api.trackers.ninja/timeの場合、ルールは次のようになります。(http.host in {"api.trackers.ninja"} and not cf.tls_client_auth.cert_verified)
-
-
ルールを編集するには、ユーザーインターフェイスを使うか、Edit expression を選びます。
Cloudflare Workers を使って、クライアント証明書の検証失敗をデバッグできます。
-
cf.properties をデバッグ出力する Worker を作成します。
export default { async fetch(request, env, ctx) { console.info({ message: JSON.stringify(request.cf, null, 2) }); return new Response(JSON.stringify(request.cf, null, 2)) } }; -
mTLS を有効にしたホスト名に、Worker ルート または Custom Domain で Worker を関連付けます。
-
設定したホスト名やパスに、mTLS クライアント証明書を付けた場合と付けない場合の両方でリクエストします。
-
Observability ダッシュボードでログを確認し、次の期待値と応答を比較します。
Observability を開く ↗
-
有効な証明書
"tlsClientAuth": { "certPresented": "1", "certVerified": "SUCCESS", }, -
無効な証明書(自己署名証明書など)
"tlsClientAuth": { "certPresented": "1", "certVerified": "FAILED:self signed certificate", }, -
証明書なし
"tlsClientAuth": { "certPresented": "0", "certVerified": "NONE", },