Network Options

The Common Settings apply to all capture channels. Once these settings have been specified, OK or Apply should be clicked. This tab defines the common Network and SSL/TLS settings to be set-up.

Ticking this box enables IPv6 support for ComCap, allowing IPv6 addresses to be specified in various settings screens.

As detailed on Network configuration, TCP Client normally sends a ping to a remote server, which is echoed back if the server exists. Some firewalls and routers may be configured to block pings, causing ComCap to fail to receive the echo and be unable to connect. This tick box bypasses the ping, allowing an immediate connection attempt to the remote server. The penalty is Windows takes about 40 seconds to time out a failed connection attempt, compare to 10 seconds for ping.

TCP/IP is often not a reliable protocol due to routing issues, sessions may drop expectedly because a router somewhere has been rebooted, re-cabled or many other reasons. ComCap therefore attempts to re-establish any TCP/IP Client connections that are unexpectedly terminated. In existing releases, there are two immediate attempts to reconnect, after which the number of further attempts and delay between them is defined in the grid in Common Settings, Network (zero attempts means keep trying for ever). This option applies to all channels, capture and echo, and prevents those two immediate retries so the first retry is after 'Wait Seconds'. Some appliances may be unable to cope with an immediate reconnect.

For TCP Client only, this option enables automatic keep alive messages to be transmitted every few seconds, defaulting to 20 seconds. Keep alive is only needed when there are long gaps during data capture, and a router or firewall may disconnect the TCP/IP connection due to inactivity (perhaps after 5 or 10 minutes). This option should not be needed on LANs. Setting seconds to zero disables Keep Alive, which may upset some routers.

When using TCP/IP Client, specifies whether the SSL certificate from the remote server is checked to ensure it is talking to the correct server. Note this increases the time for a connection to made while certificates are transmitted and checked, potentially causing the connection to fail. Also, ComCap needs the trusted root certificate issued by the Certificate Authority (CA) used to sign the server's certificate, which is how the chain of trust is proved.

None	No certificate takes place, may be needed for self signed certificates or privately issued certificates.
PEM Bundle File	A file built in to ComCap containing about 289 certificate authority trusted root certificates in PEM format, essentially the same as used by Microsoft. Note over time old CA roots become disused and newer root certificates are issued (a couple a year), so this file can become obsolete over many years. The latest version of ComCap will have the latest root bundle file.
Windows Certificate Store	Windows has a dynamic certificate store, on new installations it's a few common CA root certificates, but further root certificates are automatically downloaded as needed to verify certificate chains. This may be a little slower than using the PEM Bundle File, particularly if a new root is needed, and may fail if the download fails.

The type of certificate validation is common to all ComCap channels, but individual channels need to also be set to check remote certificates.

Specifies the SSL security level for all TCP/IP Clients (including email) to ensure that minimum SSL/TLS security standards are enforced. The options are:

None	All protocols and ciphers, any key lengths
SSLv3 Only	SSLv3 only, all ciphers, any key lengths, MD5 hash
TLSv1 Only	TLSv1 only, all ciphers, RSA/DH private keys => 2,048 bits
TLSv1.1 Only	TLSv1.1 only, all ciphers, RSA/DH private keys => 2,048 bits
TLSv1.2 Only	TLSv1.2 only, all ciphers, RSA/DH private keys => 2,048 bits - recommended
TLSv1.3 Only	TLSv1.3 only, all ciphers, RSA/DH private keys => 2,048 bits
TLSv1 or Better	TLSv1 or later, all ciphers, RSA/DH private keys => 1,024 bits
TLSv1.1 or Better	TLSv1.1 or later, all ciphers, RSA/DH private keys => 1,024 bits
TLSv1.2 or Better	TLSv1.2 or later, all ciphers, RSA/DH private keys => 2,048 bits - recommended
Backward Ciphers	TLSv1 or later, backward ciphers, RSA/DH private keys => 1,024 bits, ECC keys => 160 bits, no MD5, no SHA1 hash
Intermediate Ciphers	TLSv1.1 or later, intermediate ciphers, RSA private keys => 2,048 bits, ECC keys => 224 bits, no RC4 ciphers, no SHA1 hash
High Ciphers, 2048 keys	TLSv1.2 or later, high ciphers, RSA private keys => 2,048 bits, ECC keys => 224 bits, no RC4 ciphers, no SHA1 hash - recommended
High Ciphers, 3072 keys	TLSv1.2 or later, high ciphers, RSA private keys => 3,072 bits, ECC keys => 256 bits, Forward Security forced
High Ciphers, 7680 keys	TLSv1.2 or later, high ciphers, RSA private keys => 7,680 bits, ECC keys => 384 bits, Forward Security forced

The default security level is 'TLSv1.2 or Better' which is the PCI DSS council standard and recommended by major browsers. Generally the only reason to support old protocols or low security standards is to access 10 year or older servers that only supported those old protocols. Likewise, all SSL certificates have used 2,048 bit minimum private keys for several years and any older ones should have long expired (except some root certificates). The SHA1 hash was used to sign old certificates now replaced by SHA2 (aka SHA-256). Some SSL ciphers are potentially open to attack, but may still be needed to access very old servers that don't support anything better. Private keys with RSA 3,072 bits are the minimum recommended by NIST for use after year 2030, larger RSA keys increase the size of SSL certificates and thus the handshaking for each SSL connection.

Note if the security level is set too high, an SSL/TLS connection may just fail without any sensible explanation.

Certificate revocation can be checked, revokation is done when a certificate has been stolen or misused, and is no longer trusted.

Ticking this option causes all SSL certificates in the verification chain to be logged, each time a connection is opened.

There are several settings relating to automatic free SSL/TLS X509 certificate acquisition and installation from Let's Encrypt. Potentially commercial certificates can also be automatically bought and installed, but this requires account settings to be added and is not yet available. ComCap is only able to order certificates for channels available using public domain names on the open internet, not internal only servers. Again potentially ComCap can issue local certificates against a private certificate authority, but this also requires more account settings. Before issuing a certificate, Let's Encrypt will connect to a web server ComCap runs internally on port 80 of the same IP address used by the capture or echo channel, so public DNS must point to this IP address and there should not be any other web servers using it for validation will fail. The internal web server usually only runs for a few seconds during the certificate ordering process and while running ignores any requests other than from Let's Encrypt so is not a security risk.

The following settings are common to all automatic certificate orders, but each channel has further settings for capture and echo SSL/TLS certificates that should also be set-up.

Currently the only supplier supported is AcmeV2 which is the protocol used by Let's Encrypt that allows Domain Validated certificates to be ordered automatically.

Product should be specified as 'Let's Encrypt 3 months', the default, the certificate expire after three months which is less than commercial certificates, but ComCap re-orders a new certificate automatically before it expires.

Let's Encrypt use a challenge to ensure the certificate domain name being ordered belongs to ComCap on this server. Currently, ComCap supports the 'File - Local Web Server' challenge method, in which Let's Encrypt supplies some random text from which ComCap creates a small file accessible using the HTTP web protocol from the internet. Let's Encrypt then accesses this file using the domain name requested for the certificate and confirms the file contains the expected random text and the challenge succeeds.

Each X509 certificate needs a unique private key that ComCap will generate, and there are several methods available, the two most common are 'RSA 2,048 bits' and 'Elliptic Curve secp256', more bits are higher security, and may be needed in the future.

The X509 certificate needs to be digitally signed by the private key, using a digest, with SHA256 being most common at present, better digests may be needed in the future for more security.

Let's Encrypt certificates expire after 90 days and they recommend re-ordering 20 or 30 days before expiry, in case of problems.

The ordering process needs a work directory where new certificates, private keys and an ordering database are saved, similarly to the following:

AcmePrivateKey.pem	Acme2 account private key for signing order requests.
AcmePublicKey.pem	Acme2 account public key sent with order requests
ics-control.db	X509 certificate control database containing Acme2 account information, domain information from the last order, and challenge information for orders.
LE-1292352829-test5_comcap_co_uk-bundle.pem	Final certificate bundle in PEM format, containing domain certificate, private key and any intermediate certificates needed.
LE-1292352829-test5_comcap_co_uk-privatekey.pem	Certificate private key created by ComCap before order
LE-1292352829-test5_comcap_co_uk-request.pem	Certificate request created by ComCap before order
LE-1292352829-test5_comcap_co_uk.pfx	Final certificate bundle in PKC12 format, containing domain certificate, private key and any intermediate certificates needed.

test5_comcap_co_uk-bundle.pem	Final certificate bundle in PEM format, containing domain certificate, private key and any intermediate certificates needed.
test5_comcap_co_uk-privatekey.pem	Certificate private key created by ComCap before order
test5_comcap_co_uk-request.pem	Certificate request created by ComCap before order
test5_comcap_co_uk.pfx	Final certificate bundle in PKC12 format, containing domain certificate, private key and any intermediate certificates needed.

The certificate files are preceded by the Let's Encrypt sequential order number, and then copied again without the order number for use.

Note that the files in this directory all relate to certificates issued by a single Acme2 account, don't use the same work directory for more than one application or the account details will get confused.

If public internet access requires a proxy server, the 'Proxy URL' should be entered as http://server:port.

The administrative email address for use when ordering X509 certificates, currently Let's Encrypt use this to issue expiry notices.