[majewsky]

Wildcard certs should help with that. Also, the limit is only on certs, not on domains. If your process allows for issuing a single cert for 100 domains, that also solves the problem. (There is a limit on SANs per cert AFAIK, but I don't have the exact number.)

[viraptor]

If you're dealing with a large scale deployment that involves many endpoints (and not just subdomain-per-user scenario), there are good reasons not to use a wildcard. Other CAs will definitely stay in business there.

[gregmac]

> there are good reasons not to use a wildcard.

Such as?

[viraptor]

Example: Imagine Microsoft giving anyone "(wildcard).microsoft.com" just because they have a lot of services to deploy and don't want to deal with separate certs. Now, breaking into that service means you can mitm windows updates for anyone and they can't tell a difference.

You want to limit the exposure of your certificates, you don't want 50+ teams to share credentials/certs (they're effectively public at that point), and you want to make sure that if you need to revoke the certificate right now, you know you're impacting as few endpoints as possible.

[ivanr]

To add to this, there's potentially a similar security problem if you have a bunch of systems with different certificates sharing the same TLS session caching backend or session ticket keys. It doesn't allow any one system to impersonate another, but they can perform active and passive network (MITM) attacks.

For server-side caching, some systems now take into account SNI hostname and use it to prevent contamination. If you're in this situation, it's worth looking into how exactly your backend works.

[lucaspiller]

It is possible to get a certificate that allows to sign other certificates on your domain? For example you call Verisign and they issue a cert for *.mycompany.com, then you use that to sign another certificate for accounting.mycompany.com?

[viraptor]

Yes and no. If your company is worth a few million dollars, can get high enough insurance, can get FIPS certified, and can jump through enough hoops, then yes - you can get an intermediate certificate. That product is not even openly advertised by most CAs. If you're just a "normal company", no, you won't get one.

https://translate.googleusercontent.com/translate_c?depth=1&...

The big problem here is that the intermediate CA isn't really limited on what they can grant. You can issue a valid "google.com" cert just as well as "foo.yourcompany.com". The are x509 extensions for limiting the scope in this case, but I don't believe they're widely used or validated at the moment.

[tialaramex]

Being able to issue certificates makes you a CA, in this case a subCA. It requires a particular kind of certificate which has CA:TRUE set, usually this property of a certificate isn't present and it defaults to CA:FALSE.

This used to be not that big of a deal with hundreds of larger companies having subCAs but the rules have tightened up considerably. Apple and Google have them under one of the Symantec roots, but a lot of older ones have been deactivated. The reason is that the root CA is responsible for ensuring you're doing as good a job of issuing as they would have, since they're effectively "sponsoring" your issuance, promising you're doing it right, and that costs money. As a rule of thumb if your organisation doesn't have an actual full-time role sorting out all the certificates, you won't find it cheaper to have any subCA status. "But I spend like an hour every week doing it" is not a full-time role.

The cheapest option if you do have a subCA is a constrained subCA that's hosted. In this scenario the CA:TRUE certificates says inside it that it is only valid for certain hierarchies and mustn't be trusted outside those, this is called a "constraint". The root CA has to make sure such a subCA is properly looked after but they can do this internally themselves, so they'll want it on their server premises, not in your DC or under somebody's desk, where they can vouch for its security.

A more expensive option is still hosted but without the constraints. In this case the subCA can issue any certificate, but it does so under direct supervision of the root CA operator, often using only IT built by them. So e.g. there's a web site, you sign in, you tell it what certificates you want and then _they_ check that's OK before using "your" subCA to issue. The root CA has to do lots of extra paperwork for this scenario, but it's not so bad because they need most of the same things for their existing business, they get a sort of economy of scale on the audits, lawyers, building security etcetera.

The most expensive is on-premises unconstrained. In this case you have no limits. And so you also have to obey all the same rules as the root CAs do. This means third party auditors have to visit as witness to various routine activities, and their audit reports including adverse findings must be submitted to your root CA and to the major trust stores as a requirement of their trust. You will need a dedicated, physically secure building to house the hardware security module of the CA function, with properly trained staff following documented procedures, "No Lone Zone" policies, all that jazz. This can definitely cost a million dollars per year to sort out _before_ you pay anybody to let you do it.

Also by the way "Verisign" you're thinking of, the root CA, was sold to Symantec, who are now selling to DigiCert and the Verisign roots are to be distrusted (which is part of why Symantec are selling, they destroyed trust in these roots through a poorly managed approach to the business).