iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Host multiple HTTPS domains on one Apache server by using name-based virtual hosting with SNI. Create a separate <VirtualHost *:443> block for every domain, give each block an exact ServerName, add only the appropriate ServerAlias values, set that site’s own DocumentRoot, configure its certificate and private key, and authorize the directory with a matching <Directory> section. DNS for every hostname must point to the server, and Apache must listen on port 443.
If Apache displays the wrong site, the usual causes are a hostname that does not match any SSL virtual host, DNS pointing elsewhere, a block bound to the wrong address or port, an incorrect first-vhost fallback, or a document directory that Apache cannot access. The sections below build a working configuration and then show how to identify each failure.
How Apache chooses a site for an HTTPS request
Several domains can share one public IP address because Apache groups virtual hosts by listening address and port. For HTTPS, the relevant group is normally *:443. During the TLS handshake, the client sends the requested hostname using Server Name Indication (SNI). Apache uses that name to choose the SSL virtual host and, therefore, the certificate and filesystem settings for the request. After TLS is established, the HTTP Host header provides another hostname check.
Within the selected address-and-port group, Apache looks for an exact ServerName or a matching ServerAlias. The matching block supplies the DocumentRoot. If no name matches, Apache serves the first virtual host in that group. That ordering is why an unknown hostname can appear to load a legitimate site even though its own DNS or configuration is wrong.
Every independently hosted domain therefore needs its own HTTPS virtual host. A single block with several aliases is appropriate only when all those names intentionally serve the same application and files.
Prerequisites before writing the vhost files
Point every hostname to this server
Create the required DNS records before testing Apache. An A record should resolve the hostname to the server’s IPv4 address; an AAAA record should resolve it to the server’s IPv6 address if the server accepts IPv6 traffic. Include both the bare name and the www name when both will be used.
Apache configuration does not create DNS records. A perfectly written virtual host cannot answer a domain whose DNS points to another machine. Check resolution from a client network and confirm that the result is the address on which Apache is listening. Remove stale records or update them before interpreting an HTTP response as an Apache problem.
Prepare separate filesystem roots
Use a predictable directory layout and keep each site’s files separate. For example:
/var/www/example.com/public
/var/www/example.org/publicCreate the public directories and place a distinctive test file in each one, such as a page containing the domain name. Distinctive content makes it immediately obvious which DocumentRoot Apache selected. The parent directories must be searchable by the Apache service account, and the files must be readable by it. Ownership and permission commands differ by operating system and deployment model, so apply the least-privilege settings used by your distribution rather than making the entire tree world-writable.
Make sure Apache can accept TLS traffic
Apache must listen on port 443, and the firewall or cloud security group must permit inbound TCP 443. The SSL module must be loaded. On Debian- and Ubuntu-family systems this is commonly enabled with a2enmod ssl; package names and module commands differ on Red Hat-family and other distributions. Do not assume that a configuration file being present means the module or listener is active.
Free tools Windows power users keep installed
One-click scans. No signup required.
Build the HTTP redirect virtual hosts
Most sites accept HTTP only to redirect visitors to HTTPS. Use a port-80 block whose aliases cover the names you actually publish. Keep the destination hostname deliberate: redirecting www.example.com to https://example.com/ establishes one canonical URL.
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
Redirect permanent / https://example.com/
</VirtualHost>
<VirtualHost *:80>
ServerName example.org
ServerAlias www.example.org
Redirect permanent / https://example.org/
</VirtualHost>The redirect is separate from the SSL site. It does not select a certificate and should not be treated as a replacement for the *:443 block. If an application must preserve the original host or path, configure its canonicalization policy explicitly; otherwise, use a fixed HTTPS URL as shown.
Configure one HTTPS vhost per domain
Give each domain its own block. The following example uses separate roots, certificates and logs:
# Domain 1
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example.com/public
SSLEngine On
SSLCertificateFile /etc/ssl/example.com/fullchain.pem
SSLCertificateKeyFile /etc/ssl/example.com/privkey.pem
ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
<Directory /var/www/example.com/public>
Require all granted
</Directory>
</VirtualHost>
# Domain 2
<VirtualHost *:443>
ServerName example.org
ServerAlias www.example.org
DocumentRoot /var/www/example.org/public
SSLEngine On
SSLCertificateFile /etc/ssl/example.org/fullchain.pem
SSLCertificateKeyFile /etc/ssl/example.org/privkey.pem
ErrorLog ${APACHE_LOG_DIR}/example.org-error.log
CustomLog ${APACHE_LOG_DIR}/example.org-access.log combined
<Directory /var/www/example.org/public>
Require all granted
</Directory>
</VirtualHost>Replace every path with the real certificate and key locations supplied by your certificate issuer. The example’s fullchain.pem and privkey.pem names are conventions, not requirements. Keep private-key files protected from ordinary users and do not place them below a web-accessible document root.
Understand each directive
ServerName: the primary hostname Apache should match. Set it explicitly in every block.ServerAlias: additional names that should serve exactly the same site. Do not list another domain here if it needs different files, logs or application settings.DocumentRoot: the absolute directory from which this vhost serves web content.SSLEngine On: enables TLS processing for the block when the SSL module supports this directive.SSLCertificateFileandSSLCertificateKeyFile: identify the certificate chain and corresponding private key. The certificate must contain the requested name in its identity fields.ErrorLogandCustomLog: separate diagnostics by domain, making it possible to see which vhost handled a request.<Directory>withRequire all granted: grants Apache permission to serve that root under Apache 2.4 authorization rules. The path must match the intended root exactly.
Enable, validate and reload the configuration
- Save each site in the configuration location used by your distribution. Debian- and Ubuntu-family systems commonly use files under
/etc/apache2/sites-available/; other systems may use an included directory under/etc/httpd/. - Enable the site files using the distribution’s site-enabling mechanism where one exists. For example, Debian-family systems commonly use
a2ensite example.com.confanda2ensite example.org.conf. - Confirm that a 443 listener and SSL module are enabled. Add a
Listen 443directive only if the distribution’s default configuration does not already provide it. - Run the configuration test before reloading. A common command is
apachectl configtest; some systems providehttpd -t. Fix every syntax, certificate-path and permission error reported. - Inspect the virtual-host map with
apachectl -Sor the equivalent command on your platform. It should show both names under the address and port clients use, along with the file order and default vhost. - Reload Apache using the service manager supplied by your operating system, such as
systemctl reload apache2orsystemctl reload httpd. A reload applies valid configuration without unnecessarily dropping established connections.
Command names and configuration directories vary by distribution. Use the equivalent local command rather than copying a Debian-specific command onto another operating system.
Why SNI is required for separate certificates
TLS negotiation occurs before Apache receives the ordinary HTTP Host header. Without a hostname in the handshake, Apache cannot know which certificate to present when several certificates share one address and port. SNI supplies that hostname early enough for Apache to choose the appropriate SSL vhost.
Modern browsers and operating systems support SNI, making shared-IP HTTPS the normal design. Apache’s SNI documentation also identifies the prerequisites in the TLS and OpenSSL stack. Very old non-SNI clients cannot reliably select among multiple certificates on one IP and port. If those clients matter, use a certificate that covers all required names, provide a dedicated IP address, or expose a separate port and endpoint instead of depending on per-name certificate selection.
A wildcard certificate can cover a controlled set of names under one DNS level, while a Subject Alternative Name (SAN) certificate can list several specific names. These certificate choices change certificate management, not the need for correctly separated virtual-host blocks when the sites have different roots and behavior.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsPrevent an unknown hostname from exposing a real site
Because Apache uses the first vhost as the fallback for an unmatched name, do not let the first block accidentally expose a production site. Put an intentional default block first for the *:443 group. It can return a minimal error response or point to a neutral document root that contains no sensitive content.
<VirtualHost *:443>
ServerName invalid.example
DocumentRoot /var/empty
SSLEngine On
SSLCertificateFile /etc/ssl/default/fullchain.pem
SSLCertificateKeyFile /etc/ssl/default/privkey.pem
<Directory /var/empty>
Require all denied
</Directory>
</VirtualHost>The default still needs a certificate because TLS negotiation happens before Apache can reject an unknown HTTP hostname. Use a certificate and key that are valid for the default endpoint’s intended behavior, and ensure the directory exists. Test the default deliberately rather than assuming ordering alone solved the exposure.
Diagnose the wrong DocumentRoot
1. Check the exact hostname
Compare the browser’s address, including whether it uses www, with every ServerName and ServerAlias. A typo, an omitted alias or a request to an entirely different subdomain sends Apache to another match or to the first fallback block. Test the bare and www names separately.
2. Verify DNS and the destination address
Resolve both A and AAAA records. If IPv6 resolves to a different server, some clients will reach that server while IPv4 clients reach the expected one. Confirm that the resolved address belongs to this Apache instance and that no proxy, load balancer or stale DNS record is in front of it.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 113. Confirm the vhost address and port
The SSL block must bind to the address and port clients actually use, normally *:443. A block written for port 80 cannot answer an HTTPS request. If Apache listens only on a specific address, replace the wildcard with that address consistently and verify that the firewall permits it.
4. Inspect ordering and the active map
Run the platform’s vhost-dump command, commonly apachectl -S. Look for duplicate names, an unexpected default, a block loaded earlier than intended, or a block that was never enabled. The first block in the matching address-and-port group handles names that match nothing else.
5. Read per-site logs
Request the domain once, then inspect the access and error logs configured inside that vhost. If no entry appears, the request likely reached another server, another Apache instance or a proxy. If the entry appears in a different site’s log, the hostname-to-vhost match is wrong. Log separation is one of the fastest ways to distinguish routing from application errors.
6. Verify the root and authorization
Check that the exact DocumentRoot exists, contains the expected index file and is readable by Apache. Check every parent directory for execute/search permission. Ensure the <Directory> path is identical to the root path; a typo there can produce a 403 even when the files are present. If the page is a generic operating-system test page, remove or disable the distribution’s default site only after confirming that your replacement vhost is valid.
7. Investigate certificate and SNI symptoms
If the certificate belongs to one domain but the content belongs to another, inspect SNI support, certificate names and the order of SSL vhosts. A non-SNI client or a client that sends no hostname receives the default certificate and default vhost. A certificate mismatch is not fixed by changing DocumentRoot; correct the TLS selection first.
Choosing an architecture
| Architecture | When it fits | Important trade-off |
|---|---|---|
| One shared IP, SNI, separate certificates | Normal modern multi-domain hosting with independent sites | Requires SNI-capable clients and correctly managed certificates |
| One shared IP, wildcard or SAN certificate | Several names can be covered by one certificate and certificate administration should be consolidated | Certificate scope is shared; names must fit the wildcard rules or SAN list |
| Dedicated IP per domain | Legacy non-SNI clients or strict network separation | Consumes additional addresses and requires address-specific vhost bindings |
| Separate ports | Internal services or controlled clients where distinct endpoints are acceptable | Users must specify nonstandard ports and normal HTTPS expectations may not apply |
| Shared filesystem root | Aliases intentionally serve one application and one deployment | A mistake can expose or mix content; independent sites should use separate roots |
| Separate roots and logs | Independent domains, teams, release schedules or troubleshooting needs | More configuration and certificate files to maintain, but clearer isolation |
SNI is the standard shared-IP solution. Separate IPs, separate ports and multi-name certificates remain valid alternatives when client compatibility, certificate policy or network design requires them.
Operational and security practices
- Use a separate Unix directory and log files for each independent site.
- Keep private keys outside all document roots and restrict their permissions.
- Renew certificates before expiry and reload Apache only after validating the new paths and matching key.
- Keep aliases intentional. An alias is another public name for the same content, not a shortcut for hosting a second site.
- Do not grant broad filesystem access merely to cure a 403; correct ownership, parent-directory traversal and the matching authorization block.
- Include a neutral default vhost so random hostnames do not reveal a production site.
- Test IPv4 and IPv6 independently when both records exist.
- After every change, run a syntax test, inspect the vhost map, request each hostname and check the corresponding log.
Complete deployment checklist
- Each public hostname resolves to the server’s correct IPv4 and, where used, IPv6 address.
- Apache listens on the address and port receiving HTTPS traffic, and TCP 443 is allowed through the firewall.
- The SSL module is loaded.
- Every domain has an enabled
<VirtualHost *:443>block. - Each block has an exact
ServerNameand only the intended aliases. - Each independent site has its own absolute
DocumentRoot. - The certificate contains the requested hostname, and its private key matches.
- The
<Directory>section matches the root and grants the required access. - Per-site access and error logs are writable and are receiving requests.
- The first SSL vhost is an intentional fallback rather than an accidental production site.
- The configuration test passes, the vhost map shows the expected order, and Apache has been reloaded.
- Requests to every bare and aliased hostname return the intended content over HTTPS, while HTTP requests follow the intended redirect.
Frequently Asked Questions
Can two domains use the same Apache virtual-host block?
Yes, but only when they should serve the same files and application. Add the additional hostname as a deliberate ServerAlias; create a separate block when the domain needs a different DocumentRoot, certificate policy, logs or application settings.
Why does an unknown hostname show the first site?
Apache uses the first virtual host in the matching address-and-port group when no ServerName or ServerAlias matches. Put a restrictive default block first so unmatched names cannot expose a production root.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do I need a separate IP address for every SSL domain?
No. SNI allows modern clients to select different certificates and virtual hosts on one IP and port. A dedicated IP, a multi-name certificate or a separate port is mainly an alternative for legacy clients or special network requirements.
What does Apache configuration not fix?
It does not create DNS records, repair a hostname resolving to another server, make an invalid certificate valid, or grant filesystem permissions automatically. Those must be corrected in DNS, certificate management, networking and filesystem authorization respectively.
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.
