I have an Azure App Service with Stack General setting ASP.NET v4.7. However, in the web.config target runtime version is 4.5.1.
I have another Azure App Service which hosts a Linux container.
The first one is set to use TLS 1.2.
I am initiating requests from .NET App(first) to Linux container(second).
When the Second one, Linux container is set to use TLS 1.2 requests fail, but when set to TLS 1.0 requests process successfully.
Has anyone experienced this issue?
From the post it is tricky to narrow down on your issue but a couple of things you can try.
Ensure no hard coding of TLS version. On the contrary, you can try hardcoding the TLS version with ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;. Try to run. If it works, you'll have the clarity that there is not other issue and you need to switch to right .NET version.
Target your .NET Framework version 4.7 and above. You say your target runtime version is 4.5.1 which won't help sending requests with latest TLS version by default.
<system.web><httpRuntime targetFramework> in web.config should show the intended version of the .NET.
Last but not least it is always good to patiently read the doc and you might figure out the issue yourself.
Related
Error: java.io.IOException: Could not transmit message
Issue details: We are running our application with Jboss AS 5.1 and OpenJDK 7 (version 1.7.0_261), servers are Red Hat Linux CentOS 5.
We have a legacy application that makes several web service calls to NetSuite, after the recent NetSuite update of obsoleting the old cipher suites all our calls started failing. TLSv1.2 protocol is enabled (with -Dhttps.protocols=TLSv1.2 in run.conf), since it is Java 7 we added bouncy castle security jars to increase the supported cipher suites (as recommended in this comment by Igor: https://stackoverflow.com/a/49154932/2308058), with this, we were able to get the REST Web Service calls working but we are getting the error - org.bouncycastle.tls.TlsFatalAlertReceived: internal_error(80) for SOAP WS calls.
Other things we tried but nothing seem to bring us luck yet:
Explicitly adding cipher suites that are supported by NetSuite in run.conf with -Dhttps.cipherSuites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Adding TLS protocol with tls.client.protocol in run.conf - -Djdk.tls.client.protocols=TLSv1.2
Added self-signed cert to keystore
Added NetSuite's cert to Java cacerts
SOAP calls are working fine with Java 8 but moving this legacy application to Java 8 and Wild Fly is a very heavy lift so we are looking for alternative options.
Any suggestions on getting this resolved would be very helpful, please! TIA!
TlsFatalAlertReceived means a fatal alert was received from the peer (i.e. NetSuite failed). internal_error would usually mean that something went wrong in the implementation itself, rather than any configuration match like cipher suites, however I don't know how careful NetSuite is about its choice of alerts. In any case, apart from guessing what the issue is, the real next step is to look at the NetSuite server logs to find what's failing.
I have set up a plain SignalR solution using .NET Core 2.2. I cannot use Core 3.x because I need to use some libraries that depends on 2.2.
It works fine when i debug locally.
However, when I deploy to Azure as an App Service, whenever the JS tries to establish a connection, I can see in Chrome's network tab that it fails when calling /hub/negotiate, and that it returns a 400.
This does not happen locally. Locally I'm running IIS Express, and the server in Azure is running Kestrel.
What I have tried thus far:
Made sure web sockets is enabled under configuration in Azure. It was already enabled.
I believe Kestrel is behind a proxy in Azure, so I added app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto }); at the very top. This had no effect.
I'm not using MessagePack.
Using:
netcoreapp2.2
#aspnet/signalr 1.1.4 (is this correct for 2.2? it works locally)
What could be wrong?
I can tell you clearly that there is no problem using signalr 1.1.4 in .net core 2.2.
It can run normally when deployed in windows and linux. You can download my test code from github, and compare with your project, is there any modification that caused this error?
The proxy settings are not used.
The only thing to note is:
I found that when the project is deployed under linux, it takes a while to start normal operation, about three to five minutes. The reason is currently unclear. If you encounter it, you can raise a support ticket on the portal.
I have a web API hosted by a simple ASP.Core application using the Kestrel webserver. The webserver runs in a plain ASP.Core docker container under Ubuntu linux (there is no IIS installation).
We use the SSL Server Test to determine if the SSL configuration is considered secure:
https://www.ssllabs.com/ssltest/index.html
Currently we get the F- rating (the worst, which kinda sucks).
We only enable TLS 1.2 which is good, but apparantly our TLS 1.2 configuration supports the following cipher suits which are considered very insecure:
This server supports anonymous (insecure) suites (see below for details). Grade set to F.
TLS_ECDH_anon_WITH_AES_256_CBC_SHA (0xc019) INSECURE 256
TLS_ECDH_anon_WITH_AES_128_CBC_SHA (0xc018) INSECURE 128
How can I disable these ciphering mechanisms on the Kestrel webserver running in a container? Preferably by adding code to the application so we can still be configuration independant.
I have already disabled insecure SSLv3, TLS 1.0 and TLS 1.1 by adding the following code:
httpsOptions.SslProtocols = System.Security.Authentication.SslProtocols.Tls12;
The solution was to upgrade from ASP Core 2.2 to ASP Core 3.0-preview8.
This issue is fixed in ASP Core 3.0-preview6 and newer. By default the insecure cipher suits are disabled now. SSL test grade went from F to B without changing the code. See details about the Kestrel cipher suits here: https://github.com/aspnet/AspNetCore/issues/9349
ASP Core 3.0-preview8 is regarded as production-stable and migrating the server from 2.2 was easy (even with the IdentityServer4 library dependency). Here are the instructions we followed to migrate the server:
https://learn.microsoft.com/en-us/aspnet/core/migration/22-to-30
I have two environments. 1 online, the other is local.
online is user trial environment: win server 2016, sql server 2016,
IIS 10.0, authorized organization signed SSL certificate. Acumatica
18.000.0062
Local is development environment: windows 10, sql server 2016, IIS
10.0, Self-signed SSL certificate. Acumatica 18.000.0062
Online environment performs properly consistently, no matter for SOAP
service or Restful service(using oath 2.0).
However, Local worked correctly at the beginning, which means the screen-based API worked properly with the WSDL of each screen's web service be generated correctly at that time, and contract-based API responded correctly using cookies mode. Here comes the problem. After I installed self-signed certificate in order to use oath 2.0, both SOAP and rest APIs are crashed with same error "Object reference not set to an instance of an object".
I have digged by myself, the obvious phenomenon that indicating something went wrong is the "tools--web service" to generate WSDL. Before self-assigned certificate be installed, All screens could be generated correctly, after , all screens encountered the same error
Source File: ...\Frames\WsdlHelp.aspx.cs Line: 9
I don't want to be misleading, but these are the details as much as I could provide. What my point is the online and local environment are almost exactly the same, online always works properly even with SSL on. So my large guess is there is something to do with the self-signed certificate. however, even after turned off the https on local IIS, the problem still exists. SO,
Is there anyone can give me some help on this headache issue?
Unfortunately, this is a known issue with Acumatica and .net 4.7.2. It was fixed in 2017R2 Update 8 and 2018R1 Update 2. I'm afraid you have no choice but to either downgrade .net to 4.7.1 or upgrade Acumatica to one of those versions.
I have made a ServiceStack Web App that uses a custom AppHost from a plugin (similar to the example https://github.com/NetCoreWebApps/WebApp/tree/master/src/apps/chat). I can run it on macOS with the dotnet command as per the examples.
Can I host my Service Stack Web App on IIS? What approach should I take? Reverse-proxying Kestrel like this https://learn.microsoft.com/en-us/aspnet/core/publishing/iis?tabs=aspnetcore2x
or will I need to have different AppHost/Startup code for the two hosting situations?
Or maybe there's a fundamental reason why it will never work?
WebApp is a standard .NET Core 2.0 App so you'll be able to host it as you would any other .NET Core App. Normally reverse proxies don't require anything except the internal url where the request is proxied to, but it looks like IIS wants you to explicitly call .UseIISIntegration() which is an issue that may have prevented the existing WebApp binary as it didn't call .NET Core 2.0 WebHost.CreateDefaultBuilder(args) which among other things would turn on IISIntegration when the .NET Core App is hosted in IIS/Windows which is now being done from this commit.
You can find the updated Web App binaries with this change in the /web folder of the https://github.com/NetCoreWebApps/Chat project.