Basic put object calls suddenly stopped working (sometimes it succeds). It has been working since long.
Looks like a SSL cert issue.
Stack Trace snippet.
org.jets3t.service.S3ServiceException: S3 PUT connection failed for '/s3_request_message-38afbd8e-7d65-428a-a708-5d34104ded95-4912660956668093023.xml'
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:516)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRestPut(RestS3Service.java:800)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.createObjectImpl(RestS3Service.java:1399)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.putObjectImpl(RestS3Service.java:1317)
at org.jets3t.service.S3Service.putObject(S3Service.java:1661)
at org.jets3t.service.S3Service.putObject(S3Service.java:1914)
at com.amazon.lm.utils.aws.S3Box.putFile(S3Box.java:111)
at com.amazon.lm.engine.LMEngine.copyRequestS3(LMEngine.java:350)
at com.amazon.lm.engine.LMEngine.run(LMEngine.java:165)
at com.amazon.lm.engine.discover.DiscoveryEngine.run(DiscoveryEngine.java:156)
at com.amazon.lm.engine.discover.GoogleBaseSearch.run(GoogleBaseSearch.java:25)
at com.amazon.lm.ui.UIDiscoverTask.run(UIDiscoverTask.java:41)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: HTTPS hostname invalid: expected 'lm-requests-prod.s3.amazonaws.com', received '*.s3.amazonaws.com'
at org.apache.commons.httpclient.contrib.ssl.StrictSSLProtocolSocketFactory.verifyHostname(StrictSSLProtocolSocketFactory.java:293)
at org.apache.commons.httpclient.contrib.ssl.StrictSSLProtocolSocketFactory.createSocket(StrictSSLProtocolSocketFactory.java:215)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:342)
... 12 more
Looks like Java does not like the wildcard domain presented as '*.s3.amazonaws.com'
per Can Java connect to wildcard ssl... wildcards can be problematic with java.
But as said earlier, we have been using it since long time and suddenly started facing this issue, that too intermittently.
We are using following versions:
jdk: 1.6
jets3: 0.7
openssl:1.0
Has anyone faced this issue? If Yes, Is there any workaround?
This wasn't an issue with the AWSS3JavaClient code, based on the fact that the this problem was happening both with S3 library and with other Java S3 libraries, and the fact that SSL cert verification is done inside the JVM platform library code, not inside our S3 library code.
The problem is that our JVM's keystore didn't have the most recent certificate authorities (CAs) that allow the JVM to form a chain of trust for whatever cert we're getting from the S3 SSL endpoint. This is a fairly common problem with Java and SSL, since the JVM maintains it's own keystore (i.e. it doesn't use certs from the OS).
If you face this problem, try reproducing this issue with other JVMs. Whenever customers have seen this issue in the past, it's been because their local JVM keystore (the keystore ships with the JVM and contains the most recent certs and CAs) has been out of date. Upgrading to the latest JVM version has always fixed this in the past.
Try upgrading your JVM version to recent one, it should help because your keystore must have been expired! :)
Related
I recently migrated from Gatling 3.3.1 to Gatling 3.4.0.
As a result, everything works fine in my local machine, but crashes in k8s because of the following error:
Couldn't execute warm up request https://gatling.io
java.lang.IllegalArgumentException: TLSv1.3
at sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187)
at sun.security.ssl.ProtocolList.convert(ProtocolList.java:84)
at sun.security.ssl.ProtocolList.<init>(ProtocolList.java:52)
at sun.security.ssl.SSLEngineImpl.setEnabledProtocols(SSLEngineImpl.java:2081)
...
I migrated back to the working version.
I assumed from here, that TLSv1.3 is switched on by default.
I searched for the appropriate setting in gatling-defaults.conf, but did not succeed.
I use Java 1.8 both locally and on remote k8s
Please help me to resolve this issue!
Thanks in advance!
In order to support TLSv3, Gatling needs:
either to be able to load netty-tcnative (basically BoringSSL)
or run on Java 11+ where TLSv3 is available
We can see in the logs that the former fails. We can also see that netty_transport_native_epoll_x86_64 can't be loaded while netty_transport_native_epoll_x86 can. This means you're running on a 32-bit Linux. netty-tcnative/BoringSSL is only available on 64-bit.
The latter fails as you stated running on Java 8.
We can probably improve things on our side, but you should switch to a 64-bit host.
Otherwise, you can enforce the list of supported protocols in gatling.conf, see https://github.com/gatling/gatling/blob/master/gatling-core/src/main/resources/gatling-defaults.conf#L57
I'm kinda at a loss here.
Trying to set up proton with SSL / TLS access, but after creating the certificates with the (modified) shell scripts
supplied by the AppDev-Pack and linking the keyring and everything in notes.ini, I always seem to get
the error "Handshake failed with fatal error SSL_ERROR_SSL: error: 100000f7:SSL routines:OPENSSL_internal:
WRONG_VERSION_NUMBER".
Tried both a windows and linux server, as well as using the accessing node.js app with and without
certificates - but with no success.
Also tried the troubleshoot section of https://doc.cwpcollaboration.com/appdevpack/docs/en/proton-admin.html and it connected just fine,
but won't if i connect with node.js.
Looks like the error is thrown before a certificate is even checked?
In this example the error is thrown after trying to get a document by UNID.
notes.ini (proton parts)
gRPC Client Error
If someone has an idea how to fix that issue or where to start - that would really help me.
Thanks in advance.
It appears that the client side does not have the secure flag set. At least I get a similar stack when I try to connect without TLS when the server expects TLS.
See the secure attribute when calling useServer() function, and you'll also need to provide the credentials attributes.
I'm trying to retrieve data from an open data api. I have downloaded the certificate from the site and imported it into STRUST (SSL Client Anonymous).
Then I created a HTTP connection to external server in SM59. In the beginning it worked fine, until last week when the api changed its URL and so its DNS.
Of course it could no longer be reached by the current host. So I did above steps again for the new URL (changed everything accordingly like hostname etc. in SM59), but this time I receive following error:
SSL handshake with 'hostname:port' failed: SSSLERR_CONN_CLOSED (-10)#Remote
Peer has closed the network connection##SapSSLSessionStartNB()==SSSLERR_CONN_CLOSED##
Anyone has an idea on how to solve this?
On another forum someone helped me solve the problem. He pointed me out that the problem lies with SNI see: https://security.stackexchange.com/questions/101965/ssl3-error-when-requesting-connection-using-tls-1-2/102018#102018
https://en.wikipedia.org/wiki/Server_Name_Indication
To solve this problem you need to add following parameter: icm/HTTPS/client_sni_enabled and set it to TRUE on the DEFAULT profile. Afterwards you need to restart the application server in order to activate the effects of the parameter.
Link to the full question on SCN: https://answers.sap.com/questions/473015/sap-ssl-handshake-failed.html
EDIT:
I came across this error again later on, but this time it seemed that the error was caused because we used a certificate with TLS 1.2 which was not supported by our system. You can check this link: https://launchpad.support.sap.com/#/notes/510007 we implemented number 7 to fix this.
When using EppLib.net (and as per the Nominet instructions - http://registrars.nominet.uk/namespace/uk/registration-and-domain-management/registrar-systems/epp/testbed)
In order to verify the identity of the secure server you will need the 'Verisign Class 3 Public Primary Certification Authority' root certificate available free from www.verisign.com (the certificate is also distributed with most web browsers).
I am supplying the Verisign Class 3 PPCA Certs in .crt format (I can't export as a pfx) within the code (and have tried every cert installed on the server).
However each one fails with the error (when trying to negotiate the connection):
An existing connection was forcibly closed by the remote host.
I've confirmed that I can connect from the server to Nominet by running cURL
curl -v https://testbed-epp.nominet.org.uk:700
and that responds as I would expect - or at least without an error!
I have also tried to use the same cert that curl appears to be using without success.
Can anyone help with pointing me in the right direction with the SSL that I should be using or how to get hold of the correct certificate?
thanks in advance
For anyone having a similar issue, it wasn't a question of which SSL certificate to use, but to ensure the correct protocol was being used. Incidentally, I got it working initially using the curl-ca-bundle.crt provided with cURL.
This certificate, in combination with a change to the target .net framework for the EppLib.net project resolved my issue.
On cloning from Github the target was .net 4.0 and Nominet needs at least TLS1.1, which wasn't available in v4.
Therefore I also updated the target to 4.5.1 for the EppLib.net project and changed the SslProtocol from
SslProtocol.Tls to
SslProtocol.Tls12
I'm running a site and several sub domains on ColdFuson 10 Standard, we have just upgraded from ColdFusion 9 where everything was working fine.
The sites have a wildcard ssl certificate installed so all the sub domains are secured. I'm making http calls between the sites but getting the I/O Exception: peer not authenticated error.
Charset [empty string]
ErrorDetail I/O Exception: peer not authenticated
Filecontent Connection Failure
Header [empty string]
Mimetype Unable to determine MIME type of file.
Responseheader struct [empty]
Statuscode Connection Failure. Status code unavailable.
Text YES
I've installed the certificate in the correct key store and verified it's there using keytool -listand restarted, but still get the authentication error.
I know this is a common problem and is usually fixed by installing the certificate and there are workarounds for ColdFusion Enterprise but I'm struggling to get this working on Standard. Any suggestions?
After many days of investigation I came across this blog post which leads to bug report #3598342.
It turns out to be an issue on Windows 2012 servers running IIS 8. There is an option on the site binding to 'Require Server Name Indication' or 'SNI'. Turning this option off allows cfhttp to connect via https.
It turns out this is an issue with the HttpClient library and has been fixed in builds 288845, 288846 and 290605. Which doesn't really help as the last update 13 only gives me build 287689.
This could be an issue I have run across where I had to import the secure server certificate into coldfusion before it would allow me to connect.
http://helpx.adobe.com/coldfusion/kb/import-certificates-certificate-stores-coldfusion.html
Import Certificate for ColdFusion10
Hope that helps. I know it helped me!