Used Certbot and rollback and website still not working :(

Please help! After I used the bot my website is now refusing connections. I don’t know where to begin in debugging this.

My domain is: http://www.techmasterdesign.com

I ran these commands: sudo snap install --classic certbot; sudo certbot --apache

It produced this output: normal output saying everything worked, but then when I went to test to see if the website was working, I got “ERR_CONNECTION_REFUSED.” At this point I ran the command “certbot --apache rollback” hoping it would fix everything, but to my surprise, the website remained inaccessible.

My web server is (include version):
Server version: Apache/2.4.29 (Ubuntu)
Server built: 2020-08-12T21:33:25

The operating system my web server runs on is (include version): Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-96-generic x86_64)

My hosting provider, if applicable, is: Godaddy with Dynamic DNS from Netgear provided by NoIP

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

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

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

Your site is working nicely here, albeit it being through HTTP. There is no HTTP to HTTPS redirect present and HTTPS isn’t working (timeout).

Unfortunately, you didn’t actually pasted the output. We just need to trust you on if you have interpreted the output correctly. Because certbot should have asked you if you’d want a redirect. But I have no idea if you ansered with “yes” or “no” nor if the application of the redirect worked at all. In any case, it’s not there.

Although, I see now from the title you’ve used the rollback feature… That would explain why there is no redirect any longer.

For HTTPS you’d need an open port 443. Perhaps open it in your firewall or firewalls and/or open the port in your (NAT) router.

hmm, interestingly enough it started accepting HTTP requests again. I did not port forward 443, that might have been the problem. I don’t remember it asking me if I wanted to redirect, but I will try using the bot again and forwarding that port. It seems like some of my subdomains are still broken :frowning: It seems like the browser is trying to default to HTTPS, let me clear the cache. Yep, the cache was causing the URLS to default to https, but hide to the left of the domain (chrome). I presume after using the rollback command, it fixed the configuration but then the cached URL and pages were causing it to still not load the page. By the way, thank you for your quick reply and support <3. This time I will copy the entire command line output and input.

Alright. All is well now. You were right, all I had to do was forward port 443, also on a side note, it did not ask me if I want to redirect HTTP to HTTPS. Only problem is now that my websites look all fucked up lol, perhaps i’m not ready for HTTPS. It’s always a sweaty moment when I change my entire web configuration. It seems like many elements of the multiple websites hosted under my domain are not HTTPS compatible. For now, i’m going to leave HTTPS off with certbot --apache rollback because i’m too lazy to fix all of the webpages (for now). Seems like a display element carousel and certain forums don’t like HTTPS.

Here is the command line:

Last login: Tue Sep 8 12:28:55 on ttys000
Users-MacBook-Pro-2:~ user$ ssh george@66.215.103.152
george@66.215.103.152’s password:
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 4.15.0-117-generic x86_64)

System information as of Tue Sep 8 12:32:47 PDT 2020

System load: 1.19 Processes: 152
Usage of /: 2.9% of 915.89GB Users logged in: 0
Memory usage: 5% IP address for eno1: 192.168.1.25
Swap usage: 0%

  • Kubernetes 1.19 is out! Get it in one command with:

    sudo snap install microk8s --channel=1.19 --classic

    https://microk8s.io/ has docs and details.

  • Canonical Livepatch is available for installation.

0 packages can be updated.
0 updates are security updates.

Last login: Tue Sep 8 12:28:59 2020 from 66.215.103.152
george@dell-emc:~$ sudo certbot --apache
[sudo] password for george:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?


1: www.techmasterdesign.com


Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel):
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t close to expiry.
(ref: /etc/letsencrypt/renewal/www.techmasterdesign.com.conf)

What would you like to do?


1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (may be subject to CA rate limits)


Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 1
Keeping the existing certificate
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/000-default-le-ssl.conf
Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-enabled/000-default-le-ssl.conf


Congratulations! You have successfully enabled https://www.techmasterdesign.com


IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/www.techmasterdesign.com/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/www.techmasterdesign.com/privkey.pem
    Your cert will expire on 2020-12-07. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot again
    with the “certonly” option. To non-interactively renew all of
    your certificates, run “certbot renew”

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le

Browsers will refuse to load/run scripts and other kind of security sensitive stuff if they are not loaded through HTTPS if the site itself is HTTPS… That’s called “mixed content”. If you enable HTTPS, you should make sure all content of the site (including images, CSS, everything) is loaded through HTTPS too.

The best way to do that is not use http://example.com/foo/bar or https://example.com/foo/bar but just use //example.com/foo/bar. That’s called a protocol relative URL.

1 Like

reading the logs:

seems like there’s a problem with the nginx binary: “Could not find a usable ‘nginx’ binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.” However, it seemed that the HTTPS installation worked fine, minus the predictable issues with webpages.

2020-09-08 12:38:27,781:DEBUG:certbot._internal.main:certbot version: 1.8.0
2020-09-08 12:38:27,781:DEBUG:certbot._internal.main:Arguments: [’–apache’]
2020-09-08 12:38:27,781:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2020-09-08 12:38:27,790:DEBUG:certbot._internal.log:Root logging level set at 20
2020-09-08 12:38:27,790:INFO:certbot._internal.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2020-09-08 12:38:27,862:DEBUG:certbot_apache._internal.configurator:Apache version is 2.4.29
2020-09-08 12:38:28,057:DEBUG:certbot._internal.plugins.disco:No installation (PluginEntryPoint#nginx): Could not find a usable ‘nginx’ binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.
Traceback (most recent call last):
File “/snap/certbot/579/lib/python3.8/site-packages/certbot/_internal/plugins/disco.py”, line 157, in prepare
self._initialized.prepare()
File “/snap/certbot/579/lib/python3.8/site-packages/certbot_nginx/_internal/configurator.py”, line 184, in prepare
raise errors.NoInstallationError(
certbot.errors.NoInstallationError: Could not find a usable ‘nginx’ binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.
2020-09-08 12:38:28,059:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * apache
Description: Apache Web Server plugin
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = certbot_apache._internal.entrypoint:ENTRYPOINT
Initialized: <certbot_apache._internal.override_debian.DebianConfigurator object at 0x7f909936bc70>
Prep: True

I think that’s just the nginx module “probing” for any possible nginx binary. You’re using Apache, right? And the apache plugins works. So you can ignore the stuff about nginx.

You’re right, I am not even using nginx as a webserver so it’s just saying, there is no nginx binary. I am using apache2. I think one day I will have to go in and change a bunch of HTML code to https :confused: lol.

Consider using sed -i for that.

$ echo 'HTTP is a great protocol. Everybody uses HTTP every day for web browsing. Make sure that your site properly supports HTTP!' > example
$ cat example
HTTP is a great protocol. Everybody uses HTTP every day for web browsing. Make sure that your site properly supports HTTP!
$ sed -i 's/HTTP/HTTPS/g' example
$ cat example
HTTPS is a great protocol. Everybody uses HTTPS every day for web browsing. Make sure that your site properly supports HTTPS!

(do use it carefully and make a backup of your HTML files before running it!)

Not a fan of protocol relative URLs @schoen?

I think they’re great, but if you’re already using them you probably wouldn’t need to change the links at all.

I just did the painstaking thing of going through every single page and using find and replace. Luckily, not a lot of my links were relative, but a lot were. I then used a dead link tool. The only problem with using sed -i that I see is that not every URL is HTTPS, however a lot are. You could use sed -i and then use a dead link tool to find all the http->https occurance changes that were actually HTTP. Nonetheless, thank you both for your help and suggestions, now it’s time to donate to letsencrypt :).