The issue we've run into with Let's Encrypt, is that they have a limit on the number of new (non-renewal) certs in a time period, grouped by high-level domain. So, for example, when you have lots of separate groups running sites until a common domain (groupa.example.com, groupb.example.com), you often hit the new-issuance limit, and have to wait.
So, I expect existing CAs (and groups like InCommon) will continue to be around to serve large entities.
I don't know how helpful we can be, but we (and other companies like ours) have much higher Let's Encrypt limits. If it'd make your life better send me an email and we'll help you out.
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.)
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.
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.
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.
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?
They won’t ever offer > 90 days, but certificate lengths of about a day would certainly be interesting. I’d certainly switch to 24h valid certificates as soon as possible.
Ideally even separate certs for every subdomain, but as Let’s Encrypt has cert limits, and I want to avoid SNI in the future, I’ll probably have to use wildcard certs.
I don't trust client clocks (or x.509 not before checking) enough to use certs until they've aged at least a couple days; a week is best, if I can manage. 24 hour validity would shut out a lot of people with computers or phones that can't keep time (or choose not to)
Certificates are usually issued back-dated by one hour. Most clients on the Internet are correct +/- 60 minutes, because of a mixture of small timezone errors, daylight saving being wrongly observed / not observed / not updated and similar. It is rare for clients to have the wrong date.
Back dating with a technical rationale (e.g. to work around crap clocks and historically as a way to hide more entropy near the start of the signed certificate) is accepted in the Web PKI, it is only forbidden to use back dating to try to dodge Baseline Requirements, for example back dating to avoid the restriction on SHA-1 after 2015 was prohibited and is one of the things StartCom / WoSign were caught doing.
In what sense? An attacker can already see the endpoints of a TLS conversation, and worrying about hostname disclosure is security through obscurity; the client already divulged the destination hostname with a probably-cleartext DNS query, too. Not worth worrying about. SNI is fine. If hostname disclosure is a security threat, the system needs rearchitecture.
Systems that hostname their customers (mycompany.example.com) should use wildcards for that scenario instead of SNI, among other reasons. That’s the only possible concern I can imagine.
Wildcard certs work only 1 level deep. If you introduce regions and stages or other dimensions you would need multiple wildcard certs to cover e.g. SVCa.teama.region.example.com
Multi domain certs help but then you need to encode all the names ahead of time and if you miss a name you need to reissue and reapply the cert.
So, I expect existing CAs (and groups like InCommon) will continue to be around to serve large entities.