The sooner you catch that breakage, the easier it is to get the resources (either from that team, or from your own team) to fix it. It’s a matter of “Oh we changed that API 2 months ago, everything is fine for us, all of our people have moved on to other tasks” versus “Oh our change broke you? We can revert it until we have a workaround”.
2 months, in most orgs, is enough time to figure something out before your entire business goes offline.
Unless you want that automatic update tool on your server, which I find a bit sketchy.
Where else would you put it? You could put an ACME client somewhere else but it still needs to connect to place the updated certs.
It's one line in a crontab, hardly an enterprise level endevaour involving IBM consultants and a triple redundant K8S cluster.
> Unless you want that automatic update tool on your server, which I find a bit sketchy.
It's no sketchier than you using binaries from your distro's repo, or even the Linux kernel. I doubt you'd read either line by line to check for nefarious wrong doing.
CAs which charge for issuance often have a policy which implies an earliest sensible renewal date, because they will "carry over" remaining time on the previous certificate. There is a practical limit to that, (for example today your "one year" certificate from such a CA can only have up to 398 days until it expires, so renewing two months early won't make sense) because of the Baseline Requirements and/or trust store policies.
But if you're doing client development for ACME, the protocol Let's Encrypt implements for issuance, then yes, they'd tell you that they advise you to begin trying to renew with 30 days left. The EFF's Certbot tool, which a long time ago was just named "letsencrypt" implements this policy as do many other stand alone ACME clients.
