Our organisation is planning to add HTTPS to our sites. Because our server has only one IP (which means we can only use one certificate) we need a certificate that is valid for all sites in our organisation which have various domain names. The certificate should therefore not contain a domain name.
Are they technically possible, do CA's sign those, and how do browsers handle them?
You can't get an X.509 cert that doesn't have at least one subject principle name (the domain) specified. No useful CA is going to let you have a certificate without one that can be tied to a domain that you can demonstrate that you own. They can be wildcarded at the level that you "own" it so site1.domain.com, site2.domain.com etc are fine but site1.domain2.com wont be.
The alternative is to use Subject Alternate Names or SAN [capable] certs, these can contain a range of additional names (of various types) provided your cert provider is prepared to add them that is. For your use case they can be FQDNs for specific sites within a domain (site1.domain.com, site2.domain.com etc), FQDNs for other domains (site1.domain2.com, site1.domain.net). They can be used to add additional types of identifier depending on what you want to do, including ip-addresses however I don't know how widely supported these additional capabilities actually are. The number of SAN identifiers you can include also varies by certificate provider, Verisign allows for 19, while Digicert will support up to 150 for example.
From the OpenSSL documentation:
The subject alternative name extension allows various literal values to be included in the configuration file. These include email (an email address) URI a uniform resource indicator, DNS (a DNS domain name), RID (a registered ID: OBJECT IDENTIFIER), IP (an IP address), dirName (a distinguished name) and otherName.
The email option include a special 'copy' value. This will automatically include and email addresses contained in the certificate subject name in the extension.
The IP address used in the IP options can be in either IPv4 or IPv6 format. ... subjectAltName=email:copy,email:my@other.address,URI:http://my.url.here/ subjectAltName=IP:192.168.7.1 subjectAltName=IP:13::17 subjectAltName=email:my@other.address,RID:1.2.3.4 subjectAltName=otherName:1.2.3.4;UTF8:some other identifier
Yes - they're called wildcard SSL certificates but they only count for a single domain (*.domain.com.)
Newer certificates can also contain SANs (subject alternate names) within the certificate which I believe allows you to cross the domain name boundary (i.e. one certificate for www.domain.com and www.domain2.com.)
No. SSL Certificates are bound by their Common Names (CN), and CN is tied to a Domain Name, not an IP address.
Unfortunately there's no choice except to ask for a bunch of IPs. Most ISPs will give you a additional block of 4 (2 usable) for no additional cost on a business plan.
Contrary to popular belief it is now possible to have many SSL sites with different names on the same IP address, but it requires that both the server and the client applications support SNI (see http://en.wikipedia.org/wiki/Server_Name_Indication for info).
Lack of support in some clients (most notably IE6, and IE7/8 if run on Windows XP) is the main reason not to use SNI, but if this would not affect your userbase significantly it may be worth considering. Firefox has supported SNI since version 2, and IE7 & IE8 support it under Vista/2003/2008/7 (see the Wikipedia article linked above for more client support detail).
Another problem if your servers are Windows based and serving HTTP(S) via IIS is the lack of support in IIS - but you could get around this by installing lighttp or nginx as a reverse proxy to the real http(s) daemon (IIS).
You will still need a separate certificate for each FQDN, or at least a wildcard certificate for each group of names, of course - but it does reduce the number of IP addresses you need allocated which will be a GoodThing(tm) if these are a scarce (or otherwise expensive) resource where your server is located.
