I have an issue with a windows server where an application pointing at a https end point fails with a:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure.
Actually it used to succeed but now it does not.
This is within an enterprise so the https is pointing to a private IP address.
What options do I have to investigate the handshake failure from the windows server?
openssl is not available on windows.
I have googled wireshark and Microsoft network Monitor.
Not sure I will get the go ahead to deploy either of these 2 options.
Any suggestions?
TIA
Tony
Related
I'm trying to install a self-host WCF service on a server with Windows Server 2012.
I was following these steps:
import my pfx file with mmc
run "netsh http add sslcert ipport=0.0.0.0:49000 certhash=e09280ded2322eb858b38b3250e1a488f797b269 appid={4dc3e181-e14b-4a21-b022-59fc669b0914}"
install my service and start it
At first it works well. But after a few hours the ssl crashes and I can only get error msg at client as below
An unhandled exception of type 'System.ServiceModel.CommunicationException' occurred in mscorlib.dll.
Additional information: An error occurred while making the HTTP request to https://servername:49000/WCFServiceName. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.
run "netsh http delete sslcert ipport=0.0.0.0:49000"
and delete the imported pfx and then redo step1 and 2 can make ssl works again, but the problem will still appears in a few hours.
It's definitely not the SecurityProtocol problem, for I have already tried adding
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
before request. And both server and client uses .Net Framework 4.5.2
I've tried "netsh http show sslcert", and got below result:
IP:port : 0.0.0.0:49000
Certificate Hash : e09280ded2322eb858b38b3250e1a488f797b269
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
I've tried delete the sslcert binding on port 49000 and created an empty website binding to port 49000 in IIS and make my service listening to that port then. It works the first time and lasted for about a week before the same error pops out.
Where should I begin to locate and solve this wired problem?
First, we should ensure that the certificate private key could be accessed by WCF. The Network Service account (or Everyone account) should be added in the certificate READ/Writer group, then we run the application (windows service, or console?) with corresponding account.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-make-x-509-certificates-accessible-to-wcf
Second, as you know, TLS version need OS and Dotnetframework support, the default protocol version is ssl3.0/tls1.0(auto-negotiate, could not be configured). We had better use the latest OS version and .netframework4.7. I think this may be the cause of unstable communications.
Please refer to the below document.
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls
Feel free to let me know if the problem still exists.
I've got an intranet site setup which uses an SSL cert with a self-signed CA. On one of my Macs, Safari refuses to connect, with the "Safari can't open the page .. because Safari can't establish a secure connection to the server .." The Mac is running 10.11 (El Capitan) with the latest patch.
Chrome and Firefox are both able to connect to that server.
Safari is willing to connect to it if I use the IP address instead of the
DNS name.
In the logs I see com.apple.WebKit.Networking[3382]:
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
Another Mac on the LAN is happy to connect to the machine by its DNS name
I suspect there's something wrong in the keychain, but I can't find any certs nor revocations for anything related to either the DNS name of the machine, or its CA.
Any suggestions how to debug this are very welcome. The other StackOverflow articles seem unrelated to my issue.
My solution to this issue was to revert my Apache Configuration SSL Cipher Suite back to the default setting in WHM. Hopefully this may be of help.
I recently ran into a similar issue with an iOS device on an intranet. I installed the self-signed root and issuing certificates on the phone, but continued to receive the message. After a lot of trial and error, I found that manually changing the DNS setting (tapping the 'i' icon next to the active wifi connection in the wifi settings) to Google's public DNS ("8.8.8.8") solved the problem.
I am trying to enable SSL on Apache Server (XAMPP) on Windows Server 2012 R2. I have a signed certificate from a Certificate Authority.
Following the installation instructions, I copied the private key, Server Certificate and Intermediate CA certificate properly to right directory and also made necessary certificates name path settings in httpd-ssl file.
Now when i am trying to start Apache through Xampp it is giving me following error:
Error: Apache shutdown unexpectedly.
12:42:29 This may be due to a blocked port, missing dependencies,
12:42:29 improper privileges, a crash, or a shutdown by another method.
12:42:29 Press the Logs button to view error logs and check
12:42:29 the Windows Event Viewer for more clues
12:42:29 If you need more help, copy and post this
12:42:29 entire log window on the forums
Finally error is resolved now. The Error is because of "SSLPassPhraseDialog builtin is not supported on Win32". I followed this link and got it working. "https://support.quovadisglobal.com/KB/a90/i-get-error-message-error-init-sslpassphrasedialog.aspx" Thanks again.
I receive the following error after trying to log in to a secure website using Firefox 36.0.4. (Error code: ssl_error_bad_mac_read). The error does not occur when I hit the page, but rather after I enter my credentials and click login.
This issue began occurring starting with Firefox version 35. It does not occur using any version of IE or Chrome. I do NOT receive this error if I go into the Firefox config and set the security.tls.version.max = 2. (The default value for security.tls.version.max is 3). This indicates to me that TLSv1.1 and lower work fine.
This specific issue only occurs when my internet traffic goes out through my office firewall and then in through a remote site's F5 1600 load balancer where the web server lives. This issue does not occur if I hit the website locally (local IP) which would come in behind the F5. This issue also does not occur if I access the website outside the office. This issue can be re-created using any browser on any OS (Mac, Linux, and Windows).
The following conditions have to be true for this issue to occur:
a.)The web traffic has to go through BOTH the Fortigate 200d firewall and the F5.
b.)Using Firefox 35 and up
c.)Using the default browser TLS settings
Fortigate Firmware Version: v5.2.2,build642 (GA)
BigIP- F5 LTM 1600 Firmware Version: 11.4.0
This is problably associated with function "SSL/TLS Inspection" on Forintet router/firewall.
This functions tries to encrypt and decrypt TLS traffic, and it does something wrong in TLS negotiation (it modyfied "Client Hello" or "Server Hello" message, in place about TLS versions).
In my case, solution was to disable this function on router Fortingate.
I'm running mitmdump (from mitmproxy) on my Macbook Pro, and I'm connecting to the proxy through my Windows desktop PC.
However, Chrome (running on the PC) refuses to connect to so many sites because of the invalid certificates which mitmproxy provides.
Chrome throws the error: ERR::NET_CERT_AUTHORITY_INVALID
Here's what mitmdump shows:
But why? What's wrong with mitmproxy's certificates, why can't it just send back google's as if nothing happened?
I'd like to know how I can fix this and make (force) my desktop PC to connect to any website through my Macbook's mitmproxy.
Answering this question for people who may find this important now. To get the proxy working, you have to add the certificate as trusted in your browser.
For windows follow this: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/2/
For linux follow this: https://dev.to/suntong/using-squid-to-proxy-ssl-sites-nj3
For Mac-os follow this: https://www.andrewconnell.com/blog/updated-creating-and-trusting-self-signed-certs-on-macos-and-chrome/#add-certificate-to-trusted-root-authority
There are some additional details in the above links; tldr; import the certificate in your chrome://settings url and add the certificate as trusted. That shall do.
This will make your browser trust your self-signed certificate(mitm auto generated certificates too.)
The default certificates of mitmproxy is at ~/.mitmproxy/ directory.
Per the Getting Started page of the docs you add the CA by going to http://mitm.it while mitmproxy is running and selecting the operating system that you are using. This should solve your problem and will allow https sites to work with mitmproxy.
This is the expected behavior.
mitmproxy performes a Man-In-The-Middle attack to https connections by providing on-the-fly generated fake certificates to the client while it keeps communicating to the server over fully encrypted connection using the real certificates.
This way the communication between client and proxy can be decrypted. But the client has to actively approve using those fake certificates.
If that wasn't the case then SSL would be broken - which it isn't.
The whole story is very well explained here:
http://docs.mitmproxy.org/en/stable/howmitmproxy.html