This still wasn't answered:
2 Likes
Iām not sure what the current default policy about that is; Iāll ask some people who should know.
1 Like
We havenāt settled on a definite revalidation period yet, but I would recommend planning on doing revalidation with the same frequency you do renewal. For instance, if Letās Encrypt decided to require revalidation only once a year, but reissuance several times a year, you would have a once-a-year event thatās different from what you do the rest of the year, which is a recipe for failure. The automated validation procedures in the ACME protocol are designed so that they can be performed automatically, for exactly this reason.
3 Likes
Then why even have a manual mode since a 90 day expiration is expected to make it impractical anyway?
Why does everyone these days seem to want to control the behavior of others. This is beginning to get a Microsoft'ish feel to it. If someone forgets to renew or how to renew, or doesn't communicate to their backups, successors, etc. that's a reflection on them and their organization/business etc. That's their problem and something for their customers to hold them accountable for. Not the cert provider's (LE).
So provide automation for those who want / need it. But please do not make manual impractical for those of us who want to go that route and are capable and responsible to take care of our business for ourselves.
2 Likes
The manual mode exists because we canāt integrate with all of the server software out there and because people have requested it ā some of them donāt want to let the Letās Encrypt software modify their configurations. Certificate lifetimes are a matter of CA policy. The relatively short certificate lifetime might make manual configuration less convenient for some users, but some people said they regarded it as very important for their use cases that the manual mode exist.
3 Likes
Which means that from a practical ongoing usage perspective LE is not a workable solution for use with those server softwares and thus having a manual mode becomes largely irrelevant for them.
Were they counting on a 90 day expiration though? I know I was not. Probably most were not. The manual process is only useful for avoiding LE software modifying config if the manual process is practical. 90 days is impractical for ongoing production use.
Yeah, so. Make the policy something reasonable and practical for manual mode use.
More likely for nearly all who use the manual mode for anything that is ongoing. Like a production environment.
Yes and so do I. But 90 days makes it impractical for a very large swath of those use cases.
Again, was that with the understanding of a 90 day expiration?
2 Likes
I donāt see the problem if you make it a monthly routine. Just know that on the first of every month, you need to go refresh the certificates.
Shorter certificate lifetimes help anyways.
3 Likes
The problem is that for those who the automated process is not acceptable (for whatever reason; security concerns, desire of greater control of process, whatever). The manual process is very likely to be un-workable for many of them in a practical sense due to the very short cert lifetime.
I, and probably many others who prefer to use a manual process don't want a monthly task. In many cases that actually increases the likelihood that a cert will expire without having been renewed.
I don't like it when vendor's think it is their place to dictate what my business processes should be through some arbitrary policy of theirs.
2 Likes
Iām not exactly sure if āmanual modeā is correct term here.
Lets say I have IIS (not supportedā¦ at least yet) but I want use this.
I would use āmanual modeā but just script it, right? Lets say, once per month script will shutdown IIS (one way, I think if 443 needed) and start LetsEncrypt with correct parameters. Then I have new certificates (If needed), script will put them right places and start IIS.
If you use manual mode because of āsecurity concerns, desire of greater control of processā (does those even make any sense in any situation?) I think this is not designed for those cases. (best control of process is automate it)
1 Like
Even there are good reasons for short livetime:
- Force to Automate the Process
- Small size of revocation lists
There are on the other side good reasons for longer Livetime - Warning if certificate was changed
- Growing size of Certificate Transparency
- Renewal could be complicated on embeded devices.
From my point of view there should be an option to extend the livetime at least up to 1 Year.
There could be also an option to reduce the lifetime to less than 90 days.
4 Likes
I was hoping for at least a year here. Having to renew every 90 days seems like quite a hassle, especially for anything that canāt be done automatically with your tool.
4 Likes
Thatās not always feasible though. Additionally, while Apache and such can easily be reloaded while running, not all software can do this. For example (this may no longer be the case, but it was last I saw), UnrealIRCd needs a full restart. For longer life certificates, this is fine because you generally update the software once or twice a year, but if you need to start interrupting sessions just to reload a certificate, itās unlikely people will want to. This isnāt unique to IRC, but a lot of non-HTTP services using SSL/TLS accept self-signed certificates by default because itās not deemed that important, and thatās really something I was hoping this project would help with.
5 Likes
Whatās the difference between standalone vs. manual mode?
1 Like
Probably I will not be popular with it, but I have the same problem with this short certification lifetime. A lot of applications can use the certificate, which need a restart when You change it, or difficult to change it time to time. For example Inspircd, ZNC (IRC bouncer), and more. So I prefer the cert lifetime to be one year at least. (The one year is the minimum āstandardā, I think for DV).
4 Likes
@kelunik, manual mode gives you instructions for what to do in order to prove to the CA that you control the domain. You must then follow these instructions in order to change things on your server yourself (typically by running the commands that manual mode instructs you to run). Standalone mode obtains the certificate automatically without additional human intervention.
Manual mode doesn't require you to run the Let's Encrypt client as root. It also doesn't necessarily require you to run the client on the same computer that all of the requested subject names in the cert are pointed at. For all currently supported verification technologies, standalone mode and the other modes will require you to run the client as root.
Standalone mode is so called because it doesn't require you to have a web server (like Apache or Nginx) running in order to obtain the certificate. It will also work on machines where you're using web server software that the Let's Encrypt client isn't currently integrated with. To use standalone mode, you'll have to temporarily stop any other software that is listening on TCP port 443, which is used for HTTPS connections.
In terms of the history of the names, standalone mode is contrasted with the earlier ways of using the software that integrate with local web servers (and modify the web servers' configurations). But standalone mode is still automated. Manual mode is not automated, in the sense that a human administrator has to take additional steps to change something on a server to complete the proof of control for each requested name.
Both manual and standalone modes will give you a certificate file that you can then load into other server software. (We haven't yet investigated whether we have a practical way for this certificate to be automatically renewed.)
7 Likes