I am using the RestAssured library to make calls to certain REST API's
These are https endpoints and I tried using the "relaxedHTTPSValidation()" method provided in RestAssured to bypass SSL validation
My request looks something like
RequestSpecification req = RestAssured.given().relaxedHTTPSValidation().body().post();
I keep getting the error
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
Doeas anyone have an idea why this is happening ?
Which version are you using? We had the same issue before with an early version. After updating it to the latest the problem was solved.
Un-synched same java version b/w the client and server.
compatibility issues with different versions of SSL & TLS v1, where as client handles only using SSL v3).
Related
I'am using [Let's encrypt community for rancher][1] but since ACMEv1 is deprecated, it doesn't work anymore, i have this classic message
30/01/2020 16:29:04time="2020-01-30T15:29:04Z" level=fatal msg="LetsEncrypt client: Failed to register account: acme: Error 403 - urn:acme:error:unauthorized - Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details."
I saw there's is updated image to address this issues : https://github.com/janeczku/rancher-letsencrypt/issues/110 and in particular :
https://hub.docker.com/r/vxcontrol/rancher-letsencrypt/ or better https://github.com/TrueCarry/rancher-letsencrypt/tree/acme-v2
But since i am new at Rancher, i can figure how to use this image instead the old one ?
Can someone help me to understand how it works ?
I am using Rancher 1.6.29
Thanks a lot
I feel so dumb ... i just did an upgrade of the container, giving the uadevops/rancher-letsencrypt image, and worked flawless
The Phoenix application I'm supporting has OAuth authentication using two different authentication servers. Mysteriously, only in my development environment they have begun exhibiting unexpected behaviour.
The code uses the OAuth2 hex package for authentication.
When an attempt is made to get a token via OAuth2.Client.get_token/1, an error is returned with a tuple rather than a string for the reason. The value of the tuple is {:option, :server_only, :honor_cipher_order}. I haven't been able to find out why this is happening nor what the tuple means.
Any help would be appreciated.
Discovered that this was caused by https://github.com/benoitc/hackney/issues/591 following an upgrade on my machine to Erlang 22.1.
Without having to downgrade your erlang version, try:
mix deps.update hackney
I updated our signalr packages from 2.4.0 and added RunAzureSignalR instead of RunSignalR. Added this code in de Startup.cs
app.Map("/signalr", map =>
{
var hubConfiguration = new HubConfiguration
{
EnableDetailedErrors = true
};
map.RunAzureSignalR(typeof(Startup).FullName, hubConfiguration, options =>
{
options.ConnectionString = AppApiSettings.SignalRServiceConnectionString;
});
});
But when I try to send a message to the hub I get an exception The connection is not active, data cannot be sent to the service.. Can't find any reason this would happen or why the service would not run.
When I use RunSignalR (self hosted) everything runs great.
Any help would be greatly appreciated.
It turns out Azure Service only support TLS1.2 for security concerns.
Please add following code to your Startup:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
The hint for this solution was found on a github ticket: https://github.com/Azure/azure-signalr/issues/279
"No server available" indicates that your app server has trouble connecting to Azure service. You can enable tracing from the app server side with the following to see if any error throws.
GlobalHost.TraceManager.Switch.Level = SourceLevels.Information;
A sample here: https://github.com/Azure/azure-signalr/blob/dev/samples/AspNet.ChatSample/AspNet.ChatSample.SelfHostServer/Startup.cs#L19
If you are local debugging the server side, you can also uncheck "Just My Code" and break when any CLR exception throws:
System.Security.Authentication.AuthenticationException: "A call to SSPI failed, see inner exception."
- (inner) "The function requested is not supported"
System.ObjectDisposedException: 'Safe handle has been closed'
System.Net.WebException: 'The request was aborted: Could not create SSL/TLS secure channel.'
System.Net.WebSockets.WebSocketException: 'Unable to connect to the remote server'
- (inner) WebException: The request was aborted: Could not create SSL/TLS secure channel.
I recently had the same issue and again the accepted answer didn't help me. My project was a .NET 4.8 MVC application (so TLS version shouldn't be an issue) and following an update of the projects Nuget packages the issue arose.
I knew it was the Nuget updates that had broken my application but I didn't want to go through each one to figure out where the issue was.
Thanks to #cognophile for pointing me in the right direction. For me though I only needed to downgrade the following three Nuget packages to version 5.0.17 to fix the issue. Anything 6.x with these packages caused the issue again.
Microsoft.AspNetCore.Connections.Abstractions
Microsoft.AspNetCore.Http.Connections.Client
Microsoft.AspNetCore.Http.Connections.Common
I've recently had the same issue whereby the negotiation worked with map.RunSignalR(...) but not map.RunAzureSignalR(...) and tried the accepted answer here without resolution. For anyone still experiencing this issue having tried the accepted answer like myself, I found the below to work for a .NET Framework 4.6.1 project.
Navigating to the negotiation link (e.g. .../signalr/negotiate?clientProtocol=2.1&connectionData=...&callback=jQuery...&_=...) in the browser would give a
HTTP 500: Azure SignalR Service is not connected yet, please try again later
Having enabled the exception debugging suggestions from #Youp Hulsebos and the SignalR GitHub (source), I was able to find the following exceptions being thrown from the SignalR registration call in Startup.Configure(...):
Microsoft.Azure.SignalR.Common.ServiceConnectionNotActiveException: 'The connection is not active, data cannot be sent to the service.'
LoaderException - Method 'get_Features' in type 'Microsoft.AspNetCore.Http.Connections.Client.HttpConnection' from assembly 'Microsoft.AspNetCore.Http.Connections.Client, Version=1.0.0.0, Culture=neutral' does not have an implementation.":"Microsoft.AspNetCore.Http.Connections.Client.HttpConnection"
Having found the second of these exceptions and applying some Google-fu, I found this GitHub issue discussing the LoaderException from Microsoft.Azure.SignalR.WebSocketConnectionContext discussing this as the result of upgrading Microsoft.AspNetCore.Http.Connections.Client from 5.0.12.0 to 6.0.0.0.
Having tried downgrading the package to 5.0.12.0, I still encountered the same issue. Having checked the linked issue ([dotnet/aspnetcore#38699]), I downgraded the following packages to 5.0.11.0 and this resolved the issue:
Microsoft.AspNetCore.Connections.Abstractions
Microsoft.AspNetCore.Http.Connections.Client
Microsoft.AspNetCore.Http.Connections.Common
Microsoft.AspNetCore.Http.Features
See error from console:
WebSocket connection to 'ws://localhost:8090/vaadinServlet/PUSH?v-uiId=0&v-csrfToken=27328352-6365-44a4-b980-1ca2d7a5bc1c&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.3.2.vaadin1-javascript&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&Content-Type=application/json;%20charset=UTF-8&X-atmo-protocol=true' failed: Error during WebSocket handshake: Unexpected response code: 200
This is after upgrading to vaadin 8.0.0
Push annotation and manual enabling of Push do not seem to make a difference. It reverts to long polling.
My best guess is it is a version problem. You can see it mentions atmosphere 2.3.2 in the error, but vaadin-push 8.0.0 imports atmosphere 2.5.4
As of my understanding vaadin does have two atmosphere products integrated within vaadin-push, both forked by vaadin. One for the server side (https://github.com/vaadin/atmosphere) and one for the client side (https://github.com/vaadin/atmosphere-javascript). I assume that they do not need to be in sync. E.g. I saw that atmosphere-samples-2.4.2 has been released using atmosphere-2.4.2 and atmosphere-javascript-2.3.0.
There's also an issue https://github.com/vaadin/framework/issues/8734, which states about the problem with vaadin-push through websocket (and also the version question). Hopefully they take care of this soon.
I have a grails 1.3.7 application that makes an https api call to a third party using the apache HttpClient. The third party URL I'm hitting has a valid certificate. I create and execute my request like so:
HttpClient client = new DefaultHttpClient()
List<BasicNameValuePair> queryParams = new ArrayList<BasicNameValuePair>()
queryParams.add(new BasicNameValuePair("a_parameter", "a_parameter_value"))
URI uri = URIUtils.createURI("https", "third.party.address", 443, "/some/url/for/us", URLEncodedUtils.format(queryParams, "UTF-8"), null)
HttpGet httpGet = new HttpGet(uri)
try {
log.debug "Sending request to ${uri}"
return client.execute(httpGet)
} catch(HttpException e) {
log.error "HttpException during location lookup request: ${e}"
return
} catch(IOException e) {
log.error "IOException during location lookup request: ${e}"
return
}
This works fine when I'm running my project in dev mode. I'm also able to directly call the same URL from curl and my browser with no errors. However, once my project is built into a war file and put on a tomcat instance that has a certificate/keystore defined so that clients can connect to US using https, my requests start failing with the following IOException:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
I'm trying to figure out the point of failure here.
Why is making an https request from curl or my dev mode different than making an https request from an https configured tomcat instance?
The tomcat instance is not publicly accessible, but there are no certificate issues when I connect to it from my browser (chrome says the cert is fine, as does a verbose curl request).
I'm not an https/ssl expert by any stretch, so I'm looking for help explaining what is wrong, why it's wrong, and how I can fix it. I can provide any other needed info.
---Update---
I enabled the javax.net.debug as suggested below and the output included the following error:
java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be\
non-empty
My googling has made me think that this issue is because I'm using the following java opt when starting tomcat:
-Djavax.net.ssl.trustStore=/path/to/tomcat/conf/myStore.jks
If that's true, how can I add the things I needed in myStore.jks and not override the defaults so everyone is happy?
The solution for me ended up being that we were overriding the default java trust store with our own with the java opt. This caused the cert sent by the third party to appear to be invalid since we didn't have any of the default root certs in our myStore.jks.
By adding our self-signed cert into the default java one (/lib/security/cacerts) and removing the java opt, everything was fine.
An alternative would be to add everything in the default java store into your custom store and still use the java opt. Whichever you find more maintainable for your situation.
I have seen this error so many times. I have used the following utility to grab a cert from a site that uses SSL. Go here and grab InstallCert. Compile and Run this utility. You can use the file which was generated by this utility as a keystore.