ocserv: support custom server SSL certificate

[jacklovell]

Add UCI options for the path to the server's SSL certificate and private key. This enables the use of a certificate provided by an external certificate authority instead of the default self-signed certificate.

The self-signed certificate is still produced if it doesn't already exist, and is used by default. So this change should be transparent to existing users.

Fixes #23099.

This is the commit from #29604 cherry-picked to the master branch instead of 25.12. Tested in the OpenWRT rootfs docker container, but not on actual hardware.

📦 Package Details

Maintainer: @nmav

Description:
Add UCI options for the path to the server's SSL certificate and private key. This enables the use of a certificate provided by an external certificate authority instead of the default self-signed certificate.

---

🧪 Run Testing Details

• OpenWrt Version: snapshot
• OpenWrt Target/Subtarget: mips
• OpenWrt Device: docker rootfs

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

If your PR contains a patch:

• It can be applied using git am
• It has been refreshed to avoid offsets, fuzzes, etc., using

  make package/<your-package>/refresh V=s

• It is structured in a way that it is potentially upstreamable
  _{(e.g., subject line, commit description, etc.)
  We must try to upstream patches to reduce maintenance burden.}

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[nmav]

LGTM. My main concern is how would this be used with letsencrypt or so?

[jacklovell]

One would use LetsEncrypt to generate a certificate and key pair, for example using the ACME package - I prefer using the DNS-01 challenge available with the acme-acmesh-dnsapi package for this. The certificate and key are placed in /etc/acme/<fqdn>, and then the user configures ocserv to use the fullchain.cer and <fqdn>.key files in that directory using the new server_key and server_cert options.

For example, a certificate for the vpn.example.com domain would be found at /etc/acme/vpn.example.com/fullchain.cer and the signing key at /etc/acme/vpn.example.com/vpn.example.com.key. So one would then add the following to /etc/ocserv/config:

config ocserv 'config'
    option server_cert '/etc/acme/vpn.example.com/fullchain.cer'
    option server_key '/etc/acme/vpn.example.com/vpn.example.com.key'

It's possible to use /etc/acme/vpn.example.com/vpn.example.com.cer as the certificate but I found the full chain more reliable as some clients don't have the full chain of trust built in to the OS.

The ocserv configuration is intentionally agnostic to the method used to obtain a certificate, in case users have a certificate from another provider: there are commercial certificate authorities who may provide certificates for example. It also future-proofs the package in case the acme interface changes or another free provider gains popularity.

If this PR gets merged I would update https://openwrt.org/docs/guide-user/services/vpn/openconnect/server with instructions for how to use a custom certificate, linking to the LetsEncrypt instructions for obtaining one with acme.