/new-cert should 201 to /certificate about boulder HOT 8 CLOSED

Update on this:

• According to the spec, /new-cert should return the new certificate in its body, in addition to a Location header pointing to the canonical URL for the new certificate. The identifying part of the canonical URL is not specified: an obvious choice would be serial number.
• We probably want to modify the spec so the client requests a new cert and then polls until it's ready. This allows us to deal with a few things:
  • Ensuring the first OCSP "valid" response is signed and push to the origin server for OCSP responses.
  • It's possible the CA may lag behind during times of heavy load, and we might have to wait a moderate amount of time for the certificate to be generated.
  • The longer we hold a request open the more likely it is to get reset by random network issues. We should, relatedly, figure out what the client should do if it makes a certificate request but gets a network failure before seeing a response.

from boulder.

For now I think it's fine to proceed with coding the client to expect a certificate directly in the body of the /new-cert response. @jdkasten

from boulder.

Thanks, @jsha! cc @kuba @garrettr

On Wed, Apr 1, 2015 at 4:45 PM, jsha [email protected] wrote:

For now I think it's fine to proceed with coding the client to expect a
certificate directly in the body of the /new-cert response. @jdkasten
https://github.com/jdkasten

—
Reply to this email directly or view it on GitHub
#72 (comment).

from boulder.

Actually I'm not sure how I missed it but it looks like the current code does provide the Location header pointing to the new cert. Was this not showing up in your tests?

from boulder.

All of my info is probably outdated at this point. I have been trying to work on other aspects of the project. I stopped working on trying to get integration when the deadline was moved (local testing mode was still hardcoded). At the time I didn't write any reoccuring tests against Boulder because my solution was a hack (deadline) and it also requires authorization which was difficult to come by. @kuba or @GarettR probably know the most right now regarding protocol violations. @kuba wrote networking code and an example script to test the server here restified.py It just doesn't achieve authorization as that requires full client integration. I know he listed current problems with Boulder/spec as TODOs in the network2 code that I can forward to you if it would help.

from boulder.

Here is @kuba's restified networking code. It references Boulder throughout... but it hasn't been integrated into mainline client yet.

https://github.com/letsencrypt/lets-encrypt-preview/blob/master/letsencrypt/client/network2.py

from boulder.

network2 actually expects POST /new-cert to return DER-encoded certificate in the HTTP response body and Location header set to the Certificate Resource URI (and optionally "up" Link header poiting at chain certificate URL). It wasn't easy to derive that this is the intended behavior, but I believe it follows logically from the spec.

from boulder.

Working as intended.

from boulder.