These HPKP instructions are rather dangerous (as in: more dangerous than they have to be).
The hash is for the ISRG root certificate, which is not widely trusted yet. While an ISRG-signed intermediate certificate is available, all clients currently default to the IdenTrust-signed intermediate, and even if you decide to use the other intermediate instead (or both, which most browsers can handle), that doesn't guarantee that browser build a trust path through that intermediate - it might have the other one cached from a different site. In other words, the second pin would almost never be satisfied, which means you're screwed once your private key is compromised or changes. Screwed as in your domain is bricked for up to 30 days with this max-age setting.
A slightly better approach would be to pin to both the ISRG and the IdenTrust root[1], plus your private key and a couple of backup keys that you keep offline. One or two backup pins to other CAs couldn't hurt either. Oh, and best run with Report-Only for a while.
This is rather overly complicated and should only be used for test domains you do not care about.
Much easier and very effective is to use the apache2 or nginx config file options to manually disable sslv3, tls1.0 and tls 1.1. Permit only TLS 1.2. If you want to, manually specify the preferred order or crypto.
Any modern browser supports TLS 1.2 just fine. I've done this for every httpd I admin and it has had no effect on reachability.
How are you measuring the effect on reachability? My companies network filter can't seem to understand cloudflare certs with their 50+ other domain names in there, and so clients can't connect. If you have HSTS on you can't even fall back to http. So without a phone call to IT to our provider, people just aren't going to that site.
But what if it's not enabled? We see traffic from newish IE browsers that have TLS 1.1 and 1.2 turned off. We actually got user complaints that one of our sites stopped working when we turned off TLS 1.0.
I have no idea why they would be set up that way, but it's clearly out there.
Maybe when it initially shipped, but unless somebody has been absolutely ignoring all the last 6 years of updates, the version of IE that comes with Win7 is very much TLS1.2 compatible.
According to `pacman -Fys service`, Arch does not ship the service(8) forwarder script, so you can only use systemctl(8). I've seen service(8) on at least RHEL and SLES, though.
The hash is for the ISRG root certificate, which is not widely trusted yet. While an ISRG-signed intermediate certificate is available, all clients currently default to the IdenTrust-signed intermediate, and even if you decide to use the other intermediate instead (or both, which most browsers can handle), that doesn't guarantee that browser build a trust path through that intermediate - it might have the other one cached from a different site. In other words, the second pin would almost never be satisfied, which means you're screwed once your private key is compromised or changes. Screwed as in your domain is bricked for up to 30 days with this max-age setting.
A slightly better approach would be to pin to both the ISRG and the IdenTrust root[1], plus your private key and a couple of backup keys that you keep offline. One or two backup pins to other CAs couldn't hurt either. Oh, and best run with Report-Only for a while.
[1]: https://www.identrust.com/certificates/trustid/root-download...