Standalone Web with SSL not working

Targets Web
1

I am following this guide: https://documentation.xojo.com/UserGuide:SSL_for_Standalone_Web_Apps

I have successfully received a cert using Let’s Encrypt, and have then concatenated the fullchain1.pem and privkey1.pem files into “myapp.crt”

I then run my web app on Ubuntu with this cmd:

./myapp --secureport 9001 --certificate /somepath/myapp.crt

I made sure the path to the cert file is correct. Yet, when I try to connect to the app with https on port 9001, the Browser says that it can’t establish a connection, i.e. it gets a rejection immediately, and it’s not a secure attempt, even. Also, I log when Session.Open gets invoked - and that does not happen. So, it looks like my app does not actually listen on port 9001 at all.

And indeed - when I check with lsof -i -P -n | grep LISTEN, I see that the app’s regular port (9000) is in LISTEN mode, but there’s no open port for 9001.

So, the app simply does not listen on the SSL port. Why?

I then tried this to see what happens:

./myapp --secureport 9001 --certificate /badfile.crt

Which means: I pass the path to a nonexisting crt file.

The docs say:

Well, that’s not happening - despite passing an invalid cert file, I get no message (on the cmdline) nor does the app quit.

So, something is wrong here, but what?

I’m trying this with Xojo 2019r1

2

I’ve hit several bugs myself:

  • if the certificate is missing or broken, the app still runs w/o error.
  • <https://xojo.com/issue/53272> - In a web app, --secureport conflicts with Shared/Build/Port
3

Okay, so this could still mean that I got my cert wrong, but the app won’t even tell me. Great.

On #53272 - isn’t it documented behavior that you need to use a different port for SSL than the non-SSL port you specify in the project? The doc page I linked to above says that explicitly. Or do I misunderstand your report?

4

Even using the SSLTest.crt from Xojo’s Example SSL project doesn’t work. Which suggests that Standalone SSL handling is entirely broken and not my wrongdoing.

Does anyone have a working SSL server from a Standalone app? If so, which Xojo version was it built with?

5

[quote=436551:@Thomas Tempelmann]Okay, so this could still mean that I got my cert wrong, but the app won’t even tell me. Great.

On #53272 - isn’t it documented behavior that you need to use a different port for SSL than the non-SSL port you specify in the project? The doc page I linked to above says that explicitly. Or do I misunderstand your report?[/quote]

I suspect the documentation was changed after my report?

The overall point remains: Stand-alone Web needs better error reporting.

6

[quote=436552:@Thomas Tempelmann]
Does anyone have a working SSL server from a Standalone app? If so, which Xojo version was it built with?
[/quote]

2018R4 works fine for me, I haven’t tested with 2019R1 though.
Also, I’m building for macOS 10.13, not Ubuntu, so that’s not necessarily helpful, sorry.

7

(you probably are aware of this but…) make sure you are using a HTTPS url - if you try to connect with HTTP protocol to a HTTPS site, that will fail.

8

I just tried out the entire SSLDemo - that works with 2017r3 and 2019r1.

So, it’s my fault. But what do I do wrong? Even with the demo’s crt, the app won’t open the SSL port to listen on. The demo does.

9

It works! I’m not entirely sure yet what it was as I changed several things at once:

  1. Remove hyphen from the file names (my app was called “My-App” before.
  2. Enabled to include function names
  3. Changed ports.
10

Ha, found the reason! A very sneaky typo: When using the --secureport option, the next char has to be “=”, but I used a space (because that’s how most cmdline apps handle extra arguments to an option).

When I tried the SSLText example, I did copy the correct cmdline using the “=” and when I afterwards went back to testing my own app, I kept that arg and only changed parts of it, but always keeping the “=” in it.

Jeez, what a tricky error (of mine) this was. Took me a long time to notice.

11

Glad you found it , but still, improved error trapping still would have helped - imagine if you got a “invalid command line parameter” message - you would have figured it out right away :slight_smile:

12

Right. The fact that I passed the --secureport and --certificate args without valid values should have led to showing an error message. Or that I passed args that it did not understand (i.e. the values).