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.
It produced this output:
The following certs are not due for renewal yet:
/etc/letsencrypt/live/slidepipe.com/fullchain.pem expires on 2020-05-08 (skipped)
/etc/letsencrypt/live/www.slidepipe.com/fullchain.pem expires on 2020-05-08 (skipped)
No renewals were attempted.
My web server is (include version):nginx
I renewed the cert but in the web is still missing it. Renewal output
Your renewal configuration file is ‘missing’ an installer line. Perhaps you’ve used certbot-auto with the certonly method, which gives you a renewable certificate, but needs you to install the cert manually into the webserver. In that case, after renewal, nginx isn’t reloaded automatically. Most users use a deploy-hook to reload their webserver after renewal.
root@slidepipe-master:/etc/letsencrypt/live/slidepipe.com# sudo certbot-auto -i nginx slidepipe.com
/usr/local/bin/certbot-auto has insecure permissions!
To learn how to fix them, visit Certbot-auto deployment best practices
usage:
certbot-auto [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] …
Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: unrecognized arguments: slidepipe.com
:/etc/letsencrypt/live# sudo certbot-auto certonly -n -d slidepipe.com -d www.slidepipe.com
/usr/local/bin/certbot-auto has insecure permissions!
To learn how to fix them, visit Certbot-auto deployment best practices
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Missing command line flags. For non-interactive execution, you will need to specify a plugin on the command line.
@facildeanotar This isn’t going to work. From my perspective, it looks like you’re randomly mixing command line options without actually doing what @JuergenAuer recommends. For example, where does the certonly come from? That is exactly the opposite of -i nginx. Or the -n?
As your nginx currently only serves the www subdomain certificate, which isn’t very good if someone would try to connect to https://slidepipe.com, I would suggest just getting a brand new certificate covering both your hostnames:
It did that, but now that you've got a certificate with both hostnames, there's no certificate issue any longer. Also, your HTTP site redirected all non-encrypted traffic to the www subdomain with HTTPS, so normally users wouldn't be bothered by a warning, as normally users would not end up to the HTTPS non-www hostname.