Skip to content
Sign in
Contact Support
  • There are no suggestions because the search field is empty.

How to create a Self‑Signed Multi‑Site (SAN) SSL Certificate

This guide explains how to configure a single internal SSL certificate to securely support both the IC3 web interface (frontend) and IC3 API services (backend) when hosted on Microsoft IIS. This approach enables encrypted HTTPS access without requiring a publicly issued certificate.

Supported Scope

This configuration is supported only in the following scenarios:

  • Internal‑only IC3 environments
  • Active Directory–joined domains (for example, company.local)
  • Environments that do not require public or internet‑facing SSL 

IC3 Site Architecture

IC3 uses two distinct internal endpoints:

Component Example URL
IC3 Web Application (Frontend) https://ic3.ic-test.local
IC3 API Services (Backend) https://ic3-api.ic-test.local

Although both endpoints typically resolve to the same IIS server, they must be treated as separate DNS and SSL identities.

Prerequisites

Before proceeding, ensure the following are in place:

  • Windows Server joined to Active Directory
  • IIS installed
  • Internal DNS managed by a Domain Controller
  • Administrative permissions to manage certificates and Group Policy

Quick Configuration Checklist

This checklist confirms at a high level that you have successfully completed all the required steps:

  • Internal DNS records created for both IC3 endpoints
  • Both hostnames resolve correctly from servers and client machines
  • A single SSL certificate includes both DNS names
  • The same certificate is bound to both IIS sites
  • The certificate is trusted via Group Policy
  • End‑user browsers display no certificate warnings when accessing IC3

Step 1: Internal DNS Configuration

Create internal DNS A record for both IC3 endpoints, pointing to the IIS server’s IP address:

  • ic3.ic-test.local
  • ic3-api.ic-test.local

Verify name resolution from both servers and client machines using standard DNS lookup tools. Both names must resolve correctly for SSL validation to succeed.

Step 2: Generate the SSL Certificate

On the IIS server, generate a single self‑signed certificate that includes both DNS names as Subject Alternative Names (SANs).

The certificate must:

  • Use RSA (2048‑bit or higher)
  • Use SHA‑256 hashing
  • Be issued to both fully qualified domain names
  • Be stored in the Local Computer certificate store

Below is an elevated Powershell session you can utilize

New-SelfSignedCertificate   -DnsName "ic3.ic-test.local","ic3-api.ic-test.local"   -CertStoreLocation "Cert:\LocalMachine\My"   -FriendlyName "IC3 ic-test.local Internal SAN Certificate"   -KeyLength 2048   -KeyAlgorithm RSA   -HashAlgorithm SHA256   -NotAfter (Get-Date).AddYears(3)

Step 3: Validate Certificate Contents

After creation, verify that the certificate includes both IC3 DNS names in its SAN field (Open certlm.msc > Personal > Certificates).

If either name is missing, the certificate must be regenerated. Browsers will reject the connection if the hostname does not match the certificate.

Step 4: Configure IIS HTTPS Bindings

For each IC3 site in IIS:

  • Create an HTTPS binding
  • Specify the correct hostname
  • Assign the same SAN certificate to both the frontend and backend sites

Hostnames configured in IIS must exactly match the certificate entries.

Step 5: Export the Certificate

  • Export the certificate in DER‑encoded (.cer) format without the private key.

This exported certificate will be used to establish trust across the domain.

Step 6: Establish Domain Trust

Using Group Policy:

  • Import the exported certificate into Trusted Root Certification Authorities (Computer Configuration\Windows Settings\Security Settings\)
  • Ensure the policy is linked to all relevant computers

This step allows all domain‑joined machines to trust the IC3 certificate automatically.

Step 7: Client Validation

On client machines:

  • Refresh Group Policy (gpupdate /force)
  • Confirm the certificate appears under Trusted Root Certification Authorities

This step confirms the certificate trust has been successfully applied.

Step 8: Browser Verification

  • Confirm both IC3 endpoints loads without certificate warnings

    https://ic3.ic-test.local

    https://ic3-api.ic-test.local

Important Limitations and Considerations

Please review the following carefully before choosing this approach:

  • Self‑signed certificates are supported only for internal use
  • Short or non‑FQDN hostnames (for example, https://ic3) are not supported by modern browsers
  • This configuration is not suitable for internet‑facing or hybrid deployments
  • External services such as Microsoft Graph, Entra ID sync, or third‑party integrations may fail due to certificate trust requirements

For environments that require external connectivity or public trust, a publicly trusted SSL certificate is strongly recommended.

Key Notes

  • A single SAN certificate must be shared across all IC3 internal endpoints
  • IIS requires certificates to be installed in the Local Computer store
  • Self‑signed certificates should not be used beyond internal, domain‑controlled scenarios