Certificat not validate

[pcouas]

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: pcouas.tk

I ran this command: letsencrypt-auto certonly --standalone -d pcouas.tk

It produced this output:

Domain: pcouas.tk
Type: unauthorized
Detail: Invalid response from http://pcouas.tk/.well-known/acme-challenge/SpKK44YDNjUZtILEIrD_-cJlAQAI9fQaJnVJviLgxbM: "

<titl"

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.
2018-02-17 09:01:25,853:INFO:certbot.auth_handler:Cleaning up challenges
2018-02-17 09:01:25,853:DEBUG:certbot.plugins.standalone:Stopping server at :::80…
2018-02-17 09:01:26,175:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File “/opt/eff.org/certbot/venv/bin/letsencrypt”, line 9, in
load_entry_point(‘letsencrypt==0.7.0’, ‘console_scripts’, ‘letsencrypt’)()
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 1240, in main
return config.func(config, plugins)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 1120, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 118, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/client.py”, line 357, in obtain_and_enroll_certificate
certr, chain, key, _ = self.obtain_certificate(domains)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/client.py”, line 318, in obtain_certificate
self.config.allow_subset_of_names)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/auth_handler.py”, line 81, in get_authorizations
self._respond(resp, best_effort)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/auth_handler.py”, line 138, in _respond
self._poll_challenges(chall_update, best_effort)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/auth_handler.py”, line 202, in poll_challenges
raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. pcouas.tk (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://pcouas.tk/.well-known/acme-challenge/SpKK44YDNjUZtILEIrD-cJlAQAI9fQaJnVJviLgxbM: "

<titl"

I have change resolv.conf to dns provided by freenom 80.80.80.80 and 80.80.81.81 ?
Where is my mistake ??

My web server is (include version): tomcat7

The operating system my web server runs on is (include version): centos 6.9

My hosting provider, if applicable, is:

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

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

[jared.m]

When Let’s Encrypt requests the challenge file located at http://pcouas.tk/.well-known/acme-challenge/SpKK44YDNjUZtILEIrD_-cJlAQAI9fQaJnVJviLgxbM, your server is returning some HTML content instead. You need to find out why your server isn’t serving files out of .well-known/acme-challenge properly. A good test is to create a test file there (one you could access by going to http://pcouas.tk/.well-known/acme-challenge/test and see if you can load that properly.

[_az]

To add, the IP address to which the domain points (195.20.40.206) appears to be a domain redirector, run by Freenom.

It uses HTML-based redirect to perform the redirect to your IP address.

You will not be able to issue a certificate if the domain is setup this way. At minimum it must either do a 3xx redirect to your server (using Location redirect rather than HTML redirect), or the domain should resolve directly to your IP address, or you will have to use DNS challenge rather than HTTP/standalone/webroot.