From 89f83d49ad7d4cd8baa815993d3172ca72e5b30e Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 8 Apr 2023 12:32:25 +0300 Subject: Update content for html --- ...22-07-30-lets-encrypt-with-openbsd-and-rex.html | 64 +++++++++++----------- 1 file changed, 32 insertions(+), 32 deletions(-) (limited to 'gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html') diff --git a/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html b/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html index 7e14c984..c93e8d07 100644 --- a/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html +++ b/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html @@ -10,7 +10,7 @@

Let's Encrypt with OpenBSD and Rex



-Published at 2022-07-30T12:14:31+01:00
+Published at 2022-07-30T12:14:31+01:00

                                                /    _    \
@@ -43,31 +43,31 @@
 

 
What's Let's Encrypt?


 

-Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 265 million websites, with the goal of all websites being secure and using HTTPS.

+Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 265 million websites, with the goal of all websites being secure and using HTTPS.

 

-Source: Wikipedia

+Source: Wikipedia

 

 In short, it gives away TLS certificates for your website - for free! The catch is, that the certificates are only valid for three months. So it is better to automate certificate generation and renewals.

 

-
Meet acme-client


+
Meet acme-client


 

-acme-client is the default Automatic Certifcate Management Environment (ACME) client on OpenBSD and part of the OpenBSD base system. 

+acme-client is the default Automatic Certifcate Management Environment (ACME) client on OpenBSD and part of the OpenBSD base system. 

 

 When invoked, the client first checks whether certificates actually require to be generated.

 

 

-Oversimplified, the following steps are undertaken by acme-client for generating a new certificate:

+Oversimplified, the following steps are undertaken by acme-client for generating a new certificate:

 

 

 
Configuration


 

@@ -75,7 +75,7 @@
 

 
acme-client.conf


 

-This is how my /etc/acme-client.conf looks like (I copied a template from /etc/examples/acme-client.conf to /etc/acme-client.conf and added my domains to the bottom:

+This is how my /etc/acme-client.conf looks like (I copied a template from /etc/examples/acme-client.conf to /etc/acme-client.conf and added my domains to the bottom:

 

 
 #
@@ -141,7 +141,7 @@ domain snonux.land {
 

 
httpd.conf


 

-For ACME to work, you will need to configure the HTTP daemon so that the "special" ACME requests from Let's Encrypt are served correctly. I am using the standard OpenBSD httpd here. These are the snippets I use for the foo.zone host in /etc/httpd.conf (of course, you need a similar setup for all other hosts as well):

+For ACME to work, you will need to configure the HTTP daemon so that the "special" ACME requests from Let's Encrypt are served correctly. I am using the standard OpenBSD httpd here. These are the snippets I use for the foo.zone host in /etc/httpd.conf (of course, you need a similar setup for all other hosts as well):

 

 
 server "foo.zone" {
@@ -170,13 +170,13 @@ server "foo.zone" {
 

 As you see, plain HTTP only serves the ACME challenge path. Otherwise, it redirects the requests to TLS. The TLS section then attempts to use the Let's Encrypt certificates.

 

-It is worth noticing that httpd will start without the certificates being present. This will cause a certificate error when you try to reach the HTTPS endpoint, but it helps to bootstrap Let's Encrypt. As you saw in the config snippet above, Let's Encrypt only requests the plain HTTP endpoint for the verification process, so HTTPS doesn't need to be operational yet at this stage. But once the certificates are generated, you will have to reload or restart httpd to use any new certificate.

+It is worth noticing that httpd will start without the certificates being present. This will cause a certificate error when you try to reach the HTTPS endpoint, but it helps to bootstrap Let's Encrypt. As you saw in the config snippet above, Let's Encrypt only requests the plain HTTP endpoint for the verification process, so HTTPS doesn't need to be operational yet at this stage. But once the certificates are generated, you will have to reload or restart httpd to use any new certificate.

 

 
CRON job


 

-You could now run doas acme-client foo.zone to generate the certificate or to renew it. Or you could automate it with CRON.

+You could now run doas acme-client foo.zone to generate the certificate or to renew it. Or you could automate it with CRON.

 

-I have created a script /usr/local/bin/acme.sh for that for all of my domains:

+I have created a script /usr/local/bin/acme.sh for that for all of my domains:

 

 
 #!/bin/sh
@@ -231,7 +231,7 @@ if [ $has_update = yes ]; then
 fi
 

 

-And added the following line to /etc/daily.local to run the script once daily so that certificates will be renewed fully automatically:

+And added the following line to /etc/daily.local to run the script once daily so that certificates will be renewed fully automatically:

 

 
 /usr/local/bin/acme.sh
@@ -252,15 +252,15 @@ acme-client: /etc/ssl/snonux.land.fullchain.pem: certificate valid: 79 days left
 

 
relayd.conf and smtpd.conf


 

-Besides httpd, relayd (mainly for Gemini) and smtpd (for mail, of course) also use TLS certificates. And as you can see in acme.sh, the services are reloaded or restarted (smtpd doesn't support reload) whenever a certificate is generated or updated.

+Besides httpd, relayd (mainly for Gemini) and smtpd (for mail, of course) also use TLS certificates. And as you can see in acme.sh, the services are reloaded or restarted (smtpd doesn't support reload) whenever a certificate is generated or updated.

 

 
Rexification


 

 I didn't write all these configuration files by hand. As a matter of fact, everything is automated with the Rex configuration management system.

 

-https://www.rexify.org

+https://www.rexify.org

 

-At the top of the Rexfile I define all my hosts:

+At the top of the Rexfile I define all my hosts:

 

 
 our @acme_hosts = qw/buetow.org paul.buetow.org tmp.buetow.org dtail.dev foo.zone irregular.ninja snonux.land/;
@@ -317,7 +317,7 @@ task 'acme_invoke', group => 'frontends',
 
 

 

-Furthermore, this snippet (also at the top of the Rexfile) helps to determine whether the current server is the primary server (all hosts will be without the www. prefix) or the secondary server (all hosts will be with the www. prefix):

+Furthermore, this snippet (also at the top of the Rexfile) helps to determine whether the current server is the primary server (all hosts will be without the www. prefix) or the secondary server (all hosts will be with the www. prefix):

 

 
 # Bootstrapping the FQDN based on the server IP as the hostname and domain
@@ -337,7 +337,7 @@ our $is_primary = sub {
 };
 

 

-The following is the acme-client.conf.tpl Rex template file used for the automation. You see that the www. prefix isn't sent for the primary server. E.g. foo.zone will be served by the primary server (in my case, a server located in Germany) and www.foo.zone by the secondary server (in my case, a server located in Japan):

+The following is the acme-client.conf.tpl Rex template file used for the automation. You see that the www. prefix isn't sent for the primary server. E.g. foo.zone will be served by the primary server (in my case, a server located in Germany) and www.foo.zone by the secondary server (in my case, a server located in Japan):

 

 
 #
@@ -380,7 +380,7 @@ domain <%= $prefix.$host %> {
 
 

 

-And this is the acme.sh.tpl:

+And this is the acme.sh.tpl:

 

 
 #!/bin/sh
@@ -420,7 +420,7 @@ fi
 

 
Service rexification 


 

-These are the Rex tasks setting up httpd, relayd and smtpd services:

+These are the Rex tasks setting up httpd, relayd and smtpd services:

 

 
 desc 'Setup httpd';
@@ -498,7 +498,7 @@ task 'smtpd', group => 'frontends',
 
 

 

-This is the httpd.conf.tpl:

+This is the httpd.conf.tpl:

 

 
 <%
@@ -590,7 +590,7 @@ server "<%= $prefix %>tmp.buetow.org" {
 }
 

 

-and this the relayd.conf.tpl:

+and this the relayd.conf.tpl:

 

 
 <%
@@ -618,7 +618,7 @@ relay "gemini6" {
 }
 

 

-And last but not least, this is the smtpd.conf.tpl:

+And last but not least, this is the smtpd.conf.tpl:

 

 
 <%
@@ -648,9 +648,9 @@ match from local for any action outbound
 

 
All pieces together


 

-For the complete Rexfile example and all the templates, please look at the Git repository:

+For the complete Rexfile example and all the templates, please look at the Git repository:

 

-https://codeberg.org/snonux/rexfiles

+https://codeberg.org/snonux/rexfiles

 

 Besides ACME, other things, such as DNS servers, are also rexified. The following command will run all the Rex tasks and configure everything on my frontend machines automatically:

 

@@ -658,7 +658,7 @@ match from local for any action outbound
 rex commons
 

 

-The commons is a group of tasks I specified which combines a set of common tasks I always want to execute on all frontend machines. This also includes the ACME tasks mentioned in this article!

+The commons is a group of tasks I specified which combines a set of common tasks I always want to execute on all frontend machines. This also includes the ACME tasks mentioned in this article!

 

 
Conclusion


 

@@ -666,11 +666,11 @@ rex commons
 

 OpenBSD suits perfectly here as all the tools are already part of the base installation. But I like underdogs. Rex is not as powerful and popular as other configuration management systems (e.g. Puppet, Chef, SALT or even Ansible). It is more of an underdog, and the community is small.

 

-Why re-inventing the wheel? I love that a Rexfile is just a Perl DSL. Also, OpenBSD comes with Perl in the base system. So no new programming language had to be added to my mix for the configuration management system. Also, the acme.sh shell script is not a Bash but a standard Bourne shell script, so I didn't have to install an additional shell as OpenBSD does not come with the Bash pre-installed.

+Why re-inventing the wheel? I love that a Rexfile is just a Perl DSL. Also, OpenBSD comes with Perl in the base system. So no new programming language had to be added to my mix for the configuration management system. Also, the acme.sh shell script is not a Bash but a standard Bourne shell script, so I didn't have to install an additional shell as OpenBSD does not come with the Bash pre-installed.

 

 E-Mail your comments to hi@paul.cyou :-)

 

-Back to the main site

+Back to the main site

 

 Generated with Gemtexter |
 served by OpenBSD/httpd(8) |
-- 
cgit v1.2.3