Hi
I am writing a python script to create a certificate by existing CSR(certificate signing request) in noninteractive mode.
I execute the command, “certbot certonly --webroot -w /usr/local/bin/example/www/w3root -d example.com -n --agree-tos --email flamingo@example.com --csr //usr/local/bin/arcnas/www/w3root/server.csr”, and return the message as below,
#################################################################
IMPORTANT NOTES:
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
#################################################################
How could I fix it?
Thanks,
The webserver should only respond with the token in plain text when asked for the challenge. Your webserver is responding with HTML. Why? That’s for you to find out. Perhaps it’s the default 404 file not found page or perhaps the webserver always responds with HTML when requested for anything.
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.
Because I am writing a script to help people use certbot to apply for the certificate, I just could make up a domain name, example.com, to test my script.
I used to replace the domain name with a legal one, I still got the same issue.
In other words, if people use my script, they suppose to provide a legal domain name.
I am not sure my idea makes sense or not.
Please give me some clues to work it out.
Thank you,
The confusing thing here is that the error that you encountered appears very specific to the configuration of a particular site. In particular, a particular server did not correctly serve files placed in the specified webroot. It seems like this error can be resolved for this site by fixing the web server configuration, but it’s hard to understand why other users would encounter exactly the same error.
Hi @schoen
Thanks for response.
I am not sure we are on the same page.
The users you point out are for my script or your users for Certbot who have nothong to do with mine??
a) if you are writing a script you should test against the staging environment by using --staging
b) if you are testing what is your test domain.
c) Let’s Encrypt usually returns errors if it’s not able to complete the challenge. To find out why this is happening we need to know what domain you are testing against
If your script is going to be used by other people, I'm not sure why they would have this particular problem, since this problem seems to relate to the web server configuration. But I'm more confused about what you said here:
Nobody can get a certificate from Let's Encrypt using certbot --webroot unless the certbot --webroot command is run on an actual web server that is serving pages for the requested domain name. It doesn't really make sense to do a test with a made-up domain name, or with a domain name that isn't pointed to your own web server. In such cases, Let's Encrypt will always say that you have failed to prove control of that domain name, because the purpose of --webroot is to make a change to your web site control to prove that you control the domain name that you're asking for a certificate for. The CSR is not sufficient to obtain a certificate without also performing this proof of control.