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.
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
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):
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 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
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
@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.
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.
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.
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.
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.
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 ...
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
0 0 * * * ./certbot-auto renew --quiet --no-self-upgrade