I think this is what's going to drive the adoption of DNSSEC: free, DNS-validated SSL certs.

IPv6 should address the other problem - namely, that SSL certs are per-ip, not per-hostname, which makes hosting multiple sites a pain with IPv4. Or SNI could work, once Windows XP is truly abandoned.

Could you explain both those points in a bit more detail - I am a bit fuzzy this morning.

Historically, you can't serve multiple sites from one IP address (i.e. named virtual hosts) and use HTTPS. The reason for this is that the hostname of the site is included in the HTTP request from the client:

  HTTP/1.1 GET /
  Host: mysite.com

By the time the server has decoded and read this header, you have presumably already started the secure connection, so the server has to have already selected which certificate to use for the session.

Workarounds are to have multiple IP addresses on your box with one cert per IP, or run the server on multiple ports with one cert per port. In both cases this enables the server to know which certificate to use from the underlying connection properties, and not wait for the encoded traffic to start arriving.

SNI (Server Name Identification) is an extension to TLS (Transport Layer Security) that essentially adds the hostname into the SSL negotiation, so this cert can be selected by the server in advance. It made it into OpenSSL implementations in the mid-2000s and is reasonably widely adopted.

Legacy libraries, Internet Explorer <=7, and Windows <=XP won't support it so it's not quite ready for mainstream use. Give it 5 years or so...

The sibling poster does a good job explaining SNI. The shorter version is that without SNI all you know when establishing the secure connection is the IP address, so you can't do name based virtual hosts.

I'm not an expert on DNSSEC, but the idea is that there is a chain of trust going back to the domain registrar. If a receive a signed DNS response, and everything verifies, then I know that it comes from the person who registered the domain. I can't add a signed entry for example.com, so if I received a signed DNS response for example.com, I know it ultimately originated (with possible caching like normal DNS) from whomever registered example.com.

You can then add what is essentially a TXT record to the DNS entries for a domain that is the fingerprint of an SSL cert. If you receive that as a valid dnssec response, you know it can be trusted.

Essentially the dnssec infrastructure replaces the CA infrastructure.

You can do the same thing with ssh key fingerprints too.

aha - I shall have to go read up on dnssec.

edit: cdjk - thank you - I have to edit-reply as there appears to be an increased time delay on replies. Maybe its me. Bought it.

I recommend DNSSEC Mastery, by Michael Lucas:

http://blather.michaelwlucas.com/archives/1640

It's not out yet, but an nearly-complete draft is available on leanpub (with updates once he finishes copy editing):

https://leanpub.com/dnssecmastery

edit reply: I think the thread is nesting to far...

gandi.net provides a single-address SSL cert free-of-charge for a year with a domain registration or transfer. See: http://www.gandi.net/ssl :)

For the first year, and only the first year. You shouldn't be smiling about the recurring fee.

Actually, they give it to you for the year when you renew as well. So if you renew yearly, you get a year ssl as well.

Also their basic SSL Cert is only about $16 USD. Very reasonable.