Why does enabling SSL create two VirtualHost blocks instead of one?

Apache needs a separate VirtualHost per listening port/protocol combination; the :80 block stays to redirect plain HTTP to HTTPS, and a new :443 block carries the SSLEngine and certificate directives. Merging SSL directives into a single VirtualHost without a port-based split isn't how Apache's name-based virtual hosting works.

Do I need mod_ssl and mod_proxy enabled for this config to work?

Yes. SSLEngine/SSLCertificateFile require mod_ssl, and ProxyPass/ProxyPassReverse require mod_proxy plus mod_proxy_http, enabled via `a2enmod ssl proxy proxy_http` on Debian/Ubuntu or by uncommenting the LoadModule lines on other distributions.

What do the generated security headers actually protect against?

X-Content-Type-Options: nosniff stops browsers from MIME-sniffing a response into an unintended content type; X-Frame-Options: SAMEORIGIN blocks the page from being framed by a different origin (clickjacking); Referrer-Policy trims how much of the current URL leaks to external links. They're a reasonable baseline, not a full security hardening pass.

Why AllowOverride All in the Directory block?

It lets a .htaccess file inside DocumentRoot override server config (useful for WordPress and similar apps that manage their own rewrite rules), at a small per-request performance cost since Apache checks for .htaccess files on every request. Set it to None for a small speed gain once you know overrides aren't needed.

Apache VirtualHost Config Generator

Overview

Introduction

An Apache VirtualHost for a real site usually needs more than ServerName and DocumentRoot: SSL termination, a reverse proxy path for an API or app server, and a handful of security directives that are easy to forget on a fresh config.

This tool generates a complete VirtualHost, or a matched pair when SSL is enabled, covering all of that from a short form.

What Is Apache VirtualHost Generator?

A generator for an Apache httpd VirtualHost block with ServerName, DocumentRoot, an optional ProxyPass/ProxyPassReverse pair for routing a path to a backend, and standard security directives (ServerTokens Prod, ServerSignature Off, and three common security headers).

With SSL enabled, it generates a :80 VirtualHost that redirects to HTTPS and a :443 VirtualHost with SSLEngine on plus your certificate and key paths.

How Apache VirtualHost Generator Works

You provide a ServerName, DocumentRoot, optionally a ProxyPass path and target, and toggle SSL with certificate/key paths. The generator validates the ServerName format and that DocumentRoot is an absolute path.

It assembles either a single :80 VirtualHost, or a :80-redirects-to-:443 pair when SSL is on, inserting the ProxyPass lines, security directives, and a Directory block with sane default Options/AllowOverride/Require settings.

When To Use Apache VirtualHost Generator

Use it when standing up a new Apache-hosted site or reverse proxy in front of an application server, and you want a config that's secure by default rather than the bare minimum.

It's also handy as a quick reference for the exact ProxyPass/ProxyPassReverse pairing and SSL VirtualHost split syntax.

Often used alongside Nginx Reverse Proxy Generator, Let's Encrypt Config Generator and Caddyfile Generator.

Features

Advantages

Handles the SSL redirect-plus-second-VirtualHost pattern correctly instead of leaving you to figure out the :80/:443 split by hand.
Includes ProxyPass and ProxyPassReverse together, a pair that's easy to add one of and forget the other, breaking redirects from the backend.
Bundles a reasonable security-header baseline rather than shipping a bare VirtualHost with none.

Limitations

Assumes mod_ssl and mod_proxy(+proxy_http) are already enabled on the server; it doesn't generate the LoadModule/a2enmod steps.
Only proxies a single path prefix; a site needing several distinct ProxyPass rules will need to duplicate and adjust that block manually.

Examples

SSL-enabled VirtualHost proxying /api

Input

serverName: example.com, documentRoot: /var/www/example.com, sslEnabled: true, certPath: /etc/ssl/certs/example.com.pem, keyPath: /etc/ssl/private/example.com.key, proxyPath: /api, proxyTarget: http://127.0.0.1:3000/

Output

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com

    Redirect permanent / https://example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.pem
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    ProxyPass /api http://127.0.0.1:3000/
    ProxyPassReverse /api http://127.0.0.1:3000/
...

The :80 VirtualHost only redirects to HTTPS; all real content, proxying, and security directives live in the :443 block.

Best Practices & Notes

Best Practices

Keep the plain-HTTP VirtualHost limited to the redirect (and the Let's Encrypt webroot path, if used for renewal) rather than duplicating full site content on both ports.
Use `apachectl configtest` after editing the generated config, before reloading, to catch a missing enabled module or syntax slip.
Add HSTS (`Header always set Strict-Transport-Security`) once you're confident the site will always be served over HTTPS going forward.

Developer Notes

The two-VirtualHost SSL pattern mirrors Apache's official documented example for name-based SSL virtual hosting: distinct `<VirtualHost *:80>` and `<VirtualHost *:443>` blocks sharing a ServerName, since Apache's virtual host matching is address/port-based before it considers ServerName. `ProxyPass`/`ProxyPassReverse` need matching path prefixes and trailing slashes to rewrite `Location`/`Content-Location`/`Set-Cookie` response headers correctly, mismatched trailing slashes between the two directives is one of the most common ProxyPass configuration bugs.

Apache VirtualHost Generator Use Cases

Standing up a new Apache-hosted static site or PHP application with SSL
Reverse-proxying a specific path to a Node.js/Python/Go backend from Apache
Documenting a baseline, security-header-aware VirtualHost template for a team

Common Mistakes

Setting ProxyPass and ProxyPassReverse with different trailing slash conventions, which breaks Location header rewriting on redirects from the backend.
Enabling SSLEngine without first running `a2enmod ssl` (or the equivalent LoadModule), causing Apache to fail to start with an unrecognized-directive error.

Tips

Run `apachectl configtest` before every reload when hand-editing this generated config further, a typo in a VirtualHost block otherwise won't surface until the next restart fails.

Apache VirtualHost Generator