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

I'm pretty used to creating the PKI used for x509 authentication for whatever reason, SSL Client Verification being the main reason for doing it. I've just started to dabble with OpenVPN (Which I suppose is doing the same things as Apache would do with the Certificate Authority (CA) certificate)

We've got a whole bunch of subdomains, and applicances which currently all present their own self-signed certificates. We're tired of having to accept exceptions in Chrome, and we think it must look pretty rough for our clients having our address bar come up red.

For that, I'm comfortable to buy a SSL Wildcard CN=*.example.com. That's no problem.

What I don't seem to be able to find out is:

  1. Can we have our Internal CA root signed as a child of our wildcard certificate, so that installing that cert into guest devices/browsers/whatever doesn't present anything about an untrusted root?
  2. Also, on a bit of a side point, why does the addition of a wildcard double the cost of certificate purchase?
share|improve this question
    
CN=*.example.com - placing DNS names (like *.example.com) in the CN is deprecated by both the IETF and the CA/B Forums. Instead, place a friendly name in the CN like My Domain, and place DNS names in the SAN. There are some other rules that an operator must follow if they insist on putting DNS names in the CN. Recent version of Chrome (Sept 2014) will refuse to load the site if the CN contains a DNS name without following the additional rules placed by the CA/B Forums. Firefox will likely follow suit soon. (Browsers follow CA/B Forum policies; and don't honor IETF policies). –  jww Oct 7 at 1:28
    
"subdomains... currently present their own self-signed certificates. We're tired of having to accept exceptions in Chrome" - Chrome has probably stopped accepting them (Sept 2014). You need to have the server certificate signed by a CA. Its OK if its a private CA. But no more self signed certificates. –  jww Oct 7 at 1:34

2 Answers 2

up vote 5 down vote accepted
  1. Nope - the constraints placed on the wildcard cert will not allow for it to be used as a CA in any way, shape, or form, to grant trust to another certificate (or authority) in your control. Check the x509 Basic Constraints field; it probably contains CA:FALSE.

  2. Because that's good business. The economics of SSL certificates are questionable; the only cost to the provider is staffing and infrastructure overhead and potential staff time to confirm the identity of the party requesting the certificate.

    They'll take any chance they can get to increase their already rather imaginary fees along with a perceived increase in value to the customer - a wildcard cert provides a great opportunity to boost the margins, though these certs do generally receive more thorough validation than a basic certificate.

share|improve this answer
    
"They'll take any chance they can get to increase their already rather imaginary fees along with a perceived increase in value to the customer" - Haha! (but so true). Peter Gutmann calls it PKI-me-harder. –  jww Oct 7 at 1:33

Can we have our Internal CA root signed as a child of our wildcard certificate...

Wildcard certificate can only show up in end entity certificates if everything is working as intended or expected. And they will only show up in the "lower level" end-entity certificates, such as domain validated; and not the "higher level" extended validation certificates.

If everything is working as intended or expected, an end-entity certificate will lack keyCertSign keyUsage (and cRLSign), so it won't be able to act as a CA root and anchor a chain of trust. You won't be able to countersign anything with an end entity certificate.

This distinction between different levels or classes of certificates is touched upon below, but you are encouraged to read two chapter's from Peter Guttman's Engineering Security. Specifically, see Chapter 1 and 8 (IIRC).

CAs can sign other CAs (there's some hand waiving here, no stones, please). That's called countersigning, and its used to bridge different PKIs. For example, US Federal uses bridges to allow Treasury to consume certificates from the State department (etc).

Bridging is slightly different use case than what's used under the typical Browser model. In the browser model, cross-signed certificates are not used; rather 100's of root and intermediate certificates are pre-installed and trusted for the same effect (and more!).

Finally, the rule that "EV Certificates cannot have Wildcards" comes from the CA-Browser (CA/B) Forums. The CA/B have two guides that participating CAs and Browsers follow, and the rule is from the extended guidelines.

Taking from the extended guide, page 15:

9.2.2 Subject Alternative Name Extension

Certificate field: subjectAltName:dNSName

Required/Optional: Required

Contents: This extenstion MUST contain one or more host Domain Name(s)
owned or controlled by the Subject and to be associated with the Subject’s
server. Such server MAY be owned and operated by the Subject or another
entity (e.g., a hosting service). Wildcard certificates are not allowed
for EV Certificates. 

so that installing that cert into guest devices/browsers/whatever doesn't present anything about an untrusted root

No. The user would have to install it as a trust anchor. For example, as a "Trusted Certifcate" in a certificate store. Simply providing it as an end-entity certificate should have no effect.


Also, on a bit of a side point, why does the addition of a wildcard double the cost of certificate purchase?

To preserve profit levels.

Extended Validation certificates are another trick used to restore profit levels to a place in time before the race to the bottom destroyed confidence and profits. Taking from Peter Guttman's Engineering Security, pp. 63-64 (Guttman calls it "PKI me harder"):

The introduction ... of so-called high-assurance or extended validation (EV) certificates that allow CAs to charge more for them than standard ones, is simply a case of rounding up twice the usual number of suspects - presumably somebody’s going to be impressed by it, but the effect on phishing is minimal since it’s not fixing any problem that the phishers are exploiting. Indeed, cynics would say that this was exactly the problem that certificates and CAs were supposed to solve in the first place, and that “high-assurance” certificates are just a way of charging a second time for an existing service. A few years ago certificates still cost several hundred dollars, but now that the shifting baseline of certificate prices and quality has moved to the point where you can get them for $9.95 (or even for nothing at all) the big commercial CAs have had to reinvent themselves by defining a new standard and convincing the market to go back to the prices paid in the good old days.

This deja-vu-all-over-again approach can be seen by examining Verisign’s certificate practice statement (CPS), the document that governs its certificate issuance. The security requirements in the EV-certificate 2008 CPS are (except for minor differences in the legalese used to express them) practically identical to the requirements for Class 3 certificates listed in Verisign’s version 1.0 CPS from 1996. EV certificates simply roll back the clock to the approach that had already failed the first time it was tried in 1996, resetting the shifting baseline and charging 1996 prices as a side-effect. There have even been proposals for a kind of sliding window approach to certificate value in which, as the inevitable race to the bottom cheapens the effective value of established classes of certificates, they’re regarded as less and less effective by the software that uses them...

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.