From de2e9746d849277bd4648ef2b3eab0c07d06b59a Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 30 Jul 2022 12:10:18 +0100 Subject: Update content for gemtext --- gemfeed/atom.xml | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) (limited to 'gemfeed/atom.xml') diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 70dea87e..a00d8806 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2022-07-30T11:35:29+01:00 + 2022-07-30T12:07:23+01:00 foo.zone feed To be in the .zone! @@ -18,7 +18,11 @@ I was amazed how easy it is to automatically generate and update Let's Encrypt certificates with OpenBSD.. .....to read on please visit my site.
-

Let's Encrypt with OpenBSD and Rex

+ 1c1 +< -rw-r--r--. 1 paul paul 21429 Jul 30 10:56 ../foo.zone-content/gemtext/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.gmi +--- +> -rw-r--r--. 1 paul paul 21483 Jul 30 12:06 ../foo.zone-content/gemtext/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.gmi +

Let's Encrypt with OpenBSD and Rex

                                                /    _    \
   The Hebern Machine                            \ ." ". /
@@ -57,15 +61,15 @@
 
    
 
  • It first checks whether a certificate already exists, if not, it will attempt to generate a new one.
    • 
 
  • If the certificate already exists but expires within the next 30 days, it will renew it.
    • 
-
  • Otherwise, `acme-client` won't do anything.
    • 
+
  • Otherwise, acme-client won't do anything.
    • 
 

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

 
    
 
  • Reading its config file /etc/acme-client.conf for a list of hosts (and their alternative names) to generate certificates for. So it means you can also have certificates for abritary subdomains!
    • 
-
  • Automatic generation of the private certificate part (the certificate key) and the certificate signing request (CSR) to `/etc/ssl/...`.
    • 
+
  • Automatic generation of the private certificate part (the certificate key) and the certificate signing request (CSR) to /etc/ssl/....
    • 
 
  • Requesting Let's Encrypt to sign the certificate. This also includes providing a set of temporary files which will be requested by Let's Encrypt in the next step for verification.
    • 
-
  • Let's Encrypt then will contact the hostname for the certificate through a special URL (e.g. `http://foo.zone/.well-known/acme-challenge/...`) to verify that the requester is the valid owner of the host.
    • 
-
  • Let's Encrypt generates a certificate, which then is downloaded to `/etc/ssl/...`.
    • 
+
  • Let's Encrypt then will contact the hostname for the certificate through a special URL (e.g. http://foo.zone/.well-known/acme-challenge/...) to verify that the requester is the valid owner of the host.
    • 
+
  • Let's Encrypt generates a certificate, which then is downloaded to /etc/ssl/....
    • 
 

 
Configuration

 
There is some (but easy) configuration required to make that all work on OpenBSD.

@@ -159,7 +163,7 @@ server "foo.zone" {
 }

As you see, plain HTTP only serves the ACME challenge path. Otherwise, it is redirecting 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 actually 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 that 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 in order to use any new certificate.

+

It is worth noticing that httpd will start without the certificates actually 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 that 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 in order 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.

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

@@ -608,7 +612,7 @@ rex commons

Conclusion

ACME and Let's Encrypt greatly help reducing recurring manual maintenance work (creating and renewing certificates). Furthermore, all the certificates are free of costs! I love to use OpenBSD and Rex to automate all of this.

OpenBSD suits perfectly here as all the tools are already part of the base installation. 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. But I like underdogs.

-

I love the fact that a Rexfile is just a Perl DSL. Why re-inventing the wheel? 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 that I didn't have to install yet another shell.

+

I love the fact that a Rexfile is just a Perl DSL. Why re-inventing the wheel? 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 that I didn't have to install yet another shell as OpenBSD does not come with the Bash pre-installed.

E-Mail me your comments to paul at buetow dot org!

 -- cgit v1.2.3