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[1m
IMPORTANT NOTES:
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
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 10.255.11.15
@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.
@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).
osiris@erazer ~ $ telnet 195.20.44.199 80
Trying 195.20.44.199...
telnet: connect to address 195.20.44.199: No route to host
osiris@erazer ~ $ traceroute 195.20.44.199
traceroute to 195.20.44.199 (195.20.44.199), 30 hops max, 60 byte packets
(...)
5 80.249.210.43 (80.249.210.43) 19.774 ms 19.762 ms 20.878 ms
6 ams-eq6-01c.voxility.net (5.254.73.70) 22.056 ms ams-eq6-01c.voxility.net (5.254.73.74) 23.917 ms ams-eq6-01c.voxility.net (5.254.73.70) 23.885 ms
7 * 5.254.73.150 (5.254.73.150) 11.237 ms *
8 5.254.73.150 (5.254.73.150) 11.501 ms !X 37.46.195.28 (37.46.195.28) 12.524 ms 5.254.73.150 (5.254.73.150) 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 195.20.44.199, 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.
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.
@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