com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later.

Atlassian JIRA | Christopher Parker [Atlassian] | 1 year ago
  1. 0

    h3. Summary As of Java 1.8u51+ (also 1.7.0_85+ and 1.6.0_101+) making SSL connections to an IP address is no longer allowed. Previously the JVM would do a reverse lookup of the hostname using the IP then complete the connection using that hostname. This was a security vulnerability because an attacker that gained control of DNS could route traffic to their own server. This change is a security feature of Java. We have found there is a problem with the way Java creates LDAPS connections. The way Socket.createSocket() is used results in an SSLSocket without the hostname set in it. This results in use of an IP address to make the connection and since this is no longer allowed the connection fails. We have reported this problem to Oracle and also forwarded the information to the Java security dev list: http://mail.openjdk.java.net/pipermail/security-dev/2015-September/012845.html . Because of this _*existing LDAPS connections are broken*_ and users from that user directory are unable to login including non-local administrators. This will affect any customer using secure LDAP that upgrades the JVM. Secure LDAP is very common to protect passwords on the internal network, particularly in enterprise environments. h3. Environment * Any version of Stash using one of the noted Java versions. h3. Steps to Reproduce # Configure a user directory using a secure LDAP connection # Upgrade the JDK to a noted Java version. h3. Expected Results Logins and LDAP syncs should work as normal. h3. Actual Results Users will be unable to authenticate and LDAP syncs will fail. Errors like this will occur in the logs: {code:borderStyle=solid} 2015-07-22 12:43:05,896 WARN [http-bio-443-exec-1] @1SDVDDx763x1x0 XXXXX "POST /j_stash_security_check HTTP/1.1" c.a.s.i.s.s.PluginAuthenticationProvider Could not authenticate XXXXX; authentication by com.atlassian.stash.stash-authentication:crowdHttpAuthHandler failed com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later. at com.atlassian.stash.internal.crowd.RiotPolice.authenticate(RiotPolice.java:113) ~[stash-service-impl-3.11.1.jar:na] at com.atlassian.stash.internal.user.DefaultUserService.authenticate(DefaultUserService.java:108) ~[stash-service-impl-3.11.1.jar:na] ... ... 21 common frames omitted Caused by: org.springframework.transaction.CannotCreateTransactionException: Could not create DirContext instance for transaction; nested exception is org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.transaction.compensating.support.AbstractCompensatingTransactionManagerDelegate.doBegin(AbstractCompensatingTransactionManagerDelegate.java:90) ~[spring-ldap-core-2.0.2.RELEASE.jar:2.0.2.RELEASE] ... ... 22 common frames omitted Caused by: org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:108) ... ... 39 common frames omitted Caused by: javax.naming.CommunicationException: <DNS.NAME>:636 at com.sun.jndi.ldap.Connection.<init>(Unknown Source) ~[na:1.8.0_51] at com.sun.jndi.ldap.LdapClient.<init>(Unknown Source) ~[na:1.8.0_51] ... ... 43 common frames omitted Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.ssl.Alerts.getSSLException(Unknown Source) ~[na:1.8.0_51] at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) ~[na:1.8.0_51] ... ... 58 common frames omitted Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.util.HostnameChecker.matchIP(Unknown Source) ~[na:1.8.0_51] ... ... 67 common frames omitted {code} h3. Workaround *Option 1: Add JVM startup parameter {{-Djdk.tls.trustNameService=true}}* This reverts back to the older Java behavior while preserving all the other security related changes in the newer Java release. Your LDAP data will still be encrypted. The risk is described by Oracle in their explanation of the change at http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html : {quote}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.{quote} *Option 2: Under the LDAP connection "Advanced Settings" set "Secure SSL" to disabled* As stated in the UI this will disable all verification of the SSL certificate. Your LDAP data will still be encrypted. (!) This workaround may represent a greater vulnerability as any SSL cert could be substituted with no need to compromise a DNS server.

    Atlassian JIRA | 1 year ago | Christopher Parker [Atlassian]
    com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later.
  2. 0

    h3. Summary As of Java 1.8u51+ (also 1.7.0_85+ and 1.6.0_101+) making SSL connections to an IP address is no longer allowed. Previously the JVM would do a reverse lookup of the hostname using the IP then complete the connection using that hostname. This was a security vulnerability because an attacker that gained control of DNS could route traffic to their own server. This change is a security feature of Java. We have found there is a problem with the way Java creates LDAPS connections. The way Socket.createSocket() is used results in an SSLSocket without the hostname set in it. This results in use of an IP address to make the connection and since this is no longer allowed the connection fails. We have reported this problem to Oracle and also forwarded the information to the Java security dev list: http://mail.openjdk.java.net/pipermail/security-dev/2015-September/012845.html . Because of this _*existing LDAPS connections are broken*_ and users from that user directory are unable to login including non-local administrators. This will affect any customer using secure LDAP that upgrades the JVM. Secure LDAP is very common to protect passwords on the internal network, particularly in enterprise environments. This is exacerbated by Confluence 5.8.8 which ships with Java 1.8.0u51. h3. Environment * Any version of Confluence using one of the noted Java versions. h3. Steps to Reproduce # Configure a user directory using a secure LDAP connection # Upgrade the JDK to a noted Java version. h3. Expected Results Logins and LDAP syncs should work as normal. h3. Actual Results Users will be unable to authenticate and LDAP syncs will fail. Errors like this will occur in the logs: {code:borderStyle=solid} 2015-07-22 12:43:05,896 WARN [http-bio-443-exec-1] @1SDVDDx763x1x0 XXXXX "POST /j_stash_security_check HTTP/1.1" c.a.s.i.s.s.PluginAuthenticationProvider Could not authenticate XXXXX; authentication by com.atlassian.stash.stash-authentication:crowdHttpAuthHandler failed com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later. at com.atlassian.stash.internal.crowd.RiotPolice.authenticate(RiotPolice.java:113) ~[stash-service-impl-3.11.1.jar:na] at com.atlassian.stash.internal.user.DefaultUserService.authenticate(DefaultUserService.java:108) ~[stash-service-impl-3.11.1.jar:na] ... ... 21 common frames omitted Caused by: org.springframework.transaction.CannotCreateTransactionException: Could not create DirContext instance for transaction; nested exception is org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.transaction.compensating.support.AbstractCompensatingTransactionManagerDelegate.doBegin(AbstractCompensatingTransactionManagerDelegate.java:90) ~[spring-ldap-core-2.0.2.RELEASE.jar:2.0.2.RELEASE] ... ... 22 common frames omitted Caused by: org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:108) ... ... 39 common frames omitted Caused by: javax.naming.CommunicationException: <DNS.NAME>:636 at com.sun.jndi.ldap.Connection.<init>(Unknown Source) ~[na:1.8.0_51] at com.sun.jndi.ldap.LdapClient.<init>(Unknown Source) ~[na:1.8.0_51] ... ... 43 common frames omitted Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.ssl.Alerts.getSSLException(Unknown Source) ~[na:1.8.0_51] at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) ~[na:1.8.0_51] ... ... 58 common frames omitted Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.util.HostnameChecker.matchIP(Unknown Source) ~[na:1.8.0_51] ... ... 67 common frames omitted {code} h3. Workaround * Add JVM startup parameter {{-Djdk.tls.trustNameService=true}} ** This reverts back to the older Java behavior while preserving all the other security related changes in the newer Java release. ** Your LDAP data will still be encrypted. The risk is described by Oracle in their explanation of the change at http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html : {quote}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.{quote} * Under the LDAP connection "Advanced Settings" set "Secure SSL" to disabled ** As stated in the UI this will disable all verification of the SSL certificate. Your LDAP data will still be encrypted. ** (!) This workaround may represent a greater vulnerability as any SSL cert could be substituted with no need to compromise a DNS server. h3. Resolution * Upgrade Java to Java 8u65 (if running Confluence 5.7 or above) ** This version includes a fix for the bug that causes this issue [JDK-8135194|https://bugs.openjdk.java.net/browse/JDK-8135194]

    Atlassian JIRA | 1 year ago | Christopher Parker [Atlassian]
    com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later.
  3. 0

    h3. Summary As of Java 1.8u51+ (also 1.7.0_85+ and 1.6.0_101+) making SSL connections to an IP address is no longer allowed. Previously the JVM would do a reverse lookup of the hostname using the IP then complete the connection using that hostname. This was a security vulnerability because an attacker that gained control of DNS could route traffic to their own server. This change is a security feature of Java. We have found there is a problem with the way Java creates LDAPS connections. The way Socket.createSocket() is used results in an SSLSocket without the hostname set in it. This results in use of an IP address to make the connection and since this is no longer allowed the connection fails. We have reported this problem to Oracle and also forwarded the information to the Java security dev list: http://mail.openjdk.java.net/pipermail/security-dev/2015-September/012845.html . Because of this _*existing LDAPS connections are broken*_ and users from that user directory are unable to login including non-local administrators. This will affect any customer using secure LDAP that upgrades the JVM. Secure LDAP is very common to protect passwords on the internal network, particularly in enterprise environments. h3. Environment * Any version of Crowd using one of the noted Java versions. h3. Steps to Reproduce # Configure a user directory using a secure LDAP connection # Upgrade the JDK to a noted Java version. h3. Expected Results Logins and LDAP syncs should work as normal. h3. Actual Results Users will be unable to authenticate and LDAP syncs will fail. Errors like this will occur in the logs: {code:borderStyle=solid} 2015-07-22 12:43:05,896 WARN [http-bio-443-exec-1] @1SDVDDx763x1x0 XXXXX "POST /j_stash_security_check HTTP/1.1" c.a.s.i.s.s.PluginAuthenticationProvider Could not authenticate XXXXX; authentication by com.atlassian.stash.stash-authentication:crowdHttpAuthHandler failed com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later. at com.atlassian.stash.internal.crowd.RiotPolice.authenticate(RiotPolice.java:113) ~[stash-service-impl-3.11.1.jar:na] at com.atlassian.stash.internal.user.DefaultUserService.authenticate(DefaultUserService.java:108) ~[stash-service-impl-3.11.1.jar:na] ... ... 21 common frames omitted Caused by: org.springframework.transaction.CannotCreateTransactionException: Could not create DirContext instance for transaction; nested exception is org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.transaction.compensating.support.AbstractCompensatingTransactionManagerDelegate.doBegin(AbstractCompensatingTransactionManagerDelegate.java:90) ~[spring-ldap-core-2.0.2.RELEASE.jar:2.0.2.RELEASE] ... ... 22 common frames omitted Caused by: org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:108) ... ... 39 common frames omitted Caused by: javax.naming.CommunicationException: <DNS.NAME>:636 at com.sun.jndi.ldap.Connection.<init>(Unknown Source) ~[na:1.8.0_51] at com.sun.jndi.ldap.LdapClient.<init>(Unknown Source) ~[na:1.8.0_51] ... ... 43 common frames omitted Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.ssl.Alerts.getSSLException(Unknown Source) ~[na:1.8.0_51] at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) ~[na:1.8.0_51] ... ... 58 common frames omitted Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.util.HostnameChecker.matchIP(Unknown Source) ~[na:1.8.0_51] ... ... 67 common frames omitted {code} h2. Fix: install a Java version equal to or newer than 1.8u65 Java version 1.8u65 contains a fix [JDK-8133196|https://bugs.openjdk.java.net/browse/JDK-8133196] which addresses the problem described in this issue. Please see [How to Use System JRE Instead of Embedded JRE|https://confluence.atlassian.com/display/JIRA/How+to+Use+System+JRE+Instead+of+Embedded+JRE] for instructions to change the version of Java that JIRA runs with. h3. Workaround (!) Only necessary if you do not upgrade your Java JDK. h5. Add JVM startup parameter {{-Djdk.tls.trustNameService=true}} This reverts back to the older Java behavior while preserving all the other security related changes in the newer Java release. Your LDAP data will still be encrypted. The risk is described by Oracle in their explanation of the change at http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html. h5. Disable SSL check Under the LDAP connection "Advanced Settings" set "Secure SSL" to disabled*. As stated in the UI this will disable all verification of the SSL certificate. Your LDAP data will still be encrypted. (!) This workaround may represent a greater vulnerability as any SSL cert could be substituted with no need to compromise a DNS server.

    Atlassian JIRA | 1 year ago | Christopher Parker [Atlassian]
    com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later.
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    h3. Summary As of Java 1.8u51+ (also 1.7.0_85+ and 1.6.0_101+) making SSL connections to an IP address is no longer allowed. Previously the JVM would do a reverse lookup of the hostname using the IP then complete the connection using that hostname. This was a security vulnerability because an attacker that gained control of DNS could route traffic to their own server. This change is a security feature of Java. We have found there is a problem with the way Java creates LDAPS connections. The way Socket.createSocket() is used results in an SSLSocket without the hostname set in it. This results in use of an IP address to make the connection and since this is no longer allowed the connection fails. We have reported this problem to Oracle and also forwarded the information to the Java security dev list: http://mail.openjdk.java.net/pipermail/security-dev/2015-September/012845.html . Because of this _*existing LDAPS connections are broken*_ and users from that user directory are unable to login including non-local administrators. This will affect any customer using secure LDAP that upgrades the JVM. Secure LDAP is very common to protect passwords on the internal network, particularly in enterprise environments. This is exacerbated by JIRA 6.4.11 which ships with 1.8u51. h3. Environment * Verified: JIRA 6.3+ using the noted Java versions. * Suspected: All versions of JIRA using a noted Java version. h3. Steps to Reproduce # Configure a user directory using a secure LDAP connection # Upgrade the JDK to a noted Java version. h3. Expected Results Logins and LDAP syncs should work as normal. h3. Actual Results Users will be unable to authenticate and LDAP syncs will fail. Errors like this will occur in the logs: {code:borderStyle=solid} 2015-07-22 12:43:05,896 WARN [http-bio-443-exec-1] @1SDVDDx763x1x0 XXXXX "POST /j_stash_security_check HTTP/1.1" c.a.s.i.s.s.PluginAuthenticationProvider Could not authenticate XXXXX; authentication by com.atlassian.stash.stash-authentication:crowdHttpAuthHandler failed com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later. at com.atlassian.stash.internal.crowd.RiotPolice.authenticate(RiotPolice.java:113) ~[stash-service-impl-3.11.1.jar:na] at com.atlassian.stash.internal.user.DefaultUserService.authenticate(DefaultUserService.java:108) ~[stash-service-impl-3.11.1.jar:na] ... ... 21 common frames omitted Caused by: org.springframework.transaction.CannotCreateTransactionException: Could not create DirContext instance for transaction; nested exception is org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.transaction.compensating.support.AbstractCompensatingTransactionManagerDelegate.doBegin(AbstractCompensatingTransactionManagerDelegate.java:90) ~[spring-ldap-core-2.0.2.RELEASE.jar:2.0.2.RELEASE] ... ... 22 common frames omitted Caused by: org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:108) ... ... 39 common frames omitted Caused by: javax.naming.CommunicationException: <DNS.NAME>:636 at com.sun.jndi.ldap.Connection.<init>(Unknown Source) ~[na:1.8.0_51] at com.sun.jndi.ldap.LdapClient.<init>(Unknown Source) ~[na:1.8.0_51] ... ... 43 common frames omitted Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.ssl.Alerts.getSSLException(Unknown Source) ~[na:1.8.0_51] at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) ~[na:1.8.0_51] ... ... 58 common frames omitted Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.util.HostnameChecker.matchIP(Unknown Source) ~[na:1.8.0_51] ... ... 67 common frames omitted {code} h3. Suspected Cause Crowd is resolving DNS name into IP and then connects to LDAP server using the IP instead of the hostname. As a result, the underlying Java code tries to compare the destination IP with the DN in the certificate. If this is verified as the cause then the same issue will occur when the reverse-lookup IP doesn't match DN in certificate (DNS1 -> IP -> DNS2). This situation is quite common. h2. Fix: install a Java version equal to or newer than 1.8u65 Java version 1.8u65 contains a fix [JDK-8133196|https://bugs.openjdk.java.net/browse/JDK-8133196] which addresses the problem described in this issue. Please see [How to Use System JRE Instead of Embedded JRE|https://confluence.atlassian.com/display/JIRA/How+to+Use+System+JRE+Instead+of+Embedded+JRE] for instructions to change the version of Java that JIRA runs with. h3. Workaround (!) Only necessary if you do not upgrade your Java JDK. If your version of JIRA does not support Java 8 or you cannot upgrade to 1.8u65 a workaround is necessary. h5. Add JVM startup parameter {{-Djdk.tls.trustNameService=true}} This reverts back to the older Java behavior while preserving all the other security related changes in the newer Java release. Your LDAP data will still be encrypted. The risk is described by Oracle in their explanation of the change at http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html. h5. Disable SSL check Under the LDAP connection "Advanced Settings" set "Secure SSL" to disabled*. As stated in the UI this will disable all verification of the SSL certificate. Your LDAP data will still be encrypted. (!) This workaround may represent a greater vulnerability as any SSL cert could be substituted with no need to compromise a DNS server.

    Atlassian JIRA | 1 year ago | Pelle Kirkeby
    com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later.
  6. 0

    h3. Summary As of Java 1.8u51+ (also 1.7.0_85+ and 1.6.0_101+) making SSL connections to an IP address is no longer allowed. Previously the JVM would do a reverse lookup of the hostname using the IP then complete the connection using that hostname. This was a security vulnerability because an attacker that gained control of DNS could route traffic to their own server. This change is a security feature of Java. We have found there is a problem with the way Java creates LDAPS connections. The way Socket.createSocket() is used results in an SSLSocket without the hostname set in it. This results in use of an IP address to make the connection and since this is no longer allowed the connection fails. We have reported this problem to Oracle and also forwarded the information to the Java security dev list: http://mail.openjdk.java.net/pipermail/security-dev/2015-September/012845.html . Because of this _*existing LDAPS connections are broken*_ and users from that user directory are unable to login including non-local administrators. This will affect any customer using secure LDAP that upgrades the JVM. Secure LDAP is very common to protect passwords on the internal network, particularly in enterprise environments. h3. Environment * Any version of Stash using one of the noted Java versions. h3. Steps to Reproduce # Configure a user directory using a secure LDAP connection # Upgrade the JDK to a noted Java version. h3. Expected Results Logins and LDAP syncs should work as normal. h3. Actual Results Users will be unable to authenticate and LDAP syncs will fail. Errors like this will occur in the logs: {code:borderStyle=solid} 2015-07-22 12:43:05,896 WARN [http-bio-443-exec-1] @1SDVDDx763x1x0 XXXXX "POST /j_stash_security_check HTTP/1.1" c.a.s.i.s.s.PluginAuthenticationProvider Could not authenticate XXXXX; authentication by com.atlassian.stash.stash-authentication:crowdHttpAuthHandler failed com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later. at com.atlassian.stash.internal.crowd.RiotPolice.authenticate(RiotPolice.java:113) ~[stash-service-impl-3.11.1.jar:na] at com.atlassian.stash.internal.user.DefaultUserService.authenticate(DefaultUserService.java:108) ~[stash-service-impl-3.11.1.jar:na] ... ... 21 common frames omitted Caused by: org.springframework.transaction.CannotCreateTransactionException: Could not create DirContext instance for transaction; nested exception is org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.transaction.compensating.support.AbstractCompensatingTransactionManagerDelegate.doBegin(AbstractCompensatingTransactionManagerDelegate.java:90) ~[spring-ldap-core-2.0.2.RELEASE.jar:2.0.2.RELEASE] ... ... 22 common frames omitted Caused by: org.springframework.ldap.CommunicationException: <DNS.NAME>:636; nested exception is javax.naming.CommunicationException: <DNS.NAME>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found] at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:108) ... ... 39 common frames omitted Caused by: javax.naming.CommunicationException: <DNS.NAME>:636 at com.sun.jndi.ldap.Connection.<init>(Unknown Source) ~[na:1.8.0_51] at com.sun.jndi.ldap.LdapClient.<init>(Unknown Source) ~[na:1.8.0_51] ... ... 43 common frames omitted Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.ssl.Alerts.getSSLException(Unknown Source) ~[na:1.8.0_51] at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source) ~[na:1.8.0_51] ... ... 58 common frames omitted Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address XXXXX found at sun.security.util.HostnameChecker.matchIP(Unknown Source) ~[na:1.8.0_51] ... ... 67 common frames omitted {code} h3. Workaround *Option 1: Add JVM startup parameter {{-Djdk.tls.trustNameService=true}}* This reverts back to the older Java behavior while preserving all the other security related changes in the newer Java release. Your LDAP data will still be encrypted. The risk is described by Oracle in their explanation of the change at http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html : {quote}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.{quote} *Option 2: Under the LDAP connection "Advanced Settings" set "Secure SSL" to disabled* As stated in the UI this will disable all verification of the SSL certificate. Your LDAP data will still be encrypted. (!) This workaround may represent a greater vulnerability as any SSL cert could be substituted with no need to compromise a DNS server.

    Atlassian JIRA | 1 year ago | Christopher Parker [Atlassian]
    com.atlassian.stash.user.AuthenticationSystemException: The remote authentication server is not available. Please try again later.

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. com.atlassian.stash.user.AuthenticationSystemException

      The remote authentication server is not available. Please try again later.

      at com.atlassian.stash.internal.crowd.RiotPolice.authenticate()
    2. com.atlassian.stash
      DefaultUserService.authenticate
      1. com.atlassian.stash.internal.crowd.RiotPolice.authenticate(RiotPolice.java:113)[stash-service-impl-3.11.1.jar:na]
      2. com.atlassian.stash.internal.user.DefaultUserService.authenticate(DefaultUserService.java:108)[stash-service-impl-3.11.1.jar:na]
      2 frames