Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

up vote 3 down vote accepted

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

share|improve this answer

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.

share|improve this answer
    
To my surprise, I found out we already have about 8 IPs –  Bart van Heukelom Feb 24 '10 at 22:51
    
Well, that should cover you for 6 domains at least! (1st and last are usually unusable) –  Mark Henderson Feb 24 '10 at 23:31

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.)

share|improve this answer
    
I know about wildcard certificates but they're not enough. I mean entirely different domains, e.g. example.com and freebeer.org I'll look into SANs –  Bart van Heukelom Feb 24 '10 at 22:41
    
Why the downvote? I did point out about the cross-domain names, and I believe this is the main reason why SANs were devised. –  Andy Shellam Feb 24 '10 at 23:02
    
FYI: Not my downvote :) –  Bart van Heukelom Feb 24 '10 at 23:11

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.