Certificate expiration Please for help


#1

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.

My domain is: doumer.me

I received this message;

Your certificate (or certificates) for the names listed below will expire in
10 days (on 15 May 18 18:47 +0000). Please make sure to renew
your certificate before then, or visitors to your website will encounter errors.

Please what should I do in other to avoid that my certifcate expires


#2

Depends on how you installed the certificates in the first place.


#3

I installed it on google cloud on an apache server for wordpress


#4

HOW*?

What commands did you run? Or did you use a control panel? If so, which one and how did you do it? Et cetera.


#5

We are agreed, you setup the cert but haven’t setup automatic renewals.
https://crt.sh/?q=%doumer.me

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.

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):


#6

My domain is : doumer.me

I used certbot to set my SSL,
Here are the commands :
wget https://dl.eff.org/certbot-auto && chmod a+x certbot-auto
./certbot-auto certonly --webroot -w /opt/bitnami/apps/wordpress/htdocs/ -d 1pagezen.com -d www.1pagezen.com
./certbot-auto renew --dry-run

Then I set this in my server in other to ensure auto renewal of my certificates :slight_smile: 0 0 * * * ./certbot-auto renew --quiet --no-self-upgrade
0 12 * * * ./certbot-auto renew --quiet --no-self-upgrade

Note I am using Apache and Bitnami
My apache version is Apache/2.4.29 (Unix)
The operasting system is linux : Debian 4.9.65-3+deb9u2
My hosting provider is Google Cloud
I dont know if I can login to a rootshell on my machine
No I’m not using a control panel to manage my site


#7

You initially setup the cert via “certonly”
That does not set things up for future renewals.

Please place a test.txt file in the challenge folder:
http://doumer.me/.well-known/acme-challenge/text.txt

Also…
You have two redirects:
http://doumer.me/.well-known/acme-challenge/text.txt 302 Found
https://www.doumer.me/.well-known/acme-challenge/text.txt 301 Moved Permanently
https://doumer.me/.well-known/acme-challenge/text.txt


#8

What do you mean by that, @rg305? certbot-auto renew would attempt to renew certificates that were obtained by certbot-auto certonly.


#9

@schoen maybe it’s just lack of sleep…
I would need to see the renewal/<domain>.conf file to be sure.
But I’m thinking it wouldn’t know about webroot or Apache and would be like running:
certbot-auto renew --manual -d domain --quiet
unattended in a script.

[EDIT]
That does not set things up for future renewals.
Should maybe read more clearly as:
That does not guarantee that things are setup properly for future renewals.


#10

When you get a certificate via certonly, it creates a renewal configuration file in /etc/letsencrypt/renewal and the settings in that file will be used by renew. If the authenticator is manual, then the renewal can’t work unless you also provided an auth-hook. Otherwise, the renewal will use the same settings that were first used with certonly, and should work properly.


#11

Ok, so we need to see what is in:
/etc/letsencrypt/renewal/<domain>.conf
to be 100% certain.
At this point we don’t even know what version of certbot/certbot-auto is being used.

Given: Whenever a cert is received, the renewal/.conf file is created/updated.
But that doesn’t ensure that exact setting can be used for renewals (not 100%).

Having a look at the /var/log/letsencrypt/letsencrypt.log may also prove helpful.


#12

This may also be providing unexpected results; as the start location may not align with where certbot-auto can be found. Where was he “standing” when he downloaded it to his location?
Calling it explicitly would ensure that it was run. Like:
0 0 * * * /complete/path/to/certbot-auto renew --quiet --no-self-upgrade
0 12 * * * /complete/path/to/certbot-auto renew --quiet --no-self-upgrade
To that end, I suggest finding it and updating the cronjob with the complete file path.
which certbot-auto
cd / && find / -name certbot-auto
one, or both, should provide the location.


#13

certbot-auto from a distinct directory and cron could be a pickle indeed.

I would recommend building a cronjob with two commands combined with &&:

  1. cd /directory/where/certbot-auto/is/located/
  2. and ./certbot-auto renew

So you would get: cd /directory/where/certbot-auto/is/located/ && ./certbot-auto renew

Do note: with certonly your webserver won’t recognise the new certificate: it needs to be reloaded after the certificate was renewed.

To mitigate that shortcoming, you can add the Apache reload command from your OS to the --deploy-hook option of certbot.


#14

That move should be the first lines of code in certbot-auto
Find yourself, cd to that directory, then begin…


#15

The problem with ./certbot-auto in a cronjob isn’t really that certbot-auto will try to refer to the current working directory for any of the tasks that it performs, but that the operating system won’t be able to find the certbot-auto program so it won’t be able to start at all.


#16

ah yes, chicken and egg problem…

So then his cronjob may have never been running at all.
And calling it explicitly may not produce the desired results either.

Then @Osiris method would have to be used to ensure desired results.
cd <to location> && ./certbot-auto ...


#17

I’m really Sorry, I wasnt online.
Please I’ve gone through all the messages and replies made for my issue. But I don’t really the best one to pick in other to solve my problem.
what I did is I first renewed it manually while waiting for a solution.
Here is the command I used for this renewal : ./certbot-auto renew --dry-run


#18

Please show:
/etc/letsencrypt/renewal/<domain>.conf
/var/log/letsencrypt/letsencrypt.log


#19

Ok, let me access it and I’ll send it here


#20

Here is the content of var/log/letsencrypt/

renew_before_expiry = 30 days

version = 0.21.1
archive_dir = /etc/letsencrypt/archive/doumer.me
cert = /etc/letsencrypt/live/doumer.me/cert.pem
privkey = /etc/letsencrypt/live/doumer.me/privkey.pem
chain = /etc/letsencrypt/live/doumer.me/chain.pem
fullchain = /etc/letsencrypt/live/doumer.me/fullchain.pem

Options used in the renewal process

[renewalparams]
authenticator = webroot
installer = None
account = 1235b294af025ea9a043f4d05a789184
webroot_path = /opt/bitnami/apps/wordpress/htdocs,
[[webroot_map]]
doumer.me = /opt/bitnami/apps/wordpress/htdocs
www.doumer.me = /opt/bitnami/apps/wordpress/htdocs