Your SSL certificate is current. Your SSL certificate expires in 89 days. (2019-12-22)
Protocols
You currently have TLSv1 enabled.
This version of TLS is being phased out. This warning won't break your padlock, however if you run an eCommerce site, PCI requirements state that TLSv1 must be disabled by June 30, 2018.
So, how do I troubleshoot this? I'm running Ubuntu 18.04 on nginx 1.14.2. This setup is for a Wordpress site. The host has it set up under two separate nginx conf files- one for wordpress ssl and one for non-ssl. Here is the SSL conf file:
server {
listen 443 ssl default_server;
server_name _; #server_namewordpress.example.com;
Keep in mind, I have not done any web development in a while and hosts always set up these wacky nginx configs, so I'm floundering here, slightly. Any tips, tricks. Any way to figure out what the hell is going on here? I don't have any sites-available/sites-enabled config files. Just these guys... as far as I know.
I can only assume that the SSL settings are still sticking to a self-signed cert that was set up when the instance was generated.
Please fill in the below form in order for us to help you:
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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
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):
My domain is: shapingla.com (part of my comment already)
I ran: no command… The issue isn’t the output of a command. The issue is that my ssl doesn’t work. I posted an analysis of the SSL. Already explained this
I already explained what webserver I was running.
I already explained what my OS is.
My host is Vultr
I can run as root
I’m not using a control panel.
Certbot version 0.23.0
Well. As the web page said, you only requested a single domain certificate, which will only secures shapingla.com, if you want to also secure the www version of your website, please add www.shapingla.com when you tried to request that certificate.
For example: if you are using certbot, you should use certbot -d shapingla.com -d www.shapingla.com instead of certbot -d shapingla.com.
When I try to access https://shapingla.com, I still get a browser warning that the site is insecure. Will it not secure shapingla.com, either, if all certificates aren’t accounted for?
Your site have a redirection setup which would redirect requests from shapingla.com to www.shapingla.com, which is causing the certificate error.
Also, upon checking the certificate transparency logs, it seems that you already have a certificate with both hostnames set up. Please run certbot certificates and share us your result.
Now the case seems to be like this: You have a certificate with only one host, and a certificate with two hosts. You'll need to first find out where is the second certificate, then modify the Nginx virtual host configuration to use that certificate.
Nope. You already have the certificate issued. Also, revoking a certificate is often unnecessary if the keys aren't leaked to the public.
Please run the command certbot certificates and share us the output...
This command is going to list all certificates in this system and their path to root.
Please don't request a new certificate if the old one is still present.
Here is the output. It looks like there must be another cert somewhere, because this one only works for shapingla.com
I really wish hosts wouldn't do this automatically.
Any tips on how to find the others and get rid of them?
The only thing I can think of is that under /etc/nginx/ssl, there are two files : server.crt and server.key.
Should I recursively grep for these in the nginx folder?
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Found the following certs:
Certificate Name: shapingla.com
Domains: shapingla.com
Expiry Date: 2019-12-22 17:38:35+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/shapingla.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/shapingla.com/privkey.pem
:edit: I'm assuming if I can find out where these are referenced in config, i can remove them? They don't conform to the cert structure for Lets Encrypt certs (.crt instead of .pem, for example)... would it be feasible to replace them?
So since the old certificate is not found, you need to create a new one.
Also, is there a reason why you want to use manual DNS validation instead of http validation? (Since the domain and server seems to be the same)
manual DNS validation... is really not good for renewal.
That's a good move
Now you only need to request the new certificate, then please run to certbot certificates and see what's the full certificate path for the new certificate, then find the Nginx virtual host (SSL/Port 443) and replace the previous reference to the new one.
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: --manual-auth-hook /etc/letsencrypt/vultr-dns.py create --manual-cleanup-hook /etc/letsencrypt/vultr-dns.py delete -d shapingla.com dns-01
It seems like it's stripping the quotes or something....