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.
Support IPv6
Ticking this box enables IPv6 support for ComCap, allowing IPv6 addresses to be specified in various settings screens.
Don’t Check Connections with Ping Echo
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 Client, No Immediate Retry on Disconnect
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.
TCP/IP Send Keep Alive
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.
SSL Client Verify Certificate Mode
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 supplied with 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.
SSL Client Certificate Authority Bundle File
Specifies the actual file name of the PEM Bundle File, the file supplied with ComCap with about 289 CA root certificates is:
C:\ProgramData\Magenta-Systems\ComCap4\Certificates\RootCaCertsBundle.pem
Extra PEM root certificates can be added to this file if needed, manually, or it can be replaced with a file containing only certificates that should be trusted, perhaps self signed certificates. Note the CA file is also used to validate SSL/TLS server certificates.
SSL Client Security
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.
Check if SSL Certificates Revoked
Certificate revocation can be checked, revokation is done when a certificate has been stolen or misused, and is no longer trusted.
Log Full SSL Certificate Chain
Ticking this option causes all SSL certificates in the verification chain to be logged, each time a connection is opened.
SSL/TLS Automatic Certificate Ordering
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.
Certificate Supplier Protocol
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.
Certificate Product
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.
Certificate Challenge
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.
Certificate Private Key Type
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.
Certificate Sign Digest
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.
Days before Expiry to Order
Let's Encrypt certificates expire after 90 days and they recommend re-ordering 20 or 30 days before expiry, in case of problems.
Certificate Ordering Work Directory
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.
Proxy URL
If public internet access requires a proxy server, the 'Proxy URL' should be entered as http://server:port.
Certificate Admin Email
The administrative email address for use when ordering X509 certificates, currently Let's Encrypt use this to issue expiry notices.