SSL / HTTPS Configuration

This guide explains how to run MinuteView Server securely over HTTPS using your own SSL certificate. It covers the different ways you can obtain a certificate, how to prepare it for MinuteView, how to apply it, and — importantly — how to run MinuteView on HTTPS on a server that is already running Autodesk Vault (or any other website) on the standard HTTPS port.

---

How MinuteView Server serves web traffic

MinuteView Server runs as a self-contained Windows service (MinuteViewServer). It hosts its own web server directly — it does not need to be placed inside IIS to run.

Out of the box it listens for plain HTTP on port 8770:

http://<your-server>:8770

When you supply an SSL certificate, MinuteView adds an HTTPS listener alongside the HTTP one. Both stay active at the same time:

Protocol	Port	Purpose
HTTP	8770	Always available. Used for the initial setup, and as a safety net so an administrator can never be locked out.
HTTPS	443 (default)	Added when you supply a certificate. This is the address your users will normally use.

HTTP is never switched off

Enabling HTTPS adds a secure address — it does not remove the HTTP one. This is deliberate: it guarantees you can always reach the server to fix a certificate problem. On a production server you would typically restrict port 8770 at the firewall so that only HTTPS (443) is reachable from user machines.

Where SSL is configured

SSL is configured once, during the first-run Setup Wizard, on the Web Address step. This is intentional — the web address and certificate are sensitive infrastructure settings, so they are not exposed as an everyday settings screen. To change them later you re-run setup (see Changing the certificate later).

---

Before you begin

Decide these three things first — they drive every other choice below.

1. The hostname users will type. For example minuteview.yourcompany.com. This is the name that must appear on the certificate, and the name your DNS must resolve to the server.
2. DNS. Make sure the hostname resolves to the MinuteView server (internal DNS for an on-premises deployment, or public DNS if it is internet-facing).
3. Where the certificate will come from. See Choosing a certificate below.

The certificate must match the hostname

The name on the certificate must match the address users type. If users will visit https://minuteview.yourcompany.com, the certificate must be issued for minuteview.yourcompany.com (or a wildcard such as *.yourcompany.com that covers it). A mismatch produces a browser security warning.

---

Choosing a certificate

There are four common ways to obtain an SSL certificate. They differ in cost, how much a browser trusts them automatically, and how much setup they need. All four end up in the same file format for MinuteView (a .pfx — see What MinuteView needs).

Option	Trusted automatically by browsers?	Best for
Public CA certificate (purchased, or free e.g. Let's Encrypt)	✅ Yes, everywhere	Internet-facing servers, or anywhere you want zero client configuration
Internal PKI / Active Directory Certificate Services (ADCS)	✅ Yes, on domain-joined machines	On-premises deployments where all users are on the company domain
Self-signed certificate	❌ No — must be trusted manually on each client	Quick internal setups, testing, or small deployments
Reuse an existing certificate (e.g. the one already used for Autodesk Vault)	✅ Inherits whatever the original certificate has	Servers that already have a suitable wildcard or multi-name certificate

The rest of this section describes each option. Skip to What MinuteView needs once you know which you are using.

1. Public CA certificate (purchased or free)

A public Certificate Authority (such as DigiCert, Sectigo, GlobalSign, or the free Let's Encrypt) issues a certificate that every browser and operating system already trusts. Users get the padlock with no configuration on their machines.

This is the best choice when the server is reachable from the internet, or when you simply want the smoothest experience for users. It requires a domain name you control and (for validation) the ability to prove ownership of that domain.

You will typically receive the certificate as a .crt/.cer file plus a separate private key, or as a bundle. You then combine these into a .pfx — see From a public CA certificate.

2. Internal PKI / Active Directory Certificate Services

Most organisations running on-premises software already have an internal Certificate Authority — usually Active Directory Certificate Services (ADCS). Certificates issued by it are automatically trusted by every domain-joined Windows machine, because the CA's root certificate is already distributed through Group Policy.

This is often the ideal choice for an on-premises MinuteView server: no annual cost, no internet dependency, and no per-client trust step. Ask your IT team to issue a Web Server certificate for your MinuteView hostname, then export it to a .pfx — see From the Windows certificate store.

3. Self-signed certificate

A self-signed certificate is one you create yourself, with no authority vouching for it. It encrypts traffic just as strongly as any other certificate, but because nothing trusts it by default, every user's browser will show a warning until the certificate is manually installed as trusted on their machine.

This is fine for testing or a small internal group, but it does not scale well. To create one, see Create a self-signed certificate.

4. Reuse an existing certificate

If the server already has a certificate — very commonly the case on a machine running Autodesk Vault, which is served through IIS — you may be able to reuse it for MinuteView, provided it covers the hostname you will use for MinuteView.

• A wildcard certificate (e.g. *.yourcompany.com) covers minuteview.yourcompany.com as well as vault.yourcompany.com, so it can be reused directly.
• A single-name certificate issued only for vault.yourcompany.com does not cover a different MinuteView hostname. In that case, obtain a separate certificate for the MinuteView name (or a multi-name/SAN certificate that lists both).

To reuse a certificate that is already installed, export it (with its private key) to a .pfx — see From IIS or From the Windows certificate store.

---

What MinuteView needs

Whatever route you took above, MinuteView needs the certificate in one specific format:

A .pfx file (also called PKCS #12) that contains both the certificate and its private key, protected by a password.

The .pfx format bundles the public certificate and the private key together in a single, password-protected file. This is what you will upload in the Setup Wizard, along with the password that protects it.

A .cer, .crt, or .pem on its own is not enough

Those formats usually contain only the public certificate, not the private key. MinuteView needs the private key too, so you must provide a .pfx. The sections below show how to produce a .pfx from each source.

---

Producing the .pfx file

From IIS (reusing an existing certificate)

Use this when the certificate is already bound in IIS — for example the certificate serving Autodesk Vault.

1. Open Internet Information Services (IIS) Manager.
2. Select the server node (top level) in the left pane, then open Server Certificates.
3. Find the certificate, right-click it, and choose Export….
4. Choose a destination file (e.g. C:\certs\minuteview.pfx) and set a password. Note this password — you will need it in the wizard.
5. Click OK.

From the Windows certificate store

Use this for certificates issued by an internal CA (ADCS) or otherwise present in the machine's certificate store.

1. Run certlm.msc (Certificates – Local Computer).
2. Browse to Personal → Certificates and locate your certificate.
3. Right-click it → All Tasks → Export….
4. In the wizard choose Yes, export the private key.
5. Choose Personal Information Exchange – PKCS #12 (.PFX), set a password, and save the file.

Alternatively, with PowerShell (run as Administrator):

# List certificates to find the thumbprint you want
Get-ChildItem Cert:\LocalMachine\My

# Export it to a password-protected .pfx
$pwd = ConvertTo-SecureString -String "YourStrongPassword" -Force -AsPlainText
Export-PfxCertificate -Cert Cert:\LocalMachine\My\<THUMBPRINT> -FilePath C:\certs\minuteview.pfx -Password $pwd

Create a self-signed certificate

Run PowerShell as Administrator on the MinuteView server:

# Create a self-signed certificate for your MinuteView hostname
$cert = New-SelfSignedCertificate `
  -DnsName "minuteview.yourcompany.com" `
  -CertStoreLocation "Cert:\LocalMachine\My" `
  -FriendlyName "MinuteView Server" `
  -NotAfter (Get-Date).AddYears(5)

# Export it to a password-protected .pfx for MinuteView
$pwd = ConvertTo-SecureString -String "YourStrongPassword" -Force -AsPlainText
Export-PfxCertificate -Cert "Cert:\LocalMachine\My\$($cert.Thumbprint)" -FilePath C:\certs\minuteview.pfx -Password $pwd

Because nothing trusts a self-signed certificate automatically, you must also distribute the public certificate to each client machine and install it into Trusted Root Certification Authorities, otherwise users will see a browser warning.

From a public CA certificate

Public CAs usually deliver a certificate file (.crt/.cer) separately from the private key you generated when creating the signing request. Combine them into a .pfx.

If you requested the certificate through IIS or the Windows certificate store, complete the request there and then export to .pfx as described in the sections above. If you have the certificate and key as separate files, you can combine them with OpenSSL:

openssl pkcs12 -export -out minuteview.pfx -inkey private.key -in certificate.crt -certfile chain.crt

You will be prompted for an export password — this is the password you will enter in the wizard.

---

Applying the certificate in MinuteView

SSL is configured during the first-run Setup Wizard, on the Web Address step.

When does the wizard run?

The Setup Wizard runs the first time MinuteView Server starts on a fresh installation. If your server is already configured and you need to change the certificate, see Changing the certificate later.

1. Progress through the Setup Wizard to the Web Address step.

2. Choose Use my SSL certificate (HTTPS).

   

3. Enter the Certificate password — the password that protects the .pfx file's private key.

4. Leave the HTTPS port at 443 (the standard HTTPS port) unless you have a specific reason to change it. Using 443 means users reach the server at https://minuteview.yourcompany.com with no port number in the address.

5. Click Choose certificate (.pfx) and select your .pfx file.

MinuteView validates the certificate immediately. On success it confirms the certificate and shows who it was issued to and when it expires:

Expiry warning

If the certificate expires within 30 days, the wizard shows a warning with the expiry date. You can still proceed, but plan to replace it soon.

6. Finish the wizard. When it completes, MinuteView saves the configuration and automatically opens the HTTPS port in Windows Firewall (an inbound rule named MinuteView Server HTTPS 443).

Apply the change — restart the service

MinuteView reads its web-address configuration only when it starts. After finishing the wizard you must restart the MinuteView Server service for HTTPS to take effect:

• Open Services (services.msc), find MinuteViewServer, and choose Restart; or

• From an elevated command prompt:

  net stop MinuteViewServer && net start MinuteViewServer

Once restarted, browse to https://minuteview.yourcompany.com and confirm the padlock appears.

Certificate password is stored securely

The certificate and its password are stored in an encrypted configuration file on the server (C:\ProgramData\Tentech\MinuteView\MinuteViewServerConfig.dat), protected by Windows encryption tied to that machine. The password is never shown again in the interface.

---

Coexisting with Autodesk Vault (or any existing IIS site)

This is the most common real-world scenario. A server that runs Autodesk Vault already has IIS serving a site on port 443 (for example https://vault.yourcompany.com), with its own SSL certificate bound to the Default Web Site.

The problem: MinuteView's web server and IIS cannot both listen on port 443 on the same IP address. They are two separate web servers competing for the same port.

What happens if the port is already taken

If you enable MinuteView's built-in HTTPS on 443 but IIS is already using 443, MinuteView detects the conflict at startup and falls back to HTTP only (it will not crash or take the port from Vault). You then need to use one of the approaches below to give MinuteView a working HTTPS address.

Your goal is almost always:

• MinuteView reachable at a clean address such as https://minuteview.yourcompany.com — with no port number in it, and
• Vault still reachable at https://vault.yourcompany.com,
• both on the same server and the same port 443.

Serving two different hostnames on the same IP and port is made possible by SNI (Server Name Indication) and host headers — the web server looks at the hostname the browser asked for and serves the matching site and certificate. There are three ways to achieve this.

Option A — Reverse proxy through IIS (recommended)

Let IIS keep ownership of port 443 and act as the "front door" for both sites. IIS serves Vault directly, and forwards MinuteView traffic to MinuteView's HTTP port behind the scenes. MinuteView itself stays on plain HTTP 8770 — you do not enable its built-in HTTPS in this arrangement, because IIS provides the HTTPS.

                         ┌─────────────────────── Windows Server ───────────────────────┐
  https://vault.        │   IIS (owns port 443, uses SNI)                                 │
  yourcompany.com  ───► │     ├─ Site: vault.yourcompany.com  ─────► Autodesk Vault       │
                         │     └─ Site: minuteview.yourcompany.com ─┐                      │
  https://minuteview.   │                                          │ reverse proxy         │
  yourcompany.com  ───► │                                          └─► http://localhost:8770 (MinuteView) │
                         └────────────────────────────────────────────────────────────────┘

This keeps clean, port-free URLs for both products and lets each hostname have its own certificate.

Steps:

1. Install the IIS components for reverse proxying (once):
   • Application Request Routing (ARR) and URL Rewrite (both free Microsoft downloads).
   • The WebSocket Protocol IIS feature (see the note below).
2. In IIS Manager, enable the ARR proxy: select the server node → Application Request Routing Cache → Server Proxy Settings → tick Enable proxy.
3. Add a new IIS website for MinuteView:
   • Site name: e.g. MinuteView.
   • Binding: type https, port 443, Host name minuteview.yourcompany.com, tick Require Server Name Indication (SNI), and select the MinuteView certificate.
4. On that new site, add a URL Rewrite rule that reverse-proxies all requests to http://localhost:8770/.
5. Leave the existing Vault site exactly as it is, on its own https binding with host name vault.yourcompany.com.

Enable WebSocket forwarding

MinuteView uses WebSocket connections for real-time features (live updates, AI chat, and communication with the Automations Engine). If you reverse-proxy through IIS you must install the IIS WebSocket Protocol feature and ensure the proxy allows WebSocket traffic through, or these features will not work.

Option B — Give MinuteView its own IP address

Add a second IP address to the server. Bind Vault's IIS site to the first IP and MinuteView to the second, so each gets port 443 on its own address. DNS then points vault.yourcompany.com at the first IP and minuteview.yourcompany.com at the second.

Current limitation

MinuteView's built-in HTTPS listener currently binds to all network interfaces on the chosen port, so it will still collide with IIS's use of 443 on the same machine even across different IPs. Until MinuteView can be bound to a specific IP address, this option generally requires the reverse-proxy approach (Option A) or a separate server (Option C) instead. Contact Tentech if a dedicated-IP binding is a requirement for your environment.

Option C — Put MinuteView on its own server

The simplest arrangement conceptually: install MinuteView on a separate machine (or virtual machine) from Vault. MinuteView then owns port 443 on that machine with no competition, and you can use the built-in HTTPS wizard flow described in Applying the certificate directly. Each server has its own hostname and certificate.

Server 1:  Autodesk Vault + IIS  ─►  https://vault.yourcompany.com   (443)
Server 2:  MinuteView Server     ─►  https://minuteview.yourcompany.com (443)

Which option should I choose?

Situation	Recommended approach
MinuteView must share the same server as Vault	Option A — reverse proxy through IIS
You can dedicate a separate machine to MinuteView	Option C — separate server
You have specialised networking and a specific-IP requirement	Option B — talk to Tentech first

---

Changing or replacing the certificate later

Because the web address and certificate are sensitive settings, they are not editable from an everyday settings screen. To replace an expiring certificate, change the hostname, or switch from HTTP to HTTPS after the fact, you re-run setup:

1. Stop the MinuteViewServer service.
2. Delete the configuration file:

   C:\ProgramData\Tentech\MinuteView\MinuteViewServerConfig.dat

3. Start the service again.
4. The Setup Wizard reappears the next time you open MinuteView. Step through it again and supply the new certificate on the Web Address step.

This requires filesystem access to the server

Deleting the configuration file requires administrative access to the server itself. This is the security gate — it ensures the web address and certificate can only be changed by someone with hands-on access to the machine, not by anyone with access to the application's settings.

Deployments behind a reverse proxy or load balancer

If you are terminating HTTPS at a reverse proxy or load balancer (as in Option A, or in a hosted/SaaS deployment), you manage the certificate there, not in MinuteView. In that case leave MinuteView on HTTP and renew the certificate at the proxy.

---

Keep MinuteView Server and Automations on the same protocol

If you run MinuteView Automations as well, both components must use the same protocol.

WARNING

If MinuteView Server is served over HTTPS, the Automations Engine must also be served over HTTPS. A mixed environment (one on HTTP, the other on HTTPS) breaks the real-time WebSocket connection between them. See Platform Architecture for details.

---

Troubleshooting

Symptom	Likely cause and fix
After enabling HTTPS, the site is still only reachable on http://…:8770	The chosen HTTPS port (usually 443) was already in use — commonly by IIS/Vault — so MinuteView fell back to HTTP. Free the port, or use a coexistence approach. Remember to restart the service after configuring HTTPS.
The browser shows "Not secure" or a certificate warning	The certificate name does not match the address users typed, or the certificate is self-signed / issued by a CA the client does not trust. Ensure the certificate covers the hostname and that clients trust the issuing CA.
The wizard rejects the certificate file	The file must be a .pfx containing the private key, and the password must be correct. A .cer/.crt/.pem on its own will not work — see What MinuteView needs.
Real-time features (live updates, AI chat) don't work over HTTPS	If you are reverse-proxying, ensure the WebSocket Protocol IIS feature is installed and WebSockets are allowed through the proxy. Also confirm Server and Automations use the same protocol.
Certificate has expired	Replace it by re-running setup with a new .pfx.

---

Related pages

• MinuteView Server Installation
• Platform Architecture