Private SSL 303: Wildcard vs. Multi-Domain (SAN) SSL for Internal Networks: Which to Choose

As enterprise intranets expand across dozens of microservices, departmental portals, and on-premise application servers, managing individual single-domain certificates for every single endpoint becomes operationally expensive. Generating separate Certificate Signing Requests (CSRs), tracking distinct renewal cycles, and manually binding individual certificates across a growing server fleet consumes valuable engineering hours and increases the chance of unexpected expiration outages.

To streamline administrative overhead, IT administrators commonly turn to multi-endpoint certificates. The two primary architectures available are Wildcard Certificates and Multi-Domain (Subject Alternative Name / SAN) Certificates.

While both formats consolidate multiple hostnames under a single certificate, they differ significantly in security boundaries, private key exposure, configuration flexibility, and operational maintenance. Understanding these trade-offs is critical to selecting the right model when issuing intranet certificates through SecureNT.

Understanding Wildcard Certificates (*.domain.local)

A Wildcard certificate uses an asterisk (*) in the Common Name or Subject Alternative Name field to secure an entire level of subdomains under a designated namespace (for example, *.company.local).

• How It Works: A single certificate issued for *.corp.internal will automatically secure sharepoint.corp.internal, erp.corp.internal, git.corp.internal, and any newly created host at that exact DNS level without reissuing the certificate.
• The Core Benefit: Maximum agility for dynamic additions. IT teams can spin up new internal services and bind the existing wildcard certificate immediately without returning to the Certificate Authority to generate a new request.
• The Trade-Off (Security Scope): Because the certificate secures multiple hosts, the underlying private key must be copied and distributed across every server, reverse proxy, and container cluster hosting those subdomains. If an attacker or unauthorized actor compromises a single development VM holding the wildcard key, they hold the private key needed to decrypt traffic or spoof connections for every other service under that namespace.
• Technical Limitation: Standard wildcard certificates only cover a single DNS label. A certificate issued for *.company.local will not validate deeper multi-level domains such as app.dev.company.local.

Understanding Multi-Domain (SAN) Certificates

A Multi-Domain certificate utilizes the Subject Alternative Name (SAN) extension to specify an explicit, itemized list of hostnames, Fully Qualified Domain Names (FQDNs), and even internal IP addresses within a single certificate payload.

• How It Works: A single certificate can explicitly protect diverse, heterogeneous endpoints, such as mail.company.local, autodiscover.company.local, erp.internal.corp, and 192.168.1.50.
• The Core Benefit: Principle of least privilege and strict cryptographic scoping. You define exactly which systems are protected. Furthermore, SAN certificates natively support securing non-standard names, distinct top-level internal domains, and RFC 1918 private IP addresses—capabilities wildcards cannot fulfill.
• The Trade-Off: Adding a new service hostname requires reissuing or updating the certificate in the SecureNT console to append the new SAN entry to the certificate payload.

Head-to-Head Comparison

Scenario-Based Recommendations for Internal Networks

When to Choose a Wildcard Certificate

• Homogeneous Development & Staging Clusters: When spinning up and tearing down dozens of temporary test branches, CI preview environments, or developer sandbox containers under a shared domain (e.g., feature1.dev.local, feature2.dev.local).
• Centralized Load Balancers & Ingress Gateways: If a single reverse proxy (such as Nginx, HAProxy, or Traefik) terminates all internal traffic before routing downstream, the private key resides exclusively on that secured gateway rather than being dispersed across disparate backends.

When to Choose a Multi-Domain (SAN) Certificate

• Diverse Enterprise Workloads: When securing heterogeneous core services that share infrastructure or public-facing proxies (e.g., exchange.company.local, sharepoint.company.local, and erp.company.local).
• Appliance & IP-Based Routing: When servers, hypervisors, network switches, or storage management portals must be reached directly via internal IP address rather than DNS.
• Strict Regulated & Production Environments: Regulated networks complying with HIPAA, SOC 2, or PCI-DSS where key-sharing across distinct operational boundaries violates data isolation controls.

Implementing SAN & Wildcard Requests in SecureNT

Whether choosing a Wildcard or a SAN certificate, standardizing the issuance workflow via SecureNT ensures complete lifecycle visibility and automated chain validation:

1. Generating a Multi-Domain SAN CSR via OpenSSL

Create an OpenSSL configuration file (san_req.cnf) specifying your targeted internal assets:

Ini, TOML

[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[dn]
CN = core-gateway.company.internal
O = Enterprise
OU = IT Infrastructure
L = City
ST = State
C = US

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = core-gateway.company.internal
DNS.2 = mail.company.internal
DNS.3 = erp.company.internal
DNS.4 = sharepoint.company.internal
DNS.5 = 192.168.10.25
IP.1 = 192.168.10.25

Generate the key and CSR:

Bash
openssl req -new -nodes -out intranet_san.csr -newkey rsa:2048 -keyout intranet_san.key -config san_req.cnf

2. Generating a Wildcard CSR

For a wildcard request, specify the asterisk in the Common Name:

Bash

openssl req -new -newkey rsa:2048 -nodes -keyout wildcard_private.key -out wildcard_request.csr -subj "/C=US/ST=State/L=City/O=Enterprise/OU=IT/CN=*.company.internal"

3. Issuance via SecureNT

1. Access the SecureNT Intranet SSL management console.
2. Submit your generated CSR (intranet_san.csr or wildcard_request.csr).
3. For SAN certificates, confirm that the portal accurately parses and lists all designated DNS names and IP addresses from the request.
4. Choose the appropriate validity window and complete the issuance.
5. Download the issued certificate (server.cer) along with the required SecureNT CA-Bundle.cer for deployment.

Choosing between Wildcard and Multi-Domain SAN certificates is not an either-or proposition for modern enterprises. The most resilient architectures deploy Wildcard certificates selectively on centralized edge proxies and dynamic staging environments, while reserving Multi-Domain SAN certificates for sensitive production workloads, multi-role services, and IP-addressed infrastructure. Backed by SecureNT, both models provide verified encryption, zero browser warnings, and streamlined certificate management across your private network.