SSL/TLS Certificate validation failing

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL/TLS Certificate validation failing

mtotman
  We have an app running on Tomcat 7 / Open JDK 7 on Linux that needs to read a web page from another server. That server recently tightened it's allowed protocols down to only the following:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Since Open JDK 7 doesn't support those, I am trying to switch to BouncyCastle v1.66 but I'm having issues making it work.

I've created a standalone test app to attempt to access the same page and it's failing with the following error:
Sep 22, 2020 1:21:14 PM org.bouncycastle.jsse.provider.ProvTlsClient notifyAlertRaised
INFO: Client raised fatal(2) certificate_unknown(46) alert: Failed to read record
org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
 at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsUtils.processServerCertificate(Unknown Source)
...

This happens with 'https://google.com" as the destination, not just the page I originally wanted.

I did find a prior discussion about something BC was doing, referring to this comment in GitHub. I tried that suggested fix, but I still get this certificate error. Also, that would require updating our system to Java 8 and I'd rather not open that can of worms yet if I can avoid it.

I'm using the default TrustStore which should get me the base CACerts, as I understand it:
trustMgrFact = TrustManagerFactory.getInstance("PKIX", BouncyCastleJsseProvider.PROVIDER_NAME);
trustMgrFact.init((KeyStore) null);

Any idea what else I could be doing wrong?

Full source of my test code is available in GitHub here.

Full stacktrace of the errors:
Reading from URL 'https://google.com'.
Sep 22, 2020 1:21:14 PM org.bouncycastle.jsse.provider.ProvTlsClient notifyAlertRaised
INFO: Client raised fatal(2) certificate_unknown(46) alert: Failed to read record
org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsUtils.processServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.handleServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at java.net.URL.openStream(URL.java:1045)
at TestEula.parseEulaFromUrl(TestEula.java:165)
at TestEula.getEulaEnhanced(TestEula.java:118)
at TestEula.main(TestEula.java:33)
Caused by: java.security.cert.CertificateException: No subject alternative name found matching IP address 216.58.193.78
at org.bouncycastle.jsse.provider.HostnameUtil.checkHostname(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkExtendedTrust(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(Unknown Source)
... 22 more

org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsUtils.processServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.handleServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at java.net.URL.openStream(URL.java:1045)
at TestEula.parseEulaFromUrl(TestEula.java:165)
at TestEula.getEulaEnhanced(TestEula.java:118)
at TestEula.main(TestEula.java:33)
Caused by: java.security.cert.CertificateException: No subject alternative name found matching IP address 216.58.193.78
at org.bouncycastle.jsse.provider.HostnameUtil.checkHostname(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkExtendedTrust(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(Unknown Source)
... 22 more
certificate_unknown(46)
--
Mike Totman
SafedoorPM Lead developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS Certificate validation failing

Eckenfels. Bernd

Sitenote, if you ask me that is no "tightening down", using DHE, especially with the default 1024 or 2048 bit groups is not really secure anymore - and an interop nightmare. It would probably be better to use TLS_ECDHE_RSA_AES256_GCM_SHA384 instea. Having said that, not beein able to communicate with partners sounds like a very secure server :) 


Gruss

Bernd

-- 

http://www.seeburger.com

From: Mike Totman <[hidden email]>
Sent: Tuesday, September 22, 2020 9:38:08 PM
To: [hidden email]
Subject: [dev-crypto] SSL/TLS Certificate validation failing
 
  We have an app running on Tomcat 7 / Open JDK 7 on Linux that needs to read a web page from another server. That server recently tightened it's allowed protocols down to only the following:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Since Open JDK 7 doesn't support those, I am trying to switch to BouncyCastle v1.66 but I'm having issues making it work.

I've created a standalone test app to attempt to access the same page and it's failing with the following error:
Sep 22, 2020 1:21:14 PM org.bouncycastle.jsse.provider.ProvTlsClient notifyAlertRaised
INFO: Client raised fatal(2) certificate_unknown(46) alert: Failed to read record
org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
 at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsUtils.processServerCertificate(Unknown Source)
...

This happens with 'https://google.com" as the destination, not just the page I originally wanted.

I did find a prior discussion about something BC was doing, referring to this comment in GitHub. I tried that suggested fix, but I still get this certificate error. Also, that would require updating our system to Java 8 and I'd rather not open that can of worms yet if I can avoid it.

I'm using the default TrustStore which should get me the base CACerts, as I understand it:
trustMgrFact = TrustManagerFactory.getInstance("PKIX", BouncyCastleJsseProvider.PROVIDER_NAME);
trustMgrFact.init((KeyStore) null);

Any idea what else I could be doing wrong?

Full source of my test code is available in GitHub here.

Full stacktrace of the errors:
Reading from URL 'https://google.com'.
Sep 22, 2020 1:21:14 PM org.bouncycastle.jsse.provider.ProvTlsClient notifyAlertRaised
INFO: Client raised fatal(2) certificate_unknown(46) alert: Failed to read record
org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsUtils.processServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.handleServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at java.net.URL.openStream(URL.java:1045)
at TestEula.parseEulaFromUrl(TestEula.java:165)
at TestEula.getEulaEnhanced(TestEula.java:118)
at TestEula.main(TestEula.java:33)
Caused by: java.security.cert.CertificateException: No subject alternative name found matching IP address 216.58.193.78
at org.bouncycastle.jsse.provider.HostnameUtil.checkHostname(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkExtendedTrust(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(Unknown Source)
... 22 more

org.bouncycastle.tls.TlsFatalAlert: certificate_unknown(46)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.checkServerTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvTlsClient$1.notifyServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsUtils.processServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.handleServerCertificate(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at java.net.URL.openStream(URL.java:1045)
at TestEula.parseEulaFromUrl(TestEula.java:165)
at TestEula.getEulaEnhanced(TestEula.java:118)
at TestEula.main(TestEula.java:33)
Caused by: java.security.cert.CertificateException: No subject alternative name found matching IP address 216.58.193.78
at org.bouncycastle.jsse.provider.HostnameUtil.checkHostname(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkExtendedTrust(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkTrusted(Unknown Source)
at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(Unknown Source)
... 22 more
certificate_unknown(46)
--
Mike Totman
SafedoorPM Lead developer





     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS Certificate validation failing

Peter Dettman-3
In reply to this post by mtotman
Hi Mike,
It appears you are experiencing a known issue with HttpsURLConnection.

Please see https://github.com/bcgit/bc-java/issues/460 for an
explanation of the JDK "bug" and recommended workaround.

Another option is to use a better HTTPS client without this limitation.

Regards,
Pete Dettman

On 23/9/20 2:38 am, Mike Totman wrote:

> Full source of my test code is available in GitHub here
> <https://github.com/safedoorpm/bouncy-castle-test>.
>
> Caused by: java.security.cert.CertificateException: No subject alternative name found matching IP address 216.58.193.78
> at org.bouncycastle.jsse.provider.HostnameUtil.checkHostname(Unknown Source)
> at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
> at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
> at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkExtendedTrust(Unknown Source)
> at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkTrusted(Unknown Source)
> at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(Unknown Source)
> ... 22 more

Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS Certificate validation failing

mtotman
I was worried that was going to be the answer. If I have to upgrade to Java 8 for the fix, I don't need BC any more as it supports the protocols I need.

On Tue, 22 Sep 2020 at 20:23, Peter Dettman <[hidden email]> wrote:
Hi Mike,
It appears you are experiencing a known issue with HttpsURLConnection.

Please see https://github.com/bcgit/bc-java/issues/460 for an
explanation of the JDK "bug" and recommended workaround.

Another option is to use a better HTTPS client without this limitation.

Regards,
Pete Dettman

On 23/9/20 2:38 am, Mike Totman wrote:
> Full source of my test code is available in GitHub here
> <https://github.com/safedoorpm/bouncy-castle-test>.
>
> Caused by: java.security.cert.CertificateException: No subject alternative name found matching IP address 216.58.193.78
>       at org.bouncycastle.jsse.provider.HostnameUtil.checkHostname(Unknown Source)
>       at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
>       at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkEndpointID(Unknown Source)
>       at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkExtendedTrust(Unknown Source)
>       at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkTrusted(Unknown Source)
>       at org.bouncycastle.jsse.provider.ProvX509TrustManager.checkServerTrusted(Unknown Source)
>       ... 22 more



--
Mike Totman
SafedoorPM Lead developer
Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS Certificate validation failing

Peter Dettman-3
Hi Mike,
What JDK8 dependency are you worried about exactly?

We have an extension API for many later-JDK features to allow them to be
used back to JDK6, and with minor exceptions even JDK5.

e.g. You can use BCSSLParameters instead of SSLParameters, then set them
via the BCSSLSocket/BCSSLEngine interfaces (instances returned from the
BCJSSE factories will implement these). BCSSLParameters supports setting
server names, again with our own classes (BCSNIServerName,
BCSNIHostName). The extension API also supports SNI matchers, ALPN and
channel bindings.

Feel free to ask if you don't understand how to replicate some
particular JDK8 config.

Of course you lose portability in this way, but sounds like you really
want to stay on JDK7.

Regards,
Pete Dettman


On 23/9/20 1:07 pm, Mike Totman wrote:

> I was worried that was going to be the answer. If I have to upgrade to
> Java 8 for the fix, I don't need BC any more as it supports the
> protocols I need.
>
> On Tue, 22 Sep 2020 at 20:23, Peter Dettman
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     Hi Mike,
>     It appears you are experiencing a known issue with HttpsURLConnection.
>
>     Please see https://github.com/bcgit/bc-java/issues/460 for an
>     explanation of the JDK "bug" and recommended workaround.
>
>     Another option is to use a better HTTPS client without this limitation.
>
>     Regards,
>     Pete Dettman

Reply | Threaded
Open this post in threaded view
|

Re: SSL/TLS Certificate validation failing

mtotman
It's not the JDK 8 dependency that is a problem but the fact that it will require me to update our servers. It's probably not a problem, but it's a risk compared to a software-only solution.

On Wed, 23 Sep 2020 at 02:57, Peter Dettman <[hidden email]> wrote:
Hi Mike,
What JDK8 dependency are you worried about exactly?

We have an extension API for many later-JDK features to allow them to be
used back to JDK6, and with minor exceptions even JDK5.

e.g. You can use BCSSLParameters instead of SSLParameters, then set them
via the BCSSLSocket/BCSSLEngine interfaces (instances returned from the
BCJSSE factories will implement these). BCSSLParameters supports setting
server names, again with our own classes (BCSNIServerName,
BCSNIHostName). The extension API also supports SNI matchers, ALPN and
channel bindings.

Feel free to ask if you don't understand how to replicate some
particular JDK8 config.

Of course you lose portability in this way, but sounds like you really
want to stay on JDK7.

Regards,
Pete Dettman


On 23/9/20 1:07 pm, Mike Totman wrote:
> I was worried that was going to be the answer. If I have to upgrade to
> Java 8 for the fix, I don't need BC any more as it supports the
> protocols I need.
>
> On Tue, 22 Sep 2020 at 20:23, Peter Dettman
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     Hi Mike,
>     It appears you are experiencing a known issue with HttpsURLConnection.
>
>     Please see https://github.com/bcgit/bc-java/issues/460 for an
>     explanation of the JDK "bug" and recommended workaround.
>
>     Another option is to use a better HTTPS client without this limitation.
>
>     Regards,
>     Pete Dettman



--
Mike Totman
SafedoorPM Lead developer