HSP_HostIdPath

Global

Defines the file containing the HSP host identifier. The HSP identifier is used as a unique identifier for all components located on this host. This identifier is used for logging and correlation.

Syntax: HSP_HostIdPath <pathname>

Default is /etc/usp/hsp/hostid.

Example: HSP_HostIdPath /etc/usp/hsp/hostid

The system’s host id (gethostid(3C)) is used as the default value if no such file is specified or has not been found.

HSP_AbsoluteRedirects

Virtual Server

Controls generating absolute redirects. "Off" means, that relative (no host name) redirects are sent to the client, "on" means that absolute (including schema and host name) redirects are sent to the client, e.g. for the cookie check.

Can also been set using the ‘BrowserMatch’ directive.

Syntax: HSP_AbsoluteRedirects on|off

Default: off

HSP_InstanceId

Global

Defines the server instance identifier. The HSP identifier is used by all components as a unique instance identifier for request and client correlation.

Syntax: HSP_InstanceId <string>

Example: HSP_InstanceId srm

Default is the parent process PID.

HSP_TraceModules

Global

Enables tracing for the specified modules and events. Syntax: HSP_TraceModules <module:flags> …

where module can be one of the following:

flags is a bitset consisting of the following flags:

Do not use in productive systems.

Example:

HSP_TraceModules mod_secure_request_manager_gateway:0cff

HSP_TraceMagicValue

Global

Set the flag which is set for all the modules if HSP_TraceMagic is set to all. The default value is 0xffff . The usage of the flags is described within HSP_TraceModules.

HSP_TraceMagic

Global

Enables selective tracing of clients sending a cookie with a "magic" value. The magic value is used within the log files to identify the trace messages. Syntax: HSP_TraceMagic <value>

<value> must be one of the following values

The client needs to send a Cookie with the following format:

HSP_TraceMagic=<magic>

The value <magic> is used to identify the client within the log files.

HSP_TraceOptions

Global

Controls tracing.

Syntax: HSP_TraceOptions <option>,<option>,….

where option can be one of the following:

HSP_ClientHost

Virtual Host

Changes the default HTTP Host specification which is used by the client to access this virtual host. Affects rewriting the HTTP "location" header in HTTP responses using status 302. This directive can be used to support port mapping which violates RFC2616. If this directive is not set, host and port specified using directives "VirtualHost", "Port", "Listen" or "Bind" are used to rewrite HTTP "Location" headers sent by application servers.

Syntax:

HSP_ClientHost <host[:port]>|"$"

If "$" is used, the HTTP "Host" header sent from client is used. Please note that some HTTP client implementations do not add the port to this header. If the client does not send a HTTP "Host" header, a relative HTTP "Location" header is generated.

HSP_Chroot

Global

Implements a chrooted server. Does usually not require any configuration or environment changes.

Syntax: HSP_Chroot <path>

HSP_DeflateRequestBody

Environment Variable

Activate input filter for deflating request body before any validator or body rewriter module

Syntax: SetEnvIf <attribute> <regex> HSP_DeflateRequestBody

Example: SetEnvIf Content-Encoding "gzip" HSP_DeflateRequestBody

HSP_RedirectMatch

Virtual Host

Directive works similar to RedirectMatch of mod_alias but allows to use additional variables within the destination URL. If the ‘keep-query’ flag is specified, query parameters from the original request are preserved also if query parameters are specified in the redirect target ‘url’.

Variables:

Syntax: HSP_RedirectMatch <regex> <url> [keep-query]

Example: HSP_RedirectMatch /(.*) https://$SERVERNAME/$1 keep-query

HSP_DoubleSlashRedirects

Virtual Host

When a redirect response is generated with a target location starting with "double slashs" (absolute URL without protocol identifier) HSP will reduce the target to a single slash if not disabled.

Syntax: HSP_DoubleSlashRedirects ‘on’|‘off’

Default is "on".

HSP_DoubleSlashRedirects_Exclude

Virtual Host

This directive allows to define target hosts for which redirect URLs without protocoll identifier should be allowed without disabling the whole feature. A List of known-good-host can be specified as regex.

Syntax: HSP_DoubleSlashRedirects_Exclude <regex>

Example: HSP_DoubleSlashRedirects_Exclude "www\.trusted\.org"

RC_MaxPostSize

Location

Maximum number of bytes allowed to be transferred to the server. Syntax: RC_MaxPostSize <bytes>

Default is "49152"

RC_MaxPostSize_Status

Location

Status Code which is returned if RC_MaxPostSize is exceeded.

Syntax: RC_MaxPostSize_Status <status code>

RC_MaxPostSize_StatusMsg

Location

If you have defined RC_MaxPostSize_Status you can optionally specify a status message that should be sent to the client.

Syntax: RC_MaxPostSize_StatusMsg <status msg>

Example: RC_MaxPostSize_StatusMsge "<html><head><title>RC_MaxPostSize_StatusMsg</title></head>

<body>RC_MaxPostSize exceeded</body></html>"

RC_MaxResponseSize

Location

Maximum number of bytes allowed to be transferred from the server. Syntax: RC_MaxResponseSize <bytes>

Default is no limitation

RF_ServerAllowMethod

Virtual Server

Restricts the allowed HTTP method for the virtual server. Methods not defined by this directive are denied and result in a "405 Method Not Allowed" response. Multiple methods may be specified for each server configuration. Use the "+" prefix to allow a method and the "-" prefix to deny the specified method.

The method TRACE can’t be enabled and the server response for TRACE requests is always a 403 forbidden.

Syntax: RF_ServerAllowMethod “+”|“-”<method>

Example: RF_ServerAllowMethod -POST +PUT

Default is "+GET +HEAD +POST"

RF_LocationAllowMethod

Location

Restricts the allowed HTTP method for the location. This directive takes only effect if it has explicitly defined for a location. This filter is applied after the method filter defined by RF_ServerAllowMethod. Methods denied by RF_ServerAllowMethod can’t be allowed by this command.

Methods excluded by this directive are denied and result in a "405 Method Not Allowed" response. Multiple methods may be specified for each server configuration. Use the “+” prefix to allow a method and the “-” prefix to deny the specified method.

The method TRACE can’t be enabled and the server response for TRACE requests is always a 403 forbidden. Syntax: RF_LocationAllowMethod “+”|“-”<method>

Inheritance: Merges the per location configuration values. “+” and “-” adds and removes methods from the current location configuration.

Example: RF_LocationAllowMethod -POST

Default is "+GET +HEAD +POST"

RF_UE_PassPhrase

Virtual Server

Pass phrase used to generate a symmetric key for URL encryption.

Syntay: RF_UE_PassPhrase <string>

RF_UE_OldPassPhrase

Virtual Server

Defines a per-server secret which has been used in the past. Requests encrypted by an old pass phrase are decrypted and forwarded to the path defined by the RF_UE_OldPassPhraseErrorPage directive. The directive may be defined multiple times within the server configuration.

Syntax: RF_UE_OldPassPhrase <string>

RF_UE_OldPassPhraseErrorPage

Virtual Server

Defines a URL (path) to which a request is redirected if it has been encrypted by an old pass phrase. The received request line is passed via the specified query parameter.

Syntax: RF_UE_OldPassPhraseErrorPage <path> <query>,

Default are path=/srm-error-pages/Error500.html and query=ue_url.

RF_UE_DecryptionFailureRedirect

Virtual Server

Defines a path to which a client gets redirected to in case of a decryption error. The optional setting "mode" allows to set a custom error page for path decryption errors (mode "path") and query string decryption errors (mode "query"). The mode "path|query" can be used for a common error page. If no mode is set the default is mode "path".

Syntax: RF_UE_DecryptionFailureRedirect <path> [<mode>]

Without the use of this directive the status code 404 is delivered on path decryption errors. However, on query string decryption errors the request is yet passed to the backend.

RF_UE_JSFunction

Location

Controls URL encryption within JavaScripts, see also section "URL Encryption". This directive defines a function name whose parameter must be encrypted.

Example JavaScript code:

setField(value, "../action");

Multiple function names may be specified for each location. Use the “+” prefix to add additional rules to a location or the “-” prefix to remove a rule. A name without a prefix disable configuration inherited form the upper location.

The following function names are reserved and can’t be defined by RF_UE_JSFunction: "string", "catch", "if", "for", "while", "switch", and "with".

Syntax: RF_UE_JSFunction [‘+'|`-’] <name> [<action> <pos>]

Example (see JavaScript example above):

RF_UE_JSFunction +setField absolute 2

RF_UE_JSVariable

Location

Controls URL encryption within JavaScripts, see also section "Encryption". This directive defines a variable name whose assigned values must be encrypted.

Example JavaScript code:

var url = root + "../action" + "?" + "password=1234";
var path = new String("../path");

Multiple variable names may be specified for each location. Use the “+” prefix to add additional rules to a location or the “-” prefix to remove a rule. A name without a prefix disable configuration inherited form the upper location.

Syntax: RF_UE_JSVariable [‘+'|`-’] <name> [<action> <pos>]

Example (see JavaScript example above):

RF_UE_JSVariable +url relative 2

RF_UE_JSVariable +url query 4

RF_UE_JSVariable +path absolute 2

RF_UE_JSCharset

Location

Defines a regular expression a string must match in order to be recognizes as an URL when using JavaScript automatic encryption mode (defined by RF_UE_JSFunction or RF_UE_JSVariable ). This char set is used to detect a path pattern. Only one pattern may be defined per location.

Syntax: RF_UE_JSCharset <regular expression>

Inheritance: Inherited to sub-locations.

Default: ^(http|/)[a-zA-Z0-9/\.\?#=:@;&%_\-]*$

RF_UE_JSQueryCharset

Location

Defines a regular expression a string must match in order to be recognizes as an URL when using JavaScript automatic encryption mode (defined by RF_UE_JSFunction or RF_UE_JSVariable). This char set is used to detect a path query only. Only one pattern may be defined per location.

Syntax: RF_UE_JSQueryCharset <regular expression>

Inheritance: A sub location having any RF_UE_* directive defined does not inherit the configuration from the upper location.

Default: no pattern is defined.

Example:

RF_UE_UrlExclPattern

Location

Defines a regular expression a URL (within the processed data stream) must match in order to be excluded from the URL encryption. An excluded URL is "normalized" to an absolute path. The pattern match is applied to the normalized path. Multiple patterns may be defined per location.

Syntax: RF_UR_UrlExclPattern <regular expression>

Inheritance: No configuration merge to sub location. A sub location having any RF_UE_* directive defined does not inherit the configuration from the upper location.

Example:

RF_UE_UrlExclPattern "^/images/([a-zA-Z].*|[1-9].*)\.(jpg|gif)$"

This excludes all URLs in the stream matching ‘/images/*.jpg’ and ‘/images/*.gif’).

RF_UE_DecodeHTML

Location

HTML decodes URL containing "special characters" before URL encryption.

Please note that HTML responses sent to the client are generally forced to be HTML encoded otherwise special characters might be interpreted by the browser and could result in wrong URLs being used.

Sample: The HTML-Response “<a href="foo.cgi?chapter=1&section=2&copy=3&lang=en">…</a>” would be interpreted by the browser as “<a href="foo.cgi?chapter=1&section=2©=3&lang=en">…</a>”. To become a correct Link, the application must HTML encode this kind of data: “<a href="foo.cgi?chapter=1&amp;section=2&amp;copy=3&amp;lang=en">…</a>”

The encrypted URL must contain the decoded HTML (which differs from what is being sent to the client) otherwise the additional ‘&’ would also lead to additional parameters being sent back to the application. By turning ‘on’ this directive, the SES handles this special browser behavior.

Syntax: RF_UE_DecodeHTML "On" | "Off"

Inheritance: Inherited to sub-locations.

Default: off

RF_UE_DecodeBody

Location

Enables decryption of query values within the HTTP request body. This directive is used in conjunction with RF_UE_EncodeQueryForm directive. See RF_UE_EncodeQueryForm about activation of HTML form data encryption.

Syntax: RF_UE_DecodeBody "On"|"Off"

Default: off

RF_ChangeReqHeader

Location

Replaces a ‘search’ pattern (literal string) by the ‘replace’ pattern (literal string or environment variable defined using SetEnvIf when the replace pattern is prefixed by ‘$’) in the defined HTTP request header. Per default only the first occurrence is replace. The optional parameter “greedy” defines that all occurrences should be replaced. Supports only one rule per header.

Syntax: RF_ChangeReqHeader <header name> <search> <replace> [greedy]

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIf*Header directive defined does not inherit the configuration from the upper location.

RF_ChangeReqHeaderReplace

Location

Replaces the ‘header’ by the defined ‘value’ in the request headers. The value may specify an environment variable defined using SetEnvIf if the value is prefixed by a ‘$’. The header is added to the request if it does not exist.

Syntax: RF_ChangeReqHeaderReplace <header> <value>

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIf*Header directive defined does not inherit the configuration from the upper location.

RF_ChangeIfReqHeaderReplace

Location

Sets a HTTP request header if the specified environment variable matches the defined regular expression. The directive recognizes the occurrences of $1..$9 within the value argument and replaces them by the sub expressions of the defined regex pattern.

Syntax: RF_ChangeIfReqHeaderReplace <variable> <regex> [!]<header>=<value>

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIf*Header directive defined does not inherit the configuration from the upper location.

RF_ChangeReqFixHeader

Location

Same as RF_ChangeReqHeader but applied later in the request processing (Apache fixup handler).

RF_ChangeReqFixHeaderReplace

Location

Same as RF_ChangeReqHeaderReplace but applied later in the request processing (Apache fixup handler).

RF_ChangeResHeader

Location

Same as RF_ChangeReqHeader but applied to a response header.

RF_ChangeResHeaderReplace

Location

Same as RF_ChangeReqHeaderReplace but applied to a response header.

RF_ChangeResHeaderAdd

Location

Adds the ‘header’ with the defined ‘value’ to the response headers. The value may be specified with an environment variable using SetEnvIf (environment variable is prefixed by ‘$’). The directive is processed before the RF_ChangeResHeader, RF_ChangeResHeaderReplace, RF_SetEnvIfResHeader, and RF_ChangeIfResHeaderReplace.

Syntax: RF_ChangeResHeaderAdd <header> <value>

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIf*Header directive defined does not inherit the configuration from the upper location.

RF_SetEnvIfResHeader

Location

Creates an environment variable if the specified response header value matches the defined argument. Works similar to Apache’s SetEnvIf directive but is applied to the response headers. The directive recognizes the occurrences of $1..$9 within the header value and replaces them by the sub expressions of the defined regex pattern.

Syntax: RF_SetEnvIfResHeader <header> <regex> [!]<variable>[=<value>]

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIfResHeader directive defined does not inherit the configuration from the upper location.

RF_ChangeIfResHeaderReplace

Location

Sets a HTTP response header if the specified environment variable matches the defined regular expression. The directive recognizes the occurrences of $1..$9 within the value argument and replaces them by the sub expressions of the defined regex pattern. Works contrariwise to RF_SetEnvIfResHeader.

Syntax: RF_ChangeIfResHeaderReplace <variable> <regex> [!]<header>=<value>

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIf*Header directive defined does not inherit the configuration from the upper location.

RF_FakeServerName

Virtual Server

The server name returned to the client in the HTTP header "Server". If not defined, the default "Secure Entry Server" is used. With the value %OFF the header "Server" coming from the back-end (SRM, respectively) remains unchanged.

Inheritance: A configured server name in the global scope is merged into the scope of virtual hosts. With the value %DEFAULT the server name in a virtual host can be reset to the default server name.

Syntax: RF_FakeServerName <name>

RF_ServerRequestHeaderDeny

Virtual Server

Restrict HTTP headers for the client.

Headers denied by this directive are removed from the incoming request.

Syntax: RF_ServerRequestHeaderDeny ([“+”|“-”] <header>)*

Inheritance: Merges the deny input header list. ‘+’ and ‘-’ adds and removes headers. If no ‘-’ or ‘+’ is preceding the header name a new list is started (no merge).

Example: RF_ServerRequestHeaderDeny +HSP_FOO_ -HSP_BAR_ HSP_HELLO_

Default: +HSP +SSL +ClientCorrelator +ConnectionCorrelator +HTTPS

RF_ServerRequestHeaderAllow

Virtual

Server

Explicit allow HTTP headers for virtual server.

This directive overloads a Virtual Server RF_ServerRequestHeaderDeny directive.

Syntax: RF_ServerRequestHeaderAllow ([“+”|“-”] <header>)*

Inheritance: Merges the allow input header list. ‘+’ and ‘-’ adds and removes headers. If no ‘-’ or ‘+’ is preceding the header name a new list is started (no merge).

Example: RF_ServerRequestHeaderAllow +HSP_FOO_ -HSP_BAR_ HSP_HELLO_

Default: +HSP_TS

RF_LocationRequestHeaderDeny

Location

The same behavior like RF_ServerRequestHeaderDeny. This directive overloads the RF_ServerRequestHeaderAllow directive.

RF_LocationRequestHeaderAllow

Location

The same behavior like RF_ServerRequestHeaderAllow. This directive can not overload the RF_ServerRequestHeaderDeny directive, only the RF_LocationRequestHeaderDeny directive.

RF_ServerResponseHeaderDeny

Virtual Server

Restrict HTTP headers from the application server back to client.

Headers denied by this directive are removed from the outgoing request.

Syntax: RF_ServerResponseHeaderDeny ([“+”|“-”] <header>)\*

Inheritance: Merges the deny output header list. ‘+’ and ‘-’ adds and removes headers. If no ‘-’ or ‘+’ is preceding the header name a new list is started (no merge).

Example: RF_ServerResponseHeaderDeny +HSP_FOO_ -HSP_BAR_ HSP_HELLO_

Default: +HSP_SERVER_LOAD_INFO +HSP_AC_SESSION_ATTRIBUTES

RF_ServerResponseHeaderAllow

Virtual Server

Explicit allow HTTP headers from the application server back to client.

This directive overloads a Virtual Server RF_ServerResponseHeaderDeny directive.

Syntax: RF_ServerResponseHeaderAllow ([“+”|“-”] <header>)*

Inheritance: Merges the allow output header list. ‘+’ and ‘-’ adds and removes headers. If no ‘-’ or ‘+’ is preceding the header name a new list is started (no merge).

Example: RF_ServerResponseHeaderAllow +HSP_FOO_ -HSP_BAR_ HSP_HELLO_

Default: +HSP_TS

RF_LocationResponseHeaderDeny

Location

Note: The same behavior like RF_ServerResponseHeaderDeny. This directive overloads the RF_ServerRequestHeaderAllow directive.

RF_LocationResponseHeaderAllow

Location

Note: The same behavior like RF_ServerResponseHeaderAllow. This directive can not overload the RF_ServerResponseHeaderDeny directive only the RF_LocationResponseHeaderDeny directive.

RF_ServerRequestHeaderEntryDeny

Virtual Server

Restrict HTTP header entries from client.

Header entries denied by this directive are removed from the incoming request.

Syntax: RF_ServerRequestHeaderEntryDeny <header> ([“+”|“-”] <entry>)*

Inheritance: Merges the deny input header entry list. ‘+’ and ‘-’ adds and removes header entries. If no ‘-’ or ‘+’ is preceding the header entry name a new list is started (no merge)

Example: RF_ServerRequestHeaderEntryDeny Accept-Encoding +gzip +compress

RF_ServerResponseHeaderEntryDeny

Virtual

Server

Restrict HTTP header entries from the application server back to client.

Header entries denied by this directive are removed from the incoming request.

Syntax: RF_ServerResponseHeaderEntryDeny <header> ([“+”|“-”] <entry>)*

Inheritance: Merges the deny input header entry list. ‘+’ and ‘-’ adds and removes header entries. If no ‘-’ or ‘+’ is preceding the header entry name a new list is started (no merge)

Example: RF_ServerResponseHeaderEntryDeny Accept-Encoding +gzip +compress

RF_LocationRequestHeaderEntryDeny

Location

Note: The same behavior like RF_ServerRequestHeaderEntryDeny.

RF_LocationResponseHeaderEntryDeny

Location

Note: The same behavior like RF_ServerResponseHeaderEntryDeny.

RF_Param

Virtual Server

This directive enable ("On") or disable ("Log", "Off") the module for this server.

Syntax: RF_Param "On" | "Off" | "Log"

Inheritance: Virtual server settings overwrite global settings.

Example: RF_Param Log

Default: Off

RF_ParamGetAllow

Virtual

Server

This directive allows GET requests without parameters.

Syntax: RF_ParamGetAllow "On" | "Off"

Inheritance: Virtual server settings overwrite global settings.

Example: RF_ParamGetAllow Off

Default: On

RF_ContentTypeMap

Virtual

Server

This directive defines a new content-type based on an existing content-type. Existing content types are namely: application/x-www-form-urlencoded and multipart/form-data.

Syntax: RF_ContentTypeMap <new content type> <existing content type>

Inheritance: Virtual server settings overwrite global settings.

Example: RF_ContentTypeMap myOwn/ContentType

RF_ParamByteRange

Location

This directive defines the allowed characters.

Syntax: RF_ParamByteRange <start> <end>

Inheritance: A child location overwrites its parent’s location settings.

Note: <start> must be lesser than <end> but not lesser 0, <end> must not be bigger than 255

Example: RF_ParamByteRange 32 128

Default: 0 255

RF_ParamWhitelist

Location

This directive defines the whitelist of the allowed parameters. If a parameter is not allowed a 403 Forbidden is sent by the server.

Syntax: RF_ParamWhitelist <path> ( <parameter> [ \\"=\\" [ <num> "-" <num> ] <regex> ] )\*

Inheritance: A child location overwrites its parent’s location settings.

Example: RF_ParamWhitelist /a/b param1=[32-255]\^hallo$

Note: There must be no whitespaces in the parameter expression.

Default: All parameter which are not in the whitelist are denied.

RF_ParamWhitelist_Test

Location

Note: Same syntax as RF_ParamWhitelist, but only logs the denied parameters and does not bloc them.

RF_Html_ContinueOnParseErr

Virtual

Server

Defines whether to continue response processing on HTML parser error or not. "on" forces the continuation even an error occurs (unknown pattern).

Syntax: RF_Html_ContinueOnParseErr on|off

Default is on

RF_Js_ContinueOnParseErr

Virtual

Server

Defines whether to continue response processing on JavaScript parser error or not. "on" forces the continuation even an error occurs (unknown pattern).

Syntax: RF_Js_ContinueOnParseErr on|off

Default is on

RF_Css_ContinueOnParseErr

Virtual

Server

Defines whether to continue response processing on CSS parser error or not. "on" forces the continuation even an error occurs (unknown pattern).

Syntax: RF_Css_ContinueOnParseErr on|off

Default is on

RF_SF_SoapFilter

Virtual Server

Activates SOAP message filtering for this server.

Syntax: RF_SF_SoapFilter on|off

RF_SF_TrustedSchema

Virtual Server

Defined trusted schemas (.xsd) used/referenced within application specific .wsdl files.

Syntax: RF_SF_TrustedSchema <xsd file>

RF_SF_ResourceMapping

Virtual Server

Resources (for example Schema Files) imported from other Schema- or WSDL files by using <xsd:import schemaLocation="xy"…> need local mapping to files available on the SES’s filesystem.

Syntax: RF_SF_ResourceMapping <location> <file>

Import statements not mapped to local files result in the following error logged in the error_log:

[error] Unable to resolve <location>. Please use RF_SF_ResourceMapping for local mapping

RF_SF_DefineApplication

Virtual

Server

Defines a Variable linked to an WSDL schema file that could be later on referenced in RF_SF_AllowService directives. The WSDL file will be verified against the WSDL schema specified in the RF_SF_WSDLSchemaFile directive to assure its integrity. For validation of SOAP actions and parameter names, in general both rpc and wrapped document style WSDL files are supported (unwrapped document style is not supported).

The optional parameter <ext-schema-file> is for indicating an external xml schema that contains parameter info for a document (wrapped) style WSDL (only needed when that information is not in the WSDL itself).

Syntax: RF_SF_DefineApplication <alias> <xml name space> <wsdl file> [<ext schema file>]

Example: "RF_SF_DefineApplication APPL1 urn:SampleWebService /opt/tarsec/TSHSP/HttpsListener2/conf/SampleWebServices.wsdl /opt/tarsec/TSHSP/HttpsListener2/conf/ext/SampleWebServices.xsd"

RF_SF_SoapValidator

Location

Enables soap request validation for the location. Every POST request is validated (ignores content-type).

Syntax: RF_SF_SoapValidator ‘on’|‘off’|‘xml’

Default is off. Log is currently not supported (same effect as off).

Inheritance: Configuration is not merged to sub locations.

RF_SF_SoapValidatorResponse

Location

Enables soap response validation for the location. Every response ist validated (ignores content-type).

Syntax: RF_SF_SoapValidatorResponse ‘on’|‘off’|‘xml’

Default is off. Log is currently not supported (same effect as off).

Inheritance: Configuration is not merged to sub locations.

RF_SF_NoNsLocFile

Location

Defines Schemas used for XML-Validation. Multiple Schemas may be defined within a location to match incoming XML-(POST-)data. Validation will be done in the defined sequence (ascending). If no Schema file matches the incomming data, HTTP RC 500 will be returned to the client, resp. 302 to 500 for response validation

Syntax: RF_SF_NoNsLocFile <xml name space>

Default is none

Inheritance: Configuration is not merged to sub locations.

RF_SF_SoapVersion

Location

Defines the allowed soap versions. You may specify multiple versions for a location.

Syntax: RF_SF_SoapVersion ‘soap11’|‘soap12’

Default is none

Inheritance: Configuration is not merged to sub locations.

RF_SF_AllowService

Location

Defines the allowed actions for an application name space defined by RF_SF_DefineApplication. Use ‘*’ for the SOAP operation name in order to allow any operation within the name space.

Syntax: RF_SF_AllowService <alias> <operation>

Inheritance: Configuration is not merged to sub locations.

Note: see AC_AllowSoapMethod directive about per user authorization settings.

RF_SF_ReqParameterNameValidation

Location

Enables parameter name validation. Only parameter names defined by the wsdl are allowed for a specific method if enabled. This directive MUST be used together with the "RF_SF_DefineApplication" and "RF_SF_AllowService" directive

Syntax: RF_SF_ReqParameterNameValidation ‘on’|‘off’

Default is off (any parameter name is allowed even it has not been defined by the wsdl).

Inheritance: Configuration is not merged to sub locations.

RF_SF_ExclContentDisp

Location

Excludes specific Content-Dispositions (by "name"-attribute) in a Multipart request from (XML-)validation

Syntax: RF_SF_ExclContentDisp <n>

Example: "RF_SF_ExclContentDisp integrity_customers"

This excludes multiparts with the (Header)

Content-Disposition: form-data; name="integrity_customers"

RF_SF_ParameterPermit

Location

Allows to define a set of whitelisted element or attribute nodes in a message. "name" defines the element or attribute (in XPath syntax) whose assigned value(s) must match the "regular expression". Use the "+" prefix to add additional elements/attributes to the set or the "-" prefix to remove it. Without a prefix, a new list is created for the corresponding location.

Action "log" only logs the exception, while "deny" forces to return of the HTTP status code 403 (Forbidden) if the exception does not match.

A whitelist is merged to sub locations.

Syntax: RF_SF_ParameterPermit [+|-]<name> [log|deny] <regular expression>

Example: RF_SF_ParameterPermit /method/name deny "\^example.permittedMethod\$"

RF_SF_ParameterDeny

Location

Counterpart to RF_SF_ParameterPermit which allows to define a set of blacklisted element or attribute nodes. The value of the defined element or attribute must not match the "regular expression".

Action "log" only logs the prohibition, while "deny" forces to return of the HTTP status code 403 (Forbidden) if the prohibition applies.

Syntax: RF_SF_ParameterDeny [+|-]<name> [log|deny] <regular expression>

Example: RF_SF_ParameterDeny /method/name deny "\^example.deniedMethod\$"

RF_SF_MaxRecursionLevel

Location

Defines the maximum recursion of XML Elements in a message to prevent DOS attacks.

Syntax: RF_SF_MaxRecursionLevel <n>

Default is 40

Inheritance: Configuration is merged to sub locations.

RF_HdrValidatorRule

Virtual

Server or Location

Defines a validation rule using regular expressions. The regular expression string may include other rules using variables surrounded by "${" and "}".

Syntax: RF_HdrValidatorRule <name> <regex_string>

Inheritance: Global per server configuration can be used within locations to build new rules or can be overwritten by local rules.

A set of default rules are included with the HSP packages. Uses these rules (or a subset of) to enforce RFC compliance.

RF_SrvReqHdrValidate

Virtual

Server

Defines rules and actions for incoming (request) headers on a per server basis.

Syntax: RF_SrvReqHdrValidate <header name> <action[‘|’<action>]> <rule>

RF_SrvResHdrValidate

Virtual

Server

Defines rules and actions for outgoing (response) headers on a per server basis.

Syntax: RF_SrvResHdrValidate <header name> <action[‘|’<action>]> <rule>

RF_LocReqHdrValidate

Location

Same function as the directive RF_SrvReqHdrValidate but on a per location basis.

RF_HdrValidatorDebug

Virtual

Server or Location

Iterates through all RF_HdrValidatorRule directives within the server configuration, resolves and compiles the rules. An error message is written to stderr when a rule can not be verified correctly. Use this command once when defining new rules before adding validation directives like RF_SrvReqHdrValidate or RF_SrvResHdrValidate.

RF_UE_MatchParser

Environment Variable

This environment variable enables the match parser for URL encryption.

Syntax: RF_UE_MatchParser="[path] [query]"

Example: SetEnvIf Content-Type "application/x-javascript" RF_UE_MatchParser=path

RF_UE_InlineMatchParser

Environment Variable

This environment variable enables the inline match parser for URL encryption. With the value "match-parser-only" the JavaScript parser for inline JavaScripts is deactivated.

Syntax: RF_UE_InlineMatchParser=match-parser-only | on

Example: SetEnvIf Content-Type "text/html" RF_UE_InlineMatchparsre=match-parser-only

RF_MatchParserRegex

Location

Defines one or more pattern for URL encryption.

Syntax: RF_MatchParserRegex "<regex>"

Example: RF_MatchParserRegex “(\'[^\']*\')”

RF_MatchParserWhitelist

Location

Defines a whitelist for the found patterns.

Syntax: RF_MatchParserWhitelist “<regex>”

Example: RF_MatchParserWhitelist “http://.*” “/.*”

RF_MatchParserBlacklist

Location

Defines a blacklist for the found patterns.

Syntax: RF_MatchParserBlacklist “<regex>”

Example: RF_MatchParserBlacklist “uEtTr.*\$\$~UuE”

HGW_ClientRestrictionMaxRequestRate

Virtual Server

Activate the ClientRestriction rules with the given number of requests per a given time. With this filter it is possible to limit the number of requests a client is allowed to make for a given time.

There are two possible actions if the limit is reached either all requests after the limit get dopped and a message is written to the log or only a message is written to the log file.

Syntax: HGW_ClientRestrictionMaxRequestRate <REQUESTS> <TIME> <ACTION>

Example: HGW_ClientRestrictionMaxRequestRate 1000 60 DROP

This example allows 1000 requests within a minute for each client. If a client requests more pages within one minute, surplus requests get dropped.

HGW_ClientRestrictionIdentityHeader

Virtual Server

Define a header name that is used to identify a client. This is required if clients can not be identified by their IP address, e.g. when using a load balancer. If this directive is not set, clients are identified by IP address.

Syntax: HGW_ClientRestrictionIdentityHeader <HEADER>

Example: HGW_ClientRestrictionIdentityHeader FAKEID

This searches for a header with name FAKEID and uses its value to identify the corresponding client.

HGW_ClientRestrictionExceptionRequestRate

Virtual Server

This directive allows setting special rules for defined clients. This overwrites the values defined with the HGW_ClientRestrictionMaxRequestsRate.

Syntax: HGW_ClientRestrictionExceptionRequestRate <ID> <REQUESTS> <ACTION>

Example: HGW_ClientRestrictionExceptionRequestRate 192.168.1.10 777 LOG

With the given example directive the client "192.168.1.10" is allowed to access 777 times instead of the global defined value and if her reaches this limit the client will not be dropped instead only a log message will be written.

ICAP

The ICAP filter module is explained in more detail in section "ICAP Request and Response Modification". Some additional directives are only available in the SRManager, see section "Table 26: SRManager - Request Filter Directives".

ICAP_Host

Location

Defines the server name and port ("host:port") to send the ICAP request to. In connection with failover, several hosts can be defined by using this directive multiple times.

Syntax: ICAP_Host REQMOD|RESPMOD <host>:<port> <service>

Example: "REQMOD 127.0.0.1:4488 /av"

Note: To enable ICAP the Environment Variable ICAP_REQMODE resp. ICAP_RESMOD must be set to "ON".

Example: SetEnvIf Request_URI "/path/location" ICAP_REQMOD=ON

ICAP_ConnectTimeOut

Location

Within this time, a configured server must accept the connection. If it is a SSL connection, the socket must not be Idle more than the specified time during the SSL Handshake. If the socket for the SSL handshakes timeouts within this time, a OpenSSL syscall error is returned.

Syntax: ICAP_ConnectTimeOut REQMOD|RESPMOD <seconds> Default value is 10 (seconds).

ICAP_TimeOut

Location

Specifies timeout for ICAP requests and responses.

Syntax: ICAP_TimeOut REQMOD|RESPMOD <seconds> Default value is 120 (seconds).

ICAP_EnableSSLServerCert

Location

Use SSL (Version 3) when connecting to the server and ensure that the presented server certificate is signed by the configured Certification Authority ("CA=<PEMfile>"). Optionally, verify that the server certificate’s common name corresponds to the configured values ("CN='servername'"). Multiple "CN='servername\' are supported.

In order to allow any server certificate, configure the special value "ALLOW_ALL".

Syntax: ICAP_EnableSSLServerCert REQMOD|RESPMOD (<ca file>\ <cn>*) | ALLOW_ALL*

Example 1: REQMOD ALLOW_ALL

Example 2: RESPMOD CA=/opt/allowed/ca1.PEM CN=‘devhost.org.com’

Example 3: REQMOD CA=/opt/allowed/ca1.PEM CN=‘devhost.org.com’ CN=‘other.org.com’

ICAP_ClientCert

Location

Use the configured client certificate and private key ("CERT=<PEMfile> PKEY=<PEMfile>") for SSL client authentication if requested by the server.

Syntax: ICAP_ClientCert REQMOD|RESPMOD CERT=<cert-file> PKEY=<private key file>

Example: REQMOD CERT=/opt/cert/client/client.PEM PKEY=/opt/pkey/client/clientkey.PEM

The private key must not be password protected.

ICAP_ErrorPage

Location

Set error pages to map ICAP errors to.

Syntax: ICAP_ErrorPage REQMOD|RESPMOD <status-code> <path-to-error-page>

Example: REQMOD 500 /srm-error-pages/500.shtml

ICAP_ReqActionIf

Location

This directive defines a conditional action based on and embedded http headers and environment variables for REQMOD.

Syntax: ICAP_ReqActionIf <conditions> <actions> [<info>]

conditions: <element>"&&"<element>

element: icap.status|icap.<header>|

icap.http.res.status|icap.http.res.<header>|

icap.http.req.line|icap.http.req.<header>|<env-var>

["=~"|"!~"|"=="|"!="] <regex>

actions: log|declined|error|bad|forbidden|ok|[!]<env-var>[=<value>]

Example: ICAP_ReqActionIf icap.status=~200&&icap.http.res.status=~403&&icap.http.res.x-virus==detected forbidden|log "Virus detected"

ICAP_ResActionIf

Location

This directive defines a conditional action based on ICAP and embedded http headers and environment variables for RESPMOD.

Syntax: ICAP_ResActionIf <conditions> <actions> [<info>]

conditions: <element>"&&"<element>

element: icap.status|icap.<header>|

icap.http.res.status|icap.http.res.<header>|

icap.http.req.line|icap.http.req.<header>|<env-var>

["=~"|"!~"|"=="|"!="] <regex>

actions: log|declined|error|bad|forbidden|ok|[!]<env-var>[=<value>]

Example: ICAP_ResActionIf icap.status=~200&&icap.http.res.status=~403&&icap.http.res.x-virus==detected forbidden|log "Virus detected"

ICAP_SMFileAndSize

Global

Optional directive that specifies the semaphore file path for shared memory. If defined, it is used e.g. for caching ICAP OPTIONS response headers (performance improvement). Should be located in the Surrender's "logs" directory. The file name is suffixed by the process id of the server main process. The memory size in bytes must be specified in brackets. See also section "Client Data Store Settings".

Example: ICAP_SMFileAndSize /var/SRManager/logs/icap_shmht_lk(67108864)

Default size is 1024kB

ICAP_DefaultOptionsTTL

Location

This directive defines the Options-TTL to use if the ICAP server does not return an Options-TTL header.

Syntax: ICAP_DefaultOptionsTTL <seconds>

Example: ICAP_DefaultOptionsTTL 86400

Default value is 3600 seconds (1 hour)

ICAP_HideHeader

Location

This directive defines a header not to send to the ICAP server if the given regex matches the header value.

Syntax: ICAP_HideHeaderREQMOD|RESPMOD <header> <regex>

Example: ICAP_HideHeader RESPMOD referer .*

ICAP_FO_Enable

Location

This directive enables ICAP failover. Unless stickiness is defined with other directives, hosts are tried round robin and given a penalty count if they do not respond.

Syntax: ICAP_FO_Enable REQMOD|RESPMOD on|off

Example: ICAP_FO_Enable RESPMOD on

ICAP_FO_Penalty

Location

This directive defines the penalty count that is set on an unresponsive host (default is 10). Hosts with a penalty are skipped in round robin for the number of times set as penalty.

Syntax: ICAP_FO_Penalty REQMOD|RESPMOD <penalty>

Example: ICAP_FO_Penalty RESPMOD 20

ICAP_FO_SoftSticky

Location

This directive defines the soft sticky host (first host has index 0). Requests go first to the soft sticky host unless it has a penalty.

Syntax: ICAP_FO_SoftSticky REQMOD|RESPMOD <host index>

Example: ICAP_FO_SoftSticky REQMOD 2

ICAP_FO_SyncReqRespmod

Location

This directive defines that REQMOD and RESPMOD requests go to the failover host with the same index. Requires that the same number of ICAP hosts are defined for REQMOD and RESPMOD, as well as the same connect timeout, and that all other ICAP failover settings are identical for REQMOD and RESPMOD.

Syntax: ICAP_FO_SyncReqRespmod on|off

Example: ICAP_FO_SynReqRespmod on

ICAP_FO_SMFileAndSize

Global

Specifies the semaphore file path for shared memory. Should be located in the Surrender's "logs" directory. The file name is suffixed by the process id of the server main process. The memory size in bytes must be specified in brackets. See also section "Client Data Store Settings".

To take effect a restart is needed. Graceful restart will not be sufficient to activate this setting.

Example: ICAP_FO_SMFileAndSize /var/SRManager/logs/icap_fo_shmht_lk(67108864)

Default size is 1024kB

HGW_Host

Location

Defines the hostname (or IP address) and port of the SRManager virtual host to which the incoming request should be passed.

When using a hostname, the name must be the same as the value of the "ServerName" directive defined in the corresponding virtual host configuration of the SRManager. When using an IPv6 address, the address must be enclosed in square brackets.

Syntax: HGW_Host <host>:<port>

Example: "127.0.0.1:4488"

Example: "[::1]:4488"

HGW_KeepAsRedirectScheme

Location

Specifies whether the scheme of the location header on backend redirections is kept or not. Per default, the URI scheme is rewritten to the scheme of the received request.

Syntax: HGW_KeepAsRedirectScheme On|Off

Default: Off

Example: HGW_KeepAsRedirectScheme On

HGW_RequestHeaders

Location

A list of HTTP headers that are passed to the application server. Headers not in this list are stripped from the request.

Entries starting with ‘%’ are replaced with all headers defined for this alias. See directive "HGW_ShowAliases". Entries starting with ‘-’ are removed from the list, entries prefixed with ‘+’ are added.

In addition, wildcards for header names can be specified, e.g. with “Foo*” all headers starting with the substring “Foo” are let through. A single star “*” allows to pass all headers to the back-end. In conjunction with wildcards single headers can be excluded with a preceding exclamation mark, e.g. !Foo2 ensures that the header Foo2 is withheld even though wildcards exists.

Inheritance: Configuration values are merged to sub-locations. ‘+’ adds and ‘-’ removes headers from the merged configuration. If any of the values are not prefixed by ‘+’ or ‘-’, the settings of the current location overrides the setting of the parent location.

Syntax: HGW_RequestHeaders ['+'|'-'] (('%'<Alias>|<Headers>['*'])* | *) | !<Header>

Example: %HTTP11_std -Referer !UserLoginData +Foo*

HGW_ServerRequestHeaderEntryDeny

Virtual Server

Restrict HTTP header entries to application server.

Header entries denied by this directive are removed from the incoming request.

Syntax: HGW_ServerRequestHeaderEntryDeny <header> ([“+”|“-”] <entry>)*

Inheritance: Merges the deny input header entry list. ‘+’ and ‘-’ adds and removes header entries. If no ‘-’ or ‘+’ is preceding the header entry name a new list is started (no merge)

Example: HGW_ServerRequestHeaderEntryDeny Accept-Encoding +gzip +compress

HGW_LocationRequestHeaderEntryDeny

Location

The same behavior like HGW_ServerRequestHeaderEntryDeny.

HGW_Allow401

Location

A value of "On" disables the default behavior of mapping an HTTP response code of 401 (Not Authorized) from the server to the code 500 (Server Error). A value of "RC=<n>" also avoids a server error, but changes the response code to the value <n> (allowed range is 200..599).

Example: "HGW_Allow401 RC=403"

HGW_AllowCustomStatusLine

Location

Sometimes, an application server uses a non standard HTTP response line with a response code in defined by RFC2616. Such a response line get replaces by a "500 Internal Server Error" response line by default. You may allow any response codes using this directive.

Syntax: HGW_AllowCustomStatusLine ‘on’|‘off’

HGW_EnableSSLServerCert

Location

Not available in the HttpsListener

HGW_ClientCert

Location

Not available in the HttpsListener

HGW_SSLHeaders

Location

A list of (SES internal) SSL headers which are generated by the HttpsListener (Valid header names are listed in section "Sample Configuration Files")

HTTPS headers not contained in this list will not be set.

Aliases can be used, see directive “HGW_ShowAliases”).

HGW_SSLFingerprintDigest

Location

Specifies the message-digest-algorithm the SSLFingerprint header will be computed with. For a list of supported algorithms, refer to the OpenSSL documentation or invoke the system command 'openssl list-message-digest-algorithms\'

Syntax: HGW_SSLFingerprintDigest md5|sha1|sha256|…

Example: HGW_SSLFingerprintDigest sha1

Default: md5

HGW_ShowAliases

Global

Show all available header group alias definitions and exit. The following command prints all definitions to stdout:

%> bin/httpdctl start -args -C HGW_ShowAliases

HGW_Strict100Continue

Location

"On" specifies, that the Http(s)Listener passes a HTTP "Expect: 100-continue" message to the server (SRManager) and does not send a "100 Continue" response the client itself. If "Off" has been specified, the Http(s)Listener answer by a "100 Continue" response itself and suppress the message from the SRManager.

Default is "on".

HGW_OutConnectionExpiry

Location

Controls reuse of outgoing HTTP connections (HTTP Keep-Alive). Syntax:

HGW_OutConnectionExpiry [timeout=<secs>] [ttl=<secs>] [maxrequests=<n>]

timeout specifies the maximum time in seconds after which an idle outgoing conntion is reused. This value is the counter-part of the Apache Timeout directive.

ttl specifies the life time of the connection. If the connect is older than this value, it is not reused for new requests.

maxrequests specifies the maximum number of request to perform on a outgoing connection.

Default values are: timeout=10 ttl=30 maxrequests=300

HGW_DNSPolicy

Virtual Server

Controls DNS lookup policy. Syntax: HGW_DNSPolicy “Startup”|“Request”

For HttpsListener, this value should be left to the default (Startup). See SRManager commands for more details.

Default is value is Startup

HGW_ConnectTimeOut

Location

Within this time a configured server must accept the connection. For SSL connections see the additional directive HGW_SSLConnectTimeOut.

Syntax: HGW_ConnectTimeOut <seconds> If Failover is enabled, HGW may try to connect multiple servers within this time.

See "6.16 Fail-Over and Load-Balancing Configuration" for Details.

Default value is 10 (seconds).

HGW_TimeOut

Location

Specifies timeout for requests and responses.

Syntax: HGW_TimeOut <seconds> Depending on failover settings, the request may be retried on a different server when this time-out is reached. See "6.16 Fail-Over and Load-Balancing Configuration" for Details.

Overrides the Apache "Timeout" directive.

Default value: Value set by "Timeout" directive.

HGW_RequestBodyBuffer

Location

Sets the buffer size for forwarding request bodies from client to application servers. Syntax: HGW_RequestBodyBuffer <bytes>

For HttpsListener, this value should be left to the default. Default value is 8192 (i.e. 8 KB). Maximum allowed value is 209715200 (i.e. 200 MB).

HGW_ResponseBodyBuffer

Location

Sets the buffer size for forwarding response bodies from application servers to client. Syntax: HGW_ResponseBodyBuffer <bytes>

For HttpsListener, this value should be left to the default.

Default value is 8192 (i.e. 8 KB). Maximum allowed value is 52428800 (i.e. 50 MB).

HGW_ResponseBodyImmediateFlush

Location

Forces immediate data flush when the HGW_ResponseBodyBuffer bytes have been received.

Syntax: HGW_ResponseBodyImmediateFlush on|off

Default is off, the Apache default (SendBufferSize) buffer size is used to determine when the data is sent to the client.

HGW_TransparentContentType

Location

Sets the HSP to content transparent mode handling. If an application server does not set a Content-Type the default behavior is that the apache does set a configured Content-Type. With this directive the apache does also not set a Content-Type

Syntax: HGW_TransparentContentType "On" | "Off"

Default is Off

HGW_ResponseBodyNonBlocking

Location

If this directive is set to "on", HSP reads the response from the application server in non-blocking mode. This directive is required for OAW application integration. This directive only makes sense in combination with "HGW_ResponseBodyImmediateFlush on".

Syntax: HGW_ResponseBodyNonBlocking "On" | "Off"

Default is Off

HGW_RequestBodyNonBlocking

Location

If this directive is set to "on", HSP reads the request from the client in non-blocking mode and will send it immediately to the application server.

Syntax:HGW_RequestBodyNonBlocking "On" | "Off"

Default is Off

HGW_ChunkedBuffering

Location

If this directive is set to "off", HSP does not cache the received data from the application but will send it immediately to the client. Buffering is required if using AAI and body data is needed. The default buffer size is 8192 Bytes.

Syntax: HGW_ChunkedBuffering Off

Default is On

SGW_Host

Virtual Server

Enables SSL Gateway by defining the hostname (or IP address) and port of the SRManager virtual host where the incoming SSL traffic should be streamed to. When using an IPv6 address, the address must be enclosed in square brackets.

Syntax: SGW_Host <host>:<port>

Example: "127.0.0.1:4488"

Example: "[::1]:4488"

Default: No default

SGW_ConnectTimeOut

Location

Within this time, a configured server must accept the connection.

Syntax: SGW_ConnectTimeOut <seconds> If Fail-Over is enabled, HGW may try to connect multiple servers within this time.

See "6.16 Fail-Over and Load-Balancing Configuration" for Details.

Default value is 10 (seconds).

SGW_TimeOut

Virtual Server

Specifies idle timeout for the SGW connection.

Syntax: SGW_TimeOut <seconds> | OFF Default value: 3600 seconds

SGW_FinalTimeOut

Virtual Server

Specifies the overall timeout for the SGW connection. If set to 0 means no final timeout.

Syntax: SGW_FinalTimeOut<seconds>

Default on final timeout is set

SGW_SSLServerCert

Virtual Server

Ensure that the presented server certificate is signed by the configured Certification Authority ("CA=<PEMfile>").

In order to allow any server certificate, configure the special value "ALLOW_ALL".

Syntax: SGW_SSLServerCert ALLOW_ALL | CA=<PEMfile> Examples: "ALLOW_ALL", "CA=/opt/allowed/ca1.PEM"

Default: is ALLOW_ALL

RPC_Activate

Virtual Server

Activates RPC protocol detection over SSL Gateway.

Syntax: RPC_Activate on|off

Example: "on"

Default: off

LGW_LuaScript

Virtual

Server

This directive enables a lua script on specified place. With these scripts you can write an own protocol handler in Lua. This is useful, if i.e. citrix protocol do have changes, which our statical implementation can not handle.

Syntax: LGW_LuaScript Pre | Resolve | Post <script-path>

Default is no Lua script at all.

HSP_DosActivate

Server

Possibility to deactivate/activate DoS protection.

Syntax: HSP_DosActivate on|off

Default is on

HSP_KeepAliveTimeoutShort

Server

Reduces the keep-alive timeout of connections to <n> seconds once server (connection) load passes HSP_KeepAliveTimeoutShortThreshold %.

By setting shorter keep-alive timeouts, server connection resources are freed earlier and server overload risk is reduced.

Syntax: HSP_KeepAliveTimeoutShort <n>

Example: "HSP_KeepAliveTimeoutShort 5"

Default timeout for keep-alive when system in under load is 3 seconds.

HSP_KeepAliveTimeoutShortThreshold

Server

Threshold to be reached by system connection load to enable HSP_KeepAliveTimeoutShort.

Syntax: HSP_KeepAliveTimeoutShortThreshold <n>

Example: "HSP_KeepAliveTimeoutShortThreshold 75"

Default threshold to set keep-alive timeout to HSP_KeepAliveTimeoutShort is 70%.

Note: Some Microsoft Internet Explorers need a keep-alive timeout of at least 65 seconds to work ‘properly’. Therefore, for affected IEs, HSP_KeepAliveTimeoutShortThreshold sould be set to the same value as HSP_KeepAliveOffThreshold using the Apache BrowserMatch directive.

HSP_KeepAliveOffThreshold

Server

Threshold to be reached by system connection load to disable keep-alive on client connections.

Syntax: HSP_KeepAliveOffThreshold <n>

Example: "HSP_KeepAliveOffThreshold 90"

Default threshold to disable keep-alive is 85%.

HSP_WebSocketLoadLimit

Location

Limitation of connections used for web sockets. Connection upgrades to web sockets will be refused with an Internal Server Error 500 if the number of open web sockets have reached the configured limit. Limit is the percentage (1..100) of the total available server connections. Syntax: HSP_WebSocketLoadLimit <percentage> Default is 70 percent for WebSocket locations, otherwise, the directive is not set.

ProxyWebsocketIdleTimeout

Global, Virtual Server

Imposes a maximum amount of time (in seconds) for the tunnel to be left open while idle. Syntax: ProxyWebsocketIdleTimeout <s> Per default no timeout is set.

Some modules (QS_*, RF_Form*, HGW_TranslateParameters* directives) processing the request body and request line query data used the generic parameter parser module mod_parp. This module features some built-in parameter which may be adjusted using the following directives.

PARP_ExitOnError

Virtual Server

Defines the action to take in case of a parser error (parser can’t process the input data). Default is a HTTP 500 server response but you may define the status code 200 to ignore errors.

Syntax: PARP_ExitOnError <HTTP response code>

Default: 500

PARP_BodyData

Virtual Server

Allows you to enable raw body processing for additional content types.

Syntax: PARP_BodyData <content type>

mod_analyze

Env Variable

To activate request line and headers tracing, this environment variable must be set as well as the trace log file (to define with DBG_TraceLog) .

Example: SetEnvIf Request_URI "/test" mod_analyze

mod_analyze_body

Env Variable

If this environment variable is set request and response bodies are shown in the trace log.

Example: SetEnvIf Request_URI "/test" mod_analyze_body

DBG_TraceAllowBody

Global

Virtual Server

If this is set to "on" body recording is allowed. Note, in addition the environment variable mod_analyze_body must be set as well to activate body tracing.

Syntax: DBG_TraceAllowBody on|off

Example: DBG_TraceAllowBody on

DBG_TraceAllContentTypes

Global

Virtual Server

In conjunction with body tracing this directive allows to enable all content types.

Default is off, meaning that only bodies with content types"text/plain" and "text/html" are traced.

Syntax: DBG_TraceAllContentTypes On|Off

DBG_TraceLog

Virtual Server

This directive defines the file to write the captured data to.

Syntax: DBG_TraceLog <path>

Example: "/opt/usp/hsp/hts/logs/trace"

DBG_TraceControl

Global

Defines the parameter input file for DBG_TraceLog. If present, TraceLogging is enabled.

Syntax: DBG_TraceControl <file>

Control File do have multiple lines of rules:

[path=<path>] [srcip=<ip>] [cc=<string>] [tracebody=on|off]

All elements in a line are optional and are AND combined.

All lines are OR combined.

DBG_TraceCtlRefreshTime

Virtual Server

Sets the refresh time (in seconds) to update/re-read the TraceControl file.

Syntax: DBG_TraceCtlRefreshTime <seconds>

DBG_TraceDropHeader

Virtual Server, Location

If this directive is activated, all headers and cookies which are silently dropped, are logged in the error log.

Syntax: DBG_TraceDropHeader On|Off

Example DBG_TraceDropHeader On

Default: "Off"

MaxMindDBEnable

Global, Virtual Server, Location

This directive enables or disables MaxMind DB lookup.

Syntax: MaxMindDBEnable On|Off

Example:

MaxMindDBEnable On

Default: Off

MaxMindDBFile

Global, Virtual Server, Location

This directive associates a name placeholder with a MaxMind DB file on the disk. You may specify multiple databases, each with its own name.

Syntax: MaxMindDBFile <name> <path>

Example:

MaxMindDBFile DB /var/lib/usp/data/geoip/GeoIP.mmdb

MaxMindDBEnv

Global, Virtual Server, Location

This directive assigns the lookup result to an environment variable. The first parameter after the directive is the environment variable. The second parameter is the name of the database followed by the path to the desired data using map keys or 0-based array indexes separated by /.

Syntax: MaxMindDBEnv <varname> <name>/<path>

Example:

MaxMindDBFile DB /var/lib/usp/data/geoip/GeoIP.mmdb

MaxMindDBEnv GEOIP_CITY DB/city/names/en

GeoIP_Location_Blocking

Global, Virtual Server, Location

This directive exists to enable or disable the request blocking based on the client’s GeoIP location.

Syntax: GeoIP_Location_Blocking On|Off

Example:

GeoIP_Location_Blocking On

Default: Off

Request blocking based on the client’s GeoIP location can be overwritten by setting the subprocess environment variable GeoIP_Location_Blocking_Override. E.g. to prevent blocking of requests from local networks (as defined in RFC1918) you could add the following setting:

SetEnvIfExpr "-R '10.0.0.0/8' || -R '172.16.0.0/12' || -R '192.168.0.0/16'" GeoIP_Location_Blocking_Override

GeoIP_Location_Blacklist

Global, Virtual Server, Location

This directive defines a list of block values that the specified variable varname is checked for. If the specified varname is set to one of the configured block values, the request will be blocked. The directive has no effect unless GeoIP_Location_Blocking is set to On in the same configuration context (global, virtual server, configuration).

Syntax: GeoIP_Location_Blacklist <varname> <block value> [<block value> …]

This directive can not be combined with GeoIP_Location_Whitelist on the same configuration level. Setting this directive replaces any inherited settings of GeoIP_Location_Blacklist or GeoIP_Location_Whitelist.

GeoIP_Location_Whitelist

Global, Virtual Server, Location

This directive defines a list of allow values that the specified variable varname is checked for. The specified varname must be set to one of the configured allow values, otherwise the request will be blocked. The directive has no effect unless GeoIP_Location_Blocking is set to On in the same configuration context (global, virtual server, configuration).

Syntax: GeoIP_Location_Whitelist <varname> <allow value> [<allow value> …]

This directive can not be combined with GeoIP_Location_Blacklist on the same configuration level. Setting this directive replaces any inherited settings of GeoIP_Location_Blacklist or GeoIP_Location_Whitelist.

GeoIP_Location_BlockUnclassified

Global, Virtual Server, Location

If this directive is set to On, a request will be blocked if the specified variable varname is unset (read: the GeoIP lookup yielded no result). This directive has no effect unless GeoIP_Location_Blocking is set to On in the same configuration context (global, virtual server, location).

Syntax: GeoIP_Location_BlockUnclassified <varname> On|Off

Default: Off

GeoIP_Anonymous_Blocking

Global, Virtual Server, Location

This directive exists to enable or disable the anonymous IP blocking.

Syntax: GeoIP_Anonymous_Blocking On|Off

Default: Off

Request blocking based on the used anonymous IP informationcan be overwritten by setting the subprocess environment variable GeoIP_Anonymous_Blocking_Override. E.g. to prevent blocking of requests from local networks (as defined in RFC1918) you could add the following setting:

SetEnvIfExpr "-R '10.0.0.0/8' || -R '172.16.0.0/12' || -R '192.168.0.0/16'" GeoIP_Anonymous_Blocking_Override

GeoIP_Anonymous_Vars

Global, Virtual Server, Location

This directive defines the anonymization service types to block. If the specified varname is set to "1", the request will be blocked. This directive has no effect unless GeoIP_Anonymous_Blocking is set to On in the same configuration context (global, virtual server, location). Setting this directive replaces setting of GeoIP_Anonymous_Vars inherited from other configuration contexts.

Syntax: GeoIP_Anonymous_Vars <varname> [<varname> …]

HSP_AppId

Location

Defines the application identifier which is used for recording and send to Login Services. Must not contain "\&" or ":" Ensure to create a subdirectory in the directory defined by "REC_DestDir"for every "HSP_AppId"parameter value you have specified. Syntax: HSP_AppId <app_id>

Example: HSP_AppId SampleApp

Default is none.

HSP_HostIdPath

Global

Defines the file containing the HSP host identifier. The HSP identifier is used as a unique identifier for all components located on this host. This identifier is used for logging and correlation.

Syntax: HSP_HostIdPath <pathname>

Default is /etc/usp/hsp/hostid.

Example: HSP_HostIdPath /etc/usp/hsp/hostid

The system’s host id (gethostid(3C)) is used as the default value if no such file is specified or has not been found.

HSP_InstanceId

Global

Defines the server instance identifier. The HSP identifier is used by all components as a unique instance identifier for request and client correlation.

Syntax: HSP_InstanceId <string>

Example: HSP_InstanceId srm

Default is the parent process PID.

HSP_CorrelatorTEST

Global

If specified, an internal test is started before the component is started up. Should not be used in production.

Sxntax: HSP_CorrelatorTEST

HSP_TraceModules

Global

Enables tracing for the specified modules and events. Syntax: HSP_TraceModules <module:flags> …

where module can be one of the following:

flags is a bitset consiting of the following flags:

Do not use in productive systems.

Example:

HSP_TraceModules mod_secure_request_manager_gateway:0cff

HSP_TraceMagicValue

Global

Set the flag which is set for all the modules if HSP_TraceMagic is set to all. The default value is 0xffff. The usage of the flags is described within HSP_TraceModules.

HSP_TraceMagic

Global

Enables selective tracing of clients sending a cookie with a "magic" value. The magic value is used within the log files to identify the trace messages. Syntax: HSP_TraceMagic <value>

<value> must be one of the following values.

The client needs to send a Cookie with the following format:

HSP_TraceMagic=<magic>

The value <magic> is used to identify the client within the log files.

HSP_TraceOptions

Global

Controls tracing.

Syntax: HSP_TraceOptions <option>,<option>,….

where option can be one of the following:

HSP_ClientHost

Virtual Host

This directive should be used in the listeners only, see there for details.

HSP_Chroot

Global

Implements a chrooted server. Does usually not require any configuration or environment changes (exceptions are configurations which open new files a runtime).

Syntax: HSP_Chroot <path>

HSP_AbsoluteRedirects

Virtual Server

Controls generating absolute redirects. "Off" means, that relative (no host name) redirects are sent to the client, "on" means that absolute (including schema and host name) redirects are sent to the client, e.g. for the cookie check.

Can also been set using the ‘BrowserMatch’ directive.

Syntax: HSP_AbsoluteRedirects on|off

Default: off

HSP_DeflateRequestBody

Environment Variable

Activate input filter for deflating request body before any validator or body rewriter module

Syntax: SetEnvIf <attribute> <regex> HSP_DeflateRequestBody

Example: SetEnvIf Content-Encoding "gzip" HSP_DeflateRequestBody

HSP_AllowCache

Virtual Server

Allow mod cache functionality.

Syntax: HSP_AllowCache on|off

Example: HSP_AllowCache on

Default: off

HSP_RedirectMatch

Virtual Host

Directive works similar to RedirectMatch of mod_alias but allows to use additional variables within the destination URL. If the ‘keep-query’ flag is specified, query parameters from the original request are preserved also if query parameters are specified in the redirect target ‘url’.

Variables:

Syntax: HSP_RedirectMatch <regex> <url> [keep-query]

Example: HSP_RedirectMatch /(.*) https://$SERVERNAME/$1 keep-query

HSP_SetEnvEncryptStatic

Virtual Host, Location

Encrypts the value of the environment variable ‘env-var-in’ using the static passphrase (no random) and stores its value in the ‘env-var-out’ variable. The encrypted value is base64 encoded.

Syntax: HSP_SetEnvEncryptStatic <env-var-in> <env-var-out> <passphrase>

HSP_DoubleSlashRedirects

Virtual Host

When a redirect response is genereated with a target location starting with "double slashs" (absolute URL without protocoll identifier) HSP will reduce the target to a single slash if not disabled.

Syntax: HSP_DoubleSlashRedirects on|off

Default is "on".

HSP_DoubleSlashRedirects_Exclude

Virtual Host

This directive allows to define target hosts for which redirect URLs without protocoll identifier should be allowed without disabling the whole feature. A List of known-good-host can be specified as regex.

Syntax: HSP_DoubleSlashRedirects_Exclude <regex>

Example: HSP_DoubleSlashRedirects_Exclude "www\.trusted\.org"

RC_MaxPostSize

Location

Maximum number of bytes allowed to be transferred to the server. Syntax: RC_MaxPostSize <bytes>

Default is "49152"

RC_MaxResponseSize

Location

Maximum number of bytes allowed to be transferred to the server. Syntax: RC_MaxResponseSize <bytes>

Default is no limitation

RF_ServerAllowMethod

Virtual Server

Restricts the allowed HTTP method for the virtual server. Methods not explicitly defined by this directive are denied and result in a "405 Method Not Allowed" response. Multiple methods may be specified for each server configuration. Use the "+" prefix to allow a method and the "-" prefix to deny the specified method.

Syntax: RF_ServerAllowMethod "+"|"-"<method>

Example: RF_ServerAllowMethod -POST +PUT

Default is "+GET +HEAD +POST"

RF_LocationAllowMethod

Location

Restricts the allowed HTTP method for the location. This directive takes only effect if it has explicitly defined for a location. This filter is applied after the method filter defined by RF_ServerAllowMethod. Methods denied by RF_ServerAllowMethod can’t be allowed by this command.

Methods excluded by this directive are denied and result in a "405 Method Not Allowed" response. Multiple methods may be specified for each server configuration. Use the "+" prefix to allow a method and the "-" prefix to deny the specified method.

Syntax: RF_LocationAllowMethod "+"|"-"<method>

Inheritance: Merges the per location configuration values. ‘+’ and ‘-’ adds and removes method from the current location configuration.

Example:

RF_LocationAllowMethod -POST

Default is "+GET +HEAD +POST"

RF_UE_EncodeUrl

Location

Enables URL encryption for the defined location. Supported URL types are:

URL encryption is applied to the "Location" header and to URL references within the response body. The Set-Cookie header is not encrypted but the "path" of each cookie is set to "/".

Requests to locations where RF_UE_EncodeUrl have to have an encrypted URL, exceptions may be defined. See also RF_UE_AllowPlainText.

Syntax: RF_UE_EncodeUrl "on" | "off"

Inheritance: Merges the per location configuration values.

Default is off.

RF_UE_AllowPlainText

Location

Defines whether access with plain text URLs to locations with URL encryption enabled is allowed or not. For example, this behaviour may be used for the start page of an application. See RF_UE_AllowPlainUrl for the detailed definition of exceptions. Can only be used in conjunction with "RF_UE_EncodeUrl on".

Syntax: RF_UE_AllowPlainText "on" | "off"

Inheritance: Merges the per location configuration values.

Default is off.

RF_UE_LockSessionIdPath

Location

Locks an encrypted path to the user’s session.

Syntax: RF_UE_LockSessionIdPath "on" | "off"

Inheritance: Settings are inherited to sub-locations.

Default is off and encrypted paths are valid even the client session has expired.

RF_UE_EncodeQuery

Location

Activates the encryption of the query string of an URL. "$" forces the encryption of the whole string while "\*" forces the value of each parameter to be encrypted separately. The optional argument "name" can be used to define query-names of which only the value is encrypted. Name-value pairs of queries must be separated by "\&", e.g. ?uid=abc\&pwd=1234.

Can only be used in conjunction with "RF_UE_EncodeUrl on".

Syntax: RF_UE_EncodeQuery "$" | "" | [+|-]<name>*

Inheritance: Merges the per location configuration values. ‘+’ and - adds and removes names. If any name is neither prefixed by "+" nor "-", the settings of the current location overrides the upper location settings.

Example: RF_UE_EncodeQuery url +uid +pwd

Default is off.

RF_UE_EncodeQueryForm

Location

Encrypts the value attributes within HTML form input nodes with the specified name attribute.

Syntax: RF_UE_EncodeQueryForm [+|-]<name>

Inheritance: Merges the per location configuration values. ‘+’ and ‘-’ adds and removes names. If any name is neither prefixed by "+" nor "-", the settings of the current location overrides the upper location settings.

Example:

RF_UE_EncodeQueryForm contractid

Default is off.

RF_UE_AllowPlainTextQuery

Location

Defines whether access with plain text queries to a location having URL encryption enabled (and the specific query name defined by RF_UE_EncodeQuery/RF_UE_EncodeQueryForm) is allowed or not. "strict" enforces query encryption for any query name even it has not been specified by RF_UE_EncodeQuery, e.g. when using "RF_UE_EncodeQuery $" or "RF_UE_EncodeQuery *".

Can only be used in conjunction with "RF_UE_EncodeQuery on".

Syntax: RF_UE_AllowPlainTextQuery "on" | "off" | "strict"

Inheritance: Merges the per location configuration values.

Default is off (enforces the encryption for the defined query names).

RF_UE_LockSessionIdQuery

Location

Locks encrypted query (RF_UE_EncodeQuery and RF_UE_EncodeQueryForm) strings to the current client session (type 0).

Syntax: RF_UE_LockSessionIdQuery "on" | "off"

Inheritance: Settings are inherited to sub-locations.

Default is off and an encrypted query string is still valid even the client session has been expired.

RF_UE_EncodeAction

Location

Defines the action when receiving a plain text path or query string for a location that has URL encryption activated.

Syntax: RF_UE_EncodeAction "log" | "deny" | "drop"

Default is "deny" (request is forbidden) with response status code 403. The action "drop" denies the request and additionally cancels the session. The action "log" only writes a message to the error log.

RF_UE_AllowPlainUrl

Location

Defines an URL by an regular expression where a plain text path and query in the request line is allowed by disabling rule check.

RF_UE_AllowPlainUrl <regex url>

Default is none

Inheritance: Definitions are not merged to sub locations.

RF_UE_EncodeUrlOff

Location

Disables URL encryption (response processing) for specific URLs by use of a regular expression. This does not affect the data passing this location. To exclude specific URL patterns within the datastream the directive ‘_RF_UE_UrlExclPattern_’ (in the HttpsListener) should be considered.

RF_UE_EncodeUrlOff <regex url>

Default is none

Inheritance: Definitions are not merged to sub locations.

RF_UE_ContentTypeToEncode

Location

Enables URL encryption for the specified MIME content-types. Can only be used in conjunction with "RF_UE_EncodeUrl on".

Syntax: RF_UE_ContentTypeToEncode [+|-]<string>

Inheritance: Merges the per location configuration values. ‘+’ and ‘-’ adds and removes types. If any type is neither prefixed by "+" nor "-", the settings of the current location overrides the upper location settings.

The current version of the URL encryption module supports HTML, JavaScript and CSS. Please note that JavaScript and CSS HTML inline code are always encrypted automatically.

Example: RF_UE_ContentTypeToEncode +application/x-javascript

Default is "text/html"

RF_CE_PassPhrase

Virtual Server

Pass phrase used to generate a symmetric key for cookie encryption.

Syntay: RF_CE_PassPhrase <string>

RF_CE_EncryptValue

Location

Specify a cookie whose value is encrypted. This directive can be used in conjunction with the directives SE_IntCookie_PersistentCookies and SE_IntCookie_PersistentCookiesMatch. The cookie name is defined using regular expression.

Syntax: RF_CE_EncryptValue <regex>

Inheritance: Command is used for the current location and all sub-locations until the directive is defined again. The directive can be specified multiple times within a location.

Example: RF_CE_EncryptValue LS_.*

RF_CE_EncryptNameValue

Location

Specify a cookie whose name and value is encrypted. Different key are used for the name and the value portion (the outcome of name encryption is always the same). This directive can be used in conjunction with the directives SE_IntCookie_PersistentCookies and SE_IntCookie_PersistentCookiesMatch. The cookie name is defined using regular expression.

Syntax: RF_CE_EncryptNameValue <regex>

Inheritance: Command is used for the current location and all sub-locations until the directive is defined again. The directive can be specified multiple times within a location.

Example: RF_CE_EncryptNameValue LS_.*

RF_CE_FilterPlainText

Location

Set the policy how received cookies are handled whose value has not been encrypted.

Default is "off" (no action, lets the cookie pass).

Syntax: RF_CE_FilterPlainText "off" | "log" | "delete" | "deny"

Inheritance: Command is used for the current location and all sub-locations until the directive is defined again.

RF_FormValidation

Location

This directive enables or disables the module for this server.

If mode is "On", an invalid parameter throws a "500 Internal Server Error" and the action taken is written to the end of the log entry for the invalid parameter. If mode is "Off", the module does not check anything. In "Log" mode, parameters are checked and invalid parameters are logged, but requests are never blocked.

The validation does not only check HTML forms but also HTML hyperlinks and redirect location headers.

See section "HTML Form Validation" for further information.

Syntax: RF_Param "On" | "Off" | "Log"

Inheritance: Overrides definitions in parent locations.

Example: RF_FormValidation Log

Default: Off

RF_FormLogEncPassphrase

Virtual Server

Defines the passphrase that is used to encrypt sensible validation data in log files. The passphrase must be at least 8 characters long. The passphrase can be set globally (server-wide) or for each virtual host specifically.

Syntax: RF_FormLogEncPassphrase <string>

Default: Without the custom passphrase a build-in default string is used for encryption.

RF_FormTypeDef

Location

This directive assigns a regex to a type identifier.

In the simplest case, the type corresponds to the value of the type attribute of an <input> in a <form>, for example "text" for a text input field. In reality, things are more complex, see section "HTML Form Validation" for a detailed guide how to configure form validation including how to use this directive.

Syntax: RF_FormTypeDef <type> <regex>

Inheritance: Overrides definitions in parent locations individually.

Note: Missing type defs can (due to inheritance) not be detected at server startup and are instead logged to the error log when processing requests.

Examples: RF_FormTypeDef text "^\[\[:alnum:]]*$

Default types: See section "HTML Form Validation"

RF_FormParamType

Location

Assigns a type to either a parameter name or to a regex for the parameter name.

When checking a request, the form validator iterates through all form parameters and determines its type (either defined by this directive or stated by the form field if there is no matching directive) in order to validate the input. See section "HTML Form Validation" for a detailed guide how to configure form validation.

Syntax: RF_FormParamType (<param-name>|regex:<param-name-regex>) <type>

Inheritance: Overrides definitions in parent locations en bloc: If a location defines no form param types, all are inherited from the parent location; if a location defines form parameter types, none are inherited from the parent location.

Example: RF_FormParamType streetname text

RF_FormParamException

Location

Assigns a type (or a regex for the parameter value) to a parameter name (or to a regex for the parameter name).

The main difference to RF_FormParamType is that the parameter name can be the name of a parameter that was not present in any HTML form. See section "HTML Form Validation" for a detailed guide how to configure form validation.

Syntax: RF_FormParamException [+|-](<param-name>|regex:<param-name-regex>) (type:<type>|<param-value-regex>)

Inheritance: If a location defines no parameter exceptions all definitions from the parent location are inherited . If prefixed by "+" a parameter exception is added to the inherited set. Prefixed by "-" removes an exception from the inherited set. Any exception without a prefix disables inheritance form the upper location.

Examples:

RF_FormParamException +age type:number

RF_FormParamException +regex:^.*name$ type:text

RF_FormActionMap

Location

This directive maps a form action to an alternative form action.

Syntax: RF_FormActionMap <orig form action> <alternative form action>

Inheritance: Overrides definitions in parent locations en bloc.

Example: RF_FormActionMap /sls/login /sls/manipulated/login

RF_FormExpiration

Location

This directive defines the expiration of stored form data used for form validation.

Syntax: RF_FormExpiration <seconds>

Inheritance: Overrides definitions in parent locations.

Example: RF_FormExpiration 86400

Default: 86400 seconds

RF_FormNumberIdenticalIds

Location

This directive defines the number of forms with identical ID that can be stored simultaneously in the CDS.

Syntax: RF_FormNumberIdenticalIds <number>

Default: 10 forms.

RF_FormAuditLog

Virtual Server

Specifies an audit log where the form validation deny messages are written to. If this log is used, no parameter values are written to the standard error log file. Directive supports piped logging. This log may be used in conjunction with the fvfilter2 utility in order to update the form validation rules.

Syntax: RF_FormAuditLog <file>

RF_FormDecodeHtml

Location

Decodes HTML encoded query strings within HTML references.

Syntax: RF_FormDecodeHtml on|off

Default is off.

Inheritance: Overrides definitions in parent locations.

RF_ChangeReqHeader

Location

Replaces a ‘search’ pattern (literal string) by a ‘replace’ pattern. The replace pattern can be a literal string or an environment variable defined by use of SetEnvIf. In the latter case the replace pattern is prefixed by ‘$’. Per default, only the first occurrence is replaced. The optional parameter "greedy" defines that all occurrences should be replaced. Only one rule per header is supported.

Syntax: RF_ChangeReqHeader <header name> <search> <replace> [greedy]

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIf*Header directive defined does not inherit the configuration from the upper location.

RF_ChangeReqHeaderReplace

Location

Replaces the ‘header’ by the defined ‘value’ in the request headers. The value may be specified with an environment variable using SetEnvIf (value is prefixed by ‘$’). The header is added to the request if it does not yet exist.

Syntax: RF_ChangeReqHeaderReplace <header> <value>

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIf*Header directive defined does not inherit the configuration from the upper location.

RF_ChangeIfReqHeaderReplace

Location

Sets a HTTP request header if the specified environment variable matches the defined regular expression. The directive recognizes the occurrences of $1..$9 within the value argument and replaces them by the subexpressions of the defined regex pattern.

Syntax: RF_ChangeIfReqHeaderReplace <variable> <regex> [!]<header>=<value>

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIfResHeader directive defined does not inherit the configuration from the upper location.

RF_ChangeReqFixHeader

Location

Same as RF_ChangeReqHeader but applied later in the request processing (Apache fixup handler).

RF_ChangeReqFixHeaderReplace

Location

Same as RF_ChangeReqHeaderReplace but applied later in the request processing (Apache fixup handler).

RF_ChangeResHeaderAdd

Location

Adds the ‘header’ with the defined ‘value’ to the request headers, e.g. to add a cookie. The value may be specified by an environment variable using SetEnvIf (the value is prefixed by ‘$’). The directive is processed before the directives RF_ChangeResHeader, RF_ChangeResHeaderReplace, RF_SetEnvIfResHeader, and RF_ChangeIfResHeaderReplace.

Syntax: RF_ChangeResHeaderAdd <header> <value>

Inheritance: No configuration merging to sub locations. A sub location having any RF_Change* or RF_SetEnvIfResHeader directive defined does not inherit the configuration from the upper location.

RF_ChangeResHeader

Location

Same as RF_ChangeReqHeader but applied to a response header.

RF_ChangeResHeaderReplace

Location

Same as RF_ChangeReqHeaderReplace but applied to a response header.

RF_SetEnvIfResHeader

Location

Creates a process environment variable if the specified response header value matches the defined argument. Works similar to Apache’s SetEnvIf directive but is applied against the HTTP response headers. The directive recognizes the occurrences of $1..$9 within the header value and replaces them by the subexpressions of the defined regex pattern.

Syntax: RF_SetEnvIfResHeader <header> <regex> [!]<variable>[=<value>]

Inheritance: No configuration merge to sub location. A sub location having any RF_Change* or RF_SetEnvIfResHeader directive defined does not inherit the configuration from the upper location.

RF_ChangeIfResHeaderReplace

Location

Sets a HTTP response header if the specified environment variable matches the defined regular expression. The directive recognizes the occurrences of $1..$9 within the value argument and replaces them by the subexpressions of the defined regex pattern. Works contrariwise to RF_SetEnvIfResHeader.

Syntax: RF_ChangeIfResHeaderReplace <variable> <regex> [!]<header>=<value>

Inheritance: No configuration merge to sub location. A sub location having any RF_Change* or RF_SetEnvIfResHeader directive defined does not inherit the configuration from the upper location.

RF_AddHeaderContent

Location

Add header content to query. This works also for propagated headers from SLS.

Syntax: RF_AddHeaderContent <query-parameter> <header name>

Inheritance: No configuration inheritance to sub location.

RF_RemoveQueryParameter

Location

Remove a specific query parameter.

Syntax: RF_RemoveQueryParameter <query-parameter>

Inheritance: No configuration inheritance to sub location.

Cross-Site Request Forgery (CSRF)

The following configuration directives offer protection against Cross-Site Request Forgery attacks.

Take a look at chapter 4.38 Cross-Site Request Forgery Protection for a more detailed functionality description and configuration examples.

RF_CSRF

Location

Enables or Disables form or query based Cross-Site Request Forgery (CSRF) prevention for a Location.

Syntax: RF_CSRF "on"|"off"

Default is off.

Note: This directive can also be used with the BrowserMatch Apache-directive:

BrowserMatch "curl" RF_CSRF=off

Inheritance: Settings from parent locations are inherited to sublocations.

RF_CSRF_Header

Location

Enables HTTP-Header based Cross-Site Request Forgery (CSRF) prevention for a Location and allows to optionally define the HTTP-Header name.

Syntax: RF_CSRF_Header [<header-name>]

Default is off.

If no <header-name> is provided, the default header "X-CSRF-Token" will be used.

The injected JavaScript can be defined with "RF_CSRF_Header_InjectedJavaScript".

If no script is provided, the default script will be injected.

To distinguish GET requests generated by JavaScript and those made by the browser (href, src, etc.), the "X-Requested-With" header is used. GET requests are only checked for a token if the request contains the "X-Requested-With" header. Many common JavaScript frameworks and libraries set this header automatically. Nevertheless, GET request should never be used for state changing operations. POST requests are always checked.

Inheritance: Settings from parent locations are inherited to sublocations.

To disable protection the directives "RF_CSRF_DisableVerification" and "RF_CSRF off" can be used.

RF_CSRF_Header_InjectedJavaScript

Location

Allows to set a custom JavaScript that is injected when CSRF header protection is enabled. The script code can either be read from a file (path to file prefixed by file://) or stated directly in the configuration.

Syntax: RF_CSRF_Header_InjectedJavaScript file://<path>|<script-inline>

Examples:

// inject contents of a file
RF_CSRF_Header_InjectedJavaScript file:///tmp/csrf_inject.js

// define an inline script
RF_CSRF_Header_InjectedJavaScript \
   var x = "simple "; \n \
   var y = "javascript "; \n \
   var z = "syntax"; \n \
   alert(x+y+z);

Inheritance: Settings from parent locations are inherited to sublocations.

RF_CSRF_CustomTypes

Location

Add custom content types for which Cross-Site Request Forgery (CSRF) prevention should be enabled by default only http is supported. Add all additional supported types as a list to this directive. The content must provide html compliant tags otherwise it will not work.

Can only be used in conjunction with "RF_CSRF on".

Syntax: RF_CSRF_CustomTypes [+|-]<name>

Inheritance: Merges the per location configuration values. ‘+’ and ‘-’ adds and removes types. If any type is neither prefixed by "+" nor "-", the settings of the current location overrides the upper location settings.

Examples:

RF_CSRF_CustomTypes xml

RF_CSRF_UnverifiedRequestTypes

Location

Allows to define request content types for which access without token verification is permitted. Without explicit definition all requests with Content-Type header values other than application/x-www-form-urlencoded, multipart/form-data, and multipart/mixed are blocked.

Syntax: RF_CSRF_UnverifiedRequestTypes <type 1> [<type 2> … <typen n>]

Inheritance: Settings from parent locations are inherited to sublocations.

Examples:

RF_CSRF_UnverifiedRequestTypes application/xml

RF_CSRF_SetTokenName

Location

Directive defines a parameter name within a form or URL query which contains the session ticket. If not set and CSRF is turned on, "CSRF_TOKEN" is used as parameter name.

Can only be used in conjunction with "RF_CSRF on".

Syntax: RF_CSRF_SetTokenName <token-name>

Examples:

RF_CSRF_SetTokenName MY_CSRF_TOKEN

RF_CSRF_PostDataProtection

Location

Allows to enable or disable POST body data protection. If enabled POST body is checked for the CSRF Token.

Can only be used in conjunction with "RF_CSRF on"

Syntax: RF_CSRF_PostDataProtection "on"|"off"

Default is on.

RF_CSRF_GetQueryProtectionUrlRegex

Location

This directive allows to enable CSRF prevention for GET requests. The request URLs matching the URL-regex will be checked for the CSRF token. The links in the response returned by the request will be extended with the token if the target URL is matched.

Can only be used in conjunction with "RF_CSRF on".

Syntax: RF_CSRF_GetQueryProtectionUrlRegex [+|-]<regex>

Inheritance: Merges the per location configuration values. ‘+’ and ‘-’ adds and removes names. If any name is neither prefixed by "+" nor "-", the settings of the current location overrides the upper location settings.

Example:

RF_CSRF_GetQueryProtectionUrlRegex ^.*$

Default is no query protection enabled.

RF_CSRF_DisableVerification

Location

When a request URL matches the regex specified by this directive the URL is not checked for a valid CSRF token. However, the response returned by the request will be extended with tokens.

Can only be used in conjunction with "RF_CSRF on" or "RF_CSRF_Header".

Syntax: RF_CSRF_DisableVerification [+|-]<regex>

Inheritance: Merges the per location configuration values. ‘+’ and ‘-’ adds and removes names. If any name is neither prefixed by "+" nor "-", the settings of the current location overrides the upper location settings.

Example:

RF_CSRF_DisableVerification start +entry

Per default no disabling is active.

Note: To disable verification for GET requests only, the environment variable CSRF_DISABLE_GET_VERIFICATION can be set.

Examples:

SetEnvIfPlus X-Requested-With WebView CSRF_DISABLE_GET_VERIFICATION

RF_CSRF_SetErrorCode

Location

Allows to set a different return code when the CSRF validation fails.

Can only be used in conjunction with "RF_CSRF on".

Syntax: RF_CSRF_SetErrorCode <http-error-code>

Default is "403"

RF_CSRF_DeveloperJavaScript

Location

This directive adds a JavaScript to the HTML header on each page. The script contains two functions: getCSRFTokenName() and getCSRFTokenValue(). This allows to create a valid CSRF protected request by the developer itself.

Can only be used in conjunction with "RF_CSRF on".

Syntax: RF_CSRF_DeveloperJavaScript "on"|"off"

Default value is off.

RF_CSRF_DefaultUnprotectedResourcesDisable

Location

Per Default requests on resources like images and style-sheets are not protected. The determination if the request is a resource is based on the filename ending. Should it be necessary to add CSRF protection to these kind of requests, this directive allows to enable it.

Can only be used in conjunction with "RF_CSRF on".

Syntax: RF_CSRF_DefaultUnprotectedResourcesDisable "on"|"off"

Default is "RF_CSRF_DefaultUnprotectedResourcesDisable off".

ICAP

The ICAP filter module is explained in more detail in section "ICAP Request and Response Modification". The directive syntax is defined in "Table 15: Http(s)Listener - Request/Response Filter Directives" on page 45. Directives that are only supported in the SRManager are described below.

ICAP_FO_SessionSticky

Location

This directive defines that ICAP requests for the same HTTP session try to stick on the same ICAP host (incl. service URI), i.e. the host corresponding to the session is tried first.

Syntax: ICAP_FO_SessionSticky REQMOD|RESPMOD on|off

Example: ICAP_FO_SessionSticky REQMOD on

REC_BehaveOnError

Location

Defines the server behave on error. The server may either ignore the error and continue operation without recording data or the server can abort a request on errors which causes a HTTP server error sent to the Client.

Syntax: REC_BehaveOnError <action>

where "action" is either IGNORE or ABORT

Example: REC_BehaveOnError ABORT

Default is IGNORE

REC_BodyLimit

Location

Defines the maximal number of bytes to be recorded for the specified body data type.

Syntax: REC_BodyLimit <type_name>=<size>

where "type_name" is either RQBC or RSBC and "size" the number of bytes.

Example: REC_BodyLimit RQBC=1024

There are no limitations set by default.

REC_ContentType

Location

Defines the content types to be recorded. Setting is applied to incoming and outgoing body data.

Multiple content types may be specified by multiple arguments. “ALL” can be used to enable recording of all content types. Otherwise type alias names or specific mime types may be specified. See the "REC_SHOWCT" command directive to get a list of all available alias names.

The prefixes “+” and “-” are used to name additional content types to be recorded (+) or filtered (-).

Syntax: REC_ContentType [“+” | “-”] <alias_name | <content_type>

Inheritance: Merges the per location configuration values. ‘+’ and ‘-’ adds and removes content types from the current location configuration. If the value is not prefixed by ‘+’ or ‘-’, it Overrides the upper location settings.

Example: REC_ContentType ALL -IMAGE +image/jpeg -text/plain

Default is none

REC_MsgType

Location

Colon separated list of message types to be recorded. Available values are ALL, NONE, RQHC, RQHS, RQBC, RSHC, RSHS, RSBC.

Syntax: REC_MsgType <type id:><type id>:<type id>

Example: REC_MsgType RQHC: RSHC

Default is NONE

REC_SHOWCT

Global

Causes the SRM to list all the available content type alias names and the mime-type names embraced by the alias name. The command causes the SRM to exit immediately.

You might use the command as shown below to do this:

REC_DestDir

Global

Path where the recorded data is stored to. This directory must be created before the server is started. Ensure to create also the necessary subdirectories: Create a subdirectory for every "HSP_AppId"command directive you have defined.

Syntax: REC_DestDir <directory>

Example: REC_DestDir /var/opt/usp/hsp/srm/recdata

REC_RotateTime

Global

Time in seconds defining the time interval to rotate the output files.

Syntax: REC_RotateTime <seconds>

Example: REC_RotateTime 600

Default is one second

RF_FakeServerName

Virtual Server

The server name returned in the HTTP header "Server". If not defined, the default "Secure Entry Server" is used. With the value %OFF the header "Server" coming from the back-end remains unchanged.

Inheritance: A configured server name in the global scope is merged into the scope of virtual hosts. With the value %DEFAULT the server name in a virtual host can be reset to the default server name.

Syntax: RF_FakeServerName <name>

HGW_Host

Location, Session Attribute

Defines the server name and port ("host:port") to send the request to.

"host:port" can be hard-coded or dynamically selected during runtime via environment variables ($ENV.<name>), request header values ($HDR.<header>) or Session Attributes sent by the Login Service ($ACA). For failover, multiple servers can be specified, separated by semicolon or whitespace. If failover is not enabled and multiple hosts are specified, then only the first host is used. The DNS resolving policy is controlled by directive "HGW_DNSPolicy". When using an IPv6 adress, host addresses must be enclosed in square brackets.

There are some dependencies between this directive and HTTP server addressing:

Syntax: HGW_Host <host>:<port>|$ACA|$ENV.<variable>|$HDR.<name> (<host>:<port>|$ENV.<variable>|$HDR.<name>)\*

Example: "app1.com:8080"

Example: "$ACA"

Example: "$ENV.DYNAMIC_HOST $HDR.DYNAMIC_HOST"

Example: "192.168.9.2:8080 [fc00::cafe]:8080"

HGW_AutomaticHostRewrite

Virtual Server

Location

All URLs in the body pointing to an internal location will be automatically rewritten to point to Hsp-ListenerUri.

Syntax: HGW_AutomaticHostRewrite On|Off

Example:

If Hsp-ListenerUri is set to: www.example.net:10443 and the connection uses ssl then the following URI will be replaced as follows

http://backend1.local.net/foo/bar

will become

https://www.example.net:10443/foo/bar

Configuration example (shows relevant settings only):

<Location /foo/bar>
  HGW_Host                    backend1.local.net
  HGW_AutomaticHostRewrite    on
</Location>
<Location /foo/bar/a>
  # HGW_AutomaticHostRewrite  is set to on
</Location>
<Location /foo/bar/a/b>
  HGW_AutomaticHostRewrite    off
</Location>
<Location /foo/bar/a/b/c>
  # HGW_AutomaticHostRewrite  is set to off
</Location>

Precedence:

The last <Location> overrides the earlier ones despite being less specific.

HGW_AutomaticHostRewriteContentType

Virtual Server

Location

Allows to automatically rewrite URLs in document bodies other than text/html if directive HGW_AutomaticHostRewrite is enabled. If not defined, URLs will be rewritten only in documents with a content-type text/html. The setting of the current Location overrides the upper Location or VirtualHost setting.

Syntax: HGW_AutomaticHostRewriteContentType <regex>

Example:

<Location /x>
  # enable URL rewrite in text/html documents
  HGW_AutomaticHostRewrite on
  # rewrite URLs in text/xml document as well
  HGW_AutomaticHostRewriteContentType text/xml
</Location>
<Location /x/app>
  # rewrite URLs in text/html and json documents (overrides definition in Location /x)
  HGW_AutomaticHostRewriteContentType application/.\*json
</Location>

HGW_Disable

Location

Allows to disable the HTTP 1.1 Gateway for a HGW-enabled sublocation. Use this, if you want a sublocation to be handled locally (i.e. not by the http_1_1_gw_handler), although its superlocation has HTTP 1.1 Gateway enabled.

Syntax: HGW_Disable

Example:

<Location /x/y>
  SetHandler default
  HGW_Disable
</Location>

HGW_ForceHost

Location, Session Attribute

Forces the "Host:" header to the given value. Without this directive, the value is set according to the "HGW_Host" directive.

Syntax: HGW_ForceHost <host_specification> [<host_specification> ] …

If the directive value starts with ‘$HEADER(’ and ends with ‘)’, the value of the header name enclosed in the parentheses will be copied to the "Host:" header. A single ‘$’ is interpreted as the "HSP_HTTPS_HOST:" header containing the name of the Https Listener. ‘$LISTENER_HOST’ uses similar to a single ‘$’ the "HSP_HTTPS_HOST" header value, but removes any port information. If "off" is specified, the default (from the "HGW_Host" directive) is used.

If multiple values are defined, they will be used for the corresponding servers (same index) specified with "HGW_Host". If fewer host specifications than servers are specified, the first value specified with "HGW_ForceHost" is used.

Examples: "HGW_ForceHost $HEADER(Host)", "HGW_ForceHost $"

HGW_KeepAsRedirectScheme

Location

Specifies whether the scheme of the location header on backend redirections is kept or not.

Per default, the URI scheme is rewritten to the scheme of the received request.

Syntax: HGW_KeepAsRedirectScheme On|Off

Default: Off

Example: HGW_KeepAsRedirectScheme On

HGW_RequestHeaders

Location

A list of HTTP headers that are passed to the application server. Headers not in this list are stripped from the request.

Entries starting with ‘%’ are replaced with all headers defined for this alias. See directive "HGW_ShowAliases". Entries starting with ‘-’ are removed from the list, entries prefixed with ‘+’ are added.

In addition, wildcards for header names can be specified, e.g. with "Foo*" all headers starting with the substring "Foo" are let through. A single star "*" allows to pass all headers to the back-end. In conjunction with wildcards single headers can be excluded with a preceding exclamation mark, e.g. !Foo2 ensures that the header Foo2 is withheld even though wildcards exists.

Inheritance: Configuration values are merged to sub-locations. ‘+’ adds and ‘-’ removes headers from the merged configuration. If any of the values are not prefixed by ‘+’ or ‘-’, the settings of the current location overrides the setting of the parent location.

Syntax: HGW_RequestHeaders ['+'|'-'] (('%'<Alias>|<Headers>['*'])* | *) | !<Header>

Example: %HTTP11_std -Referer !UserLoginData +Foo*

HGW_Allow401

Location

A value of "On" disables the default behavior of mapping an HTTP response code of 401 (Not Authorized) from the server to the code 500 (Server Error). A value of "RC=<n>" also avoids a server error, but changes the response code to the value <n> (allowed range is 200 to 599).

Syntax: HGW_Allow401 On|Off|RC=<n>

Example: "HGW_Allow401 RC=403"

HGW_AllowCustomStatusLine

Location

Sometimes, an application server uses a non standard HTTP response line with a response code in defined by RFC2616. Such a response line get replaces by a "500 Internal Server Error" response line by default. You may allow any response codes using this directive.

Syntax: HGW_AllowCustomStatusLine On|Off

HGW_NoLoginUserDataHeaderUntil401

Location

If set to "On", the Login-Credentials (UserData) header will not be sent to the application server, until it replies with an HTTP status code of "401 AUTHORIZATION REQUIRED". Once this happens, the request will be repeated (transparently for the client) with the Login-Credentials header. From then on, the Login-Credentials header will be sent with every request as usual (until the client logs out). This mimics the behavior of a browser regarding basic authentication.

For POST requests with a content length over 8192 bytes, the Credentials header will always be sent.

Syntax: HGW_NoLoginUserDataHeaderUntil401 On|Off

HGW_HandleStatusLocal

Virtual Server Location

Specifies error responses sent by application server to be handled locally.

For each location it is possible to add or remove status pages from the parent with a “+” or “-” prefix. If no prefix is specified then the parent values will be disabled for this location.

Syntax: HGW_HandleStatusLocal [+|-]<status>[:<local_status>]

If specified, the error page with the specified error code sent by the application server is discarded and handled locally. If an error page is defined for this status, it will be display as if it was a local error. If <local_status> is specified, the applications status code is mapped to <local_status> before handling it.

HGW_Proxy

Location

Defines the hostname (or IP address) and port of the forward proxy via which to send the request.

If SSL is enabled, a tunnel (HTTP CONNECT) is established to the forward proxy. When using an IPv6 address, the address must be enclosed in square brackets.

For failover, multiple servers must be specified. However, if multiple servers are specified but failover is not enabled, only the first server specified is used.

If both HGW_Proxy and HGW_Host are used for a location and HGW_Proxy is defined before HGW_Host, the DNS lookups for hosts defined in HGW_Host are skipped at startup.

Syntax: HGW_Proxy <host>:<port> [<host>:<port>] …

Example: "prox1.foo.com:8080 prox2.foo.com:8080"

Example: "192.168.9.2:8080"

Example: "[fc00::cafe]:8080"

HGW_Balancer

Location

Defines the name of a load balancer via which to distribute the requests.

A load balancer with the given name must be defined with <Proxy balancer> on VirtualHost level. For details see the description to mod_hgw_balancer.

Can be combined with one ore more forward proxies defined with HGW_Proxy.

Inheritance: The usage of a specific balancer is merged to sublocations.

Syntax: HGW_Balancer <name>

Example:

<Proxy balancer://mybalancer>
   BalancerMember  https://host1.com:443
   BalancerMember  https://host2.com:443
</Proxy>

<VirtualHost 1.2.3.4:443>
  <Location /balanced>
    HGW_Balancer mybalancer
    HGW_EnableSSLServerCert ALLOW_ALL
  </Location>
</VirtualHost>

HGW_BalancerErrorRedirect

Location

Defines a dedicated URL to redirect to if a load balancer is in use and no backend is available.

The URL can either be absolute, or relative. In case of a relative URL, the HSP redirects to the specified path on the same virtual host.

The setting is inherited to sublocatios. "off" allows to disable redirects in sublocations. If no load balancer is defined with HGW_Balancer the directive is ignored.

Syntax: HGW_BalancerErrorRedirect <url>|off

Examples:

<VirtualHost 1.2.3.4:443>
  # redirect to 1.2.3.4:443/errorpage
  <Location /balanced/rel>
    HGW_BalancerErrorRedirect /errorpage
  </Location>

  <Location /balanced/abs>
    HGW_BalancerErrorRedirect https://www.u-s-p.ch
  </Location>

  <Location /balanced/rel/sub>
    HGW_BalancerErrorRedirect off
  </Location>
</VirtualHost>

Inheritance: Redirect URL is merged to sublocations.

HGW_EnableSSLServerCert

Location

Use SSL when connecting to the server and ensure that the presented server certificate is signed by one the configured Certification Authority (CA=<ca-cert>). The directive VerifyDepth (by default set to ‘1’) states the maximum depth of CA certificates in the server certificate verification. In order to allow any server certificate, configure the special value "ALLOW_ALL".

Optionally, verify that either one of the CN attribute(s) of the certificate’s subject or of the Subject Alternative Name (SAN) extension corresponds to the value configured by CN=‘<host-name>'. Multiple CN=`<host-name>’ are supported as well as dynamic declarations by use of environment or header variables. Also, if CRL paths are configured the server certificate is checked for revocation by use of present CRL files in the given directories.

Use HGW_SslClientProtocol to define the protocol to use.

Syntax: HGW_EnableSSLServerCert ALLOW_ALL | [CA=<ca-cert>] | [VerifyDepth=<depth>] | [CN=‘<host-name>'|`$ENV.<env-var>’|‘$HDR.<header>’] | [CRL=<crl-path>]

Examples:

HGW_EnableSSLServerCert ALLOW_ALL

HGW_EnableSSLServerCert CA=/path/to/ca.cert.pem VerifyDepth=5

HGW_EnableSSLServerCert CA=/path/to/ca.cert.pem CN=‘example.com' CN=$ENV.VAR-NAME’ HGW_EnableSSLServerCert CA=/path/to/ca.cert.pem CN=‘example.com' CN=$HDR.HEADER-NAME’

HGW_EnableSSLServerCert CA=/path/to/ca.cert.pem CRL_PATH=/path/to/crls

HGW_SSLConnectTimeOut

Location

Sets the timeout for the SSL connection establishment. If the socket timeouts during the establishment an OpenSSL syscall error is returned.

Syntax: HGW_SSLConnectTimeOut <seconds>

If this directive is not set the same timeout as for the TCP connection establishment is used. See HGW_ConnectTimeout.

HGW_DisableSSLServerCert

Location

Disable SSL for a sub location (undo HGW_EnableSSLServerCert).

HGW_ClientCert

Location

Use the configured client certificate and private key ("CERT=<PEMfile> PKEY=<PEMfile>") for SSL client authentication if requested by the server.

Example: "CERT=/opt/cert/client/client.PEM PKEY=/opt/pkey/client/clientkey.PEM"

The private key must not be password protected.

Settings are inherited to sub-locations. However, inheritance is inhibited if HGW_EnableSSLServerCert is set on a sub-location so that a re-definition becomes necessary.

HGW_ClientCertChain

Location

Allows to configure a PEM file with a chain of intermediate CA certificates which will be used for SSL client authentication, if the certificate configured with HGW_ClientCert is not directly signed by any CA in the given CA list in the server’s CertificateRequest.

Syntax: HGW_ClientCertChain <PEMfile>

Settings are inherited to sub-locations. However, inheritance is inhibited if HGW_EnableSSLServerCert is set on a sub-location so that a re-definition becomes necessary.

HGW_SslClientProtocolDefault

Global, Virtual Server

Defines the default protocol to be used for sessions to the application server, when HGW_SslClientProtocol is not defined.

Syntax: HGW_SslClientProtocolDefault TLSv1 | TLSv1.1 | TLSv1.2 | TLSv1.3 | any | recent

Default is TLSv1.2

"any" allows all Protocols

"recent" allows only TLSv1.2 and TLSv1.3

HGW_SslClientProtocol

Location

Selects the protocol to be used for sessions to the application server.

Important: This directive must be defined before HGW_EnableSSLServerCert to take.

Syntax: HGW_SslClientProtocol TLSv1 | TLSv1.1 | TLSv1.2 | TLSv1.3 | any

Default is as specified by HGW_SslClientProtocolDefault or TLSv1.2.

HGW_SslClientCipherSuite

Location

Selects the SSL ciphers to be used. Valid ciphers depend on the SSL protocol type (see HGW_SslClientProtocol).

The optional protocol specifier can configure the cipher suite for a specific SSL version. "SSL" can be used for all SSL protocols up to and including TLSv1.2, whereas the protocol specifier "TLSv1.3" can be used to configure the cipher suite for TLSv1.3.

Syntax: HGW_SslClientCipherSuite [<protocol>] <cipher-suite>

Example 1: RSA:!EXP:!NULL:+HIGH:-MEDIUM:-LOW Example 2: DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA Example 3: TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

HGW_SslStaticSession

Virtual Server, Location