The MFCC configuration file (mf-client.dat) is divided into sections - section names are included in square brackets. Within each section, options are specified as name/value pairs, one per line. Blank lines and leading/trailing whitespace are ignored. Comment lines start with the hash (#) or semicolon (;) character and go to the end of the line.
The file contains the following sections:
[directories] mrpi://127.0.0.1:0
username=mf_dep password=mf_dep
[tracing] level=3
[defaults] connect-timeout=15 timeout=30 availability=available mfbinp-digest=md5
Allows characters forbidden by the standard in HTTP URLs.
Specifies the URL of a proxy for HTTP. This feature is experimental.
[options] relax-URL-rules=true proxy=https://proxy.host.com
This value can be set to either the name of an enterprise server region, or to an environment variable specified as $NAME or %NAME%, in which case the value of the environment variable will be used. If this setting is configured, when MFCC is asked to search for a service and it finds a suitable service under more than one server, it will prefer the instance of the service that belongs to the preferred server. This is mostly useful for controlling service deployment in systems that have multiple enterprise server regions configured.
[operation] preferred-server=$ES_SERVER
If you use MFCC to connect to HTTPS servers on the public Internet, a more useful root is probably CARootCerts.pem (note the "s"), which can be found in the bin directory of your Enterprise Developer product. CARootCerts.pem is a collection of roots for various commercial CAs.
You can concatenate multiple PEM files together to assemble whatever root collection meets your needs.
If the client should verify the server's certificate, set this option to a string beginning with "y", "t", or "1" (case-insensitive), then peer verification is enabled; otherwise it is disabled. The default is to enable peer verification.
Applications can override this setting, but rarely do.
Verification is critical to TLS security. It should only be disabled for testing (for example, to diagnose a certificate name-matching problem) and similar purposes, and only temporarily.
A depth of 1 allows one intermediate certificate between the root and the server's certificate, and so on.
Historically, this setting was used to prevent misusing entity certificates to sign other certificates. With modern (X.509v3) certificates, it is largely unnecessary, and should be set to a large enough value to accommodate all the server certificate chains that MFCC clients will see.
MFCC applications can override this value, but usually don't. If the application does not set a value, the configured value is used. If it is not specified in the configuration, the default is 2.
This setting has no effect if peer verification is disabled (see the verify peer setting above).
The value must be non-negative (0 or greater).
If this option is set to a string beginning with "y", "t", or "1" (case-insensitive), then name verification is enabled; otherwise it is disabled. The default is enabled.
When this is enabled (the default), MFCC attempts to match each of the names in the server's certificate against the hostname that the application specified when MFCC requests to open the connection. The comparison is case-insensitive. Some CAs will issue certificates with wildcard names like *.foo.bar.com, which should match any hostname like a.foo.bar.com. Support in MFCC for wildcard names is experimental. Also, certificates can include IP addresses, which would be used for comparison if the application specifies an address rather than a hostname. Support for IP addresses is experimental.
Name matching is critical to TLS security. It should only be disabled for testing (for example, to diagnose a certificate name-matching problem) and similar purposes, and only temporarily.
This setting has no effect if peer verification is disabled (see the verify peer setting above).
The TLS protocols option specifies the list of protocols (TLS versions) to be used, and the order of preference in which they are to be used. By default, TLS 1.0 through 1.3 are enabled, and later versions are preferred.
See Configuring a Cipher Suites List for more information on setting the cipher suites and what suites are enabled by default. The default list includes only ciphers still considered secure for normal use when the product release was developed.
TLS version 1.3 has different cipher suites from previous protocol versions, and so it has its own cipher suite list. It is rarely necessary to set this configuration option.
Enables or disables the TLS 1.3 "middlebox workaround", a feature which lets TLS 1.3 work on some connections that traverse routers, firewalls, and other systems which do not correctly handle TLS 1.3. It is enabled by default, and it is rarely necessary to change this setting. Possible values are disable and enable.
[TLS] root=/path/to/root/cert.type certificate=/path/to/client/cert.type key=/path/to/client/keyfile.type passphrase=keyfile passphrase middlebox workaround=enable verify peer name=yes verify depth=2 verify peer=yes
Use this (optional) section to set credentials (username and password) for HTTP and HTTPS requests to a given host and port, if the application does not specify them. This can be used to supply credentials to HTTP hosts that use HTTP Basic Authentication. The username and password are separated by a colon, as they would be in a URL (http://user:pass@host:port/path).
[credentials] www.tempuri.org=username:password myhost:9000=someuser:somepass
Each entry in this section takes one of two forms:
[service list] service1=http://tempuri.com service2=[service2 definition] [service2 definition] location=tcpssl:myhost:9443 config=[service2 config] [service2 config] name1=value1 name2=value2