Java security cert certificateexception no subject alternative dns name matching found

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

java.security.cert.CertificateException: No subject alternative names present #615

java.security.cert.CertificateException: No subject alternative names present #615

Comments

Kafka version: 2.0.0
Confluent version: 5.0.0
Image name: confluentinc/cp-kafka:5.0.0
Documentation: https://docs.confluent.io/current/kafka/encryption.html#

It’s a 3 node kafka running on kubernetes using helm. I’m trying to enable SSL between fafka brokers by following the documentation on confluentinc website (Linked above).

I generate the ca cert and key on my local machine and mount it on each pod then the following script runs prior to starting kafka.

#!/bin/bash cd /etc/kafka/secrets keytool -keystore server.keystore.jks -alias localhost -validity 3650 -genkey -storepass -keypass -dname CN=kafka.namespace.svc.cluster.local -ext SAN="DNS:$,IP:$,DNS:kafka.namespace.svc.cluster.local" keytool -import -noprompt -alias CARoot -file ca-cert -keystore client.truststore.jks -storepass keytool -import -noprompt -alias CARoot -file ca-cert -keystore server.truststore.jks -storepass keytool -certreq -alias localhost -file cert-file -keystore server.keystore.jks -storepass openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-file -out cert-signed -days 3650 -CAcreateserial -passin pass: keytool -import -noprompt -alias CARoot -file ca-cert -keystore server.keystore.jks -storepass keytool -import -noprompt -alias localhost -file cert-signed -keystore server.keystore.jks -storepass exec /etc/confluent/docker/run 

I get the following error on kafka-0.

[DATETIME] ERROR [Controller targetBrokerId=0] Connection to node 0 failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient) [DATETIME] WARN [RequestSendThread controllerId=0] Controller 0's connection to broker :9093 (id: 0 rack: null) was unsuccessful (kafka.controller.RequestSendThread) org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529) at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214) at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186) at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469) at org.apache.kafka.common.network.SslTransportLayer.handshakeWrap(SslTransportLayer.java:439) at org.apache.kafka.common.network.SslTransportLayer.doHandshake(SslTransportLayer.java:304) at org.apache.kafka.common.network.SslTransportLayer.handshake(SslTransportLayer.java:258) at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:134) at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:487) at org.apache.kafka.common.network.Selector.poll(Selector.java:425) at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:510) at org.apache.kafka.clients.NetworkClientUtils.awaitReady(NetworkClientUtils.java:73) at kafka.controller.RequestSendThread.brokerReady(ControllerChannelManager.scala:279) at kafka.controller.RequestSendThread.doWork(ControllerChannelManager.scala:233) at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:82) Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at java.security.AccessController.doPrivileged(Native Method) at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at org.apache.kafka.common.network.SslTransportLayer.runDelegatedTasks(SslTransportLayer.java:393) at org.apache.kafka.common.network.SslTransportLayer.handshakeUnwrap(SslTransportLayer.java:473) at org.apache.kafka.common.network.SslTransportLayer.doHandshake(SslTransportLayer.java:331) . 9 more Caused by: java.security.cert.CertificateException: No subject alternative names present at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:145) at sun.security.util.HostnameChecker.match(HostnameChecker.java:94) at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455) at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436) at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:252) at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601) . 18 more 

I checked the crt in server.keystore.jks it has the correct SANs. I’m not sure where i should be looking for fix this.

The text was updated successfully, but these errors were encountered:

Источник

java.security.cert.CertificateException: No subject alternative DNS name matching found

Using SSL to connect Confluence to an LDAP directory can result in the following error:

java.security.cert.CertificateException: No subject alternative DNS name matching found

This error may be found within the UI when testing the directory connection or when testing user retrieval. The error also appears in /logs/atlassian-confluence.log.

Cause

There can be multiple causes to this issue.

Due to changes introduced Confluence starting at version 4.2, Confluence may check the hostname on SSL certificates when communicating with an LDAP server over SSL. What this means is that the hostname used to connect to the LDAP server must match that of the SSL certificate, or Confluence will not be able to connect to the directory. This is by design.

Another possible cause for this issue is if Advanced Settings > Follow Referrals is enabled unnecessarily in User Directory Configurations when connecting to a single-node LDAP directory without cross-domain memberships.

Resolution

Try them in following order:

1. Fix the certificate to contain the correct name. This is the preferred (and most secure) fix.
2. Uncheck «Advanced Settings > Secure SSL» in User Directory Configurations while still configuring an SSL connection. Confluence will connect to the LDAP server over SSL but will not verify that the hostname and certificate match.
   NOTE This option is only found in Confluence 5.1.3 and later, as per CONF-26049 — Getting issue details. STATUS
3. Edit /etc/hosts to allow you to use the incorrect name in the certificate. Add the FQDN on the certificate and match it to the IP address of the server.
4. Disable «Follow Referrals» in the User Directory configuration, if cross-domain memberships are not used.
5. If you are using JDK 1.8.0_51 or later (bundled in Confluence 5.8.8 and later), the JDK no longer performs reverse name lookup for IP addresses by default, as per this java doc. You can re-enable reverse lookup by adding ‘-Djdk.tls.trustNameService=true’ to your system parameters.

If an application does need to perform reverse name lookup for raw IP addresses in SSL/TLS connections, and encounter endpoint identification compatibility issue, System property «jdk.tls.trustNameService» can be used to switch on reverse name lookup. Note that if the name service is not trustworthy, enabling reverse name lookup may be susceptible to MITM attacks.

Источник

java.security.cert.CertificateException: No subject alternative DNS name matching found

Connection from JIRA to LDAPS (LDAP with SSL enabled) fails with the above exception.

The following appears in atlassian-jira.log :

com.atlassian.crowd.exception.OperationFailedException: java.util.concurrent.ExecutionException: com.atlassian.crowd.exception.OperationFailedException: org.springframework.ldap.PartialResultException: nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: simple bind failed: :636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching found.]] OR nested exception is javax.naming.CommunicationException: :636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching found.]

Diagnosis

One or more of the following scenarios may apply:

1. The LDAP server hostname has changed but it’s still using an old SSL certificate that refers to the old hostname
2. JIRA and/or Java has recently been upgraded/updated whereby JIRA is now using Java version 1.8.0_181 or above
3. There are a bunch of LDAP servers in the same forest that can communicate with one another with Follow Referrals enabled

Causes

Cause 1

According to CWD-2690, JIRA now verifies if the CN/SANs of the SSL certificate matches the hostname of the LDAP server. If there’s a mismatch, JIRA will fail the connection and throws the above error. For example:

• LDAP server hostname is ldapserver.com
• CN/SANs of SSL certificate is jiradirectory.com
• JIRA is using ldapserver.com to connect to LDAP, which differs from jiradirectory.com

Cause 2

JIRA is connected to LDAP server 1 with Follow Referrals enabled. With this configuration, LDAP server 1 may attempt to communicate with LDAP server 2 that may have a different hostname and/or SSL certificate, causing an unexpected mismatch.

Workarounds

For Cause 1

Workaround 1

Edit the hosts file in the JIRA server and map the CN of the SSL certificate to the IP address of the LDAP server. Then connect JIRA to LDAP using that CN.

Following the example in Cause 1 section:

Workaround 2

Disable Secure SSL by editing the LDAP directory and unchecking that box from Advanced Settings.

If JIRA is using Java 1.8.0_181 or above ( refer to JRASERVER-66241 ), the following JVM parameter must also be set following Setting properties and options on startup :

Refer to JDK 8u181 Update Release Notes for more details on this.

For Cause 2

Disable Follow Referrals by editing the LDAP directory and unchecking that box from Advanced Settings.

Resolution

This applies to Cause 1 only

Источник