Accessing myServer from the Internet using HTTPS

myServer is used on a daily basis within the home or business it is controlling. When you are outside of the home, it can be very handy to be able to interact with your systems. Providing secure access to the home should be done in a deliberate way so as not to allow unauthorized use or monitoring of the system.

Security is important and is like layers of an onion.  Each layer adds another level of security.  Multiple levels are typically implemented.  Only you can determine to what degree of security is needed and the cost and time to implement.  With enough time, money and experience, all systems can be hacked if exposed to the Internet.


To extend the capabilities to monitor and control your myServer home or business, follow the below instructions to do so with reasonable security.

  1. Ensure you myServer installation is up to date and working well.
  2. If you have an Internet Service Provider (ISP) static IP address, skip to step 4. If not, create a or account and setup a domain name that you like and that is available from those services.
  3. Open myServer's Options / Network configuration window. Check the box that you are using NoIP or DynDNS domain service. Type your account's username and access password. Type your provided DNS name in the "myServer DNS Name" box. Close this window, and restart myServer to activate your changes. myServer will reboot and shortly you should see it update your IP address in the Event Log. Your router should support "Port Reflection" so when you use your domain name in a URL from your local network, that the router connects you directly to the myServer PC and not out to the Internet. If this doesn't work by default by your router, consider a new router or research how to configure this on your existing router (some don't support this function, most new routers do).  PFSense based routers (freeware highly capable router software) supports "port reflection" within it's settings.
  4. Configure your myServer for some other port than Port 80 (80 is constantly being looked for by hackers), like Port 6245 or 82. Do this in the myServer Options / Network configuration window. Restart myServer for your changes to take effect.  myServer supports port 6245 for the External network and port 80 for the Internal network by default.
  5. You will need to Port Forward your Internet router to forward the port "6245" traffic (whatever you setup myServer on) to the myServer PC.
  6. You will also need to forward Ports: 6246 (web images only for the Flash Client), and 8181 (websockets connection).
  7. When myServer is connected remotely via your phone or tablet, the device is given a new client name.  If you have not created a permanent client name on your device, it will pick up the external IP address of your router as the default clientname.  If you have commands that are hard coded client names in them, you should give each client their own unique clientname.  Do this by going into the About page and set the new client name there.  Make sure each clientname is unique.
  8. Note that you should use the external URL for reaching myServer even when you are using a device within the myServer local network.
  9. An additional layer of protection is available on myServer which is a login page that by default is turned Off. To enable it, go to myServer's User Accounts page. Add an account user name by clicking the "+" button. Type in the username on the new row, and a password you will remember.  The "Enable Local Security" field forces the user to log in even when they are on the Intranet (local network) that myServer is on. Normal mode is deselected so when you are home, on your local network, you don't have to log in. This same page is used to change the password. The Authorization field sets the time when afterwards, the user will have to re-log in.
    How is this determined? When the client makes a call to the server the server looks at the IP address of the client and compares it to the IP address of the server. If they are on the same subnet then the client is assumed local and won't get the login screen. Otherwise the client is assumed to be outside the home and then will get the login screen.
  10. Yet another layer of security can be added if myServer is behind a Virtual Private Network (VPN) setup that is typically created on the Internet facing router. Setting this up isn't myServer specific, so outside of the scope of this document. OpenVPN is a popular VPN choice to setup.  VPN is recommended as it is not difficult to "hack" into the system by a knowledgeable specialist in the levels implemented above.
  11. Finally, the latest versions of myServer5 support HTTPS.  You will need to purchase a server certificate.  More details on this at the bottom of this article.  You need to port forward port 8181 and the webserver port (typically port 80) to the Internet.  No need to forward port 6246 as that is only for the legacy Flash clients.


It's a good idea not to create your Intranet (local network) using "typical" IP settings.  Most networks are 192.168.0.XXX or 1.XXX.  A good idea is to configure the network with settings like 125.XXX or other. Don't forget that all of your routers, port forwarding and other network settings are contingent on this strategy, so decide on this early in your network configuration.

It's also a good idea to have a firewall running either on your Internet facing router and / or on your myServer PC. The myServer installer will open appropriate ports during it's installation on a Windows firewall. Since it is highly recommended to not use the myServer PC as a normal desktop computer, firewall protection is then optional. myServer PC should be a dedicated automation server. If you can't get two PCs to communicate with each other (like a Remote PC), first thing to do is temporarily disable the firewall to isolate where the communication is being blocked. Once understood, modify the firewall settings as appropriate to allow the wanted connection.

Ensure your myServer PC Operating System is updated regularly. Don't use XP as it is no longer supported by Microsoft (and Allonis).

Another good idea is to use a myServer webpage keyboard to activate / deactivate your security system. Don't "hard code" your security system authentication into myServer.

Use unique username's and passwords for all web services configured in myServer - like Pandora, Netflix, Amazon, Google, etc.

Here is the "chain" of networking that is recommended:
Internet web client > VPN client > Your Home's Domain URL (administered by > your ISP's IP address for your home > Your home's VPN Server (on router) > Your home's firewall (on a router) > Port forward to myServer PC (on router)> myServer on a non typical Intranet IP address (like >myServer user name validation > myServer's web pages > myServer Apps and Content

Configuring myServer Login authentication:

myServer supports three general modes of access:

  • open access - you can access any myServer webpages from the Internet or Intranet (your local network).  Not generally recommended for security reasons.
  • Intranet easy access - you must login when accessing via Internet, but Intranet access does not require login.  Most homes are configured this way.
  • Secure access - you must login from both Intranet and Internet.  Most businesses are configured this way unless the WiFi network supports a Guest (patrons) and a Secure (employees) connections.
 Access Mode  Network Setting  myServer Setting  HTML customer.js
 Intranet Only, Login required  Configure router so myServer cannot be accessed via Internet  select "Enforce Local Security"  
 Intranet Only, Login not required  Configure router so myServer cannot be accessed via Internet  deselect "Enforce Local Security"  
 Internet or Intranet, Login via both  myServer connected to Internet, ports are forwarded  select "Enforce Local Security"  var ENABLE_SECURITY=1;
 Internet Login only   myServer connected to Internet  deselect "Enforce Local Security"  var ENABLE_SECURITY=1;
 No login required via both  myServer connected to Internet  deselect "Enforce Local Security"  var ENABLE_SECURITY=0;

How to configure:

  • For Network Settings, see the networking tips at the top of this article
  • myServer Settings, open myServer, click on Tools / User Accounts.  You will see the Enforce Local Security box.  You can also set the number of hours that logged in users need to relog in.
  • HTML custom.js:  Easiest is to open myDesigner, and open the scripts folder for the HTML user interface you want to use.  Double click on the custom.js file.  Make your modifications to ENABLE_SECURITY=    and then save the file.


If you cannot access myServer from the Internet, or if not all functions are working as you expect, open the web page in Chrome and select Developer Tools.  Click on Console to see the browser diagnostic log:

Scripts.js:381 WebSocket connection to 'ws://' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED

  1. This is an example that port 8181 is not properly forwarded to myServer from the Internet.  A firewall or router configuration issue.

Creating a Certificate with OpenSSL

1) Download OpenSSL for Windows from

Select the "Win64 OpenSSL v1.1.0h Light" for 64 bit Windows PCs

Install to the default C:\OpenSSL-Win64 folder (for example)

Do not put the binaries into the Windows System32 folder. Select \bin.

2) Open a Windows Admin Command Prompt shell (Creating a self-signed certificate)

a) cd \openssl-win64\bin

b) set OPENSSL_CONF=C:\OpenSSL-Win64\bin\openssl.cfg

c) openssl req -x509 -newkey rsa:2048 -keyout myserverkey.pem -out myservercert.cert -days 365 Enter PEM pass phrase: <<YOUR OWN PASS PHRASE>> ! don't forget it

Verifying - Enter PEM pass phrase: <<YOUR OWN PEM PHRASE>>

Country Name (2 letter code) [AU]: US State or Province Name (full name) [Some-State]: <<YOUR OWN STATE>>

Locality Name (eg, city) []: <<YOUR CITY>>

Organization Name (eg, company) [Internet Widgits Pty Ltd]: <<MAKE UP A NAME>>

Organizational Unit Name (eg, section) []: <<MAKE UP A NAME>>

Common Name (e.g. server FQDN or YOUR name)[] : <<MYSERVER DNS NAME>> like

Email Address []: <<A VALID EMAIL>>

d) openssl pkcs12 -inkey myserverkey.pem -in myservercert.cert -export -out myserverpfx.pfx

Enter pass phrase for myserverkey.pem: <<PASS PHRASE FROM ABOVE>>

Enter Export Password: <<A NEW PASSWORD>>  ! don't forget it

Verifying - Enter Export Password: <<A NEW PASSWORD>>

This created the myServerpfx.pfx file that can be imported into Windows

e) From an administrative command prompt on the target machine, run mmc

Press Ctrl + M, or Click File > Add/Remove Snap-in

Choose Certificates, and click Add >

In the dialog that appears, Choose Computer Account, and click Next

Choose Local Computer. Click Finish, then Okay

f) Import the certificate (pfx) into the Windows Certificate Store on the target machine

In the mmc window previously opened, drill down to Certificates (Local Computer) > Personal

Right-click on Personal, then click on All Tasks -> Import...

In the 2nd screen of the dialog that appears, find and import your certificate.

You'll have to change the file-type filter to Personal Information Exchange or All Files in order to find it.

On the next screen, enter the password you chose in step e), and pay close attention to the first check box. This determines how securely your certificate is stored, and also how convenient it is to use. Make sure it is checked for exporting.

On the last screen, choose Place all certificates in the following store.

Verify that it says Personal, then click Finish Repeat the import procedure above for the Trusted Root Certification Authorities certificates section.

3) Create the port associations for myServer

Note: The use of 6243 in the following command. This MUST match the SSL port you are using on myServer!

Look at the properties of the certificate in the mmc. Grab the thumbprint.

a) netsh http add sslcert ipport= certhash=<<THUMBPRINT>> appid={ed9fea88-2d76-47c0-bd5e-9e5cb9847d7f}


SSL (or TLS if you want to be super totally correct) gives us many things:


All three of those are needed when you are purchasing online. But we also use SSL for web user interfaces and other GUIs when  administering devices in our control. When a website gets an SSL certificate, they typically purchase one from a major certificate authority such as DigiCert, Symantec (they bought Verisign’s registrar business), or if you like the murder of elephants and freedom, GoDaddy.  They range from around $12 USD a year to several hundred, depending on the company and level of trust. The benefit that these certificate authorities provide is a chain of trust. Your browser trusts them, they trust a website, therefore your browser trusts the website.

Your devices, on the other hand, the ones you configure and only your organization accesses, don’t need that trust chain built upon the public infrastrucuture. For one, it could get really expensive buying an SSL certificate for each device you control. And secondly, you set the devices up, so you don’t really need that level of trust. So web user interfaces (and other SSL-based interfaces) are almost always protected with self-signed certificates. They’re easy to create, and they’re free. They also provide you with the privacy that comes with encryption, although they don’t do anything about trust. Which is why when you connect to a device with a self-signed certificate, you get one of these: So you have the choice, buy an overpriced SSL certificate from a CA (certificate authority), or get those errors. Well, there’s a third option, one where you can create a private certificate authority, and setting it up is absolutely free.


OpenSSL is a free utility that comes with most installations of MacOS X, Linux, the *BSDs, and Unixes. You can also download a binary copy to run on your Windows installation. And OpenSSL is all you need to create your own private certificate authority. The process for creating your own certificate authority is pretty straight forward:


Once you do that, every device that you manage via HTTPS just needs to have its own certificate created with the following steps:

You can have your own private CA setup in less than an hour. And here’s how to do it.

Create the Root Certificate (Done Once)

Creating the root certificate is easy and can be done quickly. Once you do these steps, you’ll end up with a root SSL certificate that you’ll install on all of your desktops, and a private key you’ll use to sign the certificates that get installed on your various devices.

Create the Root Key


  1. The first step is to create the private root key which only takes one step. In the example below, I’m creating a 2048 bit key:

openssl genrsa -out rootCA.key 2048

The standard key sizes today are 1024, 2048, and to a much lesser extent, 4096. I go with 2048, which is what most people use now. 4096 is usually overkill (and 4096 key length is 5 times more computationally intensive than 2048), and people are transitioning away from 1024. Important note: Keep this private key very private. This is the basis of all trust for your certificates, and if someone gets a hold of it, they can generate certificates that your browser will accept. You can also create a key that is password protected by adding -des3:

openssl genrsa -des3 -out rootCA.key 2048

You’ll be prompted to give a password, and from then on you’ll be challenged password every time you use the key. Of course, if you forget the password, you’ll have to do all of this all over again.

The next step is to self-sign this certificate.

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

This will start an interactive script which will ask you for various bits of information. Fill it out as you see fit.

You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.


Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Oregon
Locality Name (eg, city) []:Portland
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Overlords
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:Data Center Overlords
Email Address []:This email address is being protected from spambots. You need JavaScript enabled to view it.

Once done, this will create an SSL certificate called rootCA.pem, signed by itself, valid for 1024 days, and it will act as our root certificate. The interesting thing about traditional certificate authorities is that root certificate is also self-signed. But before you can start your own certificate authority, remember the trick is getting those certs in  every browser in the entire world.

Install Root Certificate Into Workstations

For your laptops/desktops/workstations, you’ll need to install the root certificate into your trusted certificate repositories. This can get a little tricky. Some browsers use the default operating system repository. For instance, in Windows both IE and Chrome use the default certificate management.  Go to IE, Internet Options, go to the Content tab, then hit the Certificates button. In Chrome going to Options and Under The Hood, and Manage certificates. They both take you to the same place, the Windows certificate repository. You’ll want to install the root CA certificate (not the key) under the Trusted Root Certificate Authorities tab.

However, in Windows Firefox has its own certificate repository, so if you use IE or Chrome as well as Firefox, you’ll have to install the root certificate into both the Windows repository and the Firefox repository. In a Mac, Safari, Firefox, and Chrome all use the Mac OS X certificate management system, so you just have to install it once on a Mac. With Linux, I believe it’s on a browser-per-browser basis.

Create A Certificate (Done Once Per Device)

Every device that you wish to install a trusted certificate will need to go through this process. First, just like with the root CA step, you’ll need to create a private key (different from the root CA).

openssl genrsa -out device.key 2048

Once the key is created, you’ll generate the certificate signing request.openssl req -new -key device.key -out device.csrYou’ll be asked various questions (Country, State/Province, etc.). Answer them how you see fit. The important question to answer though is common-name.

Common Name (eg, YOUR name) []:

Whatever you see in the address field in your browser when you go to your device must be what you put under common name, even if it’s an IP address.  Yes, even an IP (IPv4 or IPv6) address works under common name. If it doesn’t match, even a properly signed certificate will not validate correctly and you’ll get the “cannot verify authenticity” error. Once that’s done, you’ll sign the CSR, which requires the CA root key.

openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days 500 -sha256

This creates a signed certificate called device.crt which is valid for 500 days (you can adjust the number of days of course, although it doesn’t make sense to have a certificate that lasts longer than the root certificate). The next step is to take the key and the certificate and install them in your device. Most network devices that are controlled via HTTPS have some mechanism for you to install. For example, I’m running F5’s LTM VE (virtual edition) as a VM on my ESXi 4 host. Log into F5’s web GUI (and should be the last time you’re greeted by the warning), and go to System, Device Certificates, and Device Certificate.

In the drop down select Certificate and Key, and either past the contents of the key and certificate file, or you can upload them from your workstation.

After that, all you need to do is close your browser and hit the GUI site again. If you did it right, you’ll see no warning and a nice greenness in your address bar.

And speaking of VMware, you know that annoying message you always get when connecting to an ESXi host?

You can get rid of that by creating a key and certificate for your ESXi server and installing them as /etc/vmware/ssl/rui.crt and /etc/vmware/ssl/rui.key.