Configuration of Jupiter Server SSL Certificates

Jupiter Server supports two ports being configured with SSL certificates. One port for a Self Signed Certificate and the other port for a CA Signed Certificate. The reason for supporting two ports is that unless an on premise DNS server exists, a CA signed certificate being presented by Jupiter Server to other LAN based devices can cause certificate errors on those devices. Self Signed certificate that Jupiter Server presents is refreshed every 24 hours.  For those businesses who would like to present their internet located devices a CA signed certificate, binding a CA Signed certificate that is stored in the Local Certificate Store in Windows to a port that Jupiter Server is listening on, will achieve this.

The Jupiter Server Command Console allows the business to configure which ports will be used for Self Signed or CA Signed certificates, display which certificates are bound to those ports, and if there is a local Windows Firewall Rule configured. 

Binding SSL CA Certificates to a port

Jupiter Server handles the binding of Self Signed Certificates to a port. If a port is configured to be used with a Self Signed Certificate, and the binding or the certificate itself is broken, then Jupiter Server will fix it when the Service is started.

The management and binding of SSL CA Certificates to a port is typically done on the commandline in an Administrator Powershell window.

To show if a SSL Certificate is bound to a port use this command. If a certificate is bound to the port, then information about the certificate will be shown

netsh http show sslcert ipport=

If no certificate is found bound to the port then the result of the netsh commend is

The system cannot find the file specified

To remove the binding or a certificate to a port.

netsh http delete sslcert ipport=

To bind a CA certificate on the commandline a GUID will need to be created. In Powershell generate to a guid and the display the GUID

Write $guid

To display the Thumbprint of the CA certificate

get-childitem Cert:\LocalMachine\My -Recurse

or if IIS is installed

get-childitem Cert:\LocalMachine\WebHosting -Recurse

To bind a certificate to port 22223. Assumes that the certificate is in the \LocalMachine\WebHosting certificate store

netsh http add sslcert ipport= certhash=INSERTTHUMBPRINTHERE certstorename=WebHosting appid="$guid"

Creating a Let’s Encrypt Certificates

Process to create, install and setup the renewal of Let’s Encypt certificates on Windows. Assumes Azure DNS is used to host the DNS records.

  1. Download the pluggable version of Win-Acme from here
    Unpack to a folder of your choice.
  2. Download the Azure-DNS plugin for win-acme from here
    Unpack the zip file to the same folder that you put Win-Acme into.
    You may need to Unblock the DLLs for the Azure plugin.
    As decribed here
  3. Open an Administrator Powershell window and navigate to the folder you put Win-Acme into. Run wacs.exe at the Powershell prompt.
  4. Choose Menu option.
    M: Create Certificate
  5. Determine Domains
    2: Manual input
    Enter in a host name
    Enter in a friendly name
  6. Choose method to Prove Ownership
    6: [dns-01] Create verification records in Azure DNS

    Choose the Azure Environment being used

    2: AzureCloud

    Select no to use a Managed Service identity.
    In your Azure Active Directory you will need to create an App registration to handle the Domain Authorization and Renewal of the Let’s Encrypt Certificate.

    1. The name you choose of your App registration will be needed later.
    2. Accept the deault access for the API to be Default Directory only - Single Tenant
    3. Leave the Redirect API blank
    4. Click Register
    5. Record the client ID and the tenant ID for later use

    6. Create a Client Secret in your new App registration
      Enter in a description and select an expiry. Be sure to record in your calendar the expiry so that you can renew prior to the expiry date
      The Client Secrets table listing your new client secret will show a Value. Be sure to record this value later use. If you navigate away in the Azure Portal without recording the Client Secret value, then it will not be available to see at a future time.
    7. Enter in your Azure Tenant ID

      Recorded earlier

      Enter in your Application client id

      Recorded earlier

      Enter in the Client Secret for your Azure App
      Enter in your DNS resource group name and the subscription id for your DNS zone
    8. Navigate to your domain name DNS Hosting in AzureAD and provide access to your App Registration to your DNS Hosting for your domain

      Click Access Control
      Add a Role Assignment
      Enter in the subscription ID for your domain name in AzureAD
      Select the Role "DNS Zone Contributor"

      In the Select text box, begin typing the name of the App Registration you created earlier.

      Click your App Registration and then Click Save
    9. Enter in the subscription ID for your domain
  7. Choose Certificate Key type

    2: RSA Key
  8. Choose way to store certificate
    4: Windows Certificate Store
    3: PFX archive
    Enter in path to store the .pfx file
    Enter in a password for the .pfx file
    5: No (additional) store steps
  9. Choose steps to update your applications
    4: No (additional) installation steps
  10. Enter Y to open the Lets Encrypt Terms of service in default application
  11. Enter Y to agree to the terms.
  12. Enter an email address for notifications about problems.
  13. the authorization and validation process with AzureAD will now commence. If successful then certificate will be created and stored into a Certificate Store. Take note of the name of the Store displayed in the output. The Win-Acme utility will create a Scheduled Task to renew the certificate.