Most low-cost SSL certificate providers really only verify that you control a domain name. For those types of certificates, rather than pay a third party to verify that I control the DNS records for the domain, why not "sign" the certificate in DNS? If I generate a keypair on a server and publish the same public key in DNS for the hostname, I'd think that would be an equivalent level of security.
I see two problems with the design, but both seem minimal:
- EA certificates and the higher-level certs that verify personal/corporate details can't be done this way. Organizations wishing to pay to get the green bar in browsers are free to continue doing so.
- A malicious network with rogue DNS servers could redirect you to both a different hostname and a different trusted SSL certificate. Perhaps DNSSEC could take care of this repudiation problem?
I'm not aware of any browsers implementing something like this, but it seems like it would be a good method to at least get a trusted, encrypted connection without displaying the dreaded "Untrusted certificate" dialog. Aside from the issues I noted above and existing commercial certification authorities fighting the idea, are there any other reasons doing this would be a bad idea?
Best Answer
It's already perfectly possible to encode an X.509 certificate inside a DNS Record - look at the
CERTrecord type from RFC 4398.The main reason it's not being done in anger much is because the transport mechanism isn't yet secure. This will change dramatically later this year when the root zone gets DNSSEC signed and as more and more TLDs support DNSSEC.
DNS query size (as mentioned elsewhere) is also a concern, although it's worth noting that the
CERT RRalso allows you to simply store the URL from which the real X.509 certificate can be downloaded. At this point there's something of a chicken and egg problem, though...