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=0.0.0.0:22222
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=0.0.0.0:22222
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
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=0.0.0.0:22223 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.
- Download the pluggable version of Win-Acme from here
Unpack to a folder of your choice.
- 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 https://www.win-acme.com/reference/plugins/validation/dns/azure/
- Open an Administrator Powershell window and navigate to the folder you put Win-Acme into. Run wacs.exe at the Powershell prompt.
- Choose Menu option.
M: Create Certificate
- Determine Domains
2: Manual input
Enter in a host name
Enter in a friendly name
- Choose method to Prove Ownership
6: [dns-01] Create verification records in Azure DNS
Choose the Azure Environment being used
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.
- The name you choose of your App registration will be needed later.
Accept the deault access for the API to be Default Directory only - Single Tenant
Leave the Redirect API blank
Record the client ID and the tenant ID for later use
- 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.
Enter in your Azure Tenant ID
Enter in your Application client id
Enter in the Client Secret for your Azure App
Enter in your DNS resource group name and the subscription id for your DNS zone
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
Enter in the subscription ID for your domain
2: RSA Key
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
4: No (additional) installation steps