certbot

[Gerard E. Seibert]

I am currently running FreeBSD 14.0-RELEASE-p6.

When running the following command from CRON, I receive an error
message.

/usr/local/bin/certbot renew –apache

Traceback (most recent call last):
File "/usr/local/bin/certbot", line 5, in <module>
from certbot.main import main
File "/usr/local/lib/python3.9/site-packages/certbot/main.py", line
6, in <module> from certbot._internal import main as internal_main
File
"/usr/local/lib/python3.9/site-packages/certbot/_internal/main.py",
line 21, in <module> import josepy as jose File
"/usr/local/lib/python3.9/site-packages/josepy/__init__.py", line 40,
in <module> from josepy.json_util import ( File
"/usr/local/lib/python3.9/site-packages/josepy/json_util.py", line 24,
in <module> from OpenSSL import crypto File
"/usr/local/lib/python3.9/site-packages/OpenSSL/__init__.py", line 8,
in <module> from OpenSSL import SSL, crypto File
"/usr/local/lib/python3.9/site-packages/OpenSSL/SSL.py", line 9, in
<module> from OpenSSL._util import ( File
"/usr/local/lib/python3.9/site-packages/OpenSSL/_util.py", line 6, in
<module> from cryptography.hazmat.bindings.openssl.binding import
Binding File
"/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
line 15, in <module> from cryptography.exceptions import InternalError
File
"/usr/local/lib/python3.9/site-packages/cryptography/exceptions.py",
line 9, in <module> from cryptography.hazmat.bindings._rust import
exceptions as rust_exceptions RuntimeError: OpenSSL 3.0's legacy
provider failed to load. This is a fatal error by default, but
cryptography supports running without legacy algorithms by setting the
environment variable CRYPTOGRAPHY_OPENSSL_NO_LEGACY. If you did not
expect this error, you have likely made a mistake with your OpenSSL
configuration.

If I run the command from the command line, it works as expected. I did
place the following in the environment: CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1

I have the latest version of OpenSSL installed:
OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30 Jan 2024)

Why is this failure only when I run the command from CRON, not the
command line?

I Googled this problem and found this solution:

vi /usr/local/bin/certbot

after import sys:
import os
os.environ['CRYPTOGRAPHY_OPENSSL_NO_LEGACY'] = '1'

Before I do something that might compromise my system, I want to
confirm that this is how to correct the problem. This is the present
content:

# -*- coding: utf-8 -*-
import re
import sys
from certbot.main import main
if __name__ == "__main__":
sys.argv[0] = re.sub(r"(-script\.pyw|\.exe)?$", "", sys.argv[0])
sys.exit(main())

When inserting the new text, do I remove everything after “import sys”?

I still do not understand why this error only happens from CRON.

[John Levine]

It appears that Gerard E. Seibert <je...@seibercom.net, ques...@freebsd.org> said:
>If I run the command from the command line, it works as expected. I did
>place the following in the environment: CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1

>I still do not understand why this error only happens from CRON.

Most likely because that variable is not there. Cron uses a standard
rather sparse environment. See "man 5 crontab".

In this case rather than messing with the script, just set the
variable on the command line in the crontab, e.g.

0 1 * * * CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1 certbot ...

R's,
John

[Dag-Erling Smørgrav]

"John Levine" <jo...@iecc.com> writes:

> Gerard E. Seibert <je...@seibercom.net, ques...@freebsd.org> writes:
> > If I run the command from the command line, it works as expected. I did
> > place the following in the environment: CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1
> > I still do not understand why this error only happens from CRON.
>
> Most likely because that variable is not there. Cron uses a standard
> rather sparse environment. See "man 5 crontab".
>
> In this case rather than messing with the script, just set the
> variable on the command line in the crontab, e.g.
>
> 0 1 * * * CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1 certbot ...

Even simpler:

CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1
@daily certbot renew --apache

put this in, say, /etc/cron.d/certbot.

DES
--
Dag-Erling Smørgrav - d...@FreeBSD.org

[paul beard]

The meta question for me and perhaps others running FreeBSD 13 is what changed and how do we prepare for it if we expect to run certbot in FreeBSD 14? I run it as I always have, since release 11 or so. 

00 00 * * Sun   python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/certbot renew --renew-hook 'service nginx reload'

Will I need to change that? Do the folks at EFF know/have they documented what changed and how to manage it? 

--

Paul Beard / www.paulbeard.org/

[Souji Thenria]

On Sat Apr 20, 2024 at 10:29 PM BST, paul beard wrote:
> 00 00 * * Sun python -c 'import random; import time;
> time.sleep(random.random() * 3600)' && /usr/local/bin/certbot renew
> --renew-hook 'service nginx reload'

Hi Paul,

Out of pure curiosity:
Is there a reason why you sleep for a random number of hours (supposed
time.sleep() takes seconds as input parameter) before executing the
certbot?

Regards,
Souji

[paul beard]

I think I saw that in the docs…I could never have come up with that on my own. I think it's to reduce any spikes (like midnight as it crosses time zones). 

[Souji Thenria]

On Sun Apr 21, 2024 at 2:24 AM BST, paul beard wrote:
> I think I saw that in the docs…I could never have come up with that on my
> own. I think it's to reduce any spikes (like midnight as it crosses time
> zones).
>

> On Sat, Apr 20, 2024 at 6:11 PM Souji Thenria <mail@souji-thenrianet>

> wrote:
>
> > On Sat Apr 20, 2024 at 10:29 PM BST, paul beard wrote:
> > > 00 00 * * Sun python -c 'import random; import time;
> > > time.sleep(random.random() * 3600)' && /usr/local/bin/certbot renew
> > > --renew-hook 'service nginx reload'
> >
> > Hi Paul,
> >
> > Out of pure curiosity:
> > Is there a reason why you sleep for a random number of hours (supposed
> > time.sleep() takes seconds as input parameter) before executing the
> > certbot?
> >
> > Regards,
> > Souji
> >
> >

Oh true, that makes sense.

Thanks,
Souji

[John Levine]

It appears that paul beard <paul...@gmail.com> said:
>-=-=-=-=-=-

>
>The meta question for me and perhaps others running FreeBSD 13 is what
>changed and how do we prepare for it if we expect to run certbot in FreeBSD
>14? I run it as I always have, since release 11 or so.
>
>00 00 * * Sun python -c 'import random; import time;
>time.sleep(random.random() * 3600)' && /usr/local/bin/certbot renew
>--renew-hook 'service nginx reload'
>
>Will I need to change that? Do the folks at EFF know/have they documented
>what changed and how to manage it?

I don't see any reason that won't work, but there are much easier ways to do a
random sleep up to an hour, e.g.

00 00 * * Sun sleep $(jot -r 1 1 3600); certbot renew --renew-hook 'service nginx reload'

[paul beard]

It ain't broke, so I am not inclined to fix it. And that example came from the Let's Encrypt docs so I can circle back to them if I have problems. 

The question at hand is why OP can't use something as straightforward as what I run. Why does he need to run it with environment variables where I don't? 

[Souji Thenria]

On Sun Apr 21, 2024 at 4:13 AM BST, paul beard wrote:
> The question at hand is why OP can't use something as straightforward as
> what I run. Why does he need to run it with environment variables where I
> don't?

FreeBSD 14 uses a newer OpenSSL version, which probably disables some
older algorithms that are needed by certbot.

You don't have this problem since you are running FreeBSD 13, which
still uses the older OpenSSL version and supports those algorithms by
default.

[Paul Kagan]

I use certbot on FreeBSD 14 and it works fine there was a thread that I did
that answers this question... just to modify the script to not use the
legacy open ssl..

-----Message d'origine-----
De : owner-freeb...@FreeBSD.org
<owner-freeb...@FreeBSD.org> De la part de Souji Thenria
Envoyé : samedi 20 avril 2024 23:42
À : paul beard <paul...@gmail.com>; John Levine <jo...@iecc.com>
Cc : freebsd-...@freebsd.org
Objet : Re: certbot

[paul beard]

Just to add a little more detail…that randomized cron job ran at 12:34 (called at midnight). 

It runs weekly, perhaps overkill, considering the ways expirations are managed: 

The following certificates are not due for renewal yet:
  /usr/local/etc/letsencrypt/live/cloud.paulbeard.org/fullchain.pem expires on 2024-05-25 (skipped)
  /usr/local/etc/letsencrypt/live/paulbeard.org/fullchain.pem expires on 2024-06-15 (skipped)
  /usr/local/etc/letsencrypt/live/www.paulbeard.org/fullchain.pem expires on 2024-06-15 (skipped)
No renewals were attempted.
No hooks were run.

Maybe I'll change it to monthly. 

[Dag-Erling Smørgrav]

paul beard <paul...@gmail.com> writes:
> It runs weekly, perhaps overkill, considering the ways expirations are

> managed: [...] Maybe I'll change it to monthly.

I wouldn't, if I were you. You want to give it plenty of chances to
recover if it fails due to a transient issue.

[paul beard]

Thanks for the tip. Why mess with it if it works?