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 '11 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 '13 at 21:34
  • @makerofthings7 Thanks, this looks like good news! Jan 8 '13 at 8:06
  • @HendrikBrummermann, Free of charge... for a limited time period.
    – Pacerier
    May 22 '15 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 '15 at 12:29

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 '12 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 '12 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 '12 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 '15 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 '14 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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