Valdras Gate - VPN Gateway

Auto-renew release. v1.1.0 adds a daily systemd timer that watches user profiles for upcoming expiry and re-issues a fresh .ovpn to anyone you opted into the auto-renew flag, before their old profile dies. The renewed profile is emailed via the same SES path the gateway already uses, so users see a normal mail with the new .ovpn attached and switch over on their own time. Existing users carry forward unchanged -- the auto-renew flag defaults off; nothing renews until you opt a user in.

The release also ships three new operator commands. ov_user_audit is a single read-only lens over the user database -- active users, supersession history, expired profiles, revoked users, and the new "stuck" state the renewal job uses when it cannot roll a partial failure all the way back. ov_user_resend re-mails the currently active profile for a user (use it when SES bounced the original, when the user lost the mail, or when SMTP was misconfigured at issue time and got fixed later). ov_user_auto_renew flips the auto-renew flag on or off for an existing user without going through delete + re-add.

ov_user_delete now soft-deletes: the user row is kept and marked revoked, the certificate is revoked and added to the CRL exactly as before, and the OpenVPN service is restarted. Functionally identical from the customer's perspective (the revoked user is locked out immediately) -- the row retention gives ov_user_audit a complete history view.

There is no in-place upgrade. This version replaces the AMI, and all operator-unique state (user database, CA private key, client certificates, CRL, email settings, split-DNS config) lives on the gateway's root volume. To move to v1.1.0, take a backup on the old gateway, launch a new instance from the v1.1.0 AMI, restore the backup onto it, and move the Elastic IP across. No client profiles need to be reissued.

The restore step automatically migrates the user database from the v1.0.x schema to the v1.1.0 schema during ov_restore. Every existing user is preserved with auto_renew=false and status=active; you opt users in afterwards with ov_user_auto_renew --email <addr> --traffic <all|partial> --enable once they are on the new gateway.

SSH into the old gateway as ec2-user and run:

ov_backup produces a single archive (/home/ec2-user/backup-<host>-<timestamp>.tar.gz) containing the user database, CA private key, every client certificate, the operational CRL, the TLS-auth PSK, the SES email credentials, the split-DNS configuration, and every issued .ovpn profile on disk. It also prints ready-to-paste scp commands for copying the archive off the box.

scp the archive off the gateway. Treat it as a master secret -- it contains the CA private key, every user's private key, and your SES SMTP credentials. Encrypt at rest, transfer over SSH only, never email it, never commit it to git.

Launch a new EC2 instance from the v1.1.0 AMI in the same VPC. Same security group, same subnet, same instance type as before is fine.

Wait for first boot to finish before restoring. First boot generates a throwaway CA and seeds /etc/openvpn/udp-server.conf with DNS push lines for the new VPC's resolvers. Confirm completion by checking that /opt/0x4447/.done exists.

scp the backup archive to the new instance (/home/ec2-user/), SSH in, and run:

ov_restore runs four pre-flight checks (whitelist, presence, CA-cert sanity, sibling-path) before touching the filesystem. On success it stops the service, extracts the archive, re-asserts permissions on every secret file, migrates the user database in place from the v1.0.x schema to the v1.1.0 schema, re-applies the saved split-DNS rules, restarts the service, and prints a restore summary. If any pre-flight fails, nothing is written and the tool aborts with a specific error.

The schema migration is idempotent -- re-running ov_restore against the same archive is safe.

Delete the archive once you are done: rm -f <archive>.tar.gz.

Reassign the Elastic IP from the old gateway to the new one before users reconnect. Existing .ovpn profiles bake in the public IP at issue time -- same IP means every existing profile keeps working with no client-side change. Different IP means every profile must be reissued with ov_user_add.

The user list must match the old gateway. Then verify the CRL survived the restore:

The count must match the number of users you have revoked over the lifetime of the old gateway. A zero or low count means revoked users will reconnect -- investigate before moving on.

Confirm the migration landed on schema v1.1.0:

Must print 1.1.0.

Finally, connect a test client using an .ovpn profile issued by the old gateway and confirm it authenticates. If you have a revoked profile on hand, confirm it is rejected.

Once everything checks out, stop and terminate the old instance.

The migration carries every user forward with auto-renew disabled. Pick the users you want renewed automatically and run:

The daily renewal job fires at 00:00 UTC with a one-hour jitter window and re-issues profiles whose expiration_date is within 10 days. The new profile is emailed via SES; the old profile keeps working until its own expiry, giving the user time to switch clients.

Each renewed profile keeps the user's original validity length: the new certificate expires one original term beyond the old expiry date, not one default term beyond the renewal moment. A user issued a 365-day profile and renewed a week early comes out with a certificate still good for ~372 days -- so users stay on their original renewal cadence instead of drifting earlier every cycle.

Auto-renew needs SES configured. If /opt/0x4447/configs/email.conf does not have SMTP_USERNAME and SMTP_PASSWORD filled in, the renewal still runs -- a fresh certificate is issued and becomes the user's active profile -- but the new .ovpn is not emailed; the job logs email_skipped and the profile waits on the gateway under /home/ec2-user/openvpn_users/. The user keeps working on their old profile until it expires, but never receives the replacement, so they are locked out at expiry unless you step in. Configure SES before you opt users in. If a renewal already fired while SES was down, fix the credentials and run sudo ov_user_resend --email <addr> --traffic <all|partial> to mail the active profile.

This release preserves the v1.0.x revocation guarantees. ov_user_delete revokes the user's certificate, regenerates the CRL, copies it into /etc/openvpn/server/crl.pem, restarts the OpenVPN service, and marks the user row revoked in the database. The certificate is rejected by the server immediately, not on next renewal -- the soft-delete is a database-audit-trail addition, not a softening of the revocation gate.

For SOC 1, SOC 2, and PCI DSS environments: backups produced by ov_backup continue to contain the CA private key and every user's private key. Encrypt them at rest (S3 + KMS is fine), transfer them only over SSH, and rotate the gateway CA if a backup is ever exposed. The ov_user_audit command provides a complete read-only history of every certificate ever issued -- useful evidence for access-review controls.

Full documentation, including the ov_user_audit lenses, the auto-renew SES setup walkthrough, and troubleshooting for the new commands, lives at:

https://products.0x4447.com/product/gate/documentation/1.1.x/