V02 staging accepts bogus “notAfter”


#1

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.


#2

I guess it’s intended?

If Let’s Encrypt always issues 90 day certificates, it’s not absolutely necessary to validate what the client requests.


#3

That’s legit, but it does seem to violate the spec:

The server MUST return an error if it cannot fulfill the request as specified

Maybe LE should reject any request that specifies a notAfter or notBefore?


#4

Well, you must be new here @FGasper :smile:
It doesn’t seem that at any point anyone really cared about RFC compliance.


#5

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.


#6

#7

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.

And sorry for going off topic.


#8

@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.


#9

Understood. Please don’t use this impression as a reason to discourage others from reporting draft RFC divergences.


NotBefore and NotAfter are not supported
#10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.