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”.
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
application/jose+json was for the
SimpleHTTP challenge. A recent spec revision replaced
http-01, which fixes a signature reuse issue. In theory, the required Content-Type is
SimpleHTTP challenges (which will soon go away), and
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!
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
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
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 https://github.com/centminmod/centminmod/commit/eb889de864ee44fdeb019d95cc7a243982f0e19e
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 https://community.letsencrypt.org/c/client-dev) 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.
Just what I was after too!
Unless I missed something, I don’t think there was already a mix of manual mode and webroot, so I make a really simple patch.
It’s also worth mentioning file permissions. When using it last night, it took a few attempts as letsencrypt-auto created files and directories as root:root with mode 700/600 - which meant Apache returned a 403. I had to umask 022 before running LE-A, and then it was fine.
I’ve yet to look for command line flags to set file mode or owner; as LE-A does sudo, I can’t immediately have it run as the Apache daemon user (although I suspect I can change scripts to make that work, that’s something to look at on another day).