It produced this output:
Failed authorization procedure. pi.eazyigz.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 74.68.41.104:443 for TLS-SNI-01 challenge
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: pi.eazyigz.com
Type: connection
Detail: Failed to connect to 74.68.41.104:443 for TLS-SNI-01
challenge
My operating system is (include version): Raspberry Pi3 Debian 8
My web server is (include version): Google Subdomain
My hosting provider, if applicable, is: Google
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): domains.google.com
As certbot tells you, it is a connection issue. I canât connect to it either.
First, get to a point where someone outside your network can connect to your rpi on port 443 with a default/self-signed certificate. The latter will give a certificate warning, that is good indicator that things are set up correctly.
Right now, the connection times out. Once you have routing and firewalling configured correctly, but not yet started apache, the connection will reset immediately. When you then start apache with a self-signed cert, your external tester will get a certificate error.
Setting up the server for https with self-signed cert is the part I was missing on my own âhome boxâ system. Just decided to try that and was setting it up when I tripped over this post. Nice to know I was on the right path.
Yes, as @kkp and @gypsypriest indicate you need to port forward 443 to your Raspberry Pi. On my Plusnet (UK) HubOne modem/router I used âAdvancedâ, âFirewallâ, âPort forwardingâ and assigned âHTTPS Serverâ to the internal IP of my Pi.
telnet does nothing more than set up a TCP session. It sends a SYN packet towards your rpi, and waits for a SYNACK packet back. Now there are three different outcomes:
If the firewalling and routing is misconfigured, the packet never reaches the rpi, and the rpi never sends a SYNACK packet. My telnet will sit there, slowly transmitting SYN packets, and finally give up and time out. This is what happened here.(*)
If the packet reaches the rpi, and nothing is listening on port 443, the rpi will send an RST packet back. My telnet will print âconnection refusedâ.
If the packet reaches the rpi, and something is listening on port 443, the rpi will send a SYNACK packet. My telnet will print âconntectedâ.
(*) misconfigured routing and firewalling on the outbound path will give the same result as misconfigured firewalling on the inbound path.
Nope! telnet is able to connect to any sort of TCP server. You can see this with something like
telnet www.google.com 80 GET / HTTP/1.0
(It's not very useful to use telnet to establish communications with an actual TLS service because you probably won't be able to speak TLS, a binary protocol, very easily yourself.)