I'm updating a legacy application to use a new payment REST service and I'm having trouble with a POST request. The code runs fine on a Windows 10 development machine but fails on Windows Server 2008 SP2:
Set HttpReq = Server.CreateObject("MSXML2.ServerXMLHTTP")
HttpReq.open "POST", uri, False
HttpReq.setRequestHeader "Content-Type", "application/json"
HttpReq.setRequestHeader "Authorization", authHeader
HttpReq.send json '<-- Error here
The Error I receive is:
msxml3.dll error '80072f8f'
A security error occurred
The webservice I'm calling only supports TLS 1.2, but as far as I can tell the machine running this code also supports TLS 1.2.
There is another question on StackOverflow with similar symptoms to this question that occurs on a Windows Server 2003 machine. The solution to that question suggests a HotFix be applied, but the link to the hotfix has been replaced with a cryptography programming guide which, whilst probably relevant, does not point to an obvious solution.
Update: It looks like I can send the same request via CURL on the same machine, so the machine itself can handle the connection to the url
Update 2: I've check the cipher suites available on the server against those reported for the target site, and there is some overlap. Also the target site is accessible via CURL, so I assume the two machines are able to communicate over https at some level
Update 3: I've adjusted the CreateObject line to use "MSXML2.ServerXMLHTTP.3.0" and "MSXML2.ServerXMLHTTP.6.0", but the error is just the same
Update 4: I've added the setOption line as suggested in other solutions on SO here and here, but the error code is the same. E.g. objHTTP.SetOption 2, objHTTP.GetOption(2)
Update 5: I ended up working around the problem by writing the necessary logic in a .NET Framework assembly, and accessing the functionality via COM. I don't particularly like the solution as it spreads the code across many codebases and complicates the deployment somewhat, but it was a pragmatic choice. I've also advised the business owners that the application and server are overdue for modernisation
I add the same issue a couple of years ago.
Then, can you try this piece of code and confirm that you see TLS v1.2 at the end of the response?
Set Http = CreateObject("MSXML2.ServerXMLHTTP.6.0")
http.SetOption(2) = 13056
http.open "GET", yourUri, False
http.Send
Response.write http.responseText
If TLS VERSION returned is not TLS 1.2, then it means your Windows 2008 server still needs a bit of configuration. Please proceed like described here and it should work.
Related
I have recently upgraded to 1.6.6.1 version of SuperSocket.Common, SuperSocket.SocketBase, SuperSocket.SocketEngine and SuperSocket.WebSocket. Everything works fine except it does not work when the client is using https to connect to my Web service.
Both http & https work fine with the older version of SuperSocket dlls and SuperWebSocket dll.
Has anyone used 1.6.6.1 versions of SuperSocket.Common, SuperSocket.SocketBase, SuperSocket.SocketEngine and SuperSocket.WebSocket with Https?
When I look at the logs I see that session was connected and then was closed by the client after few secs. When I attach the debugger it seems to call only the CloseSession handler but does not call the SessionConnect and SessionMessageReceive handlers in my code. It throws no exception or any other error log.
Does this require TLS 1.2 to be enabled to work? or any new config for tls for SuperSocket.WebSocket?
I have a Windows application (APP) and Audio Processing Object (APO) loaded by AudioDG.exe that communicate via gRPC:
APP part that is written in C# creates server via Grpc.Core.
APO part creates client via grpc++.
Server is on 127.0.0.1:20000 (I can see it's up and listening with netstat -ano).
I can confirm that APO is loaded into audio device graph by inspecting it with process explorer.
Everything worked like a charm on Windows 8 and 10, but on 11 it cannot communicate at all - I get either Error Code 14, Unavailable, failed to connect to all addresses or 4, Deadline Exceeded.
After enabling debug traces, I now see "socket is null" description for "connect failed" error:
I0207 16:20:59.916447 0 ..\..\..\src\core\ext\filters\client_channel\subchannel.cc:950: subchannel 000001D8B9B01E20 {address=ipv4:127.0.0.1:10000, args=grpc.client_channel_factory=0x1d8bb660460, grpc.default_authority=127.0.0.1:10000, grpc.internal.subchannel_pool=0x1d8b8c291b0, grpc.primary_user_agent=grpc-csharp/2.43.0 (.NET Framework 4.8.4470.0; CLR 4.0.30319.42000; net45; x64), grpc.resource_quota=0x1d8b8c28d90, grpc.server_uri=dns:///127.0.0.1:10000}: connect failed: {"created":"#1644240059.916000000","description":"socket is null","file":"..\..\..\src\core\lib\iomgr\tcp_client_windows.cc","file_line":112}
What I've tried so far:
Updating both parts to the latest grpc versions.
Using "no proxy", "Http2UnencryptedSupport" and other env variables.
Using "localhost" or "0.0.0.0" instead of "127.0.0.1".
Updating connection to use self signed SSL certificates (root CA, server cert + key, client cert + key).
Adding inbound / outbound rules for my port, and then disabling firewall completely.
Creating server on APO side and trying to connect with the client in APP.
Everything works (both insecure and SSL creds) if I create both client and server in C# part, but as soon as it's APP-APO communication it feels blocked or sandboxed.
What has been changed in Windows 11 that can "block" gRPC?
Thanks in advance!
In your input you write:
Server is at 127.0.0.1:20000
Further looking at the logs, you can see that:
The server is located at
grpc.server_uri=dns:///127.0.0.1:10000
Based on the question posed and the amount of data provided, I would check which port the server is really using and which port the client is looking for a connection on.
The easiest way to do this is to use the built-in Resource Monitor application. On the Network tab, in the TCP Connections list, you can find the application and the port it uses.
You can also use the PowerShell command
Test-NetConnection -Port 10000 -InformationLevel "Detailed"
Test-NetConnection -Port 20000 -InformationLevel "Detailed"
At least this is the first thing I would check based on what you described.
Regarding your question about the changes in Windows 11, I do not think that this is something that's causing problems for you. However, Windows 11 has additional security features compared to Windows 10, try disabling the security features completely as a test. Perhaps this will help solve the problem.
As for ASP.NET Core 6.0 itself (if I understood the version correctly), then there is a possibility that the server part, working not in the sandbox of the programming environment, still does not accept the client certificate. At the program level, you can try to fix this by adding the following exception to the code:
// This switch must be set before creating the GrpcChannel/HttpClient.
AppContext.SetSwitch(
"System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
// The port number(5000) must match the port of the gRPC server.
var channel = GrpcChannel.ForAddress("http://localhost:5000");
var client = new Greet.GreeterClient(channel);
More troubleshooting issues with ASP.NET Core 6.0 Microsoft described in detail here.
https://learn.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-6.0
I hope it was useful and at least one of the solutions I suggested will help solve your problem. In any case, if I had more information, I think I could help you more accurately.
I'm trying to send https post request using either FM HTTP_POST or class CL_HTTP_CLIENT but I wasn't successful yet.
To test my code I'm using https://ptsv2.com.
When posting to HTTP everything works fine but when I send a request to HTTPS I'm getting:
"OpenSSL not available" for rfc destination SAPHTTP.
"SapSSL error: SSSLERR_SSL_CONNECT" for default rfc destination -
SAPHTTPA
I think the problem might be from the BASIS site, I've already tried doing some magic with SM59/STRUST but those changed nothing so I was probably just messing around.
If anyone has any tips or sample codes(preferably with adresses to test) I'd be happy to try it out :)
You need to install the server SSL certificate root CA with t-code STRUST into the PSE SSL Client (Anonymous). Also you need to know the exact handshake configuration with your server. If your server only supports TLS 1.2, your SAP system must have commoncryptolib (sapcryptolib) at least 8.431 and the profile parameter ssl/client_ciphersuites must be configured. You can check the commoncryptolib version with the program SSF02.
If you need to investigate in details, you can go to t-code SMICM. Configure the trace level as 2 (Goto -> Trace Level -> Set). Reset trace file (Goto -> Trace File -> Reset) for removing old logs. Run your program again and check trace file (Goto -> Trace File -> Display All).
STRUST won't help, if you try to connect from the SAP GUI. This is where destination SAPHTTP goes to. In this case SAP note 2979489 might help.
My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.
I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)
I use HTTP protocol for send binary data to server (PUT request and Content-Type: application/octet-stream). Until recently time this worked fine.
But now I getting 504 http error on Windows (I try it on several Windows mashines).
I try do all what imagine, so correct this behavior. When I catch request through Fiddler. I see what full request has sended to server, but server not respond.
I send absolutly same request from Linux machine, so it still works fine as a before.
In addition I notice, what Windows mashine works correctly (PUT request and Content-Type: application/octet-stream) when in the body request contains only literal characters.
Any idea, what I do with this? Is it known issue?
I solve this issue. Problem wasn't on Windows.
This has came with server kernel version (kernel 3.0.23).
When I update kernel (Ubuntu server from 3.0.23 to 3.0.24 version), it was working again.
That most likely problem in recognizing TCP packages.