Recommended Free Tools
Apache can serve different HTTPS sites, each with its own certificate, from one IP address and TCP port 443. The mechanism is TLS Server Name Indication (SNI): the browser sends the requested hostname during the TLS handshake, Apache selects the matching name-based virtual host, and mod_ssl presents that host’s certificate. Every hostname still needs correct DNS, a matching <VirtualHost *:443> block, and a certificate/private-key pair that covers the name.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What makes multiple certificates on one IP possible?
Before SNI, a TLS server generally had to choose one certificate as soon as a connection reached an IP address and port. That made several unrelated HTTPS domains on the same address impractical: the server did not yet know which hostname the client intended to visit. SNI adds the hostname to the initial TLS handshake, before Apache sends its certificate.
As an Amazon Associate I earn from qualifying purchases.
With Apache configured for name-based SSL virtual hosting, the sequence is:
- The client resolves a hostname, such as
example.com, to the server’s IP address and connects to TCP port 443. - During the TLS ClientHello, an SNI-capable client includes
example.com. - Apache’s virtual-host matcher compares that name with the
ServerNameandServerAliasvalues on the SSL virtual hosts bound to that address and port. mod_ssluses the selected block’sSSLCertificateFileandSSLCertificateKeyFileto send the appropriate certificate.- After TLS is established, Apache serves the request from the selected virtual host, including its document root and other site-specific settings.
If the client does not send SNI, or if the supplied name does not match any configured virtual host, Apache cannot select a site-specific certificate. It returns the certificate from the first virtual host listed for that IP-address-and-port combination. That first block is the deliberate fallback and must be configured accordingly.
#1 Best Overall
- Used Book in Good Condition
Requirements and compatibility
Gather these items before editing Apache. Missing any one of them can produce a certificate warning even when the virtual-host syntax is correct.
- SNI-capable Apache and OpenSSL: Apache’s SNI guidance calls for OpenSSL 0.9.8f or later with TLS extensions. Apache’s FAQ documents Apache 2.2.12 or later with OpenSSL 0.9.8j or later for name-based SSL virtual hosting. Modern Apache 2.4 installations normally meet these requirements, but verify the versions supplied by your operating system.
mod_ssl: The SSL module must be installed and enabled. Apache must also be built against an OpenSSL implementation that supports TLS extensions and SNI.- A reachable TLS listener: The server needs one listener on TCP port 443, or on another TLS port that clients actually use. Firewalls, security groups, NAT rules and load balancers must pass that port to Apache.
- DNS records: Every hostname must resolve to the address that receives the HTTPS connection. Create the required A records for IPv4 and AAAA records for IPv6, and make sure both paths reach the same Apache configuration.
- Coverage-matched certificates: Each certificate must contain its hostname in the Subject Alternative Name (SAN) extension. The corresponding private key must match the certificate, and the server should send the required intermediate chain.
- Administrative access: You need permission to read certificate and key files, edit Apache configuration, run a configuration test and reload the service.
Do not assume that a certificate for the bare name also covers a www name, or that a certificate for one domain covers another domain. Check the SAN list explicitly.
Plan the hostname-to-certificate mapping
Make a small inventory before creating virtual hosts. It prevents the most common operational error: placing a certificate in a block whose ServerName does not match the names on that certificate.
| Hostname group | Apache name matching | Certificate and key | Content location |
|---|---|---|---|
example.com and www.example.com |
ServerName example.com plus ServerAlias www.example.com |
A certificate whose SAN list includes both names, with its matching private key | /var/www/example |
example.org |
ServerName example.org |
A certificate whose SAN list includes example.org, with its matching private key |
/var/www/example-org |
Use a separate row for every certificate boundary. If two sites share one wildcard or SAN certificate, they can still have separate virtual hosts; certificate reuse and content sharing are independent decisions.
Build the Apache SSL virtual hosts
1. Define the TLS listener
Ensure Apache listens on the port used by the virtual hosts. A representative Apache 2.4 configuration is:
Listen 443 httpsSome distributions already define the listener in a packaged SSL configuration. Do not add a duplicate Listen directive if one is present. If you use a non-standard TLS port, replace both the listener port and the virtual-host port consistently.
2. Create one name-based virtual host per site
Place the blocks in a file loaded by Apache, using your distribution’s normal sites or conf-enabled directory. This example gives two domains separate document roots and certificates:
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>
<VirtualHost *:443>
ServerName example.org
DocumentRoot /var/www/example-org
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.org/privkey.pem
</VirtualHost>SSLEngine on enables TLS for the block. SSLCertificateFile points to the certificate file (often a full chain), and SSLCertificateKeyFile points to the private key. The paths are examples; use the paths created by your certificate authority or internal PKI.
Keep each key readable by Apache but not by ordinary users. The private key should not be placed in a web-accessible document root, committed to a repository, or copied into a public backup.
3. Enable the module and site definitions
On Debian-family systems, administrators commonly enable SSL with a2enmod ssl and enable a site file with a2ensite. Other distributions use different directories and service tooling, so follow the conventions of the operating system rather than copying those commands blindly. Confirm that the resulting configuration is actually included by the main Apache configuration.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →4. Test before reloading
Run:
apachectl configtestProceed only when the result is Syntax OK. A successful syntax test checks that Apache can parse the directives; it does not prove that DNS, certificate coverage, private-key matching or external connectivity is correct.
5. Reload gracefully
Reload Apache using the service method supplied by your operating system. A graceful reload lets existing connections finish while workers adopt the new configuration. If the reload fails, keep the previous configuration active, read the service error log, correct the reported issue and run apachectl configtest again before retrying.
Choose the correct default virtual host
Apache treats the first virtual host listed for an address and port as the default. SNI-capable clients that request a configured name receive the matching block, regardless of which block is first. The first block matters for three cases:
- A legacy client that omits SNI.
- A client that sends an unknown hostname.
- A connection where the request cannot be matched to another configured name.
Put the site whose certificate and content should be exposed as the fallback first. This is a policy choice, not a technical afterthought. You might select a neutral landing site rather than a production domain, especially if unknown hostnames should not appear to belong to a particular customer or application.
Changing file names does not necessarily change load order. Apache’s include order and your distribution’s site-enabling tool determine which block is first. Inspect the active virtual-host map with the diagnostic command supported by your Apache build, and verify the order after enabling or disabling sites.
Make DNS, certificates and names agree
DNS must reach the same listener
Resolve every hostname from an external network and confirm that its A and, where used, AAAA records lead to the server or load balancer that holds these virtual hosts. An A record pointing to the right address does not compensate for an AAAA record pointing somewhere else: IPv6 clients may receive a different certificate or no service at all.
Check the firewall and upstream network path for TCP 443. If a reverse proxy or load balancer terminates TLS before Apache, the certificate-selection problem belongs to that device unless it passes TLS through unchanged.
Each certificate must cover every alias
For example.com and www.example.com, either use one certificate containing both SAN entries or use separate virtual hosts and certificates with separate name mappings. A certificate that contains only example.com does not automatically validate www.example.com. Wildcard matching also has boundaries: a wildcard for *.example.com covers one label such as shop.example.com, not the bare example.com and not a deeper name such as api.shop.example.com.
Separate certificates versus wildcard and SAN certificates
Multiple certificates are not the only way to cover several HTTPS names. The right model depends on ownership boundaries, renewal workflow and the consequences of a key or certificate failure.
| Model | Hostname coverage | Operational characteristics | Main risk or trade-off |
|---|---|---|---|
| One certificate per hostname or site | Each certificate covers the names assigned to its virtual host | Independent issuance, renewal and revocation; a change for one site can be isolated | More certificate files, renewal jobs and key-management tasks |
| Wildcard certificate | One wildcard covers matching subdomains under its domain; the exact covered names depend on the certificate’s SAN entries and wildcard scope | Fewer certificates to deploy and renew for a domain’s subdomains | The wildcard private key has a larger blast radius if compromised or revoked, and it does not cover unrelated domains or every level of subdomain |
| SAN (multi-name) certificate | Every covered hostname is explicitly listed in the SAN extension | One certificate and key can cover several names across a planned set | Adding or removing a name requires reissuing the certificate; one revocation affects all names on it |
Wildcard and SAN certificates do not remove the need for SNI, correct DNS or matching Apache names. They change how many names one certificate can validate; Apache still needs a virtual host for each site that has different content or settings.
Best Value
Validate every hostname after deployment
Use a repeatable check rather than testing only the first site.
- Check resolution: Confirm that each A and AAAA record resolves to the intended endpoint and that TCP 443 is reachable from outside the server’s local network.
- Check configuration: Run
apachectl configtestand confirm the service reload completed without errors. - Check the certificate: Visit each HTTPS hostname in a browser or inspect it with a TLS client. Verify the certificate subject/SAN list, issuer chain, expiration date and the hostname shown by the client.
- Check the key pair: Confirm that each configured private key corresponds to its certificate. A mismatch normally prevents Apache from starting or reloading that SSL virtual host.
- Check aliases: Test every
ServerAlias, not only the primaryServerName. An alias can resolve correctly while still being absent from the certificate. - Check the fallback: Request an intentionally unknown hostname and confirm that the deliberately chosen first-listed certificate is returned. This verifies that default behavior is understood rather than accidental.
- Check renewal timing: Record the expiration dates and ensure your renewal process updates the files Apache actually reads, followed by a configuration test and graceful reload.
When a browser displays a certificate for another site, inspect the name used in the request, the address reached over IPv4 or IPv6, and the order of the SSL virtual hosts before changing certificates.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Troubleshoot the wrong certificate
The first site’s certificate appears for every domain
- Confirm the client supports SNI. A non-SNI client receives the first-listed certificate by design.
- Check that the requested hostname is spelled exactly as a
ServerNameorServerAlias. Name matching is not based on the document root. - Verify that the relevant block is bound to
*:443(or the actual address and port), hasSSLEngine on, and is loaded by Apache. - Check that DNS is not sending the hostname to another server, proxy or old IP address.
- Inspect IPv4 and IPv6 separately. A correct A record cannot fix an incorrect AAAA path.
The certificate is correct, but the browser reports a name error
Read the SAN list, not just the certificate’s display name. Add the missing alias to the certificate and renew it, or map that alias to a certificate that already covers it. Then update the corresponding Apache block and reload gracefully.
Apache refuses to reload
- Run
apachectl configtestand fix the first reported syntax or file-path error. - Check that certificate and key files exist at the configured paths and that Apache can read them.
- Confirm that the private key matches the certificate. Replacing only one file creates a mismatch.
- Look for duplicate or conflicting
Listendirectives and overlapping virtual-host definitions. - Review the service log for permission, parsing and cryptographic-library errors before attempting another reload.
Only older clients fail
Some older TLS clients do not send SNI. They can receive only the default certificate, even though modern browsers receive the correct one. Decide whether those clients must be supported. If they must, make the first-listed certificate a suitable compatibility certificate, or provide a separate address for the legacy service. Do not expect additional name-based certificates on the same IP and port to solve a client-side lack of SNI.
Renewal and key-management practices
Certificate selection happens at handshake time, but operational mistakes often appear during renewal. Keep a record linking each hostname, certificate path, key path, expiration date and renewal owner. When a certificate is replaced:
- Install the new certificate and, if applicable, its complete intermediate chain with restrictive permissions.
- Verify that the new private key matches the new certificate.
- Confirm that the SAN list still contains every
ServerNameandServerAliasin the block. - Run
apachectl configtest. - Reload Apache gracefully.
- Inspect the served certificate for each affected hostname and check the expiration date and issuer chain.
Do not delete the previous working certificate until the new files have been tested and the reload has succeeded. Store backups securely, protect private keys with appropriate filesystem permissions, and revoke a key promptly if it is exposed. With a SAN or wildcard model, account for the broader impact of a single certificate or key failure.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Design choices that prevent future outages
- Use explicit names: Give every site one canonical
ServerNameand list only intentional aliases. This makes certificate coverage auditable. - Choose the fallback deliberately: Keep the intended default block first and document why it is safe for unknown or non-SNI connections.
- Keep certificates scoped: Separate certificates reduce the number of unrelated names affected by a revocation, while wildcard and SAN certificates reduce renewal overhead. Choose based on the administrative boundary, not file-count convenience alone.
- Test both address families: If you publish AAAA records, validate the IPv6 route as carefully as IPv4.
- Automate safely: Renewal automation should run a configuration test and graceful reload, then perform a post-reload certificate check. A job that copies files without reloading leaves Apache serving the old certificate.
- Monitor expiration: Alert before certificates expire and include every alias in the monitoring set. Testing only the default hostname can miss a failed renewal for another virtual host.
When one IP is not enough
SNI solves certificate selection when clients support it and all names can share the same listener. A separate IP address or TLS termination layer may still be appropriate when a required client does not support SNI, when policy requires strict network separation, or when another service already owns the address and port. Those are architectural constraints, not Apache certificate-file settings. For ordinary modern HTTPS traffic, correctly ordered SNI virtual hosts provide distinct certificates on one IP without allocating an address per domain.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
