Sure, nothing wrong with that, as long as the client isn't rechecking the certificate it got at the start for expiry (not bloody likely lol). The TLS session is already established, it's not like you're changing out the session keys or the cipher.
2 Likes
Actually, I donât think it is a narrow way of thinking about it. The fact that this absolutely critical service (Whether itâs Email, IRC, or whatever else) can lose data or have a negative impact on your business by the service restarting is an indication that the deployment is not as robust as it should be. There should be another server running by its side and the client should gracefully failover to the alternate server, allowing full restarts of a single server as and when needed. I appreciate that not all pieces of software support this, but I think you should consider the cost of one of your servers needing to be restarted and from that decide whether or not these pieces of software are suitable for your business, or if you should be finding other providers. Obviously config reloading negates some of this, but it doesnât solve the fact that your business is dependant on these services being up constantly and cannot cope with any downtime, which for me is a serious risk.
By using the sledgehammer approach, Letâs Encrypt will help speed up the software improvements required in the same way as the major browsers dropped support for SHA1 certificates and native browser APIs to force change in an otherwise stagnant software world. When the softly-softly approach is used, the end result is usually that no significant changes actually occur.
In response to your comment about forgetting to renew your certificates every 90 days - How do you currently remember to renew your certificates every 1/2 years ? Whatever process you use for this can also be applied to the 90 model. You should use a reminder or tasks list to ensure that your certificates are kept in-date regardless of how long they last.
1 Like
While I agree that it would be fantastic if all software worked in that way, this isn't always the case and some products might be proprietary, archaic, poorly-written, or all of those things. Particularly with larger or older businesses, you may get some ancient software that has no alternatives that the developers no longer really give a damn about - or make you pay through the nose for upgrades.
What would you say to those people?
Because it's at the same time as my domain renewals, although I agree that isn't an ideal way to remember.
1 Like
Well itâs really a business decision to use these older and more archaic products. The decision essentially boils down the to cost of using that piece of software (Cost of supporting an old piece of software, cost of it not being as highly available as it should be, cost of not being able to offer the latest features to your customers, etc) vs the cost of using something different (Cost of buying new licenses, cost of developing bespoke software, cost of the risk of changing software vendor, etc). Ultimately by deciding to use or start with these older products, the decision has been made that availability is not as critical as some other factors and that some downtime every so often is acceptable. Of course if this is not the case then Iâd suggest re-evaluating this decision.
I do appreciate that there arenât always alternatives to a piece of very old software, but in this case the decision is between using it and not using it at all. I do also of course appreciate the additional cost and annoyance of having to go through a renewal process every 90 days. That in itself is part of the decision that I mention above, the cost of renewing certificates should be carefully considered and should be factored in. This is something you have to decide on as part of a case by case decision for your own company.
Iâd strongly suggest that even if you stick to your existing 1/2 year certificates that you use reminders of some sort to let you know when you need to action things like domain and certificate renewal. It will also serve as a nice way of handing things over to your successor should you ever move on from the company.
I say all this knowing that automation isnât as easy as it sounds. When I work, we recently automated the deployment of our entire software stack to Amazon. I say entire but the truth is that some parts are still manual. We made the decision that at the time it was more time efficient to keep the manual steps in there, but we are at least moving towards full automation.
6 Likes
This is actually a pretty great answer. Thanks for taking the time to type it out.
I think you make a fair point here - Different priorities mean different considerations. Good way of looking at it.
2 Likes
Hereâs another point: It forces you to make reissuance easy, because it turns an emergency into the routine.
With LE, the client can update and automatically reissue your certificate with updated parameters.
4 Likes
I think there are two different points between how easy reissuance is and what is the forced maximum time.
Because it is already said that you can recreate the certificate before the time.
Also small Lifetime mean much data on certificate transparency but small CRL.
1 Like
I donât see mail servers as problematic. SMTP as protocol is specifically suited to unexpected interruptions, resending, backup routing, and (contrary to popular belief among users) being ok with reasonable delays, so that restart and interruption is IMHO just a bit annoying rather than critical. Granted, an email that requires an unusually long connection (due to large attachments or low use of bandwidth) might need to unnecessarily resend a lot of data - but that situation could also happen once a year instead of once every three months. Especially, if youâre able to schedule it to off-hours (and off those hours where you routinely send around those DVD attachments) I donât see a problem. (Client submission may be a different situation though than receiving or relaying).
I do see your point regarding VPN services that are more expected to be highly available and low-latency. Then again, we already have key renegotiations every few hours - so maybe the software could also be made cope with certificate renegotiations every few months?
But then again, the recurring theme of this thread kicks in: The short lifetime makes it absolutely necessary that the processes can be automated. And those automated processes must run very reliably.
1 Like
A shorter lifetime also does a lot of encouraging on the CA side to automate renewal processes and ensure 100% uptime. After all, you may expect 4 to 8 times as many renewal requests from the same number of clients than a CA issuing 1 or 2 year certificates. Actually, if the renewal is attempted after 60 days already, we are at 6 to 12 times as many requests.
1 Like
will you ever issue them for 3 or 6 years?
1 Like
If anything, they will probably issue certs for even less than 90 days of validity later on. Also 3 years is the absolute maximum lifetime permitted by CA/B Forum, so 6 years is out of the question.
EDIT: Iâve just reread second post in this topic, which confirmed my suspicions.
1 Like
And encryption scheme are constantly evolving to stay several steps forward (it's a cat and mouse situation). You also wouldn't want to use a non-expiring certificate that is still using SSLv3 and remain vulnerable to attack because of inaction on your behalf.
1 Like
@m-p-3, most of the cryptographic parameters used in a TLS session arenât specified by the certificate, but only during the TLS session negotiation. For example, you could use a Letâs Encrypt certificate with 56-bit DES as your cipher, if the client and server were both OK with that. The certificate just doesnât set most of these kinds of policies today, historically because CAs didnât think it was their responsibility â rather, user-agents thought it was their responsibility to negotiate safe options (and the client and server can upgrade to better cryptography, with the single exception of changing the subject public key itself, without reissuing the certificate).
I agree that it would be useful to have administrators or at least operating system developers revisiting their crypto setups more frequently than they do today, which is often âneverâ.
1 Like
Well, I too had been looking forward to LE certificates. Now, with manually âphoning inâ for approval every 90 days, or else constantly running LE software, I will probably have to do without or buy a âproperâ one. Though I donât trust any of the CAs and donât like supplying the personal info to get one.
I suppose all the LE donations have produced at least something better than nothing - but Iâm glad I have not donated yet. Next some will tell me not to say anything for that reasonâŚ
Unfortunately this is a common problem with Linux and other volunteer tech offerings - there is no external market discipline or motivation to serve the customer. âIt is free and you will take what you get and like it. I know whatâs best for youâ.
Unfortunately that is also the way, as an earlier poster mentioned, with the likes of Microsoft at the other end of the spectrum. They can force awful products and tell people what to do because they have a stranglehold due to an IP monoploy. Yet, after all these years, for most people even these awful offerings have still been preferable to Linux on desktops.
Why not be different for a change and stop âforcingâ people for their own good?
Of course, the other thing could be that in order to get a recognised CA to cross sign, LE had to show them they would not compete on their turf. Then why not say so instead of the condescending âitâs for your own goodâ stuff?
Iâll decide whatâs good for my servers not LE and if LE cannot offer something proper for all the donations they have taken in - without the know-it-all central planning, handholding and strings attached - Iâll have to do without.
3 Likes
Whatâs a âproperâ certificate? Just because theyâre not valid for more than 90 days? Did you know that Google chose that way, too? They use 90 day certificates as well.
2 Likes
There is no compelling reason to lock the certificate lifetimes to 90 days (or any other period) that will pass scrutiny.
First, training people to automate so they will not forget how to do things is the antithesis of what is being promoted. Once automated how to process the task will definitely be a forgotten skill. The choice of 90 days could have then been 45 days or any other random number that could be sold to a gullible client base based on fear-mongering. This reason for selecting 90 days is not convincing and does not have an open rationale.
EDIT: I did forget to mention that once renewal is automated the administrators no longer need to be at the helm the number of unattended certificates WILL increase rather than expire when no longer maintained through human intervention.
Selecting a default period that forces automation does not explain why other periods will not be available. I think 90 days as a default is probably quite practical for most use cases.
Certain tasks may by design or convenience do better with a longer or a shorter (revoking is often a possible workaround) period and should be accommodated. Some things will not lend themselves to regular supervision, imagine your certificates expire while on the way to Mars in hibernation and the wakeup command cannot be authenticated.
Lack of flexibility in the matter has to be assumed to be due to sponsor pressure and could explain the number of sponsors who want the appearance of a free CA but are happy to have a limited or crippled service.
With the pace of the internet many certificates may no longer be needed 39 months (as provided by some other CA) from now and would never come up for renewal.
One concern that I have not seen addressed is the increasing amount of coded traffic that the periodic (and reasonably predictably timed) refreshing of the certificates will cause to leak to and from the CA and the client. Unexpected data and meta-data may pass that does not need to that may be giving opportunity to eavesdroppers to track activity, this alone should give pause to anyone using a cryptographic system or application of any sort that has arbitrary limits placed on end users that do not ring true. If the system insisted that all certificates were between 1 and 38 months plus rand(700) hours (and then automatically refreshed with the client software as promoted) it would make me suspect much more good faith. Does it quack like a duck?
If any free service is limited by decisions made against user interests it must be assumed that people (actual individuals, seldom does a complete group need to be compromised) in leadership positions have been coerced into promoting the party line, there can be no other logical conclusion and the service must be used within these limitations.
@paulxx Mentions some similar thoughts above. Mostly he also said the customer should be the one to decide.
I hope my cynicism is misdirected and the problem will be resolved flexibly. I also apologise if any persons in authority in this project feel I have imputed that they are not free of possible bowing to pressure, but sadly the easiest way to subvert any important system with leaders is through the leaders.
6 Likes
What does the comment below mean in practice?
Why is it there and not discussed much though it seems to relate to this thread?
// DefaultAuthorizationLifetime is the 10 month default authorization lifetime.
// When used with a 90-day cert lifetime, this allows creation of certs that will
// cover a whole year, plus a grace period of a month.
// TODO(jsha): Read from a config file.
1 Like
@KalleMP, I think the authorization lifetime is how long an authorization to issue certificates for a particular name lasts (without a need to re-perform the domain validation process). That is, if you have an existing authorization you can renew a cert without having to do the DV challenges again.
The authorization mechanism is kind of a behind-the-scenes feature from the point of view of many users; the ones who would likely become more aware of it or actively benefit from it are users who get certificates for many domains, especially if they want to frequently re-issue for different subsets of a large pool of names.
2 Likes
Thank you, yes, I do now remeber reading (perhaps in this thread or elsewhere) that the validation and certificate lifetimes were not locked to the same time table.
1 Like
I think on the discussion should be another point remembered. "HTTP Public Key Pinning"
If you change the certificate in short interval than there are two options:
- You always use the same key and does not need to change the pinning. But have no security improvements.
- Always change the pinning and risk blocked users
- Pin the CA and then fixed to this CA.
1 Like