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}/

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?

  • 1
    The problem is essentially that SSL connection needs to be successfully established before you even can sent HTTP protocol messages. That requires that your temporary server has valid certificates for all URL's that you use - in which case you won't need to redirect to http any more and can simply sent a pretty 503 response over https – HBruijn Apr 8 at 12:58
  • You already have an SSL certificate, just use that! – Michael Hampton Apr 8 at 13:25
  • @HBruijn Yes, it looks like I'll have to recreate all the virtual hosts on the outage server, using their respective SSL certificates, and have them all use the same "DocumentRoot" instead. I was hoping to avoid that, as we have a good dozen vhosts to cover but I guess SSL means it's the only way. – Bob Apr 8 at 15:35

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.

  • We do have multiple web servers behind a load balancer - and I've set up link aggregation for all network links (except for the dedicated symmetric fibre optic line coming from our ISP, but we have an SLA on that, guaranteeing service or they owe us money per hour it's down), plus each service (web, email, cloud) is separated onto different storage servers. – Bob Apr 8 at 15:17
  • The server box in question is to be the remote hosted outage message (but I have to set that up). Basically, I've been removing single points of failure as much as I can. This outage, ironically, is part of that - the whole server cabinet needs to be physically moved to put it all onto proper UPS. I've done as much as I can to eliminate single points of failure within the constraints of the budget I'm given. – Bob Apr 8 at 15:24
  • Definitely, sometimes improvements require a maintenance window. Your question wasn't clear you had a load balancer and multiple app servers to work with. If those span racks and/or power feeds, you might be able to fail over with minimal downtime. But sometimes you just don't have the redundancy, which is fine for many services. – John Mahowald Apr 8 at 17:38
  • Yeah, they don't currently span power feeds sufficiently to avoid some shutdown. That's the underlying point of the move, to fix this situation. Basically, the cluster has been gradually added to in an ad-hoc way - as it has slowly funded its own expansion - but this has left some earlier choices, done to just make things initially work, now inadequate going forward. I regret the shutdown - the first we've ever done in a few years of operation - but it's to re-jig things so that it should never be needed ever again. – Bob Apr 10 at 3:58

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.

  • I have a wildcard for our own domain name's services, but we also host some websites with completely different domain names, so our wildcard won't cover those. And, yes, our cloud service (via Nextcloud) does use HSTS, so it won't be a valid option. – Bob Apr 8 at 15:30

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.