Standalone SSL Connection Reset Error

[quote=136551:@Greg O’Lone]For what it’s worth, I just checked this on OS X, Windows and Linux using our certificate, which has an intermediate bundle with four certificates in it and it works as expected on all three platforms.

Also, I am not using openssl for verifying, I’m using our supported browsers.[/quote]

Come on, Greg… you can’t be serious. Just because a browser is forgiving at the moment, there are instances were it will break (see my issue with Firefox). There are tests out there (why do I keep feeling I’m repeating myself with this, and it’s just getting ignored) that you can test the chain with… DIRECTLY FROM WHAT THE SERVER REPORTS VIA THE CERTIFICATE HANDSHAKE (has nothing to do with the browser).

AGAIN, you can go here:
http://www.sslshopper.com/ssl-checker.html

or here:
https://sslcheck.globalsign.com/en_US/

If any of those complain about a broken chain or verification issues (which they do w/ the sslSocket currently within Xojo) then there is a problem.

Also, according to this:
http://security.stackexchange.com/questions/56824/what-happens-when-intermediate-certificates-are-installed-in-the-wrong-order

there is a specific issue the certificates must be in. Perhaps the main reason mixing the order per your blog didn’t change anything is because they weren’t being relayed properly to begin with. If I have to take my time and use a sniffer and deconstruct the SSL handshake between a Xojo-created server and my local connection just to prove this… I will. But be damned sure, I won’t be renewing my damned license. I don’t agree w/ BH on just about anything… but when you post stuff like this, after myself and others keep pointing the obvious, I’m starting to think there’s a meaning behind all the screaming he is doing.

Use the tools SPECIFICALLY for testing these things… it’s what they’re there for.

BTW… don’t include your intermediate certificates using Xojo. Just double paste the public certificate. Under any normal circumstance… this SHOULD cause problems; however, doing so doesn’t within the browsers you are testing. Why? Because the certificate and trust was already established (likely from a 3rd-party site using a popular certificate authority that you are using with Xojo). Because it doesn’t complain about the issue doesn’t mean it’s not broken. This will let you observe that your certificate used with Xojo will APPEAR to be working just as you stated (testing only with the browsers)… but in fact, since the certificate doesn’t contain the intermediate certificate then you know it shouldn’t be.

Ouch.

[quote=136537:@Greg O’Lone]There are a few things that immediately come to mind:

  1. Are you sure that IIS isn’t already binding to port 443?
  2. Are you sure that you have permission to bind to port 443? Have you tried another port (something above 1023) just to be sure?
  3. Is the filesystem case-sensitive? If so, the SSL certificate name must match the application exactly. SSLTest ? ssltest.crt

I’m curious… what do you mean by “re-keyed”?[/quote]

  1. IIS has only one “Default Site” in it and it is “stopped” by default so I dont think it would be binding to port 443.

  2. I enabled the worker role to open 443 so that traffic can run through it. (firewall open)

To address 1 and 2 - Is there a way to see if the launched app indeed has an open listener to this port some how?

  1. Cases match exactly.

~4) Re-keyed meant I generated a new Private key and a new CSR. I submitted this to godaddy using their “re-key” certificate option to overwrite the old key as an attempt to fix the problem. It did not, but I figured it was worth a shot at this point. I’m incredibly frustrated with trying to get Web Standalone working with SSL and I’m willing to try anything at this point. Next on the list is praying to the Juju Gods… *sigh

Brock- have you tried this on a local Windows instance- and if so, do you get the same connection reset errors?

I spooled up an Azure virtual machine at the end of my day. Tomorrow I’ll try that and then try a local instance if that doesn’t work.

One thing to check also… you said you put the certificate file next to your app; however, have you double-checked the path pointed to the folderitem that’s referenced to the sslSocket.certificateFile property within your server source code?

Eric- I’ve verified case 34263 (intermediate certs not being properly relayed in a standalone SSL webapp) and we’ll get that addressed. You can split discussion of that to another thread if you like. We’ll keep this one about Brock’s connection-reset issue since he started it, which I believe to be a wholly separate thing.

Is that something I need to configure in the worker role? Or something I check in the xojo app?

I believe we’re talking about a standalone web app- so I don’t think there is any managing of sockets and their properties directly here, unless I’m mistaken.

Brock, it’s been awhile since I’ve changed anything in my web application (I’ve been using the sslSocket directly under a console application for the past month or so, so I’m a little foggy). Travis may be correct here.

Travis is correct. This is a Standalone web application trying to run SSL. The HTTP traffic goes through fine but the HTTPS traffic fails despite the firewall being open to FTP traffic on port 443 and the certificate meeting specifications. The app is launched with the appropriate parameters as indicated earlier in this discussion.

I deployed it to a Virtual Machine instead of the worker role. It’s happy now and works with HTTPS. Also firefox is now happy with my SSL certificate too :smiley:

Good to hear!

So I could get it working on a remote machine with Azure but it couldn’t talk to my databases. When I have a virtual machine in my VPN, and the proper subnet I can get it to talk to my databases but now HTTPS doesn’t work.

I think Azure is blocking the HTTPS traffic to Virtual Machines in my VPN subnet. Not sure why and I’ve tried googling how to fix this but I haven’t found anything helpful. If anyone has any experience in the Azure world and might know how to set this up. I would definitely appreciate any ideas.

http://stackoverflow.com/questions/9183663/azure-ports-required

Could it be because Azure is using 443 for its own use? Never used Azure before… but I had a similar experience using VMWare, where 443 was in use by the way I was already connecting to it.

Oops, I just forgot to add an endpoint in this case. Everything is working right now :smiley:
Thanks to everyone who offered suggestions :slight_smile:

[quote=136540:@Greg O’Lone]Something else to note…

Internet Explorer may not come with TLS turned on by default. If you will be connecting to a standalone web app using SSL, you’ll need to turn it on:

  1. Go to Tools->Internet Options->Advanced
  2. Scroll all the way to the bottom of the Settings list
  3. Check Use TLS 1.0[/quote]
    My apologies, I was mistaken about this. I’d been doing some tests regarding the Poodle SSLv3 vulnerability last week and forgot to revert the VM to its pristine state. TLS is ON for Internet Explorer by default, at least back through v8. I have not checked any versions before that.

I am suddenly seeing this in my web SSL standalone webapp (at https://www.inqua-planer.de) compiled with Xojo 2018 r3.2 running under UBUNTU14.04 which ran reliably for years. I am using a letsencrypt certificate, and there seems nothing wrong with it as confirmed by https://www.sslshopper.com/ssl-checker.html#hostname=https://www.inqua-planer.de

I can restart the app, and it will launch fine, but as soon as I type something into the login window

Chrome reports this:

Erm, this is kind of urgent, any kind of hint would be highly appreciated…

Hmm, now it seems to work again, after restarting the app for the 10th time. Very scary. If anyone has a guess to offer as to how to avoid these issues…