由于OpenJDk Java 11收到javax.net.ssl.SSLHandshakeException:收到致命警报:handshake_failure [英] Since OpenJDk Java 11 getting javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

查看：844
本文介绍了由于OpenJDk Java 11收到javax.net.ssl.SSLHandshakeException:收到致命警报:handshake_failure的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

最近将应用程序从Oracle Java 9更新到了AdoptJDk 11.0.6，现在我看到以下代码形式的错误:

Have recently updated application from Oracle Java 9 to AdoptJDk 11.0.6 and I am now seeing errors of the form this code:

 public static String convertWikidataUrl(String wikidataUrl)
    {
        String qPage  = wikidataUrl.substring(wikidataUrl.lastIndexOf('/') + 1);
        String apiUrl = WIKIDATA_IMAGE_API_URL + qPage;
        try
        {
            URL url = new URL(apiUrl);
            HttpURLConnection uc = (HttpURLConnection) url.openConnection();
            int responseCode = uc.getResponseCode();
            if (responseCode != HttpURLConnection.HTTP_OK)
            {
                MainWindow.logger.severe(":ResponseCode:"+responseCode);

            }

            //Everything ok so continue
            BufferedInputStream bis = new BufferedInputStream(uc.getInputStream());
            JAXBContext jc = getWikidataInitialContext();
            Unmarshaller um = jc.createUnmarshaller();
            Api api = (Api) um.unmarshal(bis);
            if(api.getClaims()!=null
                    && api.getClaims().getProperty()!=null
                    && api.getClaims().getProperty().getClaim()!=null
                    && api.getClaims().getProperty().getClaim().getMainsnak()!=null
                    && api.getClaims().getProperty().getClaim().getMainsnak().getDatavalue()!=null)
            {
                return api.getClaims().getProperty().getClaim().getMainsnak().getDatavalue().getValue();
            }
            else
            {
                return null;
            }
        }
        catch (JAXBException e)
        {
            MainWindow.logger.log(Level.SEVERE, e.getMessage(), e);
        }
        catch (MalformedURLException mue)
        {
            MainWindow.logger.log(Level.SEVERE, mue.getMessage(), mue);
        }
        catch (Exception ex)
        {
            MainWindow.logger.log(Level.SEVERE, ex.getMessage(), ex);
        }
        return null;
    }

失败:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307)
    at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:291)
    at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:180)
    at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
    at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151)
    at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062)
    at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
    at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
    at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
    at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515)
    at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527)
    at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:334)
    at com.jthink.songkong.analyse.musicbrainz.WikipediaImage.convertWikipediaUrl(WikipediaImage.java:49)
    at com.jthink.songkong.analyse.musicbrainz.ArtistArtwork.findArtistImageLink(ArtistArtwork.java:54)
    at com.jthink.songkong.analyse.musicbrainz.ArtistArtworkOnlineLookup.call(ArtistArtworkOnlineLookup.java:63)
    at com.jthink.songkong.analyse.musicbrainz.ArtistArtworkOnlineLookup.call(ArtistArtworkOnlineLookup.java:26)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)

该问题已在Windows上看到，但也可能在其他平台上发生

The problem has been seen on Windows but may occur on other platforms as well

肯定是由于JRE更改引起的错误，但是我不知道问题是从Java 9迁移到11，还是从Oracle迁移到AdoptJdk，我该如何解决呢?

The error is definitently due to changing JRE but I don't know if the issue is moving from Java 9 to 11, or moving from Oracle to AdoptJdk, how can I resolve this ?

更新

  1. 在使用11.0.6的MacOS上不会发生此问题
  2. 在Windows上，从11.0.6升级到11.0.7无效
  3. 在Windows上添加-Dhttps.protocols = TLSv1.1，TLSv1.2(禁用TLS1.3支持)可解决此问题.
  4. 此错误的可能版本 https://bugs.openjdk.java.net/浏览/JDK-8206923
  1. The problem does not occur on MacOS using 11.0.6
  2. On Windows Updating from 11.0.6 to 11.0.7 had no effect
  3. On Windows adding -Dhttps.protocols=TLSv1.1,TLSv1.2 (to disabled TLS1.3 support) fixes the issue.
  4. Possibly version of this bug https://bugs.openjdk.java.net/browse/JDK-8206923

推荐答案

客户端无法打开与服务器的连接，因为它们可能不支持相同的TLS版本或设置.

The client can't open a connection to the server because they likely don't support the same TLS versions or settings.

尝试通过以下方式启动应用程序:

Try to start the application with:

  • -Dhttps.protocols=TLSv1.2
  • -Dhttps.protocols=TLSv1.3
  • -Dhttps.protocols=TLSv1.0
  • -Dhttps.protocols=TLSv1.2
  • -Dhttps.protocols=TLSv1.3
  • -Dhttps.protocols=TLSv1.0

TLSv1.2(2008)是TLS的当前受支持版本，该版本已部署到任何地方，并得到所有地方的支持.这是安全的默认设置，是迫使事情正常进行的原因.

TLSv1.2 (2008) is the currently supported version of TLS that is deployed everywhere and supported by everywhere. That's the safe default and what to force for things to just work.

TLSv1.3(2018)是即将发布的版本.它正在缓慢地遍及所有地方(Web服务器，应用程序，负载平衡器，CDN等).过渡应该是无缝的，但事实并非如此，没有软件是第一次完美的尝试，并且会出现一些错误和不兼容性. JDK 11引入了TLSv1.3，并在默认情况下尝试使用它，但由于出现该错误，效果并不理想，因此，解决方法是强制使用TLSv1.2.

TLSv1.3 (2018) is the upcoming version. It's being rolled across everywhere slowly (web servers, applications, load balancers, CDN, etc...). The transition should be seamless but it's not quite the case, no software is perfect on the first try and there are some bugs and incompatibilities coming up. The JDK 11 introduces TLSv1.3 and tries to use it by default, which didn't go well given the error, so the workaround is to force using TLSv1.2 instead.

如果您依靠TLS进行客户端证书身份验证，则存在一些棘手的情况，通常在处理诸如银行API之类的高度敏感信息的企业系统中使用. TLS 1.3更改了客户端身份验证的发生方式，因此客户端和服务器软件都可能需要升级，以便完全有机会工作. HTTP/2设计破坏了客户端身份验证，RFC尚待达成解决方案的共识，同时使用HTTP/1.1.

There are tricky edge cases if you rely on TLS for client certificate authentication, often used in enterprise systems dealing with highly sensitive information like banking APIs. TLS 1.3 changed the way client authentication happens so both client and server software likely need to be upgraded for it to have a chance to work at all. HTTP/2 breaks client authentication by design, a RFC is pending to agree on a solution, in the meantime use HTTP/1.1.

TLSv1.0(1999)是一个过时的版本，禁止使用，并且已在最新的库版本(OpenSSL 1.1.x，JDK 11等)中删除.如果您使用的是多年未维护的遗留企业Java应用程序，那么到2020年，仍然有可能遇到这种情况.这些确实需要升级.

TLSv1.0 (1999) is an obsolete version that is prohibited from usage and removed in latest library versions (OpenSSL 1.1.x, JDK 11, etc...). It's possible to encounter it still as of 2020 if you work around legacy enterprise java apps that ain't been maintained for years. These really need to be upgraded.

这篇关于由于OpenJDk Java 11收到javax.net.ssl.SSLHandshakeException:收到致命警报:handshake_failure的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆