Apache Httpd 2.4

On the listing, choose Get it now. In the Azure portal, set your subscription, resource group, region and size, your SSH key and the inbound ports, then choose Review and create. For inbound ports, allow SSH (22), HTTP (80) and HTTPS (443). When the VM exists, narrow SSH to your own address in the network security group.

Create a resource group and a network security group that allows SSH from your own address and web traffic from everyone. If only your own networks should see the site, put their ranges in place of Internet:

az group create --name myResourceGroup --location eastus
az network nsg create --resource-group myResourceGroup --name my-apache-nsg
az network nsg rule create --resource-group myResourceGroup --nsg-name my-apache-nsg \
  --name allow-ssh --priority 100 --protocol Tcp --access Allow \
  --source-address-prefixes <your-ip>/32 --destination-port-ranges 22
az network nsg rule create --resource-group myResourceGroup --nsg-name my-apache-nsg \
  --name allow-web --priority 110 --protocol Tcp --access Allow \
  --source-address-prefixes Internet --destination-port-ranges 80 443

The image has a Marketplace purchase plan. Accept its terms once per subscription, then create the virtual machine. Replace <your-vm-size> with the size you chose:

az vm image terms accept --urn sac1647283583153:apache-httpd-ubuntu-24-04:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-apache-vm \
  --image sac1647283583153:apache-httpd-ubuntu-24-04:default:latest \
  --size <your-vm-size> \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --nsg my-apache-nsg \
  --public-ip-sku Standard

On your own workstation, find the public IP address, then connect:

az vm show --resource-group myResourceGroup --name my-apache-vm --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

If you connect right after the VM starts, wait for first boot to finish:

sudo cloud-init status --wait

It prints status: done.

systemctl is-active apache2 apache-firstboot.service apache2 -v sudo ss -Htln '( sport = :80 or sport = :443 )' | awk '{print $4}'

Both services report active, the version line reads Server version: Apache/2.4.58 (Ubuntu), and Apache listens on *:80 and *:443.

curl -s -o /dev/null -w 'http://localhost/ -> HTTP %{http_code}\n' http://localhost/
curl -sk -o /dev/null -w 'https://localhost/ -> HTTP %{http_code}, HTTP/%{http_version}\n' https://localhost/

On a new VM both return HTTP 403, the HTTPS one over HTTP/2: Apache is answering, and the document root is still empty. The next step adds a page.

Put your site's files in /var/www/html. Write an index page, then fetch it:

echo '<h1>It works on Azure</h1>' | sudo tee /var/www/html/index.html curl -s http://localhost/ curl -sk -o /dev/null -w 'HTTP %{http_code}, HTTP/%{http_version}\n' https://localhost/

The page comes back over HTTP, and HTTPS returns HTTP 200, HTTP/2. From your workstation, open http://<vm-ip>/ in a browser. https://<vm-ip>/ works too, with a certificate warning until you install a real certificate (Step 9).

To publish a whole site, copy its files into /var/www/html, for example with scp or rsync over SSH. Keep them readable by the www-data user that Apache runs as.

Apache on Ubuntu keeps each site, module and configuration fragment in its own file, and turns them on with symbolic links:

Directory Holds Turn on / off

/etc/apache2/sites-available/ virtual hosts sudo a2ensite <name> / sudo a2dissite <name>

/etc/apache2/mods-available/ modules sudo a2enmod <name> / sudo a2dismod <name>

/etc/apache2/conf-available/ configuration fragments sudo a2enconf <name> / sudo a2disconf <name>

List what is turned on:

sudo apache2ctl -S 2>/dev/null | head -3 sudo apache2ctl -M 2>/dev/null | grep -E '^ (ssl|rewrite|headers|http2|proxy|proxy_http|mpm_event)_module' ls /etc/apache2/conf-enabled/

apache2ctl -S lists the two SecureAnyCloud virtual hosts, *:443 from 000-sac-ssl.conf and *:80 from 000-sac.conf. The module list shows headers, http2, mpm_event, proxy, proxy_http, rewrite and ssl, and conf-enabled includes zz-security-sac.conf.

After any change, test the configuration, then reload Apache. A reload drops no connections:

sudo apache2ctl configtest
sudo systemctl reload apache2

configtest prints Syntax OK when the configuration is valid.

To serve a domain from its own directory, give it a virtual host. Replace example.com with your domain:

sudo mkdir -p /var/www/example.com echo '<h1>example.com</h1>' | sudo tee /var/www/example.com/index.html
sudo tee /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF' <VirtualHost *:80> ServerName example.com ServerAlias www.example.com DocumentRoot /var/www/example.com <Directory /var/www/example.com> Options -Indexes +FollowSymLinks AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/example.com-error.log CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined </VirtualHost> EOF
sudo a2ensite example.com
sudo apache2ctl configtest
sudo systemctl reload apache2

Check it before your DNS points at the VM by sending the host name yourself:

curl -s -H 'Host: example.com' http://localhost/
curl -s http://localhost/

The first request gets the new site (<h1>example.com</h1>), and any other name still gets the default site in /var/www/html. Once your domain's DNS A record points at the VM's public IP, browsers reach the new site by name.

The proxy and proxy_http modules are already on, so Apache can pass requests to an application that listens on the VM, for example on 127.0.0.1:8080:

sudo tee /etc/apache2/sites-available/app.example.com.conf >/dev/null <<'EOF' <VirtualHost *:80> ServerName app.example.com ProxyPreserveHost On ProxyPass / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/ </VirtualHost> EOF
sudo a2ensite app.example.com && sudo apache2ctl configtest && sudo systemctl reload apache2 curl -s -H 'Host: app.example.com' http://localhost/

With an application answering on port 8080, the last command returns the application's response through Apache. Keep the application on 127.0.0.1 so it is reachable only through Apache, and leave its port closed in the network security group.

The first-boot certificate

First boot made this VM its own self-signed certificate:

sudo cat /var/log/apache-firstboot.log
sudo ls -l /etc/ssl/sac/
sudo openssl x509 -in /etc/ssl/sac/sac.crt -noout -subject -dates -ext subjectAltName
sudo openssl x509 -in /etc/ssl/sac/sac.crt -noout -text | grep -m1 'Public-Key'

The log shows the certificate being generated at first boot, the key sac.key is readable by root only (mode 600), the subject is CN = sac-apache with the names localhost, sac-apache and 127.0.0.1, it is valid for one year from first boot, and the key is Public-Key: (2048 bit). First boot runs once: a reboot keeps the same certificate.

Browsers do not trust a self-signed certificate and show a warning. Use it for testing only, and install a real certificate for your domain with one of the two options below.

Option A: a free Let's Encrypt certificate with Certbot

You need a domain whose DNS A record points at the VM's public IP, a virtual host with that ServerName (Step 7), and port 80 open to the internet (Let's Encrypt checks the domain over HTTP). Install Certbot and its Apache plugin from Ubuntu's repository:

sudo apt-get -q update
sudo apt-get install -y certbot python3-certbot-apache certbot --version

It prints certbot 2.9.0 on Ubuntu 24.04. Then request the certificate for your names:

sudo certbot --apache -d example.com -d www.example.com

Certbot's Apache plugin proves you control the domain, installs the certificate in an HTTPS virtual host for those names, and reloads Apache. The package also turns on certbot.timer, which renews certificates before they expire:

systemctl is-enabled certbot.timer
sudo certbot renew --dry-run

Option B: your own certificate

To use a certificate from your own certificate authority, copy the certificate (with its chain) and the key onto the VM, keep the key readable by root only, and point the HTTPS virtual host at them. The default HTTPS site reads these two lines:

grep -E 'SSLCertificate(Key)?File' /etc/apache2/sites-available/000-sac-ssl.conf

They read SSLCertificateFile /etc/ssl/sac/sac.crt and SSLCertificateKeyFile /etc/ssl/sac/sac.key. Change them to your files (or add the same two lines to your own *:443 virtual host), then run sudo apache2ctl configtest and sudo systemctl reload apache2.

curl -sI http://localhost/ | grep -i '^Server:' grep -hE '^(ServerSignature|TraceEnable)' /etc/apache2/conf-enabled/zz-security-sac.conf
curl -s -o /dev/null -w 'TRACE -> HTTP %{http_code}\n' -X TRACE http://localhost/

The header reads Server: Apache, with no version or operating system, the file shows ServerSignature Off and TraceEnable Off, and a TRACE request gets HTTP 405. The zz- prefix makes the file load after Ubuntu's own security.conf, so its settings win: keep the name.

The image was patched when it was built. Ubuntu security updates install automatically because unattended-upgrades is enabled. Other updates do not, so update a new VM before you put it into service, and update it regularly afterwards:

sudo apt-get -q update
sudo apt-get -y upgrade

Apache is an Ubuntu package, so Apache updates arrive this way too. Reboot if a new kernel was installed.

Everyday service commands:

sudo systemctl status apache2 --no-pager sudo systemctl reload apache2
sudo systemctl restart apache2
sudo tail -n 50 /var/log/apache2/error.log
sudo tail -n 50 /var/log/apache2/access.log

The default HTTPS site logs to error-ssl.log and access-ssl.log in the same directory, and Ubuntu's logrotate rotates the Apache logs. Before a big change, take a snapshot of the OS disk, and back up /etc/apache2/ and your sites under /var/www/.