Unable to Generate a Certificate for Server Anymore

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: pianoconquest.com

I ran this command:
sudo docker run -it --rm
-v /home/stanleyndunwere/sites/holder/:/etc/letsencrypt/
-v /docker-volumes/var/lib/letsencrypt:/var/lib/letsencrypt/
-v /home/stanleyndunwere/sites/:/data/letsencrypt/challenge/
-v “/home/stanleyndunwere/sites/log:/var/log/letsencrypt/”
certbot/certbot
certonly --webroot
–email test@pianoconquest.com --agree-tos --no-eff-email
–webroot-path=/data/letsencrypt/challenge/
–staging
-d pianoconquest.com
-d www.pianoconquest.com

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for pianoconquest.com
http-01 challenge for www.pianoconquest.com
Using the webroot path /data/letsencrypt/challenge for all unmatched domains.
Waiting for verification…
Challenge failed for domain pianoconquest.com
Challenge failed for domain www.pianoconquest.com
http-01 challenge for pianoconquest.com
http-01 challenge for www.pianoconquest.com
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:

My web server is (include version): nginx 1.13.0

The operating system my web server runs on is (include version): ubuntu 18.04 lts

My hosting provider, if applicable, is: Google Cloud Platform

I can login to a root shell on my machine (yes or no, or I don’t know): Yes I can

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): Not Using a Control Panel

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): Certbot v 1.3.0 ina docker container

Additional Information:

I ran the same configuration quite a number of times (somewhere north of 10 times but under 15 times using the --staging flag to get the docker container volumes to map correctly) and it was successful for the last three trials. The domains validated properly and I had a sample certificate generated and stored in my designated location inside a folder with my domain name as the folder name ie pianoconquest.com/other/letsencrypt/stuff.

I deleted those certificates as my work directory was messed up and I wanted to generate a new one with a saner directory structure after which I attempted to test again with the --staging flag. This time it failed the challenge and has not been successful ever since.

I’ve looked up my domain at letsdebug.net and it says I should be fine but well… apparently i am not. lol.

I currently have a test file located at pianoconquest.com/.well-known/acme-challenge/test.html. if you want I can touch a new one to prove that the folder is responding to external requests.

I’d appreciate all the help I can get to debug this issue.

2

can your nginx read stuff from this location in the certbot container?

(PS: I've been trying to do the same for some time, there is no sane way to use certbot inside a docker container. You could potentially obtain certs with --standalone but you'd have no way to install or autorenew without mounting the docker socket inside the container or sharing the pid namespace with --pid=host. You might want to install it directly on the host, that way you can just --deploy-hook "docker exec whatever" or "docker kill -SIGHUP container")

3

Sorry for the late reply. So here’s a rundown of what I chose to do eventually:

Ditched the container path and went for a raw hosted certbox tool on my OS following your advice.
Tried to run the same install automatically but for some reason, I was getting a partial authorization error for the folder where I wanted to store the certificates.
Decided to ditch the auto-validate challenge path too.
Read extensively about the manual process of validation and since it allows me to renew with a single line of bash command ‘certbox renew’ to renew all certificates I went with it.

Command I ran: sudo certbot certonly --manual --staging -d pianoconquest.com

I eventually got a challenge task:

  1. Created a file containing some random string
  2. Renamed the file according to the link I was given and tested it following my own link to validate that it worked - It did.

So I went back to the terminal and continued the flow and finally, I was successful.
I guess I can deal with manually logging into the server every other 2.5 months for renewal purposes, or I’d find a clever way to write the cron job to handle it here on out.

As regards the docker procedure. I suspect the problem is the container’s inability to read the folder and write to it as well. I mean the /etc/letsencrypt/challenge/ which is odd because it did just that yesterday. It is possible i may have messed up the volume mapping between then and now however.

I tried the commands you suggested but found myself sliding down the rabbit hole of docker’s cryptic filesystem very fast and decided to give up quite quickly. Things started to get really complicated and I was afraid of being unable to replicate it sometime in the future should I ever have to.

I think it’s necessary to add that the Nginx service is still in a container. That part stayed intact.

I appreciate all the help regardless and I guess I’ll be fine now. Thanks for taking out the time to respond. :vulcan_salute: :vulcan_salute: :slightly_smiling_face:

4

you are trying to reimplement the --webroot plugin, don't. :smiley: it's there already.

just change the path to the right one (i suppose /var/www/html) or omit it.

you haven't installed your cert yet. it could probably just work if you run certbot --nginx

5

Ah! true now that i think about it. The webroot plugin was what i tried that gave me the weird partial authorization error.
The problem is the entire infrastructure lives in containers including the nginx instance and i was trying to keep that consistency hence the choice for dockerized certbot.

I tried using the webroot plugin to map the certbox to write to it (nginx-filesystem volume) as it is available realtime to the nginx container but it popped up the partial authorization error :sweat_smile: :sweat_smile:. Had to consider manual.
I’ll check the settings once again now that you mentioned it.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.