I refer you to RFC6698, DANE TLSA: https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/rfc6698 In actual use, it works like this: • You implement

I refer you to RFC6698, DANE TLSA: https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/rfc6698 In actual use, it works like this: • You implement DNSSEC (easier when it's done automatically; going forward, my proposal is that every DNS registrar must support DS records in order to renew their registrar licence - adapt or die: I'm looking especially at you, Namecheap) • You publish a TLSA record • This contains a hash of a certificate's public key (other options are available, like hashing the whole certificate, or even including the whole certificate, but this is the most sensible one) and a pinning mode, one of: - 0: CA Constraint - Certificate must be trusted by browser, AND this particular CA must sign it - 1: Service Certificate Constraint - Certificate must be trusted by browser, AND it must be this particular certificate - 2: Trust Anchor Assertion: This particular CA must sign the certificate - 3: Domain-Issued Certificate: It must be this particular certificate Basically, this is a way to 'pin' certificates to DNSSEC, either additionally (0,1) or instead of (2,3) the PKIX CA system. Already implemented in Chrome as a test but taken out because no-one used it - it can come back. If clients implement it, we can replace/augment the CA system as necessary. You're welcome.