BCJSSE TLS-Server implementation fails to perform handshake.

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

BCJSSE TLS-Server implementation fails to perform handshake.

CBroeter
Good day!

I've decided to use bouncycastle for the realization of the TLS server. The dev environment consists of OpenJDK8 (build 1.8.0_265-8u265-b01-0ubuntu2~18.04-b01) on an ubuntu

Further, the libs bcpkix-jdk15on-165 and bcprov-jdk15on-165 are used for establishing the TLS connection.

After successfully retrieving the ClientHello, the server acknowledges the ClientHallo(ACK) and terminates the handshake with Alert 40 (Handshake Failure).

Here is a snippet of the tls service implementation followed by the devlog and thrown exception.

public void startSimpleServer(String serviceIP, int servicePort) throws Exception {

// Set bc JSSE Provider as priority
Security.insertProviderAt(new BouncyCastleProvider(), 1);
Security.insertProviderAt(new BouncyCastleJsseProvider(), 1);

// create a context and set up a socket factory
SSLContext sslContext = setupSSLContext(getServerCertificate(), getServerPrk());

SSLServerSocketFactory fact = sslContext.getServerSocketFactory();
SSLServerSocket sSock = (SSLServerSocket) fact.createServerSocket();
sSock.setReuseAddress(true);
try {
sSock.bind(new InetSocketAddress(serviceIP, servicePort));
} catch (Exception e) {
logger.logError(threadName + LOGGERNAME + ":[" + serviceIP
+ "]: Bind failed: " + e.getLocalizedMessage());
return;
}
// set suites
String[] suites = {
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_DHE_RSA_WITH_AES_256_CBC_SHA" };
logger.logInfo(threadName + LOGGERNAME + ": Server.enabledCipherSuites: "
+ Arrays.asList(sSock.getEnabledCipherSuites()));
sSock.setEnabledCipherSuites(suites);

//configure server socket
sSock.setNeedClientAuth(true);

while (this.isRunning()) {
sslSock = null;
logger.logInfo(threadName + LOGGERNAME + ":[" + serviceIP
+ "]: Starting to wait for SSL/TLS connection...");

while (sslSock == null && this.isRunning()) {
try {
sslSock = (SSLSocket) sSock.accept();
} catch (SocketTimeoutException e) {

}
sslSock.startHandshake();
// handshake success, handle session
SSLSession session = sslSock.getSession();
X509Certificate[] clientChain = (X509Certificate[]) session
.getPeerCertificates();

//log client chain
for(X509Certificate cert: clientChain) {
logger.logInfo(cert.getSubjectDN().getName());
}
}
}
}

private SSLContext setupSSLContext(Certificate certificate, PrivateKey prvRSAKey) throws Exception {
// set up a keystore
KeyManagerFactory mgrFact = KeyManagerFactory.getInstance("PKIX", "BCJSSE");
serverStore = KeyStore.getInstance("JKS");
serverStore.load(null, null);
serverStore.setKeyEntry("server", prvRSAKey, "".toCharArray(), new Certificate[] { certificate });
mgrFact.init(serverStore, "".toCharArray());

// set up a truststore
TrustManagerFactory trustFact = TrustManagerFactory.getInstance("PKIX", "BCJSSE");
final ClassLoader loader = SSLServer.class.getClassLoader();
KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(
loader.getResourceAsStream(serverTruststoreLocation),
serverTruststorePassword.toCharArray());
trustFact.init(trustStore);

// create a context
SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
sslContext.init(mgrFact.getKeyManagers(), trustFact.getTrustManagers(), null);
return sslContext;
}
 


Okt 12, 2020 8:34:20 AM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL
Okt 12, 2020 8:34:20 AM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFORMATION: Found string security property [jdk.certpath.disabledAlgorithms]: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
Okt 12, 2020 8:34:20 AM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer
2020/10/12 08:34:20:382 [INFO]: [SICCT Server]: Server.enabledCipherSuites: [TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA]
2020/10/12 08:34:20:383 [INFO]: [SICCT Server]:[0.0.0.0]: Starting to wait for SSL/TLS connection...
Okt 12, 2020 8:34:32 AM org.bouncycastle.jsse.provider.PropertyUtils getIntegerSystemProperty
INFORMATION: Found integer system property [jdk.tls.ephemeralDHKeySize]: 2048
Okt 12, 2020 8:34:32 AM org.bouncycastle.jsse.provider.ProvTlsServer notifyAlertRaised
INFORMATION: Server raised fatal(2) handshake_failure(40) alert: Failed to read record
org.bouncycastle.tls.TlsFatalAlert: handshake_failure(40)
at org.bouncycastle.tls.AbstractTlsServer.getSelectedCipherSuite(Unknown Source)
at org.bouncycastle.jsse.provider.ProvTlsServer.getSelectedCipherSuite(Unknown Source)
at org.bouncycastle.tls.TlsServerProtocol.generateServerHelloMessage(Unknown Source)
at org.bouncycastle.tls.TlsServerProtocol.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.TlsServerProtocol.accept(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at org.bouncycastle.jsse.provider.ProvSSLSocketDirect.startHandshake(Unknown Source)
at java.lang.Thread.run(Thread.java:748)

The clients supported cipher suites in the request are "TLS_DHE_RSA_WITH_AES_128_CBC_SHA" and "TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
As per configuration the server is supposed to support both.

Here a screenshot(prnt.sc) of the network traffic

Since, in a successful handshake the server would provide a serverhello, certificate and serverhellodone next, I am suspecting that the issue is related to the setup of the trustmanager.
Key and truststore initialization can be seen in the snippet Method:setupSSLContext(Certificate, PrivateKey). The keystore contains exactly one privatekey and auth-certificate whereas the truststore contains multiple certificates including the cert-chain of the auth-certificate.

Sadly, I am not able to debug any deeper. Hope all this information helps.

Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: BCJSSE TLS-Server implementation fails to perform handshake.

Lothar Kimmeringer-4


Am 20.10.2020 um 14:01 schrieb Christoph Bröter:

>     SSLContext sslContext = setupSSLContext(getServerCertificate(), getServerPrk());

what's the server certificate you're using here?

> The clients supported cipher suites in the request are
> "TLS_DHE_RSA_WITH_AES_128_CBC_SHA" and "TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
> As per configuration the server is supposed to support both.
>
> Here a screenshot(prnt.sc) <https://prnt.sc/v290zz> of the network traffic

can you provide the actual trace? That way, all parts of the ClientHello
can be checked.

> Since, in a successful handshake the server would provide a serverhello,
> certificate and serverhellodone next, I am suspecting that the issue is
> related to the setup of the trustmanager.

Quite unlikely. The TrustManager comes into action when checking the
trustworthyness of a client's certififate but that can only happen
after the server answered to the client with a CertificateRequest message
as additional part of the list you've mentioned.

So my guess is, that the certificate you've provided isn't suitable for
the listed ciphers in the ClientHello, e.g. because it's RSA-based while
the client only listed non-RSA-ciphers. Another reason might be a
too small DH epheremal size, at least it seems to be the last message
before the server aborts the handshake:

| Okt 12, 2020 8:34:32 AM org.bouncycastle.jsse.provider.PropertyUtils
| getIntegerSystemProperty
| INFORMATION: Found integer system property [jdk.tls.ephemeralDHKeySize]: 2048
| Okt 12, 2020 8:34:32 AM org.bouncycastle.jsse.provider.ProvTlsServer notifyAlertRaised
| INFORMATION: Server raised fatal(2) handshake_failure(40) alert: Failed to read record
| org.bouncycastle.tls.TlsFatalAlert: handshake_failure(40)

As said, the actual trace instead of a screenshot of the packet overview might
help to find the reason.


Cheers, Lothar

Reply | Threaded
Open this post in threaded view
|

Re: BCJSSE TLS-Server implementation fails to perform handshake.

Peter Dettman-3
In reply to this post by CBroeter
Hi Christoph,

I suggest that you test with the latest beta version available from
https://downloads.bouncycastle.org/betas/ (currently 167b05), and also
please configure Java Logging to log at FINE or FINER to get a few more
details about the steps the server is taking.

Generally a handshake failure in getSelectedCipherSuite means that
either there are no cipher suites in common b/w client and server, or
that the server for some reason cannot select one of the cipher suites
that they have in common. In the latter case it is usually the lack of
suitable credentials in the server's key store (KeyManager), but there
are other possibilities.

Let's see some more details in the logs and perhaps all will become clear.

Regards,
Pete Dettman


On 20/10/20 7:01 pm, Christoph Bröter wrote:

> Good day!
>
> I've decided to use bouncycastle for the realization of the TLS server.
> The dev environment consists of OpenJDK8 (build
> 1.8.0_265-8u265-b01-0ubuntu2~18.04-b01) on an ubuntu
>
> Further, the libs bcpkix-jdk15on-165 and bcprov-jdk15on-165 are used for
> establishing the TLS connection.
>
> After successfully retrieving the ClientHello, the server acknowledges
> the ClientHallo(ACK) and terminates the handshake with Alert 40
> (Handshake Failure).

Reply | Threaded
Open this post in threaded view
|

Re: BCJSSE TLS-Server implementation fails to perform handshake.

CBroeter
Hello all,
I will try to provide you with all the information requested.
First, the following link will lead you with the tcp dump of the failing handshake using bc166.
This is the servers certificate (sha256withRSA)
This behaviour still occurs in 167b05, no change here.
Intended is a mutual authenticated TLS-connection (in this case using RSA2048)

Following all printed java debug messages:

Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils getBooleanSecurityProperty
INFORMATION: Found boolean security property [keystore.type.compat]: true
Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFORMATION: Found string security property [jdk.tls.disabledAlgorithms]: SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL
Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils getStringSecurityProperty
INFORMATION: Found string security property [jdk.certpath.disabledAlgorithms]: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
WARNUNG: Ignoring unsupported entry in 'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer
Okt 27, 2020 8:56:46 AM org.bouncycastle.jsse.provider.PropertyUtils getIntegerSystemProperty
INFORMATION: Found integer system property [jdk.tls.ephemeralDHKeySize]: 2048
Okt 27, 2020 8:56:46 AM org.bouncycastle.jsse.provider.ProvTlsServer notifyAlertRaised
INFORMATION: Server raised fatal(2) handshake_failure(40) alert: Failed to read record

Here a link to a successful handshake using the default crypto provider (same code, but removed bcjsse as provider).
We are intending to use bouncycastle because we also want to support TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

Further, the PKI is very simple. There is exactly one root-CA, exactly one sub-CA and two end-entity(ee) certificates issued by the same sub-CA. One ee-cert is used on the client and one on the server. The one ee-cert on the server is the one linked above. I have double-checked the servers truststore (using openssl) and the sub-ca is present(otherwise, the connection using the default provider would also fail).

Thanks for all the support :)





Am Di., 20. Okt. 2020 um 14:58 Uhr schrieb Peter Dettman <[hidden email]>:
Hi Christoph,

I suggest that you test with the latest beta version available from
https://downloads.bouncycastle.org/betas/ (currently 167b05), and also
please configure Java Logging to log at FINE or FINER to get a few more
details about the steps the server is taking.

Generally a handshake failure in getSelectedCipherSuite means that
either there are no cipher suites in common b/w client and server, or
that the server for some reason cannot select one of the cipher suites
that they have in common. In the latter case it is usually the lack of
suitable credentials in the server's key store (KeyManager), but there
are other possibilities.

Let's see some more details in the logs and perhaps all will become clear.

Regards,
Pete Dettman


On 20/10/20 7:01 pm, Christoph Bröter wrote:
> Good day!
>
> I've decided to use bouncycastle for the realization of the TLS server.
> The dev environment consists of OpenJDK8 (build
> 1.8.0_265-8u265-b01-0ubuntu2~18.04-b01) on an ubuntu
>
> Further, the libs bcpkix-jdk15on-165 and bcprov-jdk15on-165 are used for
> establishing the TLS connection.
>
> After successfully retrieving the ClientHello, the server acknowledges
> the ClientHallo(ACK) and terminates the handshake with Alert 40
> (Handshake Failure).

Reply | Threaded
Open this post in threaded view
|

Re: BCJSSE TLS-Server implementation fails to perform handshake.

Peter Dettman-3
Hi Christoph,

Did you set the Java Logging API logging level to FINER?

The packet capture showed a ClientHello offering only DHE_RSA cipher
suites, but not offering any ffdhe NamedGroup values in the
supported_groups extension (there are only elliptic curves specified).

So the server is unable to select an ffdhe NamedGroup and therefore
unable to select any DHE_RSA cipher suite.

I'm not sure why you want to be using DHE_RSA anyway; the simplest thing
to change would be to negotiate ECDHE_RSA instead. (Although it should
be mentioned that the client seems to prefer very expensive (slow)
curves: secp521r1, brainpoolP512r1, secp384r1, brainpoolP384r1... etc.).

Regards,
Pete Dettman


On 27/10/20 3:43 pm, Christoph Bröter wrote:

> Hello all,
> I will try to provide you with all the information requested.
> First, the following link will lead you with the tcp dump of the failing
> handshake using bc166.
> https://drive.google.com/file/d/15OVYmdPW-roDei8yTkLZ51Nw9dSK1BXp/view?usp=sharing
> This is the servers certificate (sha256withRSA)
> https://drive.google.com/file/d/1rwba7Gj-IXwHrK_76sxtCGNibj5b7oQn/view?usp=sharing
> This behaviour still occurs in 167b05, no change here.
> Intended is a mutual authenticated TLS-connection (in this case using
> RSA2048)
>
> Following all printed java debug messages:
>
>     Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils
>     getBooleanSecurityProperty
>     INFORMATION: Found boolean security property [keystore.type.compat]:
>     true
>     Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils
>     getStringSecurityProperty
>     INFORMATION: Found string security property
>     [jdk.tls.disabledAlgorithms]: SSLv3, RC4, DES, MD5withRSA, DH
>     keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL
>     Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils
>     getStringSecurityProperty
>     INFORMATION: Found string security property
>     [jdk.certpath.disabledAlgorithms]: MD2, MD5, SHA1 jdkCA & usage
>     TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
>     Okt 27, 2020 8:56:40 AM
>     org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>     WARNUNG: Ignoring unsupported entry in
>     'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer
>     Okt 27, 2020 8:56:46 AM org.bouncycastle.jsse.provider.PropertyUtils
>     getIntegerSystemProperty
>     INFORMATION: Found integer system property
>     [jdk.tls.ephemeralDHKeySize]: 2048
>     Okt 27, 2020 8:56:46 AM org.bouncycastle.jsse.provider.ProvTlsServer
>     notifyAlertRaised
>     INFORMATION: Server raised fatal(2) handshake_failure(40) alert:
>     Failed to read record
>
>
> Here a link to a successful handshake using the default crypto provider
> (same code, but removed bcjsse as provider).
> https://drive.google.com/file/d/15I6WdauhM28l2OlxB3oeJNIPsRlWqotV/view?usp=sharing
> We are intending to use bouncycastle because we also want to support
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  and
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
>
> Further, the PKI is very simple. There is exactly one root-CA, exactly
> one sub-CA and two end-entity(ee) certificates issued by the same
> sub-CA. One ee-cert is used on the client and one on the server. The one
> ee-cert on the server is the one linked above. I have double-checked the
> servers truststore (using openssl) and the sub-ca is present(otherwise,
> the connection using the default provider would also fail).
>
> Thanks for all the support :)

Reply | Threaded
Open this post in threaded view
|

Re: BCJSSE TLS-Server implementation fails to perform handshake.

CBroeter
Hi,

The packet capture showed a ClientHello offering only DHE_RSA cipher
suites, but not offering any ffdhe NamedGroup values in the
supported_groups extension (there are only elliptic curves specified).

So the server is unable to select an ffdhe NamedGroup and therefore
unable to select any DHE_RSA cipher suite.
 
Pete, you were right about the supported groups. We have changed the client configuration, added ffdhe2048-4096, with success.

Sadly, the current behaviour of the server does not meet our expectations.
We expect that the server will not terminate the connection if no-ffdhe groups are provided.
RFC 7919 Section 4 (https://tools.ietf.org/html/rfc7919#section-4) states on this topic:
  If at least one FFDHE cipher suite is present in the client cipher
   suite list and the Supported Groups extension is either absent from
   the ClientHello entirely or contains no FFDHE groups (i.e., no
   codepoints between 256 and 511, inclusive), then the server knows
   that the client is not compatible with this document.  In this
   scenario, a server MAY select a non-FFDHE cipher suite, or it MAY
   select an FFDHE cipher suite and offer an FFDHE group of its choice
   to the client as part of a traditional ServerKeyExchange.
We expect the server selecting an FFDHE cipher suite (which was not present in the clienthello) and offer an ffdhe group of its choice, instead of terminating the connection.
Is there a consideration to implement a configurable behaviour to support this case?

I'm not sure why you want to be using DHE_RSA anyway; the simplest thing
to change would be to negotiate ECDHE_RSA instead. (Although it should
be mentioned that the client seems to prefer very expensive (slow)
curves: secp521r1, brainpoolP512r1, secp384r1, brainpoolP384r1... etc.).

Thanks for your recommendation, but it is mandatory to use these algorithms. The server shall replace the current generation of servers in the production line and requires to support both DHE_RSA and ECDHE_ECDSA. It's a requirement we can not bypass.

Further, not a requirement but a very interesting behavior of BC is that, if multiple ffdhe groups are named by the client, the BC server selects ffdhe2048 to be used.
RFC 7919 states on this:
 If a non-anonymous FFDHE cipher suite is selected and the TLS client
   has used this extension to offer an FFDHE group of comparable or
   greater strength than the server's public key, the server SHOULD
   select an FFDHE group at least as strong as the server's public key.
   For example, if the server has a 3072-bit RSA key and the client
   offers only ffdhe2048 and ffdhe4096, the server SHOULD select
   ffdhe4096.

Did you set the Java Logging API logging level to FINER?
Yes, we did but we did not see any changes. We used -Djavax.net.debug=Finest or -Djavax.net.debug=ssl:handshake.

Thanks for your support.
Christoph

Am Di., 27. Okt. 2020 um 18:07 Uhr schrieb Peter Dettman <[hidden email]>:
Hi Christoph,

Did you set the Java Logging API logging level to FINER?

The packet capture showed a ClientHello offering only DHE_RSA cipher
suites, but not offering any ffdhe NamedGroup values in the
supported_groups extension (there are only elliptic curves specified).

So the server is unable to select an ffdhe NamedGroup and therefore
unable to select any DHE_RSA cipher suite.

I'm not sure why you want to be using DHE_RSA anyway; the simplest thing
to change would be to negotiate ECDHE_RSA instead. (Although it should
be mentioned that the client seems to prefer very expensive (slow)
curves: secp521r1, brainpoolP512r1, secp384r1, brainpoolP384r1... etc.).

Regards,
Pete Dettman


On 27/10/20 3:43 pm, Christoph Bröter wrote:
> Hello all,
> I will try to provide you with all the information requested.
> First, the following link will lead you with the tcp dump of the failing
> handshake using bc166.
> https://drive.google.com/file/d/15OVYmdPW-roDei8yTkLZ51Nw9dSK1BXp/view?usp=sharing
> This is the servers certificate (sha256withRSA)
> https://drive.google.com/file/d/1rwba7Gj-IXwHrK_76sxtCGNibj5b7oQn/view?usp=sharing
> This behaviour still occurs in 167b05, no change here.
> Intended is a mutual authenticated TLS-connection (in this case using
> RSA2048)
>
> Following all printed java debug messages:
>
>     Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils
>     getBooleanSecurityProperty
>     INFORMATION: Found boolean security property [keystore.type.compat]:
>     true
>     Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils
>     getStringSecurityProperty
>     INFORMATION: Found string security property
>     [jdk.tls.disabledAlgorithms]: SSLv3, RC4, DES, MD5withRSA, DH
>     keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL
>     Okt 27, 2020 8:56:40 AM org.bouncycastle.jsse.provider.PropertyUtils
>     getStringSecurityProperty
>     INFORMATION: Found string security property
>     [jdk.certpath.disabledAlgorithms]: MD2, MD5, SHA1 jdkCA & usage
>     TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
>     Okt 27, 2020 8:56:40 AM
>     org.bouncycastle.jsse.provider.DisabledAlgorithmConstraints create
>     WARNUNG: Ignoring unsupported entry in
>     'jdk.certpath.disabledAlgorithms': SHA1 jdkCA & usage TLSServer
>     Okt 27, 2020 8:56:46 AM org.bouncycastle.jsse.provider.PropertyUtils
>     getIntegerSystemProperty
>     INFORMATION: Found integer system property
>     [jdk.tls.ephemeralDHKeySize]: 2048
>     Okt 27, 2020 8:56:46 AM org.bouncycastle.jsse.provider.ProvTlsServer
>     notifyAlertRaised
>     INFORMATION: Server raised fatal(2) handshake_failure(40) alert:
>     Failed to read record
>
>
> Here a link to a successful handshake using the default crypto provider
> (same code, but removed bcjsse as provider).
> https://drive.google.com/file/d/15I6WdauhM28l2OlxB3oeJNIPsRlWqotV/view?usp=sharing
> We are intending to use bouncycastle because we also want to support
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  and
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
>
> Further, the PKI is very simple. There is exactly one root-CA, exactly
> one sub-CA and two end-entity(ee) certificates issued by the same
> sub-CA. One ee-cert is used on the client and one on the server. The one
> ee-cert on the server is the one linked above. I have double-checked the
> servers truststore (using openssl) and the sub-ca is present(otherwise,
> the connection using the default provider would also fail).
>
> Thanks for all the support :)