Configure HTTPS for NIM
Settings guide
Secure NIM traffic with the certificate method that matches your network and certificate-management model.
Choose a certificate methodDirect link to Choose a certificate method
| Method | Best for |
|---|---|
| Self-signed | Local evaluation or environments where every client trusts the certificate. |
| Organization-provided | Existing server or wildcard certificates managed through your PKI. |
| Let's Encrypt | A public hostname that can complete and retain HTTP-01 validation. |
Configure HTTPSDirect link to Configure HTTPS
Choose the certificate sourceDirect link to Choose the certificate source
For an organization-provided certificate, add it to NIM before configuring HTTPS. For Let’s Encrypt, set External Host URL to the exact public hostname and ensure public DNS resolves to it.
Before importing an organization-provided certificate, include every required intermediate CA certificate in the .pfx or .p12 file along with the HTTPS certificate and its private key. A missing intermediate can cause browser trust errors even when the import succeeds. See Include intermediate certificates before import for Windows export instructions, OpenSSL commands, and verification steps outside NIM.
Configure HTTP(S) settingsDirect link to Configure HTTP(S) settings
Go to Configuration > Settings > HTTP(S). Enable HTTPS, then choose Self signed or Select from store and select the certificate. Save and access NIM using https://<hostname>/.
Test secure accessDirect link to Test secure access
Verify access from a client browser, then enable HTTP-to-HTTPS redirect when all expected callers support HTTPS.
The HTTP(S) page selects the HTTPS certificate. To change the NIM Service's minimum TLS version or allowed cipher suites, use the service-level options described under Windows Registry settings. NIM's default minimum is TLS 1.2; --tls-min-v1.3 requires TLS 1.3, and --tls-cipher-list controls the cipher list. Back up the registry key and confirm your browsers, proxies, and integrations support the selected settings before changing them.
The OWASP Transport Layer Security Cheat Sheet explains protocol selection, certificate validation, and HSTS tradeoffs. Use it when reviewing your TLS policy, then test NIM and every proxy or connector client against the chosen settings. Enable HSTS only after the intended HTTPS endpoints work consistently.
Use Let's EncryptDirect link to Use Let's Encrypt
NIM's built-in Let’s Encrypt option uses HTTP-01 validation. Before enabling it, ensure the public hostname is accurate, inbound TCP port 80 reaches NIM, and /.well-known/acme-challenge/ passes unchanged through any proxy, WAF, or load balancer. NIM also needs outbound HTTPS access and any CAA record must allow letsencrypt.org.
In HTTP(S), enable Let’s Encrypt, optionally enable Let’s Encrypt challenges only, enter a monitored contact email, accept the terms, and save. Keep the hostname, DNS, and port 80 route available for renewal.
Port 443 alone cannot complete HTTP-01 validation. Port 80 and the public challenge path must remain reachable for certificate issuance and renewal.
Apply Let's Encrypt validation guidanceDirect link to Apply Let's Encrypt validation guidance
The official Let’s Encrypt challenge documentation explains how HTTP-01 proves control of a hostname: the certificate client serves a token at http://<hostname>/.well-known/acme-challenge/<token>, and Let’s Encrypt retrieves it from potentially multiple network locations. Apply this to NIM by routing the challenge path to the server handling certificate issuance and renewal. If a load balancer serves multiple backends, ensure each can return the same challenge response.
Let’s Encrypt's Keep Port 80 Open guidance recommends retaining HTTP access and redirecting normal web traffic to HTTPS. For NIM, keep the challenge route available when configuring redirects or restricting public access. HTTP-01 cannot issue wildcard certificates; the DNS-01 documentation describes that alternative. If you need a wildcard certificate or cannot expose port 80, obtain a certificate with a suitable external client or your organization's PKI and use NIM's Select from store option.
Reverse proxies and restricted exposureDirect link to Reverse proxies and restricted exposure
When NGINX or another reverse proxy owns ports 80 and 443, use its ACME client or explicitly forward the challenge path to NIM. You can expose only /.well-known/acme-challenge/* through a NAT or WAF while keeping Studio, APIs, and apps private.
To publish approved NIM apps through an NGINX reverse proxy while keeping NIM Studio and administrative APIs internal, follow Allow External Access. The guide covers the recommended DMZ architecture, generating the NGINX configuration in NIM Studio, and restricting public access to selected application routes.