Enabling HTTPS on a Development Machine

An increasing number of the most popular websites have made the move to support HTTPS as the default protocol for their users. From a security point-of-view, this is great to hear, but it can be a bit of a nuisance for developers who are simply trying to test an application that is not yet production ready. Recently, I ran into this issue when trying to write an application to handle a WebHook from Jira. Jira requires that the URL the WebHook is pointing to uses the HTTPS protocol, but the virtual machine I was using wasn't set up to support HTTPS. In this blog, we'll go over the steps used to configure a virtual machine to use HTTPS for development purposes.


HTTPS is a secure browsing protocol that promises encrypted data transfer between client and server. In order to enable HTTPS on your domain, you'll first need to secure a certificate from a Certificate Authority (CA). There are many resources available on the internet that will explain both HTTPS and CAs better than I will, so in the interest of time, we'll jump right into how to actually request a certificate and set up your dev box to use it. 

Configuring Your Development Machine

The biggest hurdle to setting up my own dev box was actually getting an SSL certificate. Purchasing even a basic certificate from the more common CAs was looking to run me upwards of a couple hundred dollars. This is a small price to pay to ensure your users data is secure, but for a development machine with no users but myself, it certainly seemed a little steep. That's where Let's Encrypt came in to save the day.

Let's Encrypt

Let's Encrypt is a trusted certificate authority with the goal of making the web more secure by offering free SSL certificates. There are some downsides to using to Let's Encrypt as your CA including a short 90 day expiration date on their certificates and a limited number of certificate types, but for a development environment, these downsides are perfectly acceptable.

Requesting a Certificate from Let's Encrypt

Let's Encrypt works a little differently than other authorities in that the issuing of their certificates is entirely automated. The way that you prove you have control over your machine is by using an application that follows a special protocol called ACME (Automated Certificate Management Environment). There are a number of open source clients that you can download that follow this protocol and allow you to easily request a certificate. Many of these clients are built with Linux in mind, but you can follow the steps below to see how to use one of these clients built for Windows specifically.

  1. Download the latest version the win-acme to your dev box
    1. You can find a full list of the available ACME clients on the Let's Encrypt website
  2. Unzip this package
  3. Run the executable in this package
  4. Confirm that you see a command prompt asking what kind of certificate you want to install
  5. Type in 'N' and press enter to create a new certificate
  6. Type in '4' and press enter to apply the certificate against a specific host name
  7. Type in the publicly available host name of your dev box
  8. Type '1' and press enter to set up the certificate against the Default Web Site of IIS
  9. OPTIONAL: Enter an email for troubleshooting
  10. Type 'y' to open the terms of service
  11. Type 'y' to accept the terms of service

After that, the SSL certificate should be automatically requested from Let's Encrypt, and your dev box should be automatically configured to work with it. You can test this by navigating to any Innovator instance on your dev box with the HTTPS protocol (e.g. https://dev_box_name/InnovatorServer). You should see that you can navigate to this site without getting a notification from your browser that the connection is not secure. 

Editing Your Innovator Instances

If you are using Aras Innovator 12.0, there are a list of hard-coded URLs in the install folder that you'll need to update to include HTTPS. By default, the install folder would be C:/Program Files (x86)/Aras/Innovator/. From here, the URLs you'll need to change can be found at /OAuthServer/OAuth.config. These will be contained in the <redirectUris/> tag in the InnovatorClient client registry.

Require HTTPS

If your goal is to enable both HTTPS and HTTP on your Innovator instances, the above configuration is all that you would need to do. However, if you want to require that HTTPS is used, you can follow the steps below in IIS.

  1. Open the IIS Manager
  2. Select Default Web Site or whichever web site contains your Innovator instances
  3. Select SSL Settings 
  4. Check the Require SSL box and choose to Accept client certificates

There are additional IIS settings typically required to set up your SSL certificate, but the win-acme client we used to request the certificate from Let's Encrypt already took care of that for us. The last step you'll need to do to require HTTPS is update the hard-coded URLs in the install folder which you can find a list of below.

  • AppServerURL in VaultServerConfig.xml
    • <AppServerURL/>
  • SelfServiceReportConfig.xml
    • inn_server_url in <appSettings/>
  • OAuthServer/OAuthServer.config
    • innovatorServerUrl in <appSettings/>
  • InnovatorServerConfig.xml
    • InnovatorToServiceAddresss in <AgentService/>
    • Url in <OAuthServerDiscovery/>
  • ConversionServerConfig.xml
    • url in <InnovatorServer/>
  • AgentService/Aras.Server.Agent.Service.exe.config
    • InnovatorServer in <appSettings/>
    • baseAddress in <baseAddresses/>
  • Any other hard-coded urls in the database or code tree. Ex: a custom, hard-coded Vault Server URL

Looking for more Aras inspiration?

Subscribe to our blog and follow @ArasLabs on Twitter for more helpful content! You can also find our latest open-source projects and sample code on the Aras Labs GitHub page.

  • Hi Chris,

    let´s be honest. You didn´t test the ConversionServer :-). Is this one really correct?

    [...] The last step you'll need to do to require HTTPS is update the hard-coded URLs in the install folder which you can find a list of below.


    • InnovatorServer in <appSettings/>
    • baseAddress in <baseAddresses/>

    I agree for the other codetree files, but not for this specific one. Cause when we change the baseAddress to https the Agent service will completely refuse to work.

    I noticed that the file contains a huge block that starts with <!-- HTTPS enabled --> . 
    Is it correct that we have to enable this block and disable the other system.serviceMode block? Well, because at least this variant worked...