I have Spring service hosted on Jetty and I want to test that it doesn't allow users to connect with invalid certificates.
scenario("Authenticate using expired client certificate")
.exec(session => session.setAll(
Map("gatling.http.ssl.keyStore.file" -> "expiredCertificateKeystore.jks",
"gatling.http.ssl.trustStore.file" -> "truststore.jks"))
.exec(
http("GET / request")
.get("/")
.check(/*that IOException is thrown*/)
)
Since Jetty cuts connection because of expected java.security.cert.CertificateExpiredException while connecting with invalid certificate, Gatling's HTTP client doesn't receive any return code from server and throws java.io.IOException: Remotely closed
Is there any way to tell Gatling that this error is expected and this behavior should be considered as success? I could not find any documentation about such feature.
No, it's not possible to recover IO exceptions.
What you're doing is a functional test, not a load test one, which is fine, but we didn't consider this use case.
Related
I am new to Scala. I am trying to access REST API URl and trying to get json data from there using Scalaj-Http with Spark framework in local vm(Intellij). But with the following Code I am always getting Http error code 401 from code and the server log is responding with "new ssl session,TLS V1.2 No Client Cert.
The jks file that I am using seems ok with proper SSL Handshake and its installed on server side.
val url = "https://abcdef:1234/api/v1/get?q=abc"
val alias ="xxxxxx-1234 yyyyy"
val sslFactory = SSLFactory.builder()
.withIdentityMaterial("abc.jks","pass".tocharArray)
.withTrustMaterial("abc.jks","pass".tocharArray)
.withClientIdentityRoute(alias,url)
.build()
val optn = HttpOptions.sslSocketFactory(sslfactory.getSslSocketfactory)
val res = Http(url) //Here getting 401 res.code
.option(optn)
.option(HttpOptions.allowUnsafeURL)
.asString
Tried everything but unable to solve. Kindly help please
I got the code working as I have to discard this option option(HttpOptions.allowUnsafe
URL)
Thanks
I have to make https calls to an api that appears to not have validated SSL certificate. I would still like to make calls to the api using the Http().singleRequest method of akka-http.
When I make a call, I however get the following error:
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
When I make a call with curl, I get
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it.
The calls with curl however work if I had the flag --insecure.
In akka-http, I tried the following:
val badSslConfig = AkkaSSLConfig().mapSettings(
s => s.withLoose(
s.loose
.withAcceptAnyCertificate(true)
.withAllowLegacyHelloMessages(Some(true))
.withAllowUnsafeRenegotiation(Some(true))
.withAllowWeakCiphers(true)
.withAllowWeakProtocols(true)
.withDisableHostnameVerification(true)
.withDisableSNI(true)
)
)
val badCtx = Http().createClientHttpsContext(badSslConfig)
Http()
.singleRequest(
HttpRequest(
HttpMethods.POST,
uri = Uri("https://..."),
protocol = HttpProtocols.`HTTP/1.1`
),
connectionContext = badCtx
)
but I still get the same error.
What should I do to fix the issue?
PS: I understand (given the many warnings in akka-http docs) that it is something that I shouldn't do in production but I'd like this workaround to work for now...
I had similar problem some time ago and as far as I remember it had to do with this issue. Workaround for that problem is to have own implementation of SSLContext that will accept just anything. Implementation is pretty straightforward and the example can be found in the last comment of of issue linked above.
Fiddler Error Connecting to HTTPS Applications
Fiddler Log:
!SecureClientPipeDirect failed: Authentication failed because the remote party has closed the transport stream. on pipe to (CN=services.bigpond.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)
I have followed other posts but no answers
The typical explanation for this message, as documented in many places, is that the client application has not been configured to trust Fiddler's root certificate. As such, the client closes the connection to Fiddler when it sees the untrusted certificate.
http://fiddler2.com/documentation/Configure-Fiddler/Tasks/TrustFiddlerRootCert
In Kestrel I'm using an SSL cert.
I 'downgraded' the TLS protocol in order to get this to work.
This is not something you'd do in production - but in production you shouldn't be using kestrel. I'm not saying this is the best overall config, but this is mainly to show the SslProtocols option.
WebHost.CreateDefaultBuilder(args)
.UseKestrel(options =>
{
options.Listen(IPAddress.Any, 5000); // http:localhost:5000
options.Listen(IPAddress.Any, 44300, listenOptions =>
{
// https://dotnetthoughts.net/enable-http2-on-kestrel/
//listenOptions.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http2;
listenOptions.UseHttps(#"S:\WORK\SSL\example.com.pfx", "cert-password", httpsOptions =>
{
httpsOptions.SslProtocols = System.Security.Authentication.SslProtocols.Tls;
});
});
})
.UseStartup<Startup>();
I moved a working code from dev to test and encountered the following error(s) in test:
javax.xml.ws.soap.SOAPFaultException: Could not send Message.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:143)
......
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:472)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:302)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:123)
at $Proxy739.copyIntoItems(Unknown Source)
Caused by: java.io.IOException: Server returned HTTP response code: 401 for URL: http://<sharepointportal>/_vti_bin/Copy.asmx
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1436)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2046)
Environment specs:
Java 1.6
Tomcat 6
Eclipse Helios
Maven2
CXF 2.2.3
As a background work, tried to explore about the error in similar category
bad URL (ruled out as i am using same URL in dev and test. and the url, userid, password are all accessible from both the machines),
connection timeout( error is not 404 or it doesnt specify connection timed out... it says 401 response code for url)
Checked if all the jars and same versions are included in the test environment.
Can someone shed some light to understand and resolve the error?
please let me know if any more details are to be included.
401 is an authentication error.
Authentication fails either at the destination URL http:///_vti_bin/Copy.asmx (3 slashes ?) or on a forward proxy on the way.
Are you connecting to _vti_bin via a proxy in test ?
I'm troubleshooting an existing webservice. It previously worked just fine, but now SOAP-based requests to the postgreSQL database result in an "unknown error: Error Fetching http headers" error.
In looking up this problem, I come across the following tip:
When you get errors like: "Fatal error: Uncaught SoapFault exception:
[HTTP] Error Fetching http headers in" after a few (time intensive)
SOAP-Calls, check your webserver-config.
Sometimes the webservers "KeepAlive"-Setting tends to result in this
error. For SOAP-Environments I recommend you to disable KeepAlive.
Hint: It might be tricky to create a dedicated vhost for your
SOAP-Gateways and disable keepalive just for this vhost because for
normal webpages Keepalive is a nice speed-boost.
I haven't been able to figure out exactly how you disable KeepAlive or where this parameter would be set. I've tried grep -i "keepalive" /usr/share/tomcat5/conf/*, result negative.
Perhaps due to the variability of server environments this is a question for my sysadmin, but I do have root privileges.
Thanks for your help, stack!
In your Tomcat's server.xml file, set the maxKeepAliveRequests attribute to 1 on your HTTP connectors to effectively disable keep alive.
For more information:
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html#Standard_Implementation