OpenVPN suddenly stopped working? Check your certificate revocation list

I used to run a SoftEther VPN to expose an OpenVPN connection to my house, and that was great until it randomly stopped working (sometime after I switched to certificate-based connections).  So last year, I switched to running a plain old OpenVPN server with easyrsa and a couple helper shell scripts.

And that was great until it randomly stopped working.  At first, I thought that it was the FydeOS Android subsystem on my work computer that was causing problems, but when I tried to VPN from my phone, it wouldn't work, either.  It just sat there for a minute and then timed out.

When I checked the logs (/var/log/syslog), I saw this:

openvpn[557]: X.X.X.X:35633 VERIFY ERROR: depth=0, error=CRL has expired: CN=XXXX, serial=XXXX

The short version of the story is that the certificate revocation list (CRL) that I set up only has a lifetime of 180 days by default, and once it expires, OpenVPN doesn't work at all.

The solution was just to regenerate the CRL:

./easyrsa gen-crl

That created a new "crl.pem" file that just needed to be copied to "/etc/openvpn/server/".

The main trick is to make the lifetime a lot longer (such as 10 years).  You can add that to your easyrsa "vars" file with this line:

set_var EASYRSA_CRL_DAYS 3650

Once the CRL is generated with that variable set, it'll have a 10-year expiration date.

So, in addition to my "create-client-profile.sh" and "revoke-client-profile.sh" scripts, I added a "regenerate-certificate-revocation-list.sh" script.

With that, this hopefully shouldn't bite me again.  And if it does, it's just a one-liner to get it back up and running.

Signs of a current Chromium crash in GCP Cloud Run when using go-rod

This is mainly here so that I can find it again if it ever comes up, or maybe you'll find it when you're googling a log message.

The tl;dr is that Chromium crashes in GCP Cloud Run (on Alpine Linux if that's relevant) at version 146.0.7680.80-r0.

Why?  I'm not quite sure.  Yesterday, when it was running version 144.0.7559.132-r4, it ran fine.

(We use Chromium under the hood with go-rod to generate PDFs as part of our application.)

In the logs, we saw this:

Connecting to browser at endpoint: ws://127.0.0.1:42590/devtools/browser/f2909d30-39b2-4d59-9fab-e81d79a8f006

Chromium path: /usr/bin/chromium
Recovered from panic: [*net.OpError] write tcp 127.0.0.1:58219->127.0.0.1:42590: use of closed network connection
Uncaught signal: 4, pid=280, tid=280, fault_addr=94169238392146.

As best as I can tell, signal 4 on Linux has to do with a processor instruction mismatch of some kind.  Anyway, the (automatic) Chromium version change was the only thing that could explain the problem, and we rolled back by using "alpine:3.22" instead of "alpine:latest" in our Docker image.

This instantly fixed the problem.  I don't know why it broke, but I know where it broke.  Hopefully they get this fixed up, and now we know that we have to actually test this in GCP if we ever want to un-pin the Alpine version and upgrade Chromium again.