Hi all,

Is there anyone running innd with Letsecnrypt certificates? I've not
seen any write ups on how to configure and I'm sure it's not that bad
but the main question is how do you deal with certificate expiry?

Which parts of innd would need to be reloaded or restarted and by using
what mechanism to cause the least amount of interference to my users
and peers?

Maybe with enough prior knowledge and advice I can whip up a howto for
others to follow if they wish.

Thanks,


--
End Of The Line BBS - Plano, TX
telnet endofthelinebbs.com 23

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jan 23, 2024 at 1:25:46 AM CST, "Nigel Reed" <sysop@endofthelinebbs.com> wrote:

Hi all,

Is there anyone running innd with Letsecnrypt certificates? I've not
seen any write ups on how to configure and I'm sure it's not that bad
but the main question is how do you deal with certificate expiry?

Which parts of innd would need to be reloaded or restarted and by using
what mechanism to cause the least amount of interference to my users
and peers?

Maybe with enough prior knowledge and advice I can whip up a howto for
others to follow if they wish.

Thanks,

Only the nnrpd process that uses the -S flag needs to be restarted. I use the following post-renewal hook for letsencrypt, it is simple but it works. It
only kills the listening daemon pid and won't impact connected clients where a separate nnrpd process has been spawned.

#!/bin/sh
cp -f /usr/local/etc/letsencrypt/live/news.blueworldhosting.com/fullchain.pem /usr/local/news/etc/
cp -f /usr/local/etc/letsencrypt/live/news.blueworldhosting.com/cert.pem /usr/local/news/etc/
cp -f /usr/local/etc/letsencrypt/live/news.blueworldhosting.com/privkey.pem /usr/local/news/etc/
chown news:news /usr/local/news/etc/*.pem
kill `cat /usr/local/news/run/nnrpd-563.pid`
su -l news -c "/usr/local/news/bin/nnrpd -S -D -p 563"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23/01/2024 07:25, Nigel Reed wrote:

The main question is how do you deal with certificate expiry?

I run my clients website on VPs with LetsEncrypt free certificates and
the expiry is handled by certbot that I have installed. It's automatic
and you don't need to worry about the expiry dates.

The basic commands are: <https://certbot.eff.org/instructions>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jesse, Nigel,

Only the nnrpd process that uses the -S flag needs to be restarted. I use the following post-renewal hook for letsencrypt, it is simple but it works.

Are you sure that hook is really needed? When not restarting nnrpd,
running as a daemon, after a renewal of certificate, did you find an issue?

I'm also using Let's Encrypt certificates, automatically renewed by
Certbot, and I do not restart nnrpd. When a new connection arrives for
a news client, nnrpd forks and it is that fork which reads the
certificates, and therefore will take into account the new one. The
running daemon does not have them in memory.
Same thing as readers.conf by the way: you don't have to restart the
nnrpd daemon to take a change in readers.conf into account.


FWIW, my configuration with a 3072-bit RSA key (seems like what will be
the most widely supported by clients):

% cat news.trigofacile.com.conf
version = 1.12.0
archive_dir = /etc/letsencrypt/archive/news.trigofacile.com
cert = /etc/letsencrypt/live/news.trigofacile.com/cert.pem
privkey = /etc/letsencrypt/live/news.trigofacile.com/privkey.pem
chain = /etc/letsencrypt/live/news.trigofacile.com/chain.pem
fullchain = /etc/letsencrypt/live/news.trigofacile.com/fullchain.pem

[renewalparams]
account = xxx
key_type = rsa
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
rsa_key_size = 3072



And inn.conf:
tlscapath: /etc/letsencrypt/live/news.trigofacile.com
tlscertfile: /etc/letsencrypt/live/news.trigofacile.com/fullchain.pem tlskeyfile: /etc/letsencrypt/live/news.trigofacile.com/privkey.pem


Make sure that the permission rights are properly set so that the news
user or the news group can read these *directories* and *files*, and
that the private key is not world-readable.

--
Julien ÉLIE

« Prouidentia, dum ortum ante obitum ponit, sapienter fecit, sin autem
quid uitae sit notum ? » (Alphonse Allais)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jan 23, 2024 at 12:31:36 PM CST, "Julien ÉLIE" <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Jesse, Nigel,

Only the nnrpd process that uses the -S flag needs to be restarted. I use the
following post-renewal hook for letsencrypt, it is simple but it works.

Are you sure that hook is really needed? When not restarting nnrpd,
running as a daemon, after a renewal of certificate, did you find an issue?

I'm also using Let's Encrypt certificates, automatically renewed by
Certbot, and I do not restart nnrpd. When a new connection arrives for
a news client, nnrpd forks and it is that fork which reads the
certificates, and therefore will take into account the new one. The
running daemon does not have them in memory.
Same thing as readers.conf by the way: you don't have to restart the
nnrpd daemon to take a change in readers.conf into account.

FWIW, my configuration with a 3072-bit RSA key (seems like what will be
the most widely supported by clients):

% cat news.trigofacile.com.conf
version = 1.12.0
archive_dir = /etc/letsencrypt/archive/news.trigofacile.com
cert = /etc/letsencrypt/live/news.trigofacile.com/cert.pem
privkey = /etc/letsencrypt/live/news.trigofacile.com/privkey.pem
chain = /etc/letsencrypt/live/news.trigofacile.com/chain.pem
fullchain = /etc/letsencrypt/live/news.trigofacile.com/fullchain.pem

[renewalparams]
account = xxx
key_type = rsa
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
rsa_key_size = 3072

And inn.conf:
tlscapath: /etc/letsencrypt/live/news.trigofacile.com
tlscertfile: /etc/letsencrypt/live/news.trigofacile.com/fullchain.pem tlskeyfile: /etc/letsencrypt/live/news.trigofacile.com/privkey.pem

Make sure that the permission rights are properly set so that the news
user or the news group can read these *directories* and *files*, and
that the private key is not world-readable.

On my FreeBSD box, INN cannot read the certificate files in the /usr/local/letsencrypt subdirectories, so my inn.conf references the files I copy into /usr/local/news/etc. In past experience, nnrpd did not pick up the new certificate files and provided users the expired cert. I had to kill the parent daemon process and spawn a new one.

Every time the packages that provide the letsencrypt stuff got updated it
would wipe out my permissions on /usr/local/letsencrypt, so that's the way I ended up going about it. I'm sure there are more elegant ways.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:

On my FreeBSD box, INN cannot read the certificate files in the /usr/local/letsencrypt subdirectories, so my inn.conf references the
files I copy into /usr/local/news/etc.

This is also what I do, for what it's worth.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jan 23, 2024 at 12:55:27 PM CST, "Jesse Rehmer" <jesse.rehmer@blueworldhosting.com> wrote:

On Jan 23, 2024 at 12:31:36 PM CST, "Julien ÉLIE" <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Jesse, Nigel,

Only the nnrpd process that uses the -S flag needs to be restarted. I use the
following post-renewal hook for letsencrypt, it is simple but it works.

Are you sure that hook is really needed? When not restarting nnrpd,
running as a daemon, after a renewal of certificate, did you find an issue? >>
I'm also using Let's Encrypt certificates, automatically renewed by
Certbot, and I do not restart nnrpd. When a new connection arrives for
a news client, nnrpd forks and it is that fork which reads the
certificates, and therefore will take into account the new one. The
running daemon does not have them in memory.
Same thing as readers.conf by the way: you don't have to restart the
nnrpd daemon to take a change in readers.conf into account.


FWIW, my configuration with a 3072-bit RSA key (seems like what will be
the most widely supported by clients):

% cat news.trigofacile.com.conf
version = 1.12.0
archive_dir = /etc/letsencrypt/archive/news.trigofacile.com
cert = /etc/letsencrypt/live/news.trigofacile.com/cert.pem
privkey = /etc/letsencrypt/live/news.trigofacile.com/privkey.pem
chain = /etc/letsencrypt/live/news.trigofacile.com/chain.pem
fullchain = /etc/letsencrypt/live/news.trigofacile.com/fullchain.pem

[renewalparams]
account = xxx
key_type = rsa
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
rsa_key_size = 3072



And inn.conf:
tlscapath: /etc/letsencrypt/live/news.trigofacile.com
tlscertfile: /etc/letsencrypt/live/news.trigofacile.com/fullchain.pem
tlskeyfile: /etc/letsencrypt/live/news.trigofacile.com/privkey.pem


Make sure that the permission rights are properly set so that the news
user or the news group can read these *directories* and *files*, and
that the private key is not world-readable.

On my FreeBSD box, INN cannot read the certificate files in the /usr/local/letsencrypt subdirectories, so my inn.conf references the files I copy into /usr/local/news/etc. In past experience, nnrpd did not pick up the new certificate files and provided users the expired cert. I had to kill the parent daemon process and spawn a new one.

Every time the packages that provide the letsencrypt stuff got updated it would wipe out my permissions on /usr/local/letsencrypt, so that's the way I ended up going about it. I'm sure there are more elegant ways.

I did testing and you are correct, if I replace the certificate files without restarting nnrpd, I do get offered the replacement. I'm not sure why I was convinced this was not the case before, so thank you for pointing it out. I will change my post renewal-hook to copy the files and set ownership.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)