Using the webroot domain verification method


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 :smile:

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. which has it’s own rss feed at - 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 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.

GitHub Issue with link to 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 -d -d --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 -d -d --agree-dev-preview --agree-tos -a webroot --webroot-path /var/www/vhosts/ --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.
Thank you!

–… Archer


problem is you’re running letsencrypt-auto and not letsencrypt

for my webroot authentication i use the following with custom --user-agent passed onto LE servers for tracking my Centmin Mod integration :smile: 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/ -d 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 =

# for beta invitees
server =

# Uncomment and update to register with the specified e-mail address
email =

# 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 :wink: :slight_smile:


Thank you eva2000!

When I read this, I face-palmed myself lol. Thank you for the example, it helps me greatly :smile:

–… Archer


NP, you are welcome :smiley:


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 
cd letsencrypt/

Get a cert:

/root/.local/share/letsencrypt/bin/letsencrypt certonly --webroot \ 
--webroot-path /var/www/example --renew-by-default --email \ --text --agree-tos --agree-dev-preview -d \ -d

Let's Encrypt and Heroku [Solved]

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?


No, 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.


Hey Leliana!

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.