[gruez]

dumb question but, but why was oscp stapling invented when it's the same as short lived certificates? have the certificate's expiration date set to a short period, have the CA renew it regularly, and place it on some http server. then you can have some cron job that downloads the certificate and reloads your server. and since the certificates are short lived, the CA/browser vendors can mark them as being excluded from OSCP checks. all the benefits of OSCP stapling, without the extra implementation complexity.

[merb]

certificates costs money and the world was mostly manual in the past (and in a lot of places still is) you can still order a 3 year cert.

[yeukhon]

Also, many CA don’t provide programmatic way to order and to download cert. Another annoying manual step, especially consider having multi-domains not convered under a single wildcard.

Sadly let’s encrypt does not support wildcard... and support for intranet is controversial to thosr who want to keep their intranet “totally private”. I love the autobot. One command to generate new cert, another command to reload my Nginx.

[pilsetnieks]

> One command to generate new cert, another command to reload my Nginx.

Maybe this is what you meant but you can do it in a single command. For example:

    certbot renew --post-hook "service nginx reload"

[merb]

that works fine, until it doesn't... multiple servers

[JetSpiegel]

Let's Encrypt will support wildcards in January 2018.

[CaliforniaKarl]

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.

[mrkurt]

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.

[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.

[apple4ever]

Finally! Now they just need to add support for specifying cert length from 10-360 days.

[kuschku]

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.

[toast0]

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)

[icebraining]

Curious, why do you want to avoid SNI?

[gruez]

>certificates costs money

you still pay for x years certificate, but you only get a valid certificate for the next y days. if the CA can sign OSCP responses for millions of visitors, surely they can resign a certificate every y days.

>the world was mostly manual in the past (and in a lot of places still is)

that makes sense when talking about OSCP, but to get OSCP stapling working, you need to configure your web server to do so. instead of standardizing OSCP stapling, why couldn't they have standardized a protocol for a server to get updated certificates from the CA?

[mrbabbage]

> why couldn't they have standardized a protocol for a server to get updated certificates from the CA?

That's essentially OCSP :-)

In general there's not really a concept of an "updated certificate". A certificate is good if the signature matches, the subject on the cert matches the server, and the current time is within the certificate's validity period; otherwise, the cert is bad. If someone steals a certificate, the website fixes this by telling the C.A. to revoke the certificate and by serving a different valid cert – my old employer kept a second valid certificate lying around in order to minimize downtime in the event of having to kill the main cert. OCSP is a way to effect the killing of the bad certificate. But in the absence of OCSP or some other revocation mechanism both certs are still good.

> if the CA can sign OSCP responses for millions of visitors, surely they can resign a certificate every y days.

I haven't worked on this stuff in a few years, but historically OCSP resolvers were notoriously unreliable and often down. That's a huge issue for a security-critical path, because you're forced to "fail open" (which defeats the whole point of having OCSP in the first place) or render a wretched experience for your user. One big reason OCSP stapling exists is to work around C.A. OCSP resolvers' unreliability.