Certificate Expiration on Server

Hi all, I have an email saying certificate expires on the 29th.

Is there a handy guide for how to install the certificate? I had a dev set up my server but now I don’t have funding to be able to pay for a service.

Much appreciated.


the easiest way to get a Let’s Encrypt certificate and to set it up afterwards is to use Certbot (https://certbot.eff.org/). On the start page you can select which software on which system you are using. You will be automatically redirected to the according tutorial.


Also, it can’t hurt to check your certificate really expires on the 29th by examining the “not after” date shown. Exactly how to do this varies by browser, but it’s usually fairly obvious.

The email warnings specify which cert is expiring but sometimes a developer might have created another similar one and abandoned it. If the cert on your site is newer it might be getting renewed automatically and then you’ve no work to do. If it is indeed expiring, carry on.

1 Like

I would suggest finding out from your developer what method was used to obtain your original certificate, in order to continue using the same method for your renewal if possible.

sorry for the delay in replying, I’ve been away for a few days. Eager to get this sorted now :slight_smile:

My dev had told me it’s the certificate for the actual server, server.domain.com (Webmin/VirtualMin) not the actual website.

Is this the same method to apply new certificate?

I didn’t quite understand your summary of what the developer told you. If the certificate was obtained using the certificate feature inside Webmin, then it should be possible to get a new certificate using that feature too.

I don’t know if this is at all up-to-date but this is a sample description of how to use that feature:

Ive been trying to find a way to access my server but I get the ‘connection is not private’ Your connection is not private

Attackers might be trying to steal your information from server.matchedbettingforums.com (for example, passwords, messages or credit cards). Learn more
Subject: vps417192.ovh.net
Issuer: vps417192.ovh.net
Expires on: 31 May 2018
Current date: 4 Sep 2017
PEM encoded chain:

So I cannot actually login to my webmin/virtualmin.

Is there a way to bypass this issue?

thanks for the guide!

Requesting a certificate for (DOMAINS) from Let’s Encrypt …
… request failed : The native Let’s Encrypt client was used previously on this system, and must be used for all future certificate requests

I have got to this point from the guide, no success but getting close i think!

Any ideas?

This suggests that your developer used Certbot. Can you log in to a command line on the server via SSH? Perhaps you’re not previously familiar with this process?

this is from putty when i try to do SSL renewal via SSH

Requesting a certificate for (DOMAINS) from Let’s Encrypt …
… request failed : The native Let’s Encrypt client was used previously on this system, and must be used for all future certificate requests

That specific message appears to be from webmin when you try to run a Let’s Encrypt certificate request through it. You can either find and use certbot/letsencrypt directly or delete the entire /etc/letsencrypt directory and use the built-in support in Webmin. Note that deleting that directory will also delete all your current certificates.

I’d suggest trying using certbot directly before deleting directories. You can first try simply running “certbot” or “letsencrypt” when you connect using SSH to see if either of these are installed directly on the system. If one of those works, you should be in good shape to get things renewed.

by this do you mean by simply typing ‘certbot’ directly on my SSH? Thanks for your support

You could try running history | grep certbot to learn if the original developer did something different to run Certbot (for example, perhaps using the certbot-auto autodownloader instead of an operating system package). However, @motoko’s suggestion was indeed to try running certbot itself at a prompt.

Hi @ForumMatchedBet,

It looks like this history shows a degree of confusion on the original developer’s part. For example, /path/to/certbot-auto is not meant to be typed in literally, but is meant to indicate to the user to substitute the actual directory path to the certbot-auto program (which is different on every system because you decide where to download certbot-auto). Also, the commands after the $ were meant to be run as separate commands. The $ symbol represents the command prompt from the OS, and is not meant to be typed in explicitly, nor is it meant to be combined with another command. The $ is a convention to show that what follows is typed in response to the $ prompt from the OS. Yet at least at first, your developer seems to have tried to type it in as though it were part of the commands in the tutorial. So, there are signs that your developer did not at first understand some of the conventions used in Unix-oriented documentation and tutorials—about what is or isn’t meant to be typed literally.

It looks like certbot-auto was probably downloaded into /opt/matchedb_forum, but I’m still not positive whether it was later used correctly from there. :slight_smile:

Maybe you could try running

ls -l /opt/matchedb_forum/certbot-auto

and also

sudo /opt/matchedb_forum/certbot-auto certificates

thanks for replying, I have tried entering the 2 codes you sent me but I am getting a command not found error

[root@server matchedb_forum]# ls -l /opt/matchedb_forum/certbot-auto
ls: cannot access /opt/matchedb_forum/certbot-auto: No such file or directory
[root@server matchedb_forum]#
[root@server matchedb_forum]# sudo /opt/matchedb_forum/certbot-auto certificates
sudo: /opt/matchedb_forum/certbot-auto: command not found
[root@server matchedb_forum]#
[root@server matchedb_forum]#

You could also try

locate certbot

There’s also the possibility that the developer used a different client rather than Certbot (or even ended up using a web-based client like https://zerossl.com/ which doesn’t involve running software on the server and doesn’t have any kind of automated renewal mechanism). However, this seems to be in contradiction to the claim that “The native Let’s Encrypt client was used previously on this system” which would most likely refer to Certbot.

Do you know where your certificate is located on disk?

ok so I think there’s a mistake here

if i go to your website this is the certificate I get. This is a self signed certificate which is why it’s not trusted.

A certificate was obtained for your domain.


However it has not been renewed

Rather than trying to figure out what your developer did I would focus on the future.

Do you want a certificate from Let’s Encrypt

If so have you done any research on webmin plugins for Let’s Encrypt


Yikes, that’s a lot of output!

Perhaps you could try running

/opt/letsencrypt/certbot-auto certificates

If that apparently finds your certificate, you could then try

/opt/letsencrypt/certbot-auto renew

Depending on how it was set up, it may succeed in renewing automatically… or you may get an error pointing to some kind of difficulty in the process.

Not sure if it’s worth pointing out I am running multiple websites from this server.
although it has failed, we seem to be getting somewhere now.

This shows in red:
Attempting to renew cert (server.matchedbettingforums.com) from /etc/letsencrypt/renewal/server.matchedbettingforums.com.conf produced an unexpected error: Failed authorization procedure. server.matchedbettingforums.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://server.matchedbettingforums.com/.well-known/acme-challenge/4cMWjQGtyyYeaapx2v_IN6XxPyhxuQrzUVSZp6SGTiU: "

". Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/server.matchedbettingforums.com/fullchain.pem (failure)

That is definitely some kind of progress. This sounds like a problem that your webroot is no longer correct. Is it possible that the directory path that the site is served from has changed since the time that the certificate was originally installed, or that the site is no longer configured to serve static files directly out of the filesystem (e.g. using some kind of proxy directive to route everything to a web application)?