Are you going to revoke certificates that you think are not used?
@jsha As far as i understand the baseline requirement the ca have to sign an positive response every 4 days.
But this is clear because it can revoked after 7 days.
But if an certificate was revoked, i would say the negative answer can be valid for the rest of the cert lifetime.
Because it is not like an physical key there i can say i want to use him again.
I know this leaves the point from @motoko with multiple sides. But with the same automation argument you can say they should automate the key distribution and if one server has an compromised key they should change change all with the same fqdn.
Since i am an java coder and can implement the cert reneval inside the keymanager it is no problem for me.
But there are lot of hosters that provide only webgui for cert deployment to their customers. So i can see why many people like longer duration.
@tlussnig In some cases you can’t automate distribution across nodes, or it’s difficult to do so. There are sometimes legitimate reasons for maintaining multiple certificates with the same CN but different private keys. If LE doesn’t want to support that kind of configuration, that’s fine. If you can afford that type of setup you can likely afford the certificate costs. However, that kind of configuration shouldn’t be discounted as a valid setup.
As for WebUI deployment, the emphasis is on automation, so I suppose the goal would be that those WebUIs are updated or changed so that a certificate can be generated and issued automatically without requiring the customer to even handle juggling CSRs, PKs, or other crypto details like they currently do. I’m not opposed to seeing an option for a longer issuance period if LE wants to try and cover those folks too. The emphasis right now seems to be on getting hosting providers to offer LE in a nice interface where the customer can just toggle on/off. Moving to that kind of penetration goes a long way in offering widespread encryption.
And very few of them that offer free certs, and no SAN certs. If the point is to get everyone using TLS, then LE should try to accommodate as many reasonable scenarios as possible. For those of us using TLSA and/or HTTP Key Pinning, where there is no automation yet, a 1 year lifetime is a reasonable compromise. Perhaps as LE matures and the client and automation processes around it mature, that can change, but for the moment it’s not unreasonable to support 1 year certs, especially when provisioning in manual mode.
So then, from Let’s Encrypt’s perspective, “not used” certificates are literally only for sites or servers that are no longer online at all?
I say this because once automatic renewal is implemented, wont the client continue to renew the 90 day certs even if the website admin is not actively “using” the site anymore, thus requiring the same exact OCSP load as longer term certificate?
I think one thing LE should do more is to make DANE (aka TLS + DNSSEC) more available, to push it more. I think LE is just a short term solution, and DANE the long-term solution.
That said, what is the problem ? DNSSEC doesn’t like short term information. I am not a specialist in this field. It is a complicated thing, but I really think that changing certificates often does not comply well with DANE, therefore I think it bad.
Thank you for considering that and debating.
I think you are missing something. changine cets quickly and HPKP can be a problem, because HPKP has an enforce lifetime. but with DANE/TLSA you can change the cert/key information anytime in the DNS and when you dont set the lifetime too high and have a nice way of auto-changing your DNS (cloudflare api might work as example) then you yould even use 1-day certs with dane. also when you use dane in TAA mode (trust anchor assertion, aka “make your own CA”) you can just specify your favored root and make as many leaf certs as you want without touching the DNSSec.
DNSSEC/TLSA also has a TTL (you have to carefully respect them in the same way as the HPKP lifetime; for the very same reason DANE alone won’t be the only solution for the future as during the TTL cache time the old certificate is still valid and cannot be revoked as with an PKI - ok, here an attacker could also “cache” a valid OCSP request for 2 days…), TAA mode does not work as not browser implements it right now OR just trust Let’s Encrypt CA and don’t win anything as it is not pinned to your own certificate.
well yeah browser need to Implement TAA, but when implementing dane, TAA could be done as well…
also I did say
in cloudflare the life of your records as be as low as 2 minutes while with HPKP the lifetime should be as long as possible because HPKP isnt really through another connection.
This gets off-topic again as I already mentioned DNSSEC/TLSA…
But: not everyone uses cloudflare and btw. if I would use cloudflare, then I could just drop DNSSEC and SSL/TLS at all, as cloudflare can manipulate DNS and therefore potentially read everything (even if you don’t use their ssl mitm, they can just use arbritrary dns answers and make visitors use their ssl mitm even if you don’t like it)… - It’s not under my control, it’s under cloudflare’s control (or, if you trust cloudflare, anyone who has my cloudflare password). Besides that: 2 minutes are 2 possible minutes with validation errors in case of a certificate update… (If someone is realy serious about security, then even DNSSEC/TLSA is not really safe, as the chain of trust is not really there, as you don’t directly give your keys to the registry, but to your domain-hoster - and if there is a break, then evil people can send arbritrary new keys to the registry…)
you dont have to use cloudflare as mitm I just use it as DNS and make the clouds grey, aka dont use the cdn.
This is clearly an off-topic sub-discussion now:
If cloudflare manages my dns, Cloudflare could still manipulate DNS and mitm my webpage (or even catch my mail)…
DNSSec, TLSA and so on
Yes, the DNSSEC discussion is indeed off-topic. Reminder: you can use “Reply as linked topic” if there’s something you’d like to discuss on a separate thread. Thanks!
on mail client side, when we change/renew SSL, user need to accept new certificate. Even once in a year, I always have too many people asking if they can just accept that pop up.
just curious : when LE will renew the SSL? on the day of expired time of we can force to renew few day earlier? If something happen on renewal date (DDoS, etc) we will left without services
karo, according to the documentation published, you should renew about 30 days before expiration, which is 60 days after issuance. There is no current stable automatic process with the official client, so you’d run the process manually.
Maybe it’s a specific client, but I haven’t seen any popups for mail clients as long as the certificate is signed by a trusted CA and you connect to the name that is specified on the certificate.
Let’s Encrypt certificates currently have a ninety-day lifetime9. Web standards do not require any minimum certificate lifetime. As of 2015, the Baseline Requirements3 specify a maximum certificate lifetime of 39 months.
The Technical Advisory Board5, chose a 90-day certificate lifetime to start with, with an expectation that people will want to auto-renew at the 60-day mark.
30 days is often used to keep CRLs small for mobile clients. That’s why Google rotates the certificates on its properties every 30 days. However, they re-certify the same public key.
Otherwise, it can create a DoS for user agents over wireless. From Peter Gutmann’s Engineering Security, page 640:
… For PKIs sized at tens of thousands of users, multi-megabyte CRLs are not uncommon, and the potential size of CRLs for hypothesised national CAs/PKIs is unpleasant to contemplate. As long ago as 1998 a Verisign employee had warned that for user populations much larger than 10,000 certificates the use of CRLs “requires infrastructure capabilities that are beyond the state of the art and further may not operate in practice”  (in practice if the CRLs are issued extremely infrequently and most clients don’t check them then this can be made to appear to work, for some value of “work”).
An example of these problems was illustrated by the Johnson and Johnson PKI which, with 60,000 users, had a CRL over a megabyte in size after its first year of operation , requiring that users fetch roughly a million times more data than necessary for any certificate check (the entire CRL had to be fetched in order to obtain the effect of a single boolean valid/not valid flag). The problem was “solved” in this instance by only issuing a CRL once a week and caching old copies of the CRL to turn it into the ritual check described earlier, a relatively common approach whenever this problem raises its head. In contrast the rather larger US Department of Defence (DoD) PKI, which by 2005 had issued sixteen million certificates and revoked ten million of those, was issuing fifty megabyte CRLs (!!) that users had to download once a day . A few years later these had grown to over a hundred megabytes, with the largest CRL known to the author, reportedly from a European government CA, being over 150MB, resulting in what’s euphemistically reported as “low user satisfaction” as systems appear to hang while they retrieve and search such monstrous CRLs .
A kludge adopted by one organisation to try and address this problem was to start removing fields from the CRL in an attempt to reduce its size, discarding accuracy in the interests of just getting some sort of data out the door . Another CA, even after taking this drastic step in addition to splitting the load across four sub-CAs, still ended up with 90MB CRLs, with widely-used tools requiring around a gigabyte of memory to process one of these monster CRLs . Other PKIs went even further, using dozens and dozens of CAs (with their attendant cost and overhead) purely to restrict the size of the CRL that any one CA had to issue. The reason for the rapid growth of these CRLs is that great quantities of certificates are routinely revoked for benign purposes entirely unanticipated by the X.509 designers, discussed in more detail in “Case Study: Inability to Connect to a Required Server” on page 502.
Maybe let’s Encrypt should issue certificates for 45 day, and send a new certificate every 30 days, without requiring a re-enrollment. At 90 days or 180 days, it could require operators to prove possession of the private key again.
And a 90-day or 180-day (or longer) certificate could be an upsell item to help defer costs.
I think there’s an extremely strong argument missing from the above list for longer certificate lifespans.
If the goal is truly to get people to “encrypt” nobody wants to login to multiple servers and update certs every 3 months. This will be the single biggest deterrent there is to getting people to embrace https and undermines the fundamental mission of LetsEncrypt.
If you go to any other certificate authority the industry standard is one year, and often they try to up-sell you to 2 or 3 years. I understand there are some security concerns with this (from the above list) but please let the end user make their own decision.
On a personal and emotional note- this seems wayyyy overly controlling to me, almost like a “father knows best” mentality.
The prior issue has been the costs by the hosting company since SNI wasn’t widely supported. That should be much relieved now, but many legacy hosters will still want to charge for “SSL” to keep the profits or because they or their software doesn’t support SNI (and unique IPv4 are often a recurring cost from the datacenter).
That is a much larger deterrent than a quarterly renewal requirement. Also, the goal is to make renewal automated, which should relieve that burden over time.
That’s because they want your money.
To a degree, it is. However, with shorter lifespans, it helps reduce the impact of Let’s Encrypt certificates should something like Heartbleed or the Debian SSLKeys weak keys issue happen again. Likewise, it would also help speed things like the transition to SHA256 signatures.
I’m personally in favor of an optional 1 year maximum lifespan for those people that want a longer cert expiration, but nothing longer.
This makes perfect sense, but it is prohibited by the Baseline Requirements. From V1.3.1, 4.9.10. On‐line Revocation Checking Requirements:
For the status of Subscriber Certificates:
The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.
I believe several root programs adjust these limits downward, so the actual limits may be shorter.