It's possible to determine whether a client supports certificates using SHA-2 by analyzing the ClientHello and use that to switch between a SHA-1 and SHA-2 certificate. CloudFlare[1] and some of the bigger sites like Facebook have done this.

[1]: https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...

And here's the technical detail of how we do it: https://blog.cloudflare.com/tls-certificate-optimization-tec....

Is there actually an open source implementation of this though?

I've looked, but never found one, though that was quite some time ago. Perhaps things have changed.

This approach is beyond the ability of most to implement for themselves if they don't have support from their webserver for it.

You can do it with HAProxy by checking for SNI and falling back to a SHA1 cert when the extension is absent. https://jve.linuxwall.info/blog/index.php?post/2015/10/04/SH...

A recent combination of Apache and OpenSSL has support for certificate switching based on key algorithm. You can serve an ECDSA+SHA2 certificate to clients that support ECDSA, and an RSA+SHA1 certificate to clients that don't. I'm pretty sure that all clients that reject SHA1 support ECDSA, so this should work.

You serve them a SHA-2 certificate. (In TLSv1.2 the client's supported hash algorithms are included in the handshake. Clients that don't support TLSv1.2 are probably fine with SHA-1. You can also use heuristics based on the ciphersuite to determine whether a client should get a SHA-1 certificate or not.)