Otdfbt

We're going to have to temporarily shutdown our servers, as they need to be physically moved and put onto a better UPS.

I don't want to just have "can't connect" errors come up for our users, and I have another smaller server box that I thought could display a "maintenance mode" message.

Reassure them that this is scheduled maintenance - so they're not panicked that we've disappeared or anything - give them a time for when everything will be back up, apologise for the inconvenience. That sort of thing.

For HTTP, this is easy to set up. I create the "maintenance mode" HTML page and then have it that the default virtualhost - the catch all - shows this page upon any request made to the server.

So that any HTTP links to any of the virtual hosts on our servers will match this and show the temporary "service unavailable" message.

But HTTPS has me a little stumped, because the host name has to match the SSL certificate to avoid the browser throwing up security warnings.

What I want is a default SSL "catch all" that'll match any host name - because none of the virtual hosts are actually up on this temporary server - and then redirect to the HTTP maintenance message.

I gave this a go:

<VirtualHost *:443>
 ServerName catch-all
 ServerAlias *
 RedirectMatch ^(.*)$ http://%SERVER_NAME/
</VirtualHost>

But I'm getting "the site can't provide a secure connection" in Chrome (ERR_SSL_PROTOCOL_ERROR) and curl is complaining about "ssl wrong version".

I need it so that if someone follows a HTTPS link to something on our servers, it's all redirected to the HTTP "maintenance" page.

Can a server "cancel" the SSL handshake and redirect to HTTP like this?

Use the existing certificates of the services to set up name based virtual hosts, with document roots containing the outage messages. TLS Server Name Indication support allows you to have different SSL configuration directives, including different certificates, per vhost.

If such outages are a problem for your organization, consider removing single points of failure from your design. Web servers in different racks, behind a clustered load balancer, all with dual power supplies on different circuits, remote hosted outage messages. This can get expensive, so choose the redundancy appropriate for your service availability objectives.

Technically your issue could be solved using a wildcard certificate (*.domain.com). It may be possible to manually generate one using the Let's Encrypt DNS certificate request method (https://letsencrypt.org/how-it-works/) even if your DNS provider doesn't provide an API that can be used for automatically creating TXT records as required for long-term use.

As for your suggested workaround:

If you are using the HTTP Strict Transport Security header (HSTS) - which you really should - then client browsers will refuse to acknowledge a HTTP-only site that turns up in lieu of a previously known HTTPS one; so that shouldn't be a valid option.

Following HBruijn and John Mahowald's advice, I'm just going to set up the virtual hosts on the outage server with their respective SSL certificates, but all with a "DocumentRoot /var/www/html" to serve the maintenance page.

This is more work - which I'd hoped to avoid by a "catch all", as every single virtual host will be serving the exact same content - but SSL doesn't easily permit that.

And I was also thinking that, in future, should this be needed again and we have more virtual hosts then the "catch all" idea would have kept on working, without me having to manually add any new virtual hosts to the outage server each time.

If it were possible, then it would have made more sense. But it's not, because of how SSL works, so I'll just have to do it all manually.

Well, hopefully, the outage server will rarely, if ever, be called on again.