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).
A little assistance requested in troubleshooting what I am doing wrong.
Presently I can issue this command after stopping my webserver to free up the necessary ports:
./letsencrypt-auto --server https://acme-v01.api.letsencrypt.org/directory -d hoshisato.com -d www.hoshisato.com --agree-dev-preview --agree-tos --verbose certonly
However, when I attempt to use webroot, I end up getting the fake CA, so I think I might be doing something wrong with the command:
./letsencrypt-auto --server https://acme-v01.api.letsencrypt.org/directory -d hoshisato.com -d www.hoshisato.com --agree-dev-preview --agree-tos -a webroot --webroot-path /var/www/vhosts/hoshisato.com/public_html --verbose certonly
I’ve tried a few variations with the accepting agreements and adding the email flag, but still get the fake CA. was hoping could show the right syntax I’m looking for.
problem is you’re running
letsencrypt-auto and not
for my webroot authentication https://community.centminmod.com/posts/20509/ i use the following with custom --user-agent passed onto LE servers for tracking my Centmin Mod integration You can remove --user-agent if you are not using it
letsencrypt -c /etc/letsencrypt/webroot.ini --user-agent centminmod-centos6-webroot --webroot-path /home/nginx/domains/le10.http2ssl.xyz/public -d le10.http2ssl.xyz auth
contents of /etc/letsencrypt/webroot.ini which is auto populated and created the first time it’s run when auto generating my nginx vhosts
# webroot.ini general config ini rsa-key-size = 2048 # Always use the staging/testing server #server = https://acme-staging.api.letsencrypt.org/directory # for beta invitees server = https://acme-v01.api.letsencrypt.org/directory # Uncomment and update to register with the specified e-mail address email = firstname.lastname@example.org # Uncomment to use a text interface instead of ncurses text = True agree-tos = True agree-dev-preview = True renew-by-default = True authenticator = webroot
As Letsencrypt client is being continually updated, I also always update the client before running the client as well
Thank you eva2000!
When I read this, I face-palmed myself lol. Thank you for the example, it helps me greatly
NP, you are welcome
This post needs an update.
Update: 2nd December 2015
The instructions at the start of this thread are outdated.
Check out the code and install:
cd /usr/local git clone https://github.com/letsencrypt/letsencrypt cd letsencrypt/ ./letsencrypt-auto
Get a cert:
/root/.local/share/letsencrypt/bin/letsencrypt certonly --webroot \ --webroot-path /var/www/example --renew-by-default --email \ email@example.com --text --agree-tos --agree-dev-preview -d \ site.example.org -d www.site.example.org
How about editing the start post directly instead of just linking to another post?
This looks really interesting! I have a setup w/ a Django site on Heroku. Another thread [ Let's Encrypt and Heroku [Solved] ] mentioned near the end that --web-root should replace --manual to facilitate autorenewal.
But part of the process that lets --manual work is that the prompt stops halfway through, tells us the verification response expected [a string response at a path], and gives us time to do a deploy of the file at that path. Does --web-root allow us to stop halfway through somehow so we can do a similar verification deploy?
webroot creates the file itself at that location without pausing, assuming you tell the client where it can be created via
-w and that the client has permission to write files there that the webserver will serve.
I’m trying to setup some certs using webroot but I didn’t think that it needed to be able to access the file using ssl. Would this work with just the port 80 block? If not, feel free to ignore my comment, I’m pretty new to this world.