I'm trying to communicate a web application with a desktop application and I'm trying websockets.
The desktop application will be the websocket server, and the web application is the client.
Customers will have to download the desktop app (available for Mac, Windows and Linux) and install in their own computer. The desktop application is just a 'print server' to print POS tickets directly, without browser's confirmation, open cash drawer, etc.
So, the websocket client will connect to wss://127.0.0.1 (own user desktop).
Ok, the application is working perfectly with a self signed SSL certificate, but... Is it enough for production?
I mean... What type of certificate do I need for this? Can I buy a SSL certificate for the 127.0.0.1 address?
Can I use a free self-signed certificate? Do browsers accept it?
I have developed the server desktop application for Mac, Windows and Linux (and the web app for the client side) and just need a proper certificate to release the service!
You probably think that this is a misbehaving crawler problem but this CloudFlare website:
Blocks Internet Explorer on Windows 10 desktop (uses Windows API for HTTP)
Allows Edge on Windows 10 desktop (uses Windows API for HTTP?)
Blocks my crawler on Windows using WinInet Windows API for HTTP
Allows my crawler on Mac using Mac API for HTTP
Accordingly to this Internet Explorer 7 on Windows Vista should be support on even free CloudFlare:
https://support.cloudflare.com/hc/en-us/articles/203041594-Cloudflare-SSL-cipher-browser-and-protocol-support
I am in preliminary research phase, but it feels like a certificate issue. I have not experienced this problem before on any website when using Windows 10. (But yes, older versions of Windows can have similar problems to certificate problems)
Any ideas? I have not implemeted HTTP2 part of Windows API - is that a possible explanation? Would just be a bit odd to require that so.... But could possibly explain why Edge and not IE works.
I asked the website owner and the website was setup to only support TLS 1.3 and not accept TLS 1.2 --- TLS 1.3 support is still experimental in Windows 10 (internet options)
While i'm trying to download the file from Inno Setup download plugin, it fails with following error:
When explored more on this error I identified that enabling TLS 1.1 or TLS 1.2 from Internet Explorer settings it worked fine. But when I run the code in Windows XP or Windows Server 2003 (where it supports only TLS 1.0 so I cannot enable TLS 1.1 or TLS 1.2) it fails.
Code:
idpAddFile('https://www.testwebsite.com/downloads/SetupFiles.zip',
ExpandConstant('{tmp}\SetupFiles.zip'));
idpDownloadAfter(wpSelectDir);
TLS 1.1/1.2 is indeed not supported on Windows XP. Inno Download Plugin (IDP) is just a thin wrapper around Windows built-in implementation of HTTP. So no change in IDP code will allow TLS 1.2. You would have to implement HTTP and TLS from the scratch, what is an insane task.
Though note that the the problem about TLS version, not is not about certificate.
The only reasonable solution that supports Windows XP is enabling TLS 1.0 on the server.
I tried to configure a Port with an SSL certificate, this could be achieved by Httpcfg.ext tool, but I failed to find in my windows 10, I try to download it from http://www.microsoft.com/en-us/download/details.aspx?id=18546, but it only supports Windows XP, could you share us how to use Httpcfg.exe in Windows 10?
HttpCfg.exe is not available for Windows 10. You may want to check out Configuring HTTP and HTTPS on MSDN. It states that httpcfg is used on Windows XP and Windows Server 2003, whereas you should use netsh for pretty much any Windows operating system from Vista on.
If you are looking to do this programmatically then you could investigate using the HTTP Server API.
I wrote a VB6 program which uses winhttp.dll to send and receive messages to/from a remote server. It has been working fine from various operating systems: Windows 2000, WinXP, Win7, Win8.
Recently the server provider informed me that they will "phase out support of SHA-1 security certificates" and i need to "check that the thumbprint is aligned to SHA-2 new SSL cert.".
What is happening now is that when my program runs on WinXP,7,8 - it's still OK. But when running on Windows 2000, when I call the winhttp Send() method, I get an exception "Error Occurred in the Secure Channel Support".
I am failey clueless on certificates etc and I don't really know what to do.
My Vb6 code looks as follows:
' Connect to server
Set m_ServerObj = New WinHttpRequest
m_ServerObj.Open "GET", m_ServerURL_SC
' Send request to server
m_ServerObj.Option(WinHttpRequestOption_SslErrorIgnoreFlags) = &H3300
'Unknown certification authority (CA) or untrusted root 0x0100
'Wrong usage 0x0200
'Invalid common name (CN) 0x1000
'Invalid date or certificate expired 0x2000
m_ServerObj.Send xml
The error occurres when Send is called
ERROR_WINHTTP_SECURE_CHANNEL_ERROR: This is a generic error thrown whenever Schannel.dll encounters a SSL version / feature / cipher / key-length / etc. it doesn't understand or support, or when the server (in the case of a client) will not negotiate for anything the client supports. WinHttp relies on it (which is part of the OS) to provide support for SSL / TLS secure channels.
Now, in your case, a few reasons could explain this error, but since connecting to the server in question still works under Windows XP when it fails on Windows 2000, I don't think this failure is related (yet) to those SHA-2 signatures. [more details at the end]
1) SSL 3.0 or TLS 1.0 disabled
First thing I would check: open "Internet Options" from the Control Panel, switch to the "Advanced" tab, and in the options make sure SSL 3.0 & TLS 1.0 are checked. If you had to tick any of the two, a reboot will be needed. Then check again. (afterwards, if it still fails, you're free to disable SSL 3.0 if you wish i.e. because of POODLE)
2) Disabled / Missing CSP or no CSP provides support for the required cipher(s)
Schannel.dll makes use of the available cipher suites as provided by the different Cryptographic Service Providers (CSP) installed on the machine. If none of the CSPs provide support for the cipher(s) required by the server, then the HTTPS connection will fail.
I don't know in details the difference between the exact list of ciphers available on Windows 2000 versus those on Windows XP. Well, I know AES support was introduced with Windows XP & Windows Server 2003, and SHA-2 support (hashing using the CryptoAPI, not those SHA-2 certificates for TLS) was introduced as part of Windows XP SP3. As for Windows 2000, the MSDN page Cipher Suites in Schannel doesn't say anything about Windows 2000, but the list of CSPs included with Windows 2000 can be found in the page Microsoft CryptoAPI and Cryptographic Service Providers. More research would probably give you more details on what is supported on Windows 2000 and what's not.
If the error is indeed related to the installed/available CSPs, then the discrepancy between Windows 2000 and Windows XP would mean one of three things: a) a cipher or cipher suite, available on both Windows 2000 and Windows XP, has been disabled for Schannel on that/those Windows 2000 machines; read How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll to find out which registry keys are used to disable cipher/cipher suites, so you can check if it's the case. b) a cipher or cipher suite, available on both Windows 2000 and Windows XP, is missing/not registered on that/those Windows 2000 machines; there is no easy way to check this, but if you get that connection error on every Windows 2000 machine you try, then c) would make more sense. c) a cipher suite, bringing support for at least one of the ciphers (e.g. AES) required by the server, was only introduced in Windows XP and is not available for Windows 2000; you're then out of luck, if you stick with WinHttp anyway.
By now you should have a few cues on what could cause the error (my bet: AES is the minimum being required)
About those SHA-2 certificates
Support for SHA-2 signatures (superseding SHA-1) was introduced with TLS 1.2. If you didn't know yet, the only Windows OSes supporting TLS 1.2 (and thus certificates with SHA-2 signatures) are Windows 7, Windows Server 2008 R2, Windows 8+ and Windows Server 2012. This of course should not affect most applications (e.g. Chrome uses BoringSSL, a fork of OpenSSL) unless they depend on Schannel.dll, like WinHttp or most other Windows components.
SHA-1 certificates are expected to be gone by January 1st, 2017. By then, more and more servers will have ported their certificates to the SHA-2 variety, so expect more HTTPS connection failures for WinHttp under Windows XP & Windows Vista. It makes sense, after all; support for Windows XP finally came to an end on April 8, 2014 (Microsoft had already dropped support for Windows Vista) and the last Windows OS not supporting TLS 1.1 & 1.2, Windows Server 2008, reached end of mainstream support this January.
So, what should you do?: Either stop supporting Windows 2000 & XP, or find a replacement for WinHttp that uses a SSL/TLS library, e.g. OpenSSL, being regularly updated. Maybe libcurl?
Final note: Unless you use a self-signed certificate or a certificate without a valid chain of trust for the server, you really should leave WinHttpRequestOption_SslErrorIgnoreFlags to &H0& (otherwise, what's the point of using SSL/TLS?)