I’m sending requests to LE’s v2 staging endpoint that have notAfter of hahahahah, and the service isn’t rejecting those requests. It seems just to be ignoring the invalid part.
Is this intended behavior? I’d expect it to fail a newOrder that includes an invalid date.
That seems like the right decision. Will you file a Boulder issue for this? Thanks for flagging it @FGasper.
Maybe you didn't mean it to be read this way, but this strikes me as a flippant comment that isn't adding anything constructive to this discussion. We fix our compliance mistakes wherever possible and have been instrumental in driving the overall draft. It isn't a final RFC and with a draft that rapidly evolves it is inevitable there will be divergences. We're also specifically talking about the V2 API, which we have in a testing only deploy specifically to find and fix these bugs.
Well maybe I sound to hard again (I’m not a native english speaker). I’m very sorry if I offended you.
I tried to develop a ACME client and the only documentation was always read the RFC! followed by but not the current RFC, only the first draft!, followed by ignore it and use this nice document which lists all of the differences between the RFC and boulder.
Not even the first API-Endpoint /directory (which should configure a client) used the same keys as the RFC described!
That’s why I (as a client dev) get the impression, that the RFC isn’t handled that strict.
@lbehm Yeah I had that experience at first, too. It’s because the current production API was an early draft of the ACME protocol. It’s changed significantly since then.
If you look on LE’s main page there’s documentation about writing clients and specifically how LE’s current production API follows or diverges from the various ACME drafts.