[bug] Deleting CA/Certificate in use by VPN Client corrupts device configuration

[pandafy]

Describe the bug

When a CA or Certificate used by an active VPN Client is deleted from the admin panel, the associated device's configuration becomes corrupted instead of being prevented or properly handled. The configuration status incorrectly remains as "applied" even though the configuration contains unresolved context keys.

Steps To Reproduce

1. Create a VPN with OpenVPN backend
2. Create a CA and certificate for the VPN server
3. Create a VPN Client template for the VPN server created in the previous step
4. Apply the template to a device and verify that the device's config.status changes to "applied"
5. Navigate to http://127.0.0.1:8000/admin/pki/cert/
6. Delete the certificate that was created for the device to be used in OpenVPN configuration
7. Confirm the deletion in the confirmation dialog

Expected behavior

The system should prevent deletion of CA and Certificate objects when they are actively used in a VPN Client by a device. Instead of allowing deletion, the confirmation page should direct the user to remove the template from the specific device, which will automatically delete the certificate.

Actual behavior

• The certificate and associated VPN Client are deleted
• The device's configuration status remains "applied" instead of changing to "modified"
• Cache invalidation for the Config.checksum is not triggered
• When previewing the configuration, the context keys for certificate paths and content are not resolved
• This results in a corrupted configuration with invalid placeholder values

Screenshots

OpenWISP hints that deleting the Cert object will delete the related VpnClient:

Corrupted configuration with unresolved context keys:

[omlahore]

I would like to work on this.

I traced the root cause on master and it lines up with the report. Deleting a Cert cascade-deletes the linked VpnClient (OneToOneField with on_delete=CASCADE in config/base/vpn.py), and AbstractVpnClient.post_delete never marks the owning device Config as modified or invalidates its checksum cache. The only cache-related call there is Vpn._invalidate_peer_cache(), whose body is guarded to the wireguard/vxlan backends, so for an OpenVPN VPN it is a no-op. Meanwhile get_vpn_context builds the cert content/key context from vpnclient.cert, so once the VpnClient row is gone those keys drop out and the still-applied config keeps unresolved placeholders, exactly as the screenshots show.

The asymmetry is that there is a Cert post_save handler (Config.certificate_updated) that rechecks the checksum and marks the config modified, but no equivalent on Cert post_delete, so the delete path silently leaves the config stale.

Before I open a PR, how would you prefer to fix this? The issue proposes blocking deletion of a CA/Cert that is in use and redirecting the user to remove the template. The lighter alternative is to have the VpnClient teardown transition the config to 'modified' and invalidate the checksum, matching the existing post_save behavior. I also want to flag PR #1418 (issue #1095), which rewrites the cache-invalidation wiring in these same files but does not touch this delete path. Would you rather I keep this scoped narrowly to the delete/status logic to avoid conflicting with that work?

[openwisp-companion]

Hi @omlahore 👋,

Thank you for your interest in contributing to OpenWISP! 🎉

According to our contributing guidelines, you don't need to wait to be assigned to start working on an issue.
We encourage you to:

1. Fork the repository and start working on your solution
2. Open a Pull Request (PR) as soon as possible - even as a draft if it's still in progress
3. Link your PR to this issue by including Fixes #1419 in the PR description

Note: We suggest Fixes because this appears to be a bug. You can also use:

• Closes #1419 for features/changes
• Fixes #1419 for bugs
• Related to #1419 for PRs that contribute but don't completely solve the issue

Once you open a PR that references this issue, you will be automatically assigned to it.

This approach helps us:

• See your progress and provide early feedback
• Avoid multiple contributors working on the same issue unknowingly
• Keep the contribution process moving smoothly

We look forward to your contribution! If you have any questions, feel free to ask in the PR or check our documentation.

Happy coding! 🚀

[openwisp-companion]

This issue has been automatically assigned to @omlahore who opened PR #1432 to address it. 🎯