Is your feature request related to a problem? Please describe.
Currently, OpenWISP restricts automated X.509 certificate generation exclusively to OpenVPN clients. This creates a significant architectural limitation for real-world deployments. If a network administrator wants to secure a local Web UI using HTTPS, set up 802.1x Wi-Fi enterprise authentication, or configure mTLS for local APIs, they are forced to attach an entirely unnecessary VPN configuration to the device just to generate the required certificates.
Describe the solution you'd like
#1378 implements support for general-purpose X.509 certificate generation that extends beyond OpenVPN usage. Highlighting real-life use cases will clarify why this decoupled architecture is necessary.
Key real-life use cases to document and support include:
- Securing Local Web UIs: Automatically setting up a secure connection (HTTPS) so that when an administrator logs directly into a router or device's local configuration page, their passwords and data are encrypted and safe.
- Enterprise Network Access: Making it much easier to set up high-security Wi-Fi networks, the kind typically used in corporate offices or universities where every individual device needs its own unique "digital ID card" to connect to the network.
- Safe Machine-to-Machine Communication: Allowing devices and applications on the network to securely share data and talk to each other using strict digital IDs, without requiring the heavy processing power and complex setup of a full VPN tunnel.
Additional context
Documenting these specific scenarios (HTTPS, 802.1x, mTLS) will help contributors understand the necessity of decoupling certificate generation from the VPN module. It clarifies why we need fully functional lifecycle management to automatically generate, bind, revoke, and renew these standalone certificates.
Related Work
Related work is currently being tracked and maintained in the project's Kanban board.
Is your feature request related to a problem? Please describe.
Currently, OpenWISP restricts automated X.509 certificate generation exclusively to OpenVPN clients. This creates a significant architectural limitation for real-world deployments. If a network administrator wants to secure a local Web UI using HTTPS, set up 802.1x Wi-Fi enterprise authentication, or configure mTLS for local APIs, they are forced to attach an entirely unnecessary VPN configuration to the device just to generate the required certificates.
Describe the solution you'd like
#1378 implements support for general-purpose X.509 certificate generation that extends beyond OpenVPN usage. Highlighting real-life use cases will clarify why this decoupled architecture is necessary.
Key real-life use cases to document and support include:
Additional context
Documenting these specific scenarios (HTTPS, 802.1x, mTLS) will help contributors understand the necessity of decoupling certificate generation from the VPN module. It clarifies why we need fully functional lifecycle management to automatically generate, bind, revoke, and renew these standalone certificates.
Related Work
Related work is currently being tracked and maintained in the project's Kanban board.