Peter Dettman
Peter Dettman
From v1.70, use -Dorg.bouncycastle.jsse.client.assumeOriginalHostName=true instead of -Djdk.tls.trustNameService=true. The new property additionally sets the SNI hostname, and is specific to BCJSSE, which is probably desirable. If stuck on an earlier version...
I'm not overly familiar with CertPath details. Please provide refs for the commented out Java and C# code you are referring to.
Would you happen to have some test data that specifically covers the chain validity model?
It has not yet been added to the C# build, but is on the TODO list.
Handshake_failure(40); nested exception is org.bouncycastle.tls.TlsFatalAlert: handshake_failure(40)
We need more information to help you. What version of BC jars are you using? Do you have a full stack trace for the exception? What system are you trying...
Handshake_failure(40); nested exception is org.bouncycastle.tls.TlsFatalAlert: handshake_failure(40)
This exception happens when the server simply closes the connection before the handshake has completed. It means that you would need to look at the server logs in order to...
Handshake_failure(40); nested exception is org.bouncycastle.tls.TlsFatalAlert: handshake_failure(40)
The two code examples look the same to me. Do you mean that you changed the URL from http to https? HTTP doesn't use TLS at all, so it doesn't...
Handshake_failure(40); nested exception is org.bouncycastle.tls.TlsFatalAlert: handshake_failure(40)
The HTTP connection doesn't use TLS, and the HTTPS connection does use TLS, but gets the handshake_failure exception. The TLS connection happens (and fails) before any request is sent, so...
It's loosely planned to port the latest bc-java TLS over to C# once TLS 1.3 is complete (it's about 90% done in bc-java), but I wouldn't like to guess at...
I will be porting the latest Java TLS code to C# starting later this month.