SSL certificates are made to keep data secure. When ssl certificates expire, the users are left with the impression that the data is no longer secure which is the opposite of secure. Since lets encrypt gives free ssl, implement a certificate that never expires. The expiring ones seem like a good way to make money by keep billing people every year, but since lets encrypt is free, this would be an exclusive feature. Maybe do a 10 year cert or something better than 1 year. Lifetime would be best. you can see reason 2 on the link below. https://cheapsslsecurity.com/blog/google-chrome-ssl-certificate-errors-troubleshoot-guide/ I updated this post because I was blocked from replying, but if you will block me from replying and allow me to edit the post that doen’t seem too secure either. 
You can decide to use a certificate after expiry.
Anyhow, even if your configuration doesn’t support perfect forward secrecy, your data is safe as long as the private key is not leaked (or bruteforced). If your config supports perfect forward secrecy, your past data is safe, your future data not so much.
In what way do you believe this to be the case?
I agree with @danb35, I think you might be misunderstanding what happens when a certificate expires.
And to then add to your logic, then certificates should never expire or they (or their data) will then become insecure - which is never the case (under normal circumstances).
I’m not an ssl expert so not sure about thing about it not being secure, but it it invalid? why does chrome show this error? https://cheapsslsecurity.com/blog/google-chrome-ssl-certificate-errors-troubleshoot-guide/
Are they invalid once they expire and chrome says not safe?
Hi @manueltijerino,
Let’s Encrypt has been trying to move the industry in the opposite direction from your suggestion by making certificates last a shorter time rather than a longer time. Some of this has been inspired by a 2012 paper called “Toward Short-Lived Certificates”, or at least by some of the same reasoning as this paper.
It might seem like the reason that certificates expire is to force people to pay over and over again, but a more fundamental reason is to force the certificate holder to confirm that the information in the certificate is still accurate (and, to a lesser extent, to limit the damage if the information in the certificate isn’t accurate, or becomes inaccurate over time). One simple example could be that a domain name might have been transferred to someone else; if the old domain name owner still has a valid certificate for the name, that could be used to attack visitors to the services on the new domain owner’s site. (There is another other paper about this particular risk, although I don’t remember the name of the paper or its authors.)
Since the information in certificates could become inaccurate over time, they’re supposed to be reissued to ensure that the information remains up-to-date. This is also more or less the rationale for some other kinds of credentials expiring.
There are industry rules to which Let’s Encrypt is subject that impose a maximum lifetime for publicly-trusted certificates. Separately, Apple has created its own limit of 13 months and announced that it will refuse to accept certificates that have a lifetime longer than that! All of these rules have been changing in the direction of requiring shorter and shorter certificate lifetimes, because the browser developers want to see the information in the certificates get validated sooner and sooner.
As the researchers say in the “Toward Short-Lived Certificates” paper, it’s very hard for a certificate authority to “take back” an already-issued certificate when it becomes inaccurate or is proven to be fraudulent or issued by mistake. All certificate authorities have a revocation mechanism to do this, yet not many browsers ever reliably check those revocation mechanisms. So most users wouldn’t really be able to learn if something was wrong with a certificate, under certain assumptions. In that case, having the certificates last for a shorter time reduces the window of risk of someone believing in a certificate whose contents are inaccurate.
Certbot and some other Let’s Encrypt clients also have a default behavior of generating a new encryption key for every time they renew a certificate, which can help improve security against some (mainly quite rare and obscure) risks.
Let’s Encrypt’s solution to make shorter-lived certificates more practical is automation. For example, there are web server tools like Caddy that automatically get a Let’s Encrypt certificate for you, and that always make sure that your certificate is up-to-date and valid, without you as the web site owner having to do anything at all. Hopefully this will be roughly the way that web site security works for almost everybody in the future.
Well... for rsa2048 is not that obscure a risk. Changing the key every two months and making sure forward secrecy works mitigates bruteforce attacks a lot.
I think the forward secrecy is by far the more important of the two.
I guess they complement each other.
As Schoen very diplomatically said, I don't think you understand security well, and don't understand the implications of what you're asking.
Paid certificates don't expire to make money, they expire so they remain secure. The technology that secured certificates back in 1995 can be cracked in seconds on my phone today. The technology that secures certificates today will likely be considered insecure in a decade.
Even if the tech itself remains safe, a single compromise would effectively make the certificate worthless, yet the certificate would still appear legitimate in people's browsers forever.
If you really want a 10 year certificate, create a self-signed certificate (there are plenty of guides online that will show you). All modern browsers will throw up a warning, but will then allow you to proceed if you wish. I used to use self-signed certs before I upgraded to Let's Encrypt, and they work fine for a personal site where it's just for you or your personal group.
But if you want others to actually trust your site, you'll want to demonstrate the legitimacy of your certificate, and part of that is demonstrating the certificate is actively maintained. If certificates were perpetual, then they would have no meaning or legitimacy.
Indeed, most paid certification authorities don't sell "one certificate for this hostname, valid a year from now," they sell "one certificate at a time for this hostname, for a year, replace at will." Their costs are mostly support and sales, not csr-signing.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.