I Cant Get An SSL Certificate

My domain is: mcmoddev.tk

I ran this command: certbot certonly --webroot

It produced this output:`Microsoft Windows [Version 10.0.18363.1198]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Windows\system32>certbot certonly --webroot
Saving debug log to C:\Certbot\log\letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'
to cancel): mcmoddev.tk
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mcmoddev.tk
Input the webroot for mcmoddev.tk: (Enter 'c' to cancel): C:\xampp\htdocs
Waiting for verification...
e[31mChallenge failed for domain mcmoddev.tke[0m
http-01 challenge for mcmoddev.tk
Cleaning up challenges
e[31mSome challenges have failed.e[0m
e[0m - The following errors were reported by the server:

Domain: mcmoddev.tk
Type: dns
Detail: No valid IP addresses found for mcmoddev.tk`

My web server is (include version): APACHE 2.4.43

The operating system my web server runs on is (include version): WIN64 Home 1909

My hosting provider, if applicable, is: None

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot 1.9.0

I Have Tried To Get An SSl Certificate In manual Mode But It Doesn't Work

But Github Pages Giving An SSL Certificate Works

BTW My Isp/Router Blocks Connections Using A Devices Public IP So I Have To Use My Routers Public IP

This command seems incomplete.
The webroot has to match the root being served by your nginx web server.

Not necessarily, without -w it'll ask the user for the webroot, as shown further down in the log:

There is another issue altogether:

The host resolves to a private IP range:

mcmoddev.tk. 3600 IN A

@PutoPug You can't use the webroot plugin if your hostname resolves to a private IP range. If your server isn't reachable from the world wide web, you'll need to use the dns-01 challenge.

1 Like

Then that must have been a recent IP change:

curl -Iki mcmoddev.tk
HTTP/1.1 203
Server: nginx
Date: Fri, 20 Nov 2020 09:24:31 GMT
Content-Type: text/html;charset=UTF-8
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Server: ip-172-31-21-103

@rg305 Are you sure that's not something from your own infrastructure? Looking at the HTTP 203 response status code and the X-server header (which I don't see very often and which is also pointing to a private IP range).

That's because it must have been another IP at that time.
This is what I get now:

curl -Iki mcmoddev.tk
curl: (7) Failed to connect to mcmoddev.tk port 80: Connection timed out

Based on my logs, the IP was at that time.

And as evidenced by:

curl -Iki
HTTP/1.1 203
Server: nginx
Date: Fri, 20 Nov 2020 10:29:06 GMT
Content-Type: text/html;charset=UTF-8
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Server: ip-172-31-12-230

So What Should I Do?

You mean this evidence?:

osiris@erazer ~ $ telnet 80
telnet: connect to address No route to host
osiris@erazer ~ $ traceroute
traceroute to (, 30 hops max, 60 byte packets
 5 (  19.774 ms  19.762 ms  20.878 ms
 6  ams-eq6-01c.voxility.net (  22.056 ms ams-eq6-01c.voxility.net (  23.917 ms ams-eq6-01c.voxility.net (  23.885 ms
 7  * (  11.237 ms *
 8 (  11.501 ms !X (  12.524 ms (  12.521 ms !X
osiris@erazer ~ $ 

Notice the !X.

Even if there were a different IP than there is now, I doubt it would have been succesful.

More proof: if you do a whois, you'll see the IP range is assigned to the "OpenTLD Web Network TK", which probably is the organisation running the dot-TK TLD.

You should point your domain to the correct (i.e., public) IP address of your server.

I showed you what I connected to.
And then reconnected to it and got the same result.
I rest my case.

@rg305 That might be the case, but:

a. the domain isn't pointing to that IP address any longer
b. it probably didn't work in the first place, because it 1. most likely isn't the IP address of the OP and 2. the HTTP 203 status code isn't very regular and I wouldn't expect to see something like that at the nginx configuration of a "normal" user.

It means he has changed the IP.

Yes, this we can all see from the 10 dot IP it now has.

@Osiris, you asked if what I connected to was within my own infrastructure.
The answer to that was what I posted.
The evidence was to show that it wasn't from anything in my own infrastructure.
And the only reason we got different results was timing.
He must have changed the IP from the time I connected and the time you connected.
As evidenced above.

AND if you can't reach that IP, then there are some GeoLocation rules blocking you OR the Internet is broken (again) - LOL

Hi @PutoPug


D:\temp>nslookup mcmoddev.tk. ns01.freenom.com.
Name: mcmoddev.tk

not a public ip address. So http validation can't work.

If you don't have a public ip address, you can't use http validation.


So I Just Used DNS verification And it Woks
Thanks :slight_smile:

1 Like

But will you be accessing that system from the Internet?
Or only from within your internal/local network?

I Want To Access From Internet

Then you need to provide the Internet a way to reach your server.
[and your problem is not yet (completely) solved]

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