Troubleshooting Secure Configuration (SSL/TLS)

Verifying and Troubleshooting certificate files

OpenSSL can be used for verifying the certificate chain. Depending on how the certificate was issued, there are two main ways to do this. OpenSSL for Windows can be downloaded from https://wiki.openssl.org/index.php/Binaries.

Verifying a certificate signed by a trusted CA

To verify a certificate signed by a trusted CA, use the following command:

openssl verify seeq-cert.pem

The output of the command should be something like "seeq-cert.pem: OK". If it's not, there might be an issue with the certificate or the certificate chain, so you'll need to inspect the certificate to dig further (see below).

Verifying a certificate signed by an internal (non-official) CA or a self-signed certificate

When using a certificate signed by an internal (non-official) CA or a self-signed certificate, the seeq-cert.pem file should contain the entire chain of certificates starting with the server certificate, then any intermediate certificate and finally the CA certificate. To verify such a certificate, each certificate block in the seeq-cert.pem file needs to be saved in its own file, for example seeq-cert1.pem for the server certificate, seeq-cert2.pem for the intermediate certificate and seeq-cert3.pem for the CA certificate (the numbers correspond to the order which the certificate blocks appear in seeq-cert.pem). Note that the file numbering is only for verifying the certificate using OpenSSL, Seeq does not use the individual files, so after the verification is successful, the numbered files can be deleted. The command to run to verify the entire certificate chain is as follows:

openssl verify -CAfile seeq-cert3.pem -untrusted seeq-cert2.pem seeq-cert1.pem

The output of the command should be something like "seeq-cert.pem: OK". If it's not, there might be an issue with the certificate or the certificate chain, so you'll need to inspect the certificate to dig further (see below).

Certificate verification messages

The following is a list of known certificate verification messages and resolutions.

Most of the OpenSSL error messages will also output a depth, for example "error 2 at 1 depth lookup:unable to get issuer certificate". Depth indicates the certificate number (starting a 0).

Inspecting a certificate

In case of a certificate verification failure, each individual certificate file (seeq-cert1.pem, seeq-cert2.pem and seeq-cert3.pem from above) can be inspected using the following OpenSSL command:

openssl x509 -in seeq-certX.pem -text -noout

There could be several different problems with the certificates, but make sure the expiration dates aren't passed and take a look at the lines containing "Subject" (what the certificate is for) and "Issuer" (who issued the certificate) to make sure they're in the correct order in seeq-cert.pem. The correct order is server certificate, then intermediate certificate (if such exists), then CA certificate. Also make sure the server certificate is issued for the correct server name (CN part of the Subject line).

Verifying that a private key matches a certificate

If the certificate and key file are not a matching pair, the server will generate an error at startup. If you suspect that this is the case, you can verify that using openssl. See the Apache SSL/TLS FAQ for a description.

openssl x509 -noout -modulus -in server-cert.pem | openssl md5
openssl rsa -noout -modulus -in server-key.pem | openssl md5

Each of these commands should generate a sequence of numbers and letters (a hash). In a correct pair, those sequences should be the same. If those two sequences are different, then the certificate and key files were not generated from the same certificate request and cannot be used to secure Seeq.

Troubleshooting certificate connection issues

Inspecting certificate details

OpenSSL can also be used to verify the certificate after it's installed, which can sometimes be difficult with a web browser as it only provides some some basic (user friendly) information. Use the following command to connect to the Seeq Server and have OpenSSL verify the validity of the certificate:

openssl s_client -host <SEEQ-SERVER-HOSTNAME> -port <SEEQ-SERVER-SECURE-PORT>

OpenSSL will output a lot of information about the certificates served by the Seeq Server and a status message about the validity. Reading all the output is hard to describe in detail, but if there are connection issues that need investigation, this output will help Seeq with the investigation.

One common issue is that a Certificate Proxy server exists between a Seeq server in an internal corporate network and a public Seeq server outside of that network (in the cloud, for instance). In such cases, when running this command, you will observe that the certificate chain will start with the target server's DNS name (or wildcard) but will proceed to Certificate Authorities that are internal to the company's network instead of those in the actual seeq-cert.pem file used in the keys folder (usually commonly used public certificates. You can view the certificate chain on the seeq-cert.pem file by running this command:

openssl x509 -in certificate.crt -text -noout

Missing required fields

Browsers have specific requirements for what fields must be present in order for them to declare a certificate to be valid. A common field that is missing from a certificate is the Subject Alternate Name field. Google Chrome (and possibly others) will display a certificate error if this field is missing. The only resolution to this problem is to generate a new certificate signing request (CSR) with that field specified.

Mismatched Hostname/IP

The hostname or IP address that the user enters to navigate to Seeq must be listed as a name in the certificate. For example, the certificate may include the fully-qualified name (FQN) such as "https://seeq.customer.com". But if users accessed the Seeq server using only "https://seeq", the browser would reject the certificate and cause the connection to fail. Resolution to this problem is to generate a new certificate signing request (CSR) with the Subject Alternative Name (SAN) field populated with all possible hostnames or IP addresses that users might use to access the server.

Known Issues

Connectors that use the JVM agent aren't shown on the connected datasources. The error "unable to find valid certification path to requested target" is shown in the jvm-link.log

In some situations, using a self-signed or internal CA issued certificate can result in an error in the jvm-link.log similar to below:

ERROR 2019-04-02T09:26:56.987+02:00 [Connection: https://my.server.tld:443/api] com.seeq.link.agent.DefaultLoginAuthManager - Error authenticating against the API
shaded.seeq.javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

In this situation connections that run inside the JVM agent do not show up on the sources list and when trying to use datasources that use JVM it will throw an error on the interface similar to below:

Solution:

Add the certificate to the necessary trust stores:

Adding to cacerts

• On the Seeq server and any connected remote agent desktop open a Command Prompt with administrator access and do the following:

  • cd "C:\Program Files\Seeq Server\jdk\files\bin"

  • keytool -import -trustcacerts -file "c:\my.cer" -alias mydomain -keystore "C:\Program Files\Seeq Server\jdk\files\lib\security\cacerts"

Changing -file "c:\my.cer" & -alias mydomain to the location of the certificate and a unique alias.

• When prompted for a password enter: changeit

• If prompted type yes and hit enter.

Connectors that use the .NET agent aren't shown on the connected datasources. The error "Error calling Login: The request was aborted: Could not create SSL/TLS secure channel." is shown in the net-link.log

On Windows based servers the following errors may be seen in the net-link.log if .NET on the server is not set to use TLS1.2:

Error 1:

ERROR 2019-05-24T12:32:00.958-07:00 [Connection: https://myserver.tld:443/api] Seeq.Link.Agent.LoginAuthManager Error authenticating against the API
Seeq.Sdk.Client.ApiException: Error calling Login: The request was aborted: Could not create SSL/TLS secure channel.
at Seeq.Sdk.Api.AuthApi.LoginWithHttpInfo(AuthInputV1 body)
at Seeq.Sdk.Api.AuthApi.Login(AuthInputV1 body)
at Seeq.Link.Agent.LoginAuthManager.getAuthorizationToken() in C:\build\CRAB-CWO198-JOB1\net-link\agent\Seeq.Link.Agent\LoginAuthManager.cs:line 70

Error 2:

ERROR 2019-06-04T13:23:44.179-04:00 [Connection: https://myserver.tld:443/api] Seeq.Link.Agent.LoginAuthManager Error authenticating against the API
Seeq.Sdk.Client.ApiException: Error calling Login: The underlying connection was closed: An unexpected error occurred on a receive.
at Seeq.Sdk.Api.AuthApi.LoginWithHttpInfo(AuthInputV1 body)
at Seeq.Sdk.Api.AuthApi.Login(AuthInputV1 body)
at Seeq.Link.Agent.LoginAuthManager.getAuthorizationToken() in C:\build\CRAB-CWO182-JOB1\net-link\agent\Seeq.Link.Agent\LoginAuthManager.cs:line 70

Solution:

Enable TLS 1.2 for the .NET framework by following the steps below on the Seeq server:

• Verify this is the same issue by opening PowerShell on the Seeq server and executing: Invoke-WebRequest -Uri http://myseeqserver.tld - where myseeqserver.tld is the address of the Seeq server. This should return error stating "Could not create SSL/TLS secure channel"

• In PowerShell now execute: [Net.ServicePointManager]::SecurityProtocol - this should confirm that TLS12 is not present on the list.

The next steps should be completed by the IT team/systems administrator after a recent backup:

• Open Registry Editor and locate: HKLM > Software > Microsoft > .NETFrameWork > v4.0.30319 and add a DWORD called SchUseStrongCrypto with the value 1

• Whilst still in Registry Editor and locate: HKLM > Software > WOW6432Node > Microsoft > .NETFrameWork > v4.0.30319 and add a DWORD called SchUseStrongCrypto with the value 1

• Close PowerShell & re-open it to reflect the changes.

• In PowerShell execute: Invoke-WebRequest -Uri http://myseeqserver.tld - where myseeqserver.tld is the address of the Seeq server. This should now return the contents of the page.

• In PowerShell execute: [Net.ServicePointManager]::SecurityProtocol - this should now show TLS12 in the returned protocols.

• Verify in the net-link.log that the errors have disappeared and check the connected datasources list to confirm it is now connected.

Note:  Having TLS1.2 enabled exclusively may not work - you may need to have TLS1.0 enabled as well to get the link to establish.