SSL woe
I wasn't thinking about the fact that SSL encapsulates HTTP. This means that a browser requested site's domain name isn't visible in an incoming SSL connection initialisation and the server side. So the web server can't do name based virtual hosting and have separate SSL certificates per virtual hosts' domain...it wouldn't know which certificate it should have used until after it picked on. So I apparently can only have one of multiple domains served off my box not give a browser domain name mismatch warning.
That's annoying. I wonder why the browser then doesn't do something like get the IP of the domain listed on the server's certificate and compare it with the IP of the domain requested? SSH is okay with multiple keys per server.
Yeah, I have the same problem for my server. But IPs change, and IPs can be owned by different people. The WHOIS database indicates the one person or entity that owns a domain name. So, when you get a certificate authorized, they can check that you really should be able to have an authorized certificate for that domain. In other words, I can't end up with a certificate for www.amazon.com just because I happened to have that host IP before.
So there currently is no IP address included in part of an SSL certificate. SSH doesn't have multiple server keys either, at least per sshd instance. You can have multiple personal keys, but SSL allows that too. Personal certificates.
What I'd intended to say was that SSH is fine with multiple IP's (and implicitly names for those IP's) for a single key, which is what I'd like SSL to do. But I guess with SSH, you have a certain amount of implied trust that the key you've negotiated is correct and SSH asks you if you want to trust the key and add it to your keyring. SSL is instead trying to set up a trust hierarchy. But then again that's totally bogus too, because an SSL key's trust level is associated primarily with the amount of money paid for it today.
I liked PGP's web of trust model, but that's combersome to implement.