Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

We are making a web-based application that will be installed in intranets as a virtual machine image (we send the user a CD with the virtual machine image, user runs it in a VMWare/VirtualBox/...).

We want to protect the application frontend by using HTTPS. We thought about getting a single certificate (issued by some known CA) for domain app.ourdomain.com and installing it on all instances, but that obviously means that one could take apart an installation, take out the private key and make a man in the middle attack on some other installation (provided he had access to its network). While this is an unlikely scenario, we would still like to avoid taking the risk.

Is it possible to get a wildcard certificate that would allow us to sign our own subdomains, so that we could issue certificates app1.ourdomain.com, app2.ourdomain.com,... and they would be accepted by users browsers? (we have no control over users' browsers) If yes, how are these certificates called?

If not, is there some other way we can protect the users from one another?

UPDATE: I have since found a similar question on serverfault so it seems it is technically possible, but "you hardly will find any CA willing to provide you with such a certificate". I would still love to know if there is a CA that issues such certificates?

share|improve this question
    
If you want to avoid MITM from each node and have user browser recognition, this doesn't work this way with the public CAs as it's insecure because it validates only single company. If you want to handle several companies in different locations, you need separate certificates. –  Andrew Smith Aug 7 '12 at 22:03
add comment

2 Answers

up vote 4 down vote accepted

Wildcard certificates, i.e. certificates which contain a name with a "*" in it, are not a solution for you. A wildcard certificate is a certificate which clients will accept as "matching" several server names: a certificate which contains "*.example.com" will be good for "foo.example.com", "bar.example.com", and so on. This is precisely what you do not want: you do not want the private key and certificate contained in one instance of your product to be good for another instance with a distinct name.

To achieve what you are trying to do, you need to obtain a CA certificate, marked as such with a Basic Constraints extension with the cA flag set to TRUE. This would allow you to issue certificates yourself, and the certificates would still link up to the root CA from which you obtained your own CA certificate.

Existing, deployed CA can sell you such a certificate, but it will be expensive:

  • The existing CA has a business model which sums up as "selling lots of individual certificates". If you produce many certificates without the help of the CA, then it is losing business... and will want to get its money back.

  • That existing CA has one huge asset, which is that its root public key is included in the Web browsers and operating systems of the whole world. OS/browser vendors accept to do that only if the CA offers strong guarantees that it is serious and will issue certificates only to duly identified entities. When such a CA delegates this issuance power to a sub-CA, it tends to require the same level of seriousness. So you would need some rather strong hardware (HSM in a bunker) and heavy procedures.

In a past life, I did such a deal with GlobalSign. Is was about 10 years ago, I don't know if they still offer such deals.

Another strategy is to let your customers deal with the issue. Document how to push a certificate and key in the application, and you are done. Some customers will use their own CA (you do not have control over the browsers of the users, but the customer might have such control). Some will buy a certificate elsewhere.

Anyway, you need to allow for such a manual certificate configuration, if only to allow renewal when the certificate expires.

share|improve this answer
add comment

I don't believe there is any way to do this unless you want to pay large amounts to a CA to have them issue one that can sign any domain. My advice just buy a standard SSL for each of them, they cost about $10 a piece. You can get one at Namecheap for about $8.00. Also globessl for a few cents more.

share|improve this answer
1  
Just a quick factoid, from the same provider linked a wildcard certificate costs around $85-$91 so if you have more than 9 sub-domains to do then it would be cheaper to get the wildcard. –  Scott Chamberlain Aug 6 '12 at 14:36
    
@ScottChamberlain, but isn't that just one root certificate so you would have duplicates of it on each server? I may be mistaken though. –  Travis Pessetto Aug 6 '12 at 14:55
    
You are correct, you would deploy *.example.com on all of the servers (when you import it to the certificate store make sure that the private key is not exportable so if the server is compromised the cert is safe) then on each server you can associate the full name with the website. (if you can not set the name in IIS the friendly name of the cert must start with a * or it greys out the box, also common bug, if you get a error about it requiring the cert to be marked as exportable you loaded in to the wrong store. Load it to the machine store, not the user store.) –  Scott Chamberlain Aug 6 '12 at 15:00
2  
@TravisPessetto: BTW, if this is an affiliate link, it would probably be nice to flag it as such - I'm not even sure they are allowed at SE? –  johndodo Aug 7 '12 at 7:06
1  
@johndodo The Word of God on affiliate links is no. –  Gilles Aug 7 '12 at 9:19
show 1 more comment

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.