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: dineok.amepos.in
I ran this command: salt minionname state.apply letsencrypt and also certbot certonly --force-renew -d dineok.amepos.in
It produced this output:success, but website is not secured
My web server is (include version): nginx
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):yes
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):
Please don't use that option unless you actually know when to use it. It does NOT "magically" make e.g. failing challenges succeed.
On https://crt.sh/?Identity=dineok.amepos.in&deduplicate=Y I can see a few certificates, but your most recent one isn't yet due for renewal. Let's Encrypt recommends to renew when the certificate is 30 days away of expiry, which is not the case yet. But it also shows there has not been a renewal recently, so your (unnecessary) forced renewal did actually not succeed, contrary to what you answered in the It produced this output question. Unless crt.sh is backed up again, which happens sometimes. Therefore, it's always a good idea to not only post your own interpretation of outputs, but to post the actual output.
That said, your webserver is using the certificate issued before the one from August. I don't have experience with "salt", but it seems your webserver isn´t using the correct certificate. And it's rather difficult to advice when two separate clients (salt and certbot) are being used: which certificate is nginx configured for?
You can use the command certbot certificates to see what certificates Certbot knows about internally.
In nginx webserver we have given this
ssl_certificate /etc/letsencrypt/live/{{dns_name}}/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/{{dns_name}}/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/{{dns_name}}/chain.pem;
:/etc/letsencrypt/live/dineok.amepos.in# ls -l
total 12
lrwxrwxrwx 1 root root 40 Oct 20 04:46 cert.pem -> ../../archive/dineok.amepos.in/cert5.pem
lrwxrwxrwx 1 root root 41 Oct 20 04:46 chain.pem -> ../../archive/dineok.amepos.in/chain5.pem
lrwxrwxrwx 1 root root 45 Oct 20 04:46 fullchain.pem -> ../../archive/dineok.amepos.in/fullchain5.pem
-rw------- 1 root root 7300 Jan 13 2022 fullchain-privkey.pem
lrwxrwxrwx 1 root root 43 Oct 20 04:46 privkey.pem -> ../../archive/dineok.amepos.in/privkey5.pem
-rw-r--r-- 1 root root 692 Jan 13 2022 README
And the output of certbot certificates? Just to double check
By the way, crt.sh | dineok.amepos.in currently also shows a certificate issued today. Probably indeed the backlog I said earlier. While totally unnecessary as I said earlier as your certificate from August was still valid long enough, it does show Certbot can renew when forced to do so.
However, nginx is still serving the old certificate. As you were using certonly, you probably simply need to reload nginx to make it read the new certificate.
You can see how those both commands are not the same, right? So I'm very puzzled that if I ask for command A, suddenly it's turned into command B, which is entirely different?
You have to wait 60 (!!!) days to renew your currently perfectly fine certificate. It has renewed today, unnecessarily (too soon) and isn't up for renewal for 60 more days. Do NOT use the --force-renewal command in the future any more please. You probably don't need to run anything to renew your certificate, usually there's a cron job or systemd timer which runs certbot renew twice a day and will renew the certificate if necessary, but NOT sooner.
Your problem is your nginx: it doesn't know about the most recent certificate YET. It probably just needs a reload.
salt droplet-ameshop-backend-dev2 state.apply letsencrypt
droplet-ameshop-backend-dev2:
ID: letsencrypt-client
Function: pkg.installed
Result: True
Comment: All specified packages are already installed
Started: 06:37:11.371204
Duration: 65.573 ms
Changes:
ID: letsencrypt-config-directory
Function: file.directory
Name: /etc/letsencrypt
Result: True
Comment: The directory /etc/letsencrypt is in the correct state
Started: 06:37:11.440511
Duration: 2.638 ms
Changes:
ID: letsencrypt-config
Function: file.managed
Name: /etc/letsencrypt/cli.ini
Result: True
Comment: File /etc/letsencrypt/cli.ini is in the correct state
Started: 06:37:11.443339
Duration: 28.584 ms
Changes:
ID: letsencrypt-service-timer
Function: service.running
Name: certbot.timer
Result: True
Comment: The service certbot.timer is already running
Started: 06:37:11.473416
Duration: 70.706 ms
Changes:
ID: /usr/bin/certbot renew --dry-run --no-random-sleep-on-renew --cert-name
Function: file.absent
Result: True
Comment: File /usr/bin/certbot renew --dry-run --no-random-sleep-on-renew --cert-name is not present
Started: 06:37:11.544546
Duration: 1.149 ms
Changes:
ID: /usr/bin/certbot renew
Function: file.absent
Result: True
Comment: File /usr/bin/certbot renew is not present
Started: 06:37:11.546572
Duration: 1.491 ms
Changes: