It was discovered that when acting as TLS clients, Beats, Elastic Agent, APM Server, and Fleet Server did not verify whether the server certificate is valid for the target IP address; however, certificate signature validation is still performed. More specifically, when the client is configured to connect to an IP address (instead of a hostname) it does not validate the server certificate's IP SAN values against that IP address and certificate validation fails, and therefore the connection is not blocked as expected.

Jenkins Codefresh Integration Plugin 1.8 and earlier disables SSL/TLS and hostname verification globally for the Jenkins master JVM.

The host name verification when using TLS with the WebSocket client was missing. It is now enabled by default. Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.9, 8.5.0 to 8.5.31, 8.0.0.RC1 to 8.0.52, and 7.0.35 to 7.0.88.

Philips IntelliSpace Portal all versions of 8.0.x, and 7.0.x have a self-signed SSL certificate vulnerability this could allow an attacker to gain unauthorized access to resources and information.

Philips IntelliSpace Portal all versions of 8.0.x, and 7.0.x have an SSL incorrect hostname certificate vulnerability this could allow an attacker to gain unauthorized access to resources and information.

Philips IntelliSpace Portal all versions of 8.0.x, and 7.0.x have an untrusted SSL certificate vulnerability this could allow an attacker to gain unauthorized access to resources and information.

An issue discovered in casdoor v1.636.0 allows attackers to obtain sensitive information via the ssh.InsecureIgnoreHostKey() method.

IBM Storage Defender - Resiliency Service 2.0.0 through 2.0.9 does not properly validate a certificate which could allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client.

WebCore/platform/network/soup/SocketStreamHandleImplSoup.cpp in the libsoup network backend of WebKit, as used in WebKitGTK+ versions 2.20.0 and 2.20.1, failed to perform TLS certificate verification for WebSocket connections.

An issue was discovered in Mattermost Server before 3.0.0. It does not ensure that a cookie is used over SSL.

The D-Link DIR-615 device before v20.12PTb04 doesn't use SSL for any of the authenticated pages. Also, it doesn't allow the user to generate his own SSL Certificate. An attacker can simply monitor network traffic to steal a user's credentials and/or credentials of users being added while sniffing the traffic.

Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. In versions 2.5.0 through 2.13.0, ElasticsearchWriter, GelfWriter, InfluxdbWriter and Influxdb2Writer do not verify the server's certificate despite a certificate authority being specified. Icinga 2 instances which connect to any of the mentioned time series databases (TSDBs) using TLS over a spoofable infrastructure should immediately upgrade to version 2.13.1, 2.12.6, or 2.11.11 to patch the issue. Such instances should also change the credentials (if any) used by the TSDB writer feature to authenticate against the TSDB. There are no workarounds aside from upgrading.

Versions of the puppetlabs-apache module prior to 1.11.1 and 2.1.0 make it very easy to accidentally misconfigure TLS trust. If you specify the `ssl_ca` parameter but do not specify the `ssl_certs_dir` parameter, a default will be provided for the `ssl_certs_dir` that will trust certificates from any of the system-trusted certificate authorities. This did not affect FreeBSD.

It was found that CloudForms does not verify that the server hostname matches the domain name in the certificate when using a custom CA and communicating with Red Hat Virtualization (RHEV) and OpenShift. This would allow an attacker to spoof RHEV or OpenShift systems and potentially harvest sensitive information from CloudForms.

An issue was discovered in Mattermost Server before 3.9.0 when SAML is used. Encryption and signature verification are not mandatory.

Nextcloud Android Client is the Android client for Nextcloud. Clients using the Nextcloud end-to-end encryption feature download the public and private key via an API endpoint. In versions prior to 3.16.1, the Nextcloud Android client skipped a step that involved the client checking if a private key belonged to a previously downloaded public certificate. If the Nextcloud instance served a malicious public key, the data would be encrypted for this key and thus could be accessible to a malicious actor. The vulnerability is patched in version 3.16.1. As a workaround, do not add additional end-to-end encrypted devices to a user account.

IBM InfoSphere Data Flow Designer Engine (IBM InfoSphere Information Server 11.7 ) component has improper validation of the REST API server certificate. IBM X-Force ID: 201301.

The Nextcloud Desktop Client is a tool to synchronize files from Nextcloud Server with your computer. The Desktop client did not stop with an error but allowed by-passing the signature validation, if a manipulated server sends an empty initial signature. It is recommended that the Nextcloud Desktop client is upgraded to 3.14.2 or later.

A flaw was found in stunnel before 5.57, where it improperly validates client certificates when it is configured to use both redirect and verifyChain options. This flaw allows an attacker with a certificate signed by a Certificate Authority, which is not the one accepted by the stunnel server, to access the tunneled service instead of being redirected to the address specified in the redirect option. The highest threat from this vulnerability is to confidentiality.