SSL for web apps

You can deploy standalone web apps that take advantage of SSL (URLs that use the https prefix) starting with Xojo 2014r3.

Secure standalone web apps use TLS v1.2 by default, which may not be supported by some older versions of Internet Explorer (IE 10 and earlier) unless you enable TLS 1.2 in their Security Settings.

If you'd rather not deal with this yourself, Xojo Cloud has built-in SSL support.

Set up the SSL certificate

First you'll need an SSL certificate, which you can obtain from many sources. If you're doing local testing, feel free to use a self-signed certificate. If your web app will be available on the internet, please be sure to use a real purchased SSL certificate because it adds extra protection from certain kinds of internet attacks. Generally, a self-signed certificate will have two components (the certificate and key file) while a purchased certificate will likely have three or more (certificate, key, CABundle or intermediates).

Once you have a certificate and have downloaded it and the private key to your computer, you need to make a single file, putting all of the pieces together into that file. Create a text file that has the same name as your application with a .crt extension and paste the contents of the certificates into it, one after another in this order: 1. Certificate

  1. CABundle

  2. Private Key

Make sure to include the entire contents of your primary certificate, intermediate certificate bundle (if required) and private key.

Each file must start on a new line (don't concatenate the last line of one file and the first line of another onto the same line). As mentioned, the name of this file should match your web app name, so if your web app is named MyBestApp or MyBestApp.exe, the certificate file should be named MyBestApp.crt.

If you are running in debug mode, the built app will be named MyBestApp.Debug, but the certificate should still be named MyBestApp.crt.

Now that you have a correctly named and formatted certificate file, you'll need to make sure it is next to the built web app when it runs. A Copy Files Build Automation Step works great for this to make sure it ends up in the right place every time.

An example file might look like this:


















Configure web server to use SSL

The last piece of this puzzle is to tell your web app that you want it to listen on a secure port. You cannot set the Secure Port in the Shared Build Settings, so you'll need to use some command-line parameters to get it to work. These are the parameters that you'll be interested in:




Specifies the port number for secure connections. You must specify a port with this in order to allow secure connections.


Set the maximum number of secure sockets (default=200).


The path to the SSL certificate if you don't want to put it beside the executable (starting with 2015r2).



Specifies the type of security used. These integer values can be used: 0 (SSLv2), 1 (SSLv23), 2 (SSLv3), 3 (TLSv1), 4 (TLSv11), 5 (TLSv12, the default)


The index value (of NetworkInterfaces) to use as the NIC for secure connections.

The secure port must be different than the port selected in the IDE (or specified with the --port command line property). For example, if you built your web application using port 8080 as the listening port, you might use:

MyBestApp --secureport=8081

As with the non-ssl version, you may also increase the maximum allowed number of connected sockets if necessary, which is useful if you notice that your app rejects connections when there are a lot of users connected at the same time.

MyBestApp --secureport=8081 --maxsecuresockets=400

Remember, with the maxsecuresockets option, the number of open sockets does not represent the number of simultaneous users. Depending on the construction of your app, and how your users use it, a browser could have zero open connections (like between keystrokes or mouse clicks) or multiple open connections (if the user is clicking quickly on a control). That being said, you also shouldn't set this value too high. With more open connections comes more memory and CPU use, so you'll need to experiment with this number to find the best threshold for your app/server combination.

If you try to start with SSL but the certificate is not found or is not readable, the app will display an error and quit.

Once you've launched your app, use a browser to connect to it:

Your app should now display the appropriate "secure" indicator in the browser address area.

If you also want to prevent unsecured access to the web app, you can set the number of unsecured sockets to 0:

MyWebApp --secureport=8081 --maxsockets=0

By default, SSL standalone web apps use TLSv12 for the connection type. This is the most secure method and is recommended. But if you need to choose an older version for compatibility with older web browsers, you can do so using the command line option like this:

MyWebApp --secureport=8081 --ssltype=3

You can also set the connection type by change the WebApplication.Security.ConnectionType property in your web app's Opening event:

Self.Security.ConnectionType = WebAppSecurityOptions.ConnectionTypes.TLSv1

Generating the certificate signing request

Here are example commands you can run from the Terminal for Linux/Apache to generate a certificate signing request (CSR):

# Generate the 2048-Bit private key
openssl genrsa -out server.key 2048

# Generate the CSR
openssl req -new -key server.key -out server.csr

# Remove the passphrase from the key (so you don't have to type it in to restart Apache)
cp server.key
openssl rsa -in -out server.key

# Generate a self-signed public key (for testing only)
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt