We have an app built in Delphi 7 using Indy 9 for https connections to a php back end running on PHP, on Linux. The app connects to our current production server without a problem. We have been building a test environment for this application in house, and on the test web server, it refuses to connect using https. The app HAS been able to connect to this server using http. I can connect any current browser using the same web calls the app makes (haven't tried older browsers), and I get the connection, and the data returs perfectly, so apparently a there's something in Indy 9 holding this up from working (which is why this question is here and not on ServerFault) Does anyone have enough experience with Indy / SSL to know what's happening here?
Here are the few differences I thought might have some input:
1. I was initially starting with a wildcard cert. It is valid, and on the correct domain. It works with everything else we have on lots of servers.
2. Thinking it was possible that wildcard certs are a newer thing than Indy 9, I removed the wildcard cert, and put in a self signed cert, with the full machine name. It failed in the same way. BUT, as you know, browsers issue a cert exception with these self signed certs, so I was unsure if this would ALSO give Indy problems.
3. I'm sure the version of OpenSSH on our new development server is newer than the one that is currently on our production server. I can dig out these exact versions if someone thinks it will help.
This is an app I inherited, so my knowledge of SSL and Indy is limited. This app is at the end of it's life, so upgrading to Indy 10 is not something my company is going to fund. Any help or pointers or hints are extremely welcome, and my thanks would be infinite.
Thank you so much Stackers!
There's no mention of the specific error that is going on, so to offer suggestions without the particular error message is difficult.
1) Track down the actual responses you are receiving in the SSL handshake and try to make heads or tails of the messages. (DoStatusInfo())
2) (Big guesss here) SSL connectivity comes in different versions where the older versions are out of date and no longer recommended to be supported. If you are building a new server, it likely has defaults that are different than the current production machine which I'm assuming to be a much older build. (The older it is, the more applicable this guess is.) The newer servers should hopefully be refusing to connect to SSL V2 and V3 (and only allowing TLS) So it could be the difference of configuration of old production server and new test server and this new one is filtering out the older SSL versions and preventing the handshake to continue. (Which would be shown in handshake failures in #1 which is your real tool to use to answer this question.)
Here's a quick test of connectivity using openssl.exe. Try this connection to the test box and to the production machine to see if the connection is made. You can try v3 as well to either verify or eliminate this guess...if they act the same, then concentrate on #1. :)
openssl s_client -ssl2 -connect yourhost:443
Try enabling the sslvrfPeer flag in the TIdSSLIOHandlerSocket.VerifyMode property and then return True in the TIdSSLIOHandlerSocket.OnVerifyPeer event.
Related
I have a persistent problem with my Heroku app for some users. Since May 2020 I've had 4 users that I know of (presumably there are more) who have been unable to access my app because of the following error:
'Client and server don't support a common SSL protocol version or cipher suite'
I have spoken to Heroku about this, and they have run all tests, checked DNS, ssl certificate etc, and everything looks fine. I have done the same and can see no problem.
2 of the users were able to fix the problem and access the app by altering their DNS settings (one using a VPN, the other had their IT dept change DNS on their machine). The users have not had a similar issue with other sites.
I changed domain name provider to namecheap because they are recommended by heroku because of their dynamic ip, and I thought that might fix the problem, but it doesn't appear to have done so.
This is a very frustrating error, because I don't know what else I can do about it. What is causing this problem, and what can fix it?
We are running a legacy application on an Apache v7.0.47 server behind an Apache2 HTTPD proxy (v2.4.23).
I am trying to upgrade the Java version on the server (used by both the proxy as well as the tomcat) from v1.8.0_181 to v1.8.0_303.
After that upgrade the Tomcat does not respond any more to the Apache's passed-on requests (the application itself comes up and runs fine).
Both the Apache on its network facing side as well as Apache and Tomcat among each other were configured to "talk" TLS1.2 already for a while, so I don't think that the disabling of TLSv1.0 and TLSv1.1 in the later Java version is the cause of the issue here. And there is no error message in the logs giving any clue. The only indication is, that the Tomcat seems to close and tear down the connection without any response after having receiving the request. That seems to happen already in the SSL layer, since there is no entry in the access-log (of Tomcat).
Switching back to the "old" Java gets things going again, so firewall, network etc. are definitely NOT the issue here. With the newer Java version the connection setup fais again, causing the HTTPD to emit a "502 Bad gateway" error.
Any idea anyone what could cause the Tomcat to reject the HTTPD's requests just based on the Java version? Additional SSL verifications enabled by default in the newer stack? I searched extensively but didn't surface any suspect, yet.
Later addition: trying to identify the issue I found out that with Java v1.8.0_231 things are still working, with v1.8.0_241 and higher it fails.
Inspecting the release notes now to find a hint...
Any ideas or experiences with that upgrade anyone?
Just for the records - in case someone else stumbles over this question:
The issue here was that from Java v1.8.0_241 on upwards Java security verifies that a certificate chain read from a certificate store is rooted in a CA certificate that has a proper CA-flag. Since we were using an old certificate and trust store that had been generated with an old release of the java keytool back than this flag was missing and the new Java version thus rejected all the entries in that certificate file. It thus aborted the SSL connection setup and simply closed the connection without any response or indication.
There is a VM option -Djdk.security.allowNonCaAnchor=true that one can add to Tomcat's JAVA_OPTS variable (typically in a file setenv.sh) to disable this verification. After adding that our Tomcat was again responding to SSL-requests and worked OK again.
BTW: when trying to analyze SSL issues like the above the option -Djavax.net.debug=all:handshake:verbose proved to be a real live-saver! With this option one gets very details log output and can follow SSL handshakes and connection setups in detail. Once I had finally gotten a first useful error message pointing to this CA-flag issue searching for a solution (or rather workaround in this case) proved to be a snap compared to the initial search for what could be the issue here.
I've been searching for a few hours to find a solution to my question/problem and whilst I believe that I have been able to clarify the reason why I have problems I have been unable to find a resolution.
I have one server which is hosting multiple web sites and a couple of these web sites are using SSL certificates. I have some shared images accessed by all sites and the way to stop the none-secure error on the SSL site was to serve those shared images from https://www.example-shared-image-server.com/images/imagename.jpg
This worked fine, until that is I noticed that by using Internet Explorer on Windows XP it is giving the message "There is a problem with this website's security certificate". What I then identified is that its because its picking up a certificate for a different domain on the server. Its all to do with hosting multiple sites on one server with SSL certificates.
Lets say I have four sites with only the first two with SSL certificates installed.
https://www.one.com
https://www.two.com
http://www.three.com
http://www.four.com
And lets not forget the following:
https://www.example-shared-image-server.com
So when accessing images from the above shared image URL it is actually bringing up https://www.one.com, hence the error.
So its seems to be something to do with IE not supporting SNI or SSL/TLS on Windows XP or Vista whereas it is on Win 7 and Win 8. This seems like an immediate ploy by M$ to force people to upgrade to more current operating systems. But the fact is that all other browsers support it.
But, what I have not been able to identify is what I can do about it. So I believe my question is, is it possible to host multiple web sites using SSL on the same server on different domains without causing IE to show errors. If not, what do other people do? And it yes, how do I configure it?
I have been on this for hours so if someone could help, I would really appreciate it.
Many thanks,
Rob
Windows XP's version of SChannel does not support SNI, which means that IE and other WinINET/WinHTTP-based applications do not support SNI on that platform.
http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx
SNI support was introduced in Windows Vista; if you're not seeing it work on that platform, it's likely that IE was reconfigured away from the defaults to enable SSL2. SSLv2-compatible handshakes do not carry TLS extensions like the SNI extension.
The only real workarounds here are to either:
Host each server on a different IP or port (so the server can select the certificate based on that information)
Use a certificate that contains multiple hostnames using the SubjectAltName field of the certificate
An internal team, separate from my own, has stated that they prefer to do incoming authentication based on client certificates. Which sounds good to me, except that I haven't messed with them before and aren't quite sure where to start researching (Wikipedia went straight into a lot of detail that I'm not sure is pertinent to what I need to find out). If I have an IIS6 server with a web app that runs under an AD user account, what steps should I take to eventually fire off a request from that web app to a remote server, via .NET (I'm guessing HttpWebRequest)? I do see that we have an internal trusted certificate authority and all. Remote server is running Apache on Linux boxes.
I'm essentially in learning mode, not necessarily looking for a blow-by-blow list of what needs to happen (though if I could learn how it works while learning how to do it, that'd be nice too :) ... do you have any resources I could start looking into in order to figure out how to successfully authenticate securely via SSL with this remote server and communicate with it via client certs? Probably from creation of the client cert on up, though I'd like to more fully understand how it all works in the first place.
Here is a link - http://support.microsoft.com/kb/315588. Hope this helps with what you are looking for.
On a customer's internal network, I can make a request to my SSL site using IE6 SP1 (on Win2K) and see one cert validation requests, but if I use IE6 SP2 (on XP) 13 separate cert validation requests get fired off. Needless to say, this slows down my page load a lot.
Firefox loads the page just fine with no unnecessary cert validation requests.
The server is Apache running a pretty new lampp stack. All the server certificate / CA chain configurations seem to be fine (users can authenticate w/ trusted certs, the system can communicate to other systems with that server cert, etc.)
Is there anything I can do from a configuration standpoint? Any other ideas at all?
I'm guessing that "upgrade IE" is off the table, right? You're probably trying to find a way to support IE 6.0, SP2, with XP, so your users can use this version.
OK... one thought is trying to mess with the SSL configuration. As I remember, SSL has a number of settings that can be used and perhaps you can change one of them on your server and get a different behavior. It might be worth it to research what's happening during the SSL Handshake on the working and not-working versions of IE 6.0. I favor Ethereal, a free network traffic watching tool that will capture the SSL. It can't decrypt it easily, but you can at least see the first few messages that happen in the clear. It might give an inkling into why all these validation requests are coming in.