I'm porting a vb.net HTTPS client application on WinCE60 CF35: bsically it needs to send HTTPS REST requests to a server.
I started development on a Win10 desktop and there I have no problems (VS2015 - NET35).
When I run on WinCE I receive an exception when I send the webrequest: the system says that it does not have the error message, but I see the status = 10 = SecureChannelFailure.
The code is the following:
Private Function SendGetRequest(cmd As String) As Boolean
Dim request As WebRequest = WebRequest.Create(m_baseUrl + cmd)
request.Method = "GET"
request.Timeout = m_timeout
request.Headers.Add("Authorization", "Basic " + m_authInfo)
'
Dim dataStream As Stream
'
Try
Dim response As WebResponse = request.GetResponse()
m_statusCode = CType(response, HttpWebResponse).StatusCode
dataStream = response.GetResponseStream()
...
On the server side I don't receive anything. So, I tryed to sniff using Wireshark and I see the following:
In my understanding the client (.113) sends a RESET, but I don't know why ..
PS: if I build a HTTP request I receive response.
Multiple potential issues here:
Based on the error message, the most likely problem: The CE device may be missing a root certificate, or the root certificate may be expired or revoked, and therefore Windows CE is unable to verify the server certificate. If your CE device has a UI, open the Certificates applet in the Control Panel to verify that the required root certificate is installed and valid
.NET CF does not support SHA-2 based certificates (see answers here). Mentioning this because it's the next problem you are likely to run into, once the root cert is in place
Windows CE often sends RST to close TCP connections. Not pretty, but probably unrelated to the HTTPS problem you're seeing (as far as I understand the rationale is this is faster than having both sides send FIN/ACK)
Related
I am trying to learn some secure client / server programming. I am using .NET CORE 7, VS 2022 Pro, on Windows 11. I found the following example at MS showing how to establish a connection using TLS.
https://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslstream?view=net-6.0
I bought a cheap cert from COMODO and installed it into my Machine Personal Store. When I click on it there is a private key embedded in the certificate.
I did modify the code from the example above to pull the certificate from the store on the machine instead of loading it from a file...
Public Function getServerCert() As X509Certificate2
Dim store As X509Store = New X509Store(StoreName.My, StoreLocation.LocalMachine)
store.Open(OpenFlags.[ReadOnly])
Dim foundCertificate As X509Certificate2 = Nothing
For Each currentCertificate As X509Certificate2 In store.Certificates
If currentCertificate.IssuerName.Name IsNot Nothing AndAlso currentCertificate.Subject.Equals("CN=<certname>") Then
foundCertificate = currentCertificate
Exit For
End If
Next
Return foundCertificate
End Function
This is my Authenticate line of code...
sslStream.AuthenticateAsServer(getServerCert, clientCertificateRequired:=True, SslProtocols.Tls12 Or SslProtocols.Tls13, checkCertificateRevocation:=True)
RaiseEvent Output("Client has connected!")
The issue I am running into is on the server when the client attempts to connect I receive this error:
"The remote certificate is invalid according to the validation
procedure: RemoteCertificateNotAvailable"
I have been pulling my hair out for hours trying to get past this error. Can anybody assist in what this means and how I can possibly fix it? I am running the client and server both from the same machine as I develop it (not sure if that makes a diff) but I did try running the client from a different machine and still got the same error.
Thanks!
Background: Console app built in .Net 4.6.2
Dll: Restsharp 106.15.0.0
Mono: Mono JIT compiler version 6.12.0.122
API Endpoint: http server (not https)
At first I thought I was going mad as all was working okay on windows but when I run my console app on Debian (v9), it will constantly fail with the error: unable to read data from the transport connection. I've narrowed it down to restsharp and not a api/server issue.
When I run a debugger in parallel (HTTP Debugger) I can see the request go out from my console app on Debian and I can also see the endpoint return a result with content! This content does not come into restsharp and so restsharp gives me a content-length of 0 and an error message of:
unable to read data from the transport connection: An existing connection was forcibly closed by the remote host
Any ideas please?
Code to trigger restsharp:
Dim myUri As New Uri(url)
Dim client = New RestSharp.RestClient(myUri)
Dim request = New RestRequest With {.Method = Method.GET}
request.AddHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9")
request.AddHeader("Connection", "keep-alive")
Dim response As RestResponse = client.Execute(request)
Dim strResponse as String = response.Content)
(I've also tried without sending the headers - makes no difference, same error message)
Thanks
I have a Java agent that connects to a payment gateway to validate a CC transaction.
Everything seems to work fine when the Java logic is run on my IBM Notes client (9.0.1FP10IF3).
I am now migrating the logic to a managed bean on my Domino server (9.0.1FP6).
Whenever the connection is made through the bean, I observe the following error on the server console...
HTTP JVM: javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure
I am certain it's because the payment gateway with which I am attempting to communicate has recently upgraded to enforce mandatory TLS 1.2 communications.
However, I'm not sure how to enforce those communications on the Domino server side?
I have set the recommended NOTES.INI variables...
DISABLE_SSLV3=1
SSL_DISABLE_TLS_10=1
... and set the 'SSLCipherSpec', but nothing is working.
Here is an excerpt from the logic I'm using to test everything out.
The 'DataOutputStream' line is what triggers the error...
URL url = new URL("https://host/endpoint");
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("POST");
connection.setAllowUserInteraction(false);
connection.setDoOutput(true);
connection.setDoInput(true);
connection.setUseCaches(false);
connection.setRequestProperty("Content-type", "text/xml");
connection.setRequestProperty("Content-length", Integer.toString(postContent.length()));
DataOutputStream out = new DataOutputStream(connection.getOutputStream());
out.writeBytes(postContent);
out.flush();
out.close();
connection.disconnect();
Any advice/assistance would be most appreciated!
As Per answered, this document allowed me to resolve the issue straight away...
www-01.ibm.com/support/docview.wss?uid=swg21985289
My code is trying to access a template file on the same server as the application.
It all worked fine until we switched on SSL.
Now when connecting to the file I get a SSLHandshakeException: handshake_failure with not much information on the actual cause of the issue.
If I try to access the file through the browser I get a warning page asking if I want to proceed at my own risk.
Is it a problem with the certificate? Can I bypass it?
Edit: The server is JBoss EAP 6.1 with Java 1.7. It's configured to use TLS1.2.
The bit retrieving the template is:
URL url;
URLConnection urlConnection;
try {
url = new URL(templateUrl);
urlConnection = url.openConnection();
urlConnection.setConnectTimeout(connectionTimeout);
urlConnection.setReadTimeout(connectionTimeout);
BufferedReader breader = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
String line;
while ((line = breader.readLine()) != null) {
strHtmlContent.append(line);
}
}
Handshake error is usually not a problem with the certificate, at least not with the validation of the certificate. It can have several other reasons, typically wrong protocol version, no cipher overlap, missing use of SNI... .
Unfortunately it is impossible to say what the problem is in your specific case but you might narrow it down by trying to access the site with different clients (i.e. browser, curl, ...). If not even a browser can access the site it is probably a misconfiguration of the server.
We updated our SSL certificate to SHA2, but the intermediate certificate was SHA1. Chrome and other browsers have decided that the entire chain must be SHA2. Our customers were calling concerned about the yellow caution in the address bar. Rumor has it that in a few months Chrome and other browsers will replace the mildly unobtrusive caution with a stop screen. We certainly don't want that!
...
So we reissued the certificate and the new one is signed by the SHA2 intermediate. When we use that certificate to encrypt the traffic on our server, our applications that are using MSXML2.ServerXMLHTTP (running on Windows Server 2003) to access remote web services on that server can no longer connect.
After researching, we applied these two hotfixes that looked like they might could have addressed the issue:
https://support.microsoft.com/kb/938397/en-us
https://support.microsoft.com/kb/968730/en-us
But the problem persists. Switch the cert back to the SHA2 with SHA1 intermediate and we have no issues.
We have installed the intermediate SHA2 certificate in the trusted store but the problem persists.
We have tried specifying all versions of the MSXML2.ServerXMLHTTP and all fail.
ASP code :
function query(xml)
dim xmlhttp, xmlDoc, url
url = application("component_url")
set xmlhttp = server.createobject("MSXML2.ServerXMLHttp")
call xmlhttp.open ("POST", url, false)
call xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded")
on error resume next
err.clear
call xmlhttp.send(xml)
if err.number <> 0 then
call sendAlert("An error has occurred while trying to send your request", message)
else
dim rt
rt = ConvertUtf8BytesToString(xmlhttp.responseBody)
set xmlDoc = server.createobject("MSXML2.DomDocument")
xmlDoc.loadXml(rt)
end if
on error goto 0
set query = xmlDoc
set xmlHttp = nothing
set xmlDoc = nothing
end function
Your situation is very likely same as this post, specially the last answer as you mention the script has been running for 10+ years.
Quoting the last answer in full:
I know it is an old question. This issue could be because of
unsupported cipher suites. Try adding - TLS_RSA_WITH_AES_128_CBC_SHA
AES128-SHA - TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA
That means you have to follow this kb:
http://support.microsoft.com/kb/948963 This update is also interesting
if you are still using windows 2003. Which will allow connecting to
site using SHA2 - http://support.microsoft.com/kb/968730
Please note that Windows Server 2003 support is ending July 14, 2015
If the code is running on a Windows Server 2003, I suggest you try it on a newer machine, maybe a laptop with Windows 7 for a quick test.