Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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,,... 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
up vote 5 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 "*" will be good for "", "", 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
So just double checking. If I could issue certificates only for subdomains then I wouldn't be a threat to any CA. But, from what you're saying there's no technical solution that would allow me to do only that (issue only certificates for subdomains). Instead my only option is to effectively be a CA for $$$$$$$$. In particular I need to implement this solution but for an open source project (ie, no $$$$$$$$$) – gman 18 hours ago

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
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
@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
@johndodo The Word of God on affiliate links is no. – Gilles Aug 7 '12 at 9:19
@ScottChamberlain but beware that a certificate marked as non-exportable can still be exported. See for instance… – Brian Minton Nov 18 '14 at 14:36

Your Answer


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.