I was asked to deliver a signed SSL certificate for an IIS server for a client. I have previously done this for the same client/domain before, so it start to seem like an unnecessary expense to hold multiply certificates for different subdomains.

Godaddy charges around $250 for a single SSL certificate with 5 year duration.

I then started to consider a wildcard certificate, but this seem a bit unsafe as the result of a single compromise would have a worse outcome.

That makes me wonder, why there is nothing called Domain CA?

A Domain CA could be signed by a Root CA, and have the possibility to generate Subdomain certificates?

It seem logical to me, but this does not exist, and I wonder why. Do anyone here with a clearer insight understand why no such thing exists?

  • 2
    It makes sense to look around the web a bit further. There is at least one CA that offers valid server certificates free of charge. Nov 3, 2011 at 6:41
  • 1
    You should also check out certificates in DNS called DANE. It's an up and coming standard and allows you to publish keys in DNS for free Jan 6, 2013 at 21:34
  • @makerofthings7 Thanks, this looks like good news! Jan 8, 2013 at 8:06
  • @HendrikBrummermann, Free of charge... for a limited time period.
    – Pacerier
    May 22, 2015 at 11:25
  • @pacerier all CAs only offer certificates that are limited in time before they need to be renewd. There is no difference in principle between free and paid certificates. Except that I am only aware of free certificates that need to be renewed after one year but the are paid certificates that are valid for up to 5 years. May 22, 2015 at 12:29

2 Answers 2


In the X.509 standard (I am linking to RFC 5280 which is nominally an X.509 profile but it contains a workable copy of X.509 itself; the true X.509 standard is not free), a "Domain CA" exists. Specifically, this is a CA certificate which contains a Name Constraints extension of type "dNSName". See section, which contains this paragraph:

DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not.

which is exactly what you are looking for.

Now the trick is to get an existing recognized root CA (i.e. a CA which can emit certificates which Average Joe's Web browser will accept without any scary warning) to sell you such a certificate. Remember that the business model of a commercial CA which charges you 250$ per server is to be able to keep on charging you 250$ per server; since your goal is precisely to avoid giving them so much money, I guess that they may object, by, e.g., not signing your CA certificate.

Also, support of Name Constraints by existing deployed Web browsers might be a bit flaky. This is not the most widely used X.509 feature ever.

  • "Also, support of Name Constraints by existing deployed Web browsers might be a bit flaky" so what would happen when the constraint is not understood? Would that make me a universal CA?
    – curiousguy
    Jun 15, 2012 at 14:12
  • @curiousguy: if the "domain CA" relies on the Name Constraints to limit the power to a set of server names in a given domain, then yes, the CA is "universal" if the browser just ignores the Name Constraints. You can mark the Name Constraints as "critical" so that browsers which do not understand Name Constraints reject the certificate altogether -- but this relies on browsers actually enforcing the semantics of the "critical" flag, and existing browsers do not have a good track record in that respect either. Jun 15, 2012 at 22:19
  • So that means that some clients will refuse the certificate because they cannot process Name Constraints, a few will correctly process Name Constraints and accept it, and the others will disregard the Name Constraints as if it was a funny decoration and treat it as an intermediate CA, with the TLS client software author taking some of the blame, but most of the blame ultimately falling on the issuing CA (TLS client software author: "our software bug was not a problem until xxx signed this funny looking certificate")... I can understand that CA are not willing to sign these certificates.
    – curiousguy
    Jun 17, 2012 at 23:35
  • 1
    @ThomasPornin, This answer explain why the CA wouldn't sell domain certs for a high amount. They could sell it for $250 * 50 and make good money. Would then problem lie with implementations?
    – Pacerier
    May 22, 2015 at 11:27

As someone here mentioned this has a lot to do with "business model", but consider another angle. When a root CA issues a certificate (intermediate or otherwise) they are ostensibly on the hook for maintaining a CRL for all of the certificates under their root CA. While a wildcard certificate allows you to use one certificate for infinite servers, a domain CA would allow you to create infinite certificates under your very own intermediate CA. A root CA would likely consider this untenable given their business model, and the fact that you aren't going to pay them infinite units of currency.

  • Thanks for the comment. I do not quite buy the CRL argument, as a root CA still should be able to break the chain by revoking the wildcard/domain-ca certificate. May 26, 2014 at 14:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .