NGINXベースのWallarmノードの設定オプション¶

セルフホスト型のWallarm NGINXノードで利用できる詳細な調整オプションについて説明します。これらを活用してWallarmソリューションを最大限に活用できます。

Wallarmディレクティブ¶

disable_acl¶

リクエストの送信元解析を無効化できます。onに設定すると、フィルタリングノードはWallarm CloudからIPリストをダウンロードせず、リクエスト送信元IPの解析をスキップします。

wallarm_acl_access_phase¶

このディレクティブは、NGINXのaccessフェーズでdenylistにあるIPからのリクエストをブロックするようNGINXベースのWallarmノードに指示します。つまり:

• wallarm_acl_access_phase onの場合、Wallarmノードは任意のフィルタリングモード（offを除く）でdenylistのIPからのあらゆるリクエストを即座にブロックし、denylistのIPからのリクエストに対して攻撃兆候の検索を行いません。

  これはデフォルトかつ推奨の値です。denylistが標準どおりに動作し、ノードのCPU負荷を大幅に低減できます。

• wallarm_acl_access_phase offの場合、Wallarmノードはまず攻撃兆候の解析を行い、その後にblockまたはsafe_blockingモードで動作している場合にdenylistのIPからのリクエストをブロックします。

  monitoringフィルタリングモードでは、ノードはすべてのリクエストで攻撃兆候を検索しますが、送信元IPがdenylistでもブロックしません。

  wallarm_acl_access_phase offの挙動は、ノードのCPU負荷を大幅に増加させます。

wallarm_acl_export_enable¶

このディレクティブは、denylistのIPからのリクエストに関する統計をノードからWallarm Cloudへ送信するかどうかをon/offで切り替えます。

• wallarm_acl_export_enable onの場合、denylistのIPからのリクエストに関する統計がAttacksセクションに表示されます。

• wallarm_acl_export_enable offの場合、denylistのIPからのリクエストに関する統計は表示されません。

wallarm_api_conf¶

Wallarm APIへのアクセス要件を含むnode.yamlファイルへのパスです。

デフォルト:

wallarm_api_conf /opt/wallarm/etc/wallarm/node.yaml

フィルタリングノードからのシリアライズ済みリクエストをpostanalyticsモジュール（wstore）へアップロードする代わりに、直接Wallarm API（Cloud）へアップロードするために使用します。攻撃を含むリクエストのみがAPIへ送信されます。攻撃を含まないリクエストは保存されません。

node.yamlの内容例:

# API接続パラメータ（以下のパラメータがデフォルトで使用されます）
api:
  host: api.wallarm.com
  port: 443
  ca_verify: true

その他のパラメータ

wallarm_application¶

Wallarm Cloudで使用する保護対象アプリケーションの一意識別子です。値は0を除く正の整数にできます。

一意識別子はアプリケーションのドメインにもドメインパスにも設定できます。例:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    wallarm_application 1;
    location / {
            proxy_pass http://example.com;
            include proxy_params;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    wallarm_application 2;
    location / {
            proxy_pass http://test.com;
            include proxy_params;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    location /login {
            proxy_pass http://example.com/login;
            include proxy_params;
            wallarm_application 3;
    }

    location /users {
            proxy_pass http://example.com/users;
            include proxy_params;
            wallarm_application 4;
    }
}

アプリケーションの設定方法の詳細→

wallarm_block_page¶

ブロックされたリクエストへの応答内容を設定できます。

ブロックページとエラーコードの設定の詳細→

wallarm_block_page_add_dynamic_path¶

このディレクティブは、コード内にNGINX変数を含むブロックページを初期化し、そのブロックページへのパスも変数で設定する場合に使用します。それ以外の場合は使用しません。

ブロックページとエラーコードの設定の詳細→

wallarm_cache_path¶

サーバー起動時に、proton.dbおよびcustom rulesetファイルのコピーを保存するバックアップカタログが作成されるディレクトリです。このディレクトリはNGINXを実行するクライアントから書き込み可能である必要があります。

wallarm_custom_ruleset_path¶

保護対象アプリケーションやフィルタリングノードの設定情報を含むcustom rulesetファイルへのパスです。

wallarm_enable_apifw¶

このディレクティブは、リリース4.10以降で利用可能なAPI Specification Enforcementをonで有効化、offで無効化します。この機能を有効化しても、必要なサブスクリプションの契約およびWallarm Console UIでの設定に代わるものではない点にご注意ください。

wallarm_enable_libdetection¶

libdetectionライブラリによるSQLインジェクション攻撃の追加検証を有効/無効にします。libdetectionを使用すると二重検知が行われ、誤検知を減らせます。

libdetectionライブラリでのリクエスト解析は、すべてのデプロイオプションでデフォルト有効です。誤検知を減らすため、有効のままにすることを推奨します。

追加検証を確認するには、保護対象リソースへ次のリクエストを送信します:

curl "http://localhost/?id=1' UNION SELECT"

• 基本の検知セット（ライブラリlibproton）はUNION SELECTをSQLインジェクション攻撃の兆候として検知します。UNION SELECT単体はSQLインジェクション攻撃の兆候ではないため、libprotonは誤検知を起こします。

• libdetectionライブラリでの解析が有効な場合、リクエスト内のSQLインジェクション攻撃の兆候は確認されません。リクエストは正当と見なされ、攻撃はWallarm Cloudへアップロードされず、（フィルタリングノードがblockモードで動作していても）ブロックされません。

wallarm_fallback¶

値をonに設定すると、NGINXは緊急モードに入ることができます。proton.dbまたはcustom rulesetをダウンロードできない場合、この設定はデータのダウンロードに失敗したhttp、server、locationブロックについてWallarmモジュールを無効化します。NGINXは動作を継続します。

wallarm_file_check_interval¶

proton.dbおよびcustom rulesetファイルに新しいデータがあるかをチェックする間隔を定義します。単位は接尾辞で指定します:

• 接尾辞なし: 分

• s: 秒

• ms: ミリ秒

wallarm_general_ruleset_memory_limit¶

proton.dbおよびcustom rulesetの1インスタンスが使用できる最大メモリ量の上限を設定します。

処理中にこのメモリ上限を超えると、ユーザーには500エラーが返されます。

このパラメータでは次の接尾辞を使用できます:

• kまたはK: キロバイト

• mまたはM: メガバイト

• gまたはG: ギガバイト

値が0の場合、上限を無効化します。

wallarm_global_trainingset_path¶

wallarm_http_v2_stream_max_len¶

HTTP/2ストリームの最大許容長をバイト単位で設定します。指定値の半分に達すると、ストリームを穏やかに終了させるためにクライアントへHTTP/2のGOAWAYフレームを送信します。ストリームが閉じられず最大長に達した場合、NGINXは接続を強制終了します。

このオプションを設定しない場合、ストリーム長は無制限のままで、特に長時間接続のgRPC環境ではNGINXプロセスが無制限にメモリ消費する可能性があります。

wallarm_instance¶

wallarm_key_path¶

proton.dbおよびcustom rulesetファイルの暗号化/復号に使用するWallarmの秘密鍵へのパスです。

wallarm_local_trainingset_path¶

wallarm_max_request_body_size¶

公開用途では非公開です。

Nodeが解析するHTTPリクエストボディの最大サイズ（バイト）を定義します。リクエストボディが指定上限を超えた場合、超過部分はスキップされ、脅威の検査は行われません。

このディレクティブはリリース6.2.0以降で利用可能です。

wallarm_max_request_stream_message_size¶

Nodeが解析するgRPCまたはWebSocketストリーム内の単一メッセージペイロードの最大サイズ（バイト）を定義します。メッセージが指定上限を超えた場合、超過データはスキップされ、脅威の検査は行われません。

gRPCメッセージヘッダーはサイズ計算に含まれません。

このディレクティブはリリース6.2.0以降で利用可能です。

wallarm_max_request_stream_size¶

Nodeが解析するgRPCまたはWebSocketリクエストストリームボディの合計最大サイズ（バイト）を定義します。ストリームボディが指定上限を超えた場合、超過データはスキップされ、脅威の検査は行われません。

• HTTPヘッダーは計算に含まれません

• gRPCメッセージヘッダー（通常はメッセージ毎に5バイト）は含まれます

例えば、1000バイトのgRPCメッセージを2つ送信すると、合計ストリームサイズは(1000 + 5) × 2 = 2010 bytesになります（5バイトは各gRPCメッセージのヘッダー長）。

このディレクティブはリリース6.2.0以降で利用可能です。

wallarm_memlimit_debug¶

このディレクティブは、メモリ上限超過時にリクエスト詳細を含む/tmp/proton_last_memlimit.reqファイルをWallarm NGINXモジュールが生成するかどうかを制御します。これはリクエストのメモリ上限処理に関する問題のデバッグに非常に役立ちます。

wallarm_mode¶

トラフィック処理モード:

• off

• monitoring

• safe_blocking

• block

wallarm_modeの適用はwallarm_mode_allow_overrideディレクティブで制限できます。

フィルタリングモード設定の詳細→

wallarm_mode_allow_override¶

Wallarm Cloud（custom ruleset）からダウンロードされるフィルタリングルールによるwallarm_modeの上書き可否を制御します。

• off - customルールを無視します。
• strict - customルールは動作モードを強化する場合にのみ適用できます。
• on - 動作モードの強化と緩和の両方が可能です。

例えば、wallarm_mode monitoringかつwallarm_mode_allow_override strictの場合、Wallarm Consoleから一部リクエストのブロックを有効化できますが、攻撃解析を完全に無効化することはできません。

フィルタリングモード設定の詳細→

wallarm_parse_response¶

アプリケーションのレスポンスを解析するかどうかを制御します。レスポンス解析は、パッシブ検知および脅威リプレイテストでの脆弱性検知に必要です。

値はon（レスポンス解析を有効化）またはoff（無効化）です。

wallarm_parse_websocket ¶

WallarmはAPI Securityサブスクリプションプランの下でWebSocketを完全にサポートします。デフォルトでは、WebSocketのメッセージは攻撃解析が行われません。

この機能を有効化するには、API Securityサブスクリプションプランをアクティベートし、wallarm_parse_websocketディレクティブを使用します。

指定可能な値:

• on: メッセージ解析を有効化します。
• off: メッセージ解析を無効化します。

wallarm_parser_disable¶

パーサーを無効化できます。ディレクティブの値は無効化するパーサー名です:

• cookie
• zlib
• htmljs
• json
• multipart
• base64
• percent
• urlenc
• xml
• jwt

例

wallarm_parser_disable base64;
wallarm_parser_disable xml;
location /ab {
    wallarm_parser_disable json;
    wallarm_parser_disable base64;
    proxy_pass http://example.com;
}
location /zy {
    wallarm_parser_disable json;
    proxy_pass http://example.com;
}

wallarm_parse_html_response¶

アプリケーションレスポンスで受信したHTMLコードにHTMLパーサーを適用するかどうかを制御します。値はon（HTMLパーサーを適用）またはoff（適用しない）です。

このパラメータはwallarm_parse_response onの場合にのみ有効です。

wallarm_partner_client_uuid¶

マルチテナントWallarmノードのテナントの一意識別子です。値はUUID形式の文字列である必要があります。例:

• 11111111-1111-1111-1111-111111111111

• 123e4567-e89b-12d3-a456-426614174000

設定例:

server {
  server_name  tenant1.com;
  wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
  ...
  location /login {
     wallarm_application 21;
     ...
  }
  location /users {
     wallarm_application 22;
     ...
  }

server {
  server_name  tenant1-1.com;
  wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
  wallarm_application 23;
  ...
}

server {
  server_name  tenant2.com;
  wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222;
  ...
}
...
}

上記の設定では:

• Tenantはパートナーのクライアントを意味します。パートナーには2つのクライアントがあります。

• tenant1.comおよびtenant1-1.com向けのトラフィックは、クライアント11111111-1111-1111-1111-111111111111に関連付けられます。

• tenant2.com向けのトラフィックは、クライアント22222222-2222-2222-2222-222222222222に関連付けられます。

• 1つ目のクライアントには、wallarm_applicationディレクティブで指定された3つのアプリケーションもあります:

  • tenant1.com/login – wallarm_application 21
  • tenant1.com/users – wallarm_application 22
  • tenant1-1.com – wallarm_application 23

  これら3つのパス向けのトラフィックは対応するアプリケーションに関連付けられ、それ以外は1つ目のクライアントの汎用トラフィックになります。

wallarm_process_time_limit¶

Wallarmノードによる単一リクエスト処理の時間上限を設定します。

時間が上限を超えると、ログにエラーが記録され、そのリクエストはoverlimit_res攻撃としてマークされます。wallarm_process_time_limit_blockの値に応じて、この攻撃はブロック、モニタリング、無視のいずれかになります。

値は単位なしのミリ秒で指定します。例:

wallarm_process_time_limit 1200; # 1200ミリ秒
wallarm_process_time_limit 2000; # 2000ミリ秒

wallarm_process_time_limit_block¶

wallarm_process_time_limitディレクティブで設定した時間上限を超えたリクエストのブロック動作を制御します:

• on: wallarm_mode offでない限り常にリクエストをブロックします

• off: リクエストを常に無視します

  保護回避のリスク

  off値はoverlimit_res攻撃からの保護を無効化するため、慎重に使用する必要があります。

  例えば大容量ファイルのアップロードを行い、保護回避や脆弱性悪用のリスクがない厳密に特定されたlocationのみでoffを使用することを推奨します。

  httpやserverブロックに対してグローバルにwallarm_process_time_limit_blockをoffに設定することは強く推奨しません。

• attack: wallarm_modeディレクティブで設定した攻撃ブロックモードに依存します:

  • off: リクエストは処理されません。
  • monitoring: リクエストは無視されますが、overlimit_res攻撃の詳細はWallarm Cloudへアップロードされ、Wallarm Consoleに表示されます。
  • safe_blocking: graylistedIPアドレスからのリクエストのみブロックされ、すべてのoverlimit_res攻撃の詳細はWallarm Cloudへアップロードされ、Wallarm Consoleに表示されます。
  • block: リクエストはブロックされます。

ディレクティブの値に関係なく、wallarm_mode off;の場合を除き、overlimit_res攻撃タイプのリクエストはWallarm Cloudへアップロードされます。

wallarm_proton_log_mask_master¶

NGINXマスタープロセスのデバッグログ設定です。

wallarm_proton_log_mask_worker¶

NGINXワーカープロセスのデバッグログ設定です。

wallarm_protondb_path¶

リクエストフィルタリングのグローバル設定を保持するproton.dbファイルへのパスです。アプリケーション構造に依存しない設定です。

wallarm_rate_limit¶

次の形式でレート制限の設定を行います:

wallarm_rate_limit <KEY_TO_MEASURE_LIMITS_FOR> rate=<RATE> burst=<BURST> delay=<DELAY>;

• KEY_TO_MEASURE_LIMITS_FOR - 制限を測定したいキーです。文字列、NGINX変数、およびその組み合わせを含められます。

  例: "$remote_addr +login" は、同一IPから/loginエンドポイントへのリクエストを制限します。

• rate=<RATE>（必須） - レート制限です。rate=<number>r/sまたはrate=<number>r/mを指定します。

• burst=<BURST>（任意） - 指定したRPS/RPMを超過した際に一度にバッファリングする超過リクエストの最大数で、レートが正常に戻ったときに処理されます。デフォルトは0です。

• delay=<DELAY> - <BURST>が0以外の場合、バッファリングされた超過リクエストの実行間で定義したRPS/RPMを維持するかを制御します。nodelayはすべてのバッファ済み超過リクエストをレート制限の遅延なしに同時処理することを意味します。数値を指定すると、その数の超過リクエストを同時処理し、残りはRPS/RPMの遅延で処理します。

例:

wallarm_rate_limit "$remote_addr +location_name" rate=10r/s burst=9 delay=5;

wallarm_rate_limit_enabled¶

Wallarmのレート制限を有効/無効にします。

offの場合、レート制限ルール（推奨）もwallarm_rate_limitディレクティブも動作しません。

wallarm_rate_limit_log_level¶

レート制限により拒否されたリクエストのログレベルです。指定可能な値: info、notice、warn、error。

wallarm_rate_limit_status_code¶

Wallarmのレート制限モジュールによって拒否されたリクエストに対して返すコードです。

wallarm_rate_limit_shm_size¶

Wallarmレート制限モジュールが消費できる共有メモリの最大量を設定します。

平均キー長が64バイト（文字）でwallarm_rate_limit_shm_sizeが64MBの場合、このモジュールは約130,000個の一意キーを同時に処理できます。メモリを2倍にすると、モジュールの容量も線形に2倍になります。

キーとは、モジュールが制限を測定する際に使用するリクエストの一意値です。例えば、IPアドレスに基づいて接続を制限する場合、各一意のIPアドレスが1つのキーと見なされます。デフォルトのディレクティブ値では、約130,000個の異なるIPからのリクエストを同時に処理できます。

wallarm_request_chunk_size¶

1回のイテレーションで処理するリクエストの部分のサイズを制限します。wallarm_request_chunk_sizeディレクティブにはバイト単位の整数値を設定できます。次の接尾辞もサポートします:

• kまたはK: キロバイト

• mまたはM: メガバイト

• gまたはG: ギガバイト

wallarm_request_memory_limit¶

単一リクエストの処理に使用できる最大メモリ量の上限を設定します。

上限を超えると、リクエスト処理は中断され、ユーザーには500エラーが返されます。

このパラメータでは次の接尾辞を使用できます:

• kまたはK: キロバイト

• mまたはM: メガバイト

• gまたはG: ギガバイト

値が0の場合、上限を無効化します。

デフォルトでは上限は無効です。

wallarm_srv_include¶

API Specification Enforcement用の設定ファイルへのパスを指定します。このファイルはデフォルトで全てのデプロイメント成果物に含まれており、通常は変更不要です。

ただし、カスタムnginx.confを使用したNGINXベースのDockerイメージを使う場合は、このディレクティブを指定し、ファイルを指定したパスに配置する必要があります。

このディレクティブはリリース4.10.7以降で利用可能です。

wallarm_stalled_worker_timeout¶

NGINXワーカーが単一リクエストを処理する時間上限を秒で設定します。

時間が上限を超えると、NGINXワーカーに関するデータがstalled_workers_countおよびstalled_workers統計パラメータに書き込まれます。

wallarm_status¶

Wallarm統計サービスの動作を制御します。

ディレクティブの値の形式は次のとおりです:

wallarm_status [on|off] [format=json|prometheus];

統計サービスの設定は専用のファイルで行い、他のNGINX設定ファイルにはwallarm_statusディレクティブを記述しないことを強く推奨します。後者は安全でない可能性があるためです。wallarm-statusの設定ファイルは次の場所にあります:

• all-in-oneインストーラー: /etc/nginx/wallarm-status.conf

• その他のインストール: /etc/nginx/conf.d/wallarm-status.conf

また、デフォルトのwallarm-status設定の既存行は変更しないことを強く推奨します。変更すると、Wallarm Cloudへのメトリクスデータのアップロード処理が破損する可能性があるためです。

wallarm_tarantool_upstream¶

2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19

wallarm_timeslice¶

フィルタリングノードがリクエストの1回のイテレーション処理に費やす時間上限です。上限に達すると、ノードはキュー内の次のリクエスト処理に進みます。キュー内の各リクエストに対して1回のイテレーションを行った後、最初のリクエストに対する2回目のイテレーションを実行します。

このディレクティブに異なる時間単位の値を割り当てるには、NGINXドキュメントで説明されている時間間隔の接尾辞を使用できます。

wallarm_ts_request_memory_limit¶

wallarm_unpack_response¶

アプリケーションレスポンスで返される圧縮データを伸長するかどうかを制御します。値はon（伸長を有効化）またはoff（無効化）です。

このパラメータはwallarm_parse_response onの場合にのみ有効です。

wallarm_upstream_backend¶

シリアライズ済みリクエストの送信先を指定します。リクエストはwstoreまたはAPIのいずれかへ送信できます。

ディレクティブの指定可能な値:

• wstore

• api

他のディレクティブの有無に応じて、デフォルト値は次のように決まります:

• 設定にwallarm_api_confディレクティブがない場合: wstore

• wallarm_api_confディレクティブがあり、wallarm_wstore_upstreamディレクティブがない場合: api

  Note

  wallarm_api_confとwallarm_wstore_upstreamディレクティブが同時に設定されている場合、「directive ambiguous wallarm upstream backend」という形式の設定エラーが発生します。

wallarm_upstream_connect_attempts¶

wstoreまたはWallarm APIへの即時再接続回数を定義します。
wstoreまたはAPIへの接続が切断された場合、その接続に対する再接続は行いません。ただし、接続が1つも残っておらず、シリアライズ済みリクエストのキューが空でない場合は、この限りではありません。

wallarm_upstream_reconnect_interval¶

wallarm_upstream_connect_attemptsの閾値を超える回数だけ接続に失敗した後、wstoreまたはWallarm APIへ再接続を試みる間隔を定義します。

wallarm_upstream_connect_timeout¶

wstoreまたはWallarm APIへの接続タイムアウトを定義します。

wallarm_upstream_queue_limit¶

シリアライズ済みリクエストの件数上限を定義します。
wallarm_upstream_queue_limitを設定し、wallarm_upstream_queue_memory_limitを未設定にした場合、後者には上限がなくなります。

wallarm_upstream_queue_memory_limit¶

シリアライズ済みリクエストの総量上限を定義します。
wallarm_upstream_queue_memory_limitを設定し、wallarm_upstream_queue_limitを未設定にした場合、後者には上限がなくなります。

wallarm_wstore_upstream¶

NGINX-Wallarmモジュールを別サーバーのpostanalyticsモジュールへ接続する方法（postanalyticsサーバーのupstreamおよびSSL/TLS接続設定）を定義します。

構文:

wallarm_wstore_upstream <UPSTREAM> ssl=on|off skip_host_check=on|off insecure=on|off;

• <UPSTREAM> - postanalyticsモジュールのアドレスを指すupstreamブロック名です。

• ssl（リリース6.2.0以降で利用可能） — postanalyticsモジュールへの接続のSSL/TLSを有効/無効にします。指定可能な値: onまたはoff。

  デフォルトはoffです。

  onに設定する場合は、次も設定する必要があります:

  • wallarm_wstore_ssl_cert_file
  • wallarm_wstore_ssl_key_file
  • wallarm_wstore_ssl_ca_cert_file

• skip_host_check（リリース6.2.0以降で利用可能、ssl=on時のみ） - TLSハンドシェイク中のホスト名検証をスキップします。

  localhostやIPアドレスへ、CN（Common Name）の一致しない証明書で接続する場合に有用です。本番環境では推奨しません。

• insecure（リリース6.2.0以降で利用可能、ssl=on時のみ） - 証明書の完全な検証（CAおよびホスト名チェックを含む）を無効化します。

  自己署名や一時的な証明書を使用する開発・テスト環境でのみ使用してください。

例:

upstream wallarm_wstore {
    server 1.1.1.1:3313 max_fails=0 fail_timeout=0 max_conns=1;
    keepalive 1;
}

# omitted

wallarm_wstore_upstream wallarm_wstore ssl=on;

wallarm_wstore_ssl_cert_file¶

NGINX-WallarmモジュールがpostanalyticsモジュールへのSSL/TLS接続を確立する際に自らを認証するためのクライアント証明書のパスを指定します。

NGINX-Wallarmとpostanalyticsモジュールを別サーバーにインストールし、相互TLS（mTLS）を有効にしている場合に必要です。

このディレクティブはリリース6.2.0以降で利用可能です。

wallarm_wstore_ssl_cert_file /path/to/client.crt;

wallarm_wstore_ssl_key_file¶

wallarm_wstore_ssl_cert_fileで指定したクライアント証明書に対応する秘密鍵のパスを指定します。

NGINX-Wallarmとpostanalyticsモジュールを別サーバーにインストールし、相互TLS（mTLS）を有効にしている場合に必要です。

このディレクティブはリリース6.2.0以降で利用可能です。

wallarm_wstore_ssl_key_file /path/to/client.key;

wallarm_wstore_ssl_ca_cert_file¶

postanalyticsモジュールが提示するTLS証明書を検証するために使用する信頼された認証局（CA）証明書のパスを指定します。

カスタムCAが発行した証明書を使用するサーバーへ接続する場合に必要です。

このディレクティブはリリース6.2.0以降で利用可能です。

wallarm_wstore_ssl_ca_cert_file /path/to/ca.crt;

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send