but I dont see any need to change the DNS it just checks whether the challenge lies on the domain so if the user puts the challenge from the LE client (which doesnt have any DNS entries) to the Webserver (obviously in the domain DNS) then LE just checks “here’s the challenge, so I am happy” doesnt it?
maybe not with DVSNI (I dont even know what that means) but when you use webroot and manual mode together then we have it.
You don’t have to change anything in your DNS configuration for manual mode. Just your webserver config.
yes if user manually setups up the .well-known uri and proper content-type response as application/jose+json on the web server, then LE client should be able validate the domain.
well that sounds well and chnging a mime type is just some htaccess so that sounds easy to me.
(but why does it actually need to be changed doesnt it need to just get the text and read it? especially if the type is already known LE should check for plausibility [valid json+jose file], what should be done anyway since any file could be marked as some mime type and if that check succeeds just read the contents of it and get the challenge.
Thanks to these instructions, I was able to use the webroot method successfully. Works well!
I didn’t find out about the switch “-a” elsewhere. I think it should be added to the documentation. It’s also not mentioned in the output give when using “–help”.
Is application/jose+json still a thing? The spec changed to text/plain, but it’s also in discussion to change it and give it an extension: https://github.com/ietf-wg-acme/acme/issues/9
[quote=“kelunik, post:26, topic:1445, full:true”]
Is application/jose+json still a thing? The spec changed to text/plain, but it’s also in discussion to change it and give it an extension: https://github.com/ietf-wg-acme/acme/issues/9
[/quote]looks like for staging and beta jose+json still needed… maybe text/plain is for GA public release ?
Staging will not be updated anymore IIRC.
@eva2000, on Monday changes were merged into the master branch of the client to kill off the old challenges using jose+json and now require text/plain (or no Content-Type at all). These changes were pushed to PyPI in the last 24 hours and now effect letsencrypt-auto.
application/jose+json was for the SimpleHTTP challenge. A recent spec revision replaced SimpleHTTP with http-01, which fixes a signature reuse issue. In theory, the required Content-Type is application/jose+json for SimpleHTTP challenges (which will soon go away), and text/plain for http-01, which is currently implemented and available in staging and prod. However, looking at the code, it appears that neither Content-Type is currently enforced in Boulder. I’ve filed a bug: https://github.com/letsencrypt/boulder/issues/1089.
Note that the client does it’s own pre-check before submitting the request to Boulder for validation, and the client check is currently stricter than Boulder. Reading the client code, it appears that the client only allows text/plain, when it should really allow either that or no Content-Type header. Filed a bug: https://github.com/letsencrypt/letsencrypt/issues/1356
Thanks for bringing up this issue!
thanks @bmw and @jsha that’s a huge change especially for folks doing their integrations. You also need a way to convey such major changes to everyone too 
if i updated the client properly via wiping virtualenv and reinstall, then looks like letsencrypt still currently accepts jose+json types https://community.centminmod.com/posts/20138/ as that’s what my Centmin Mod Nginx is setup for content-type still ? What’s timetable for complete removal of jose+json support ? As right now would be hard to work on integration if we don’t know which content type is supported at time of testing ?
That’s a good point about trying to directly convey these changes to the Let’s Encrypt community. I think no matter what we do, some people fail to hear about the change, but we can certainly do better. Do you have any suggestions on how we should go about doing this? What if we tried to made a post on these forums when major changes went in? One thing I will say is such changes will likely become more rare as we launch and development slows down.
As for the Content-Type, it looks like you found a bug! You can track the issue here #1089, but I would start working on transitioning everything over to text/plain. Right now, both will be accepted, but the correct behavior is to reject application/jose+json.
or just dont care about it, I mean what counts is the content.
When I used the client on 2 new beta domains yesterday the client required text/plain then
it said for me that it required that as well, but @bmw states that the server should reject json and that, but I think why care at all? just evaluate the size and the content that is stuff that cannot be wrong because if it was the data is wrong, while the conent header can be anything, technicaly.
Correction: It appears that boulder, the Let’s Encrypt server, is accepting both application/jose+json and text/plain. If and only if you’re running letsencrypt using the manual authenticator, the client attempts to verify the challenge has been set up correctly before contacting boulder. This self verification does check that the Content-Type header is text/plain so it must be set properly when using manual. When the problem is fixed in boulder, you’ll need to make sure the Content-Type is set properly when using webroot as well.
but WHY does bolder and/or the client even CARE?
cheers @bmw, i've switched to text/plain now Updates for Letsencrypt client support · centminmod/centminmod@eb889de · GitHub 
as to suggestions for notification of changes, not sure if discourse supports it, but do forum caetgories get individual rss feeds ? on my forums using Xenforo each sub forum can support rss feeds - so i setup a dedicated sub forum for git commit updates i.e. https://community.centminmod.com/forums/centmin-mod-github-commits.41/ which has it's own rss feed at https://community.centminmod.com/forums/centmin-mod-github-commits.41/index.rss - folks can follow the rss feed for updates or registered members can subscribe and watch that particular sub forum for email notification updates
Now for letsencrypt you probably don't want all commits tracked as such, so maybe just a category for client-dev (which you already have i see Client dev - Let's Encrypt Community Support) and you can manually post major changes that affect client domain verification etc and then folks can subscribe to the rss feed or category itself for updates and can reply to individual change threads if they have questions or clarifications.
edit: okay i see you can track/watch categories
so all that's left is posting such major changes into client-dev category
To make sure that it isn’t accepting a user-uploaded file, e.g. if the server thinks you’re uploading a JPG but it’s actually the certificate challenge.
well the server also can check the size of the file it gets because the file and the content are things that cannot change no matter how retarded the settings of the server that is used for verification are.