We're building an app which interacts with a number of services, all of which use LetsEncrypt certs (thank you!). Our app has time-of-day-dependent features (depending if it's morning, afternoon or evening) which we test in an end-to-end fashion. In order to test these features we backdate the system time by up to 24h. This is leading to intermittent failures when the test is running within the 24h window after a certificate renewal, as the backdated system time is earlier than the new certificate's "Not Before" timestamp. If we could backdate the "Not Before" field to 25h before issuance (rather than 1h before), it would allow us to have enough overlap to accommodate the artificial clock skew.
1 Like
Hi @reubenm, and welcome to the LE community forum 
I doubt that would be something "simple to do" in a production CA environment.
That said, why can't you use your own private CA for such testing?
4 Likes
I think Let's Encrypt is unlikely to implement such a feature. The maximum legal backdating is 48 hours according to the Baseline Requirements (servercert/docs/BR.md at d820f37f9e1550805c210dcaf5162b7f86ccfb69 · cabforum/servercert · GitHub), but Let's Encrypt's intended goal is to reduce validity periods, not increase them. Reducing the notAfter to align with a backdated notBefore results in even less useable certificate time, which doesn't play well with ever-decreasing certificate lifetimes (like eventually 7-10 day certificates). Let's Encrypt also hasn't historically been a big fan of adding more than absolutely necessary config switches. I think to implement such a feature there needs to be much stronger motivation than "It makes my testing easier".
For your use case, you could consider simply waiting for 24 hours before you deploy new certificates. If your ACME client renews at the recommended 2/3 lifetime (60 days), you can still use the old cert for about 30 days. You could script a deployment hook for your testing environment that delays new certificate installation for 24 hours.
7 Likes
is there problem to forward dating test system? (set faketime to future, not past)
4 Likes
Hi all, thank you for your replies!
Yea, I'm not sure how complicated this actually turns out to be for the CA.
We want our end-to-end tests to run against the production services as much as possible. We already use non-prod for all other forms of automated testing, but end-to-end is most crucial where mocking or pointing at separate environments opens gaps in testing. This often happens around features that require lots of support from remote services.
This is very interesting. I'll try to figure out how to do this with cert-manager. Thanks for the tip!
Nice, that might be the simplest solution yet! We can just have a quick test at the beginning of tests which verifies if we're about to hit the renewal problem and then tells the tests to forward date instead of backdate. Thanks!
5 Likes
Just to add to what's already been said: we are very unlikely to allow changing the backdating time. It exists only to allow for a little bit of clock drift, but shouldn’t be relied on for anything else.
8 Likes
That is essentially what I do.
I have the Certificates/Keys enrolled into to source code (we use GPG via blackbox for security). A python script written in fabric is used to copy/normalize/register the certificates into our source tree - I prefer standard filenames and versioning on the directory; the same script is used by developers/production to update the environment. Certs for local developer work are all in the main source repo; other repos maintain the certs for Staging and Production.
I've only used this to test what happens on expired certs, to ensure everything works as planned. IIRC the command for that routine is something like fab cert-deploy {CERT_ID} and i'll always deploy '0001'; there is a fab cert-deploy-latest that reads the directory and deploys the latest one. it would be trivial to parse the certs and act on the notbefore/notafter; though I'd probably want to maintain a sqlite database or similar to streamline those calls.
That was my first thought too.
4 Likes