Re: [qmailtoaster] Re: Rocky9 - new mailserver setup - off topic
You just have to have certbot installed (dnf install cerbot) and
then have the timer active. That takes care of running it on a
schedule and then you just configure it in all the directories
under /etc/letsencrypt/
Here's what mine looks like.
[root@mail ~]# systemctl list-unit-files | grep certbot
certbot-renew.service
static -
certbot-renew.timer
enabled enabled
[root@mail ~]# systemctl list-timers certbot-renew.timer
NEXT LEFT
LAST PASSED
UNIT ACTIVATES
Tue 2024-04-16 21:54:51 EDT 7h left Tue 2024-04-16 07:02:57 EDT 6h
ago certbot-renew.timer certbot-renew.service
Once you get that done, Then you just need to set up apache with
the virtualhosts and run certbot and it will prompt you for the
virtualhost you want to set up a cert for. As long as you have
apache and DNS configure correctly, it will challenge verify your
site and install the cert. Once you get the cert set up, if you
have the certbot-renew.timer enabled, it will take care of
renewing that cert and execute the thing you put in the
pre,post,deploy directories.
Gary
On 4/16/2024 1:52 PM, Gary Bowling
wrote:
Yes, the script can go in those directories not in a cron. I
don't believe you have to call --deploy-hook on the command line
if the script is in those directories. Actually you don't call
anything in the command line, it's all done as part of the
certbot-renew.service and the certbot-renew.timer in systemd.
That timer runs every day, but the cert won't renew unless it's
within 30 days of expiring. Whenever it renews it will run
whatever scripts are in those directories. Or at least that's my
understanding, I haven't had my script in the "post" directory
long enough yet to verify that it runs it, but that's my
understanding. I just moved my script to there from a cron based
on William's note.
Gary
On 4/16/2024 10:34 AM, Eric Broch
wrote:
I thought William S. had mentioned something
about a Let's Encrypt hook instead of a cron job. From what
I've been reading, one's script simply goes in
/etc/letsencrypt/renewal-hooks/{pre,post,deploy] or something
like that, true? Then I suppose one calls certbot renew
--deploy-hook or something like that. The documentation seemed
sparse, anyway...
Pipe in William if you have something.
On Tue, Apr 16, 2024 at
6:33 AM Gary Bowling
wrote:
I'll help edit it if someone else that is currently
going through it wants to start it. Maybe set up a
google doc and give some people edit access. Or give
read only access and we can drop comments/suggestions
back here for someone to edit. It's been a long time
since I set it up from scratch, so I'm a bit rusty on
that.
It shouldn't be too hard to come up with something. I
like to do everything "standard" via the RH/Rocky way of
doing it. That way dnf updates work and I don't have as
much maintenance. So I don't compile, customize anything
unless I'm forced to.
The only special part on my install is the script to
"cat" the certs and create a servercert.pem. Especially
with your new updates, if it works with ECDSA certs,
then no need for that custom rsa 2048 config part.
With that, it should just be installing httpd, certbot,
and doing a standard config for the server name. The
only complication being if you use different names..
e.g. webmail.domain.com
and mail.domain.com or
something. It's much simpler if you use the same name
for both since letsencrypt queries back to the dns name
you set up on apache to validate. If you don't use the
same name, you either have to set up a dummy virtualhost
in apache to do the chal
Re: [qmailtoaster] Re: Rocky9 - new mailserver setup - off topic
Yes, the script can go in those directories not in a cron. I
don't believe you have to call --deploy-hook on the command line
if the script is in those directories. Actually you don't call
anything in the command line, it's all done as part of the
certbot-renew.service and the certbot-renew.timer in systemd.
That timer runs every day, but the cert won't renew unless it's
within 30 days of expiring. Whenever it renews it will run
whatever scripts are in those directories. Or at least that's my
understanding, I haven't had my script in the "post" directory
long enough yet to verify that it runs it, but that's my
understanding. I just moved my script to there from a cron based
on William's note.
Gary
On 4/16/2024 10:34 AM, Eric Broch
wrote:
I thought William S. had mentioned something about
a Let's Encrypt hook instead of a cron job. From what I've been
reading, one's script simply goes in
/etc/letsencrypt/renewal-hooks/{pre,post,deploy] or something
like that, true? Then I suppose one calls certbot renew
--deploy-hook or something like that. The documentation seemed
sparse, anyway...
Pipe in William if you have something.
On Tue, Apr 16, 2024 at
6:33 AM Gary Bowling
wrote:
I'll help edit it if someone else that is currently going
through it wants to start it. Maybe set up a google doc
and give some people edit access. Or give read only access
and we can drop comments/suggestions back here for someone
to edit. It's been a long time since I set it up from
scratch, so I'm a bit rusty on that.
It shouldn't be too hard to come up with something. I
like to do everything "standard" via the RH/Rocky way of
doing it. That way dnf updates work and I don't have as
much maintenance. So I don't compile, customize anything
unless I'm forced to.
The only special part on my install is the script to
"cat" the certs and create a servercert.pem. Especially
with your new updates, if it works with ECDSA certs, then
no need for that custom rsa 2048 config part.
With that, it should just be installing httpd, certbot,
and doing a standard config for the server name. The only
complication being if you use different names.. e.g. webmail.domain.com and mail.domain.com or something.
It's much simpler if you use the same name for both since
letsencrypt queries back to the dns name you set up on
apache to validate. If you don't use the same name, you
either have to set up a dummy virtualhost in apache to do
the challenge validation on that name, or you have to use
another challenge method like DNS-01 to update your certs.
Toaster doc should probably have examples of both.
Here's a generic letsencrypt setup for Rocky 8/9 and
apache. Needs some tweaks to do the challenge verification
back to your roundcube apache virtualhost instead of the
default /var/www/html/ query. Or if you have separate
names you can use the /var/www/html/ for the dummy
virtualhost to get your mail server certs, but you'll
still need another one for the roundcube virtualhost.
https://www.cyberciti.biz/faq/how-to-secure-apache-with-lets-encrypt-certificates-on-rhel-8/
Hope this helps.. Gary
On 4/15/2024 1:33 PM, Eric Broch wrote:
Anyone feel like doing a write-up
and I'll put it on the wiki?
On 4/15/2024 11:18 AM, Gary Bowling wrote:
Ah, right. Actually it looks like I can just place my
script that I currently run in my cron job in the
/etc/letsencrypt/renewal-hooks/post/ directory and it
will run as a "post renew" script.
Thanks for that.
Gary
On 4/15/2024 1:04 PM, William Silverstein wrote:
I would not use a cron script. I
use --deploy-
Re: [qmailtoaster] Re: Rocky9 - new mailserver setup - off topic
I suspect that it could be done either way. I have been using
--deploy-hook since I started using letsencrypt. I'll look at the
/etc/letsencrypt/renewal-hooks when I build my new server (soon, I hope).
On Tue, April 16, 2024 7:34 am, Eric Broch wrote:
> I thought William S. had mentioned something about a Let's Encrypt hook
> instead of a cron job. From what I've been reading, one's script simply
> goes in /etc/letsencrypt/renewal-hooks/{pre,post,deploy] or something like
> that, true? Then I suppose one calls certbot renew --deploy-hook or
> something like that. The documentation seemed sparse, anyway...
>
> Pipe in William if you have something.
>
>
>
> On Tue, Apr 16, 2024 at 6:33â¯AM Gary Bowling wrote:
>
>>
>> I'll help edit it if someone else that is currently going through it
>> wants
>> to start it. Maybe set up a google doc and give some people edit
>> access.
>> Or give read only access and we can drop comments/suggestions back here
>> for
>> someone to edit. It's been a long time since I set it up from scratch,
>> so
>> I'm a bit rusty on that.
>>
>>
>> It shouldn't be too hard to come up with something. I like to do
>> everything "standard" via the RH/Rocky way of doing it. That way dnf
>> updates work and I don't have as much maintenance. So I don't compile,
>> customize anything unless I'm forced to.
>>
>>
>> The only special part on my install is the script to "cat" the certs and
>> create a servercert.pem. Especially with your new updates, if it works
>> with
>> ECDSA certs, then no need for that custom rsa 2048 config part.
>>
>>
>> With that, it should just be installing httpd, certbot, and doing a
>> standard config for the server name. The only complication being if you
>> use
>> different names.. e.g. webmail.domain.com and mail.domain.com or
>> something. It's much simpler if you use the same name for both since
>> letsencrypt queries back to the dns name you set up on apache to
>> validate.
>> If you don't use the same name, you either have to set up a dummy
>> virtualhost in apache to do the challenge validation on that name, or
>> you
>> have to use another challenge method like DNS-01 to update your certs.
>> Toaster doc should probably have examples of both.
>>
>>
>> Here's a generic letsencrypt setup for Rocky 8/9 and apache. Needs some
>> tweaks to do the challenge verification back to your roundcube apache
>> virtualhost instead of the default /var/www/html/ query. Or if you have
>> separate names you can use the /var/www/html/ for the dummy virtualhost
>> to
>> get your mail server certs, but you'll still need another one for the
>> roundcube virtualhost.
>>
>>
>>
>> https://www.cyberciti.biz/faq/how-to-secure-apache-with-lets-encrypt-certificates-on-rhel-8/
>>
>>
>> Hope this helps.. Gary
>>
>>
>> On 4/15/2024 1:33 PM, Eric Broch wrote:
>>
>> Anyone feel like doing a write-up and I'll put it on the wiki?
>>
>> On 4/15/2024 11:18 AM, Gary Bowling wrote:
>>
>>
>>
>> Ah, right. Actually it looks like I can just place my script that I
>> currently run in my cron job in the /etc/letsencrypt/renewal-hooks/post/
>> directory and it will run as a "post renew" script.
>>
>>
>> Thanks for that.
>>
>> Gary
>>
>>
>> On 4/15/2024 1:04 PM, William Silverstein wrote:
>>
>> I would not use a cron script. I use --deploy-hook option on the
>> certbot-auto to handle it.
>>
>>
>> On Mon, April 15, 2024 9:59 am, Gary Bowling wrote:
>>
>> Great. One question. Seems like everything on my server uses
>> /var/qmail/control/servercert.pem for the cert. Dovecot and qmail
>> all use that file. And I have a cron job that runs once a month to
>> check for a new letsencrypt cert and if there is one it copies it
>> over to servercert.pem to update my mail server.
>>
>>
>>
>>
>>
>> Is that the correct way to handle that? Or is that something that
>> is
>> left over from my old server that I moved over?
>>
>>
>>
>>
>> Thanks, Gary
>>
>>
>>
>>
>> On 4/15/2024 12:44 PM, Eric Broch wrote:
>>
>>
>> Neither,
>>
>> /var/qmail/control/dh2048.pem
>> /var/qmail/control/rsa2048.pem
>>
>>
>> On 4/15/2024 10:33 AM, Gary Bowling wrote:
>>
>>
>>
>>
>>
>> Thanks, will still require rsa?
>>
>>
>>
>> On 4/15/2024 10:47 AM, Eric Broch wrote:
>>
>>
>> My next iteration on EL9 will remove keysize it's
>> deprecated,
>> has been for a while. Should have the new code out within
>> the
>> week.
>>
>> SSL_CTX_set_tmp_rsa_callback ÷ openssl/openssl ÷
>> Discussion #23769 (github.com)
>>
>>
>>
>> On 4/15/2024 6:25 AM, Gary Bowling wrote:
>>
>>
>>
>>
>>
>> Hey Jeff, glad you're making progress. Be aware that when
>> you get a new cert from Letsencrypt that the default now
>> retrieves an ECDSA cert. Which is fine for apache, but
>> doesn't work on qmail, or at least it didn't for me. To
>> fix
>> that you'll need to configure letsencrypt to give you an
>> RSA
>> 2048 cert.
>>
>>
>>
>>
>>
>> There are two
Re: [qmailtoaster] Re: Rocky9 - new mailserver setup - off topic
I thought William S. had mentioned something about a Let's Encrypt hook
instead of a cron job. From what I've been reading, one's script simply
goes in /etc/letsencrypt/renewal-hooks/{pre,post,deploy] or something like
that, true? Then I suppose one calls certbot renew --deploy-hook or
something like that. The documentation seemed sparse, anyway...
Pipe in William if you have something.
On Tue, Apr 16, 2024 at 6:33 AM Gary Bowling wrote:
>
> I'll help edit it if someone else that is currently going through it wants
> to start it. Maybe set up a google doc and give some people edit access.
> Or give read only access and we can drop comments/suggestions back here for
> someone to edit. It's been a long time since I set it up from scratch, so
> I'm a bit rusty on that.
>
>
> It shouldn't be too hard to come up with something. I like to do
> everything "standard" via the RH/Rocky way of doing it. That way dnf
> updates work and I don't have as much maintenance. So I don't compile,
> customize anything unless I'm forced to.
>
>
> The only special part on my install is the script to "cat" the certs and
> create a servercert.pem. Especially with your new updates, if it works with
> ECDSA certs, then no need for that custom rsa 2048 config part.
>
>
> With that, it should just be installing httpd, certbot, and doing a
> standard config for the server name. The only complication being if you use
> different names.. e.g. webmail.domain.com and mail.domain.com or
> something. It's much simpler if you use the same name for both since
> letsencrypt queries back to the dns name you set up on apache to validate.
> If you don't use the same name, you either have to set up a dummy
> virtualhost in apache to do the challenge validation on that name, or you
> have to use another challenge method like DNS-01 to update your certs.
> Toaster doc should probably have examples of both.
>
>
> Here's a generic letsencrypt setup for Rocky 8/9 and apache. Needs some
> tweaks to do the challenge verification back to your roundcube apache
> virtualhost instead of the default /var/www/html/ query. Or if you have
> separate names you can use the /var/www/html/ for the dummy virtualhost to
> get your mail server certs, but you'll still need another one for the
> roundcube virtualhost.
>
>
>
> https://www.cyberciti.biz/faq/how-to-secure-apache-with-lets-encrypt-certificates-on-rhel-8/
>
>
> Hope this helps.. Gary
>
>
> On 4/15/2024 1:33 PM, Eric Broch wrote:
>
> Anyone feel like doing a write-up and I'll put it on the wiki?
>
> On 4/15/2024 11:18 AM, Gary Bowling wrote:
>
>
>
> Ah, right. Actually it looks like I can just place my script that I
> currently run in my cron job in the /etc/letsencrypt/renewal-hooks/post/
> directory and it will run as a "post renew" script.
>
>
> Thanks for that.
>
> Gary
>
>
> On 4/15/2024 1:04 PM, William Silverstein wrote:
>
> I would not use a cron script. I use --deploy-hook option on the
> certbot-auto to handle it.
>
>
> On Mon, April 15, 2024 9:59 am, Gary Bowling wrote:
>
> Great. One question. Seems like everything on my server uses
> /var/qmail/control/servercert.pem for the cert. Dovecot and qmail
> all use that file. And I have a cron job that runs once a month to
> check for a new letsencrypt cert and if there is one it copies it
> over to servercert.pem to update my mail server.
>
>
>
>
>
> Is that the correct way to handle that? Or is that something that is
> left over from my old server that I moved over?
>
>
>
>
> Thanks, Gary
>
>
>
>
> On 4/15/2024 12:44 PM, Eric Broch wrote:
>
>
> Neither,
>
> /var/qmail/control/dh2048.pem
> /var/qmail/control/rsa2048.pem
>
>
> On 4/15/2024 10:33 AM, Gary Bowling wrote:
>
>
>
>
>
> Thanks, will still require rsa?
>
>
>
> On 4/15/2024 10:47 AM, Eric Broch wrote:
>
>
> My next iteration on EL9 will remove keysize it's deprecated,
> has been for a while. Should have the new code out within the
> week.
>
> SSL_CTX_set_tmp_rsa_callback · openssl/openssl ·
> Discussion #23769 (github.com)
>
>
>
> On 4/15/2024 6:25 AM, Gary Bowling wrote:
>
>
>
>
>
> Hey Jeff, glad you're making progress. Be aware that when
> you get a new cert from Letsencrypt that the default now
> retrieves an ECDSA cert. Which is fine for apache, but
> doesn't work on qmail, or at least it didn't for me. To fix
> that you'll need to configure letsencrypt to give you an RSA
> 2048 cert.
>
>
>
>
>
> There are two ways to do that. If you want all your certs to
> be RSA 2048, you can add this to the
> /etc/letsencrypt/cli.ini file.
>
> key-type = rsa
> rsa-key-size = 2048
>
>
>
>
> If you just want to do that for your keys you use in qmail,
> then you can put the above in the
> /etc/letsencrypt/renewal/domain.conf file. Where "domain" is
> the name of the cert you're renewing. Ce
Re: [qmailtoaster] Re: Rocky9 - new mailserver setup - off topic
I'll help edit it if someone else that is currently going through it wants to start it. Maybe set up a google doc and give some people edit access. Or give read only access and we can drop comments/suggestions back here for someone to edit. It's been a long time since I set it up from scratch, so I'm a bit rusty on that. It shouldn't be too hard to come up with something. I like to do everything "standard" via the RH/Rocky way of doing it. That way dnf updates work and I don't have as much maintenance. So I don't compile, customize anything unless I'm forced to. The only special part on my install is the script to "cat" the certs and create a servercert.pem. Especially with your new updates, if it works with ECDSA certs, then no need for that custom rsa 2048 config part. With that, it should just be installing httpd, certbot, and doing a standard config for the server name. The only complication being if you use different names.. e.g. webmail.domain.com and mail.domain.com or something. It's much simpler if you use the same name for both since letsencrypt queries back to the dns name you set up on apache to validate. If you don't use the same name, you either have to set up a dummy virtualhost in apache to do the challenge validation on that name, or you have to use another challenge method like DNS-01 to update your certs. Toaster doc should probably have examples of both. Here's a generic letsencrypt setup for Rocky 8/9 and apache. Needs some tweaks to do the challenge verification back to your roundcube apache virtualhost instead of the default /var/www/html/ query. Or if you have separate names you can use the /var/www/html/ for the dummy virtualhost to get your mail server certs, but you'll still need another one for the roundcube virtualhost. https://www.cyberciti.biz/faq/how-to-secure-apache-with-lets-encrypt-certificates-on-rhel-8/ Hope this helps.. Gary On 4/15/2024 1:33 PM, Eric Broch wrote: Anyone feel like doing a write-up and I'll put it on the wiki? On 4/15/2024 11:18 AM, Gary Bowling wrote: Ah, right. Actually it looks like I can just place my script that I currently run in my cron job in the /etc/letsencrypt/renewal-hooks/post/ directory and it will run as a "post renew" script. Thanks for that. Gary On 4/15/2024 1:04 PM, William Silverstein wrote: I would not use a cron script. I use --deploy-hook option on the certbot-auto to handle it. On Mon, April 15, 2024 9:59 am, Gary Bowling wrote: Great. One question. Seems like everything on my server uses /var/qmail/control/servercert.pem for the cert. Dovecot and qmail all use that file. And I have a cron job that runs once a month to check for a new letsencrypt cert and if there is one it copies it over to servercert.pem to update my mail server. Is that the correct way to handle that? Or is that something that is left over from my old server that I moved over? Thanks, Gary On 4/15/2024 12:44 PM, Eric Broch wrote: Neither, /var/qmail/control/dh2048.pem /var/qmail/control/rsa2048.pem On 4/15/2024 10:33 AM, Gary Bowling wrote: Thanks, will still require rsa? On 4/15/2024 10:47 AM, Eric Broch wrote: My next iteration on EL9 will remove keysize it's deprecated, has been for a while. Should have the new code out within the week. SSL_CTX_set_tmp_rsa_callback · openssl/openssl · Discussion #23769 (github.com) On 4/15/2024 6:25 AM, Gary Bowling wrote: Hey Jeff, glad you're making progress. Be aware that when you get a new cert from Letsencrypt
