Is your feature request related to a problem? Please describe.
Currently, OpenWISP restricts automated X.509 certificate generation exclusively to OpenVPN clients. If an administrator wants to create general-purpose certificates, for example for securing web services or 802.1x, they are forced to attach an unnecessary VPN configuration.
Describe the solution you'd like
Instead of creating a separate template model, I will extend the existing AbstractTemplate model to natively support standalone certificates.
- Add
"cert" to the TYPE_CHOICES.
- Introduce a direct
ca ForeignKey to the django_x509.Ca model.
- Introduce an optional
blueprint_cert ForeignKey to the django_x509.Cert model.
- Update the
clean() method validation to:
- Allow
auto_cert = True when type == "cert".
- Require a
ca when type == "cert".
- Clear
ca and blueprint_cert when type != "cert".
- Validate organization scoping for
ca and blueprint_cert, following the same _validate_org_relation() pattern already used by template relations.
Blueprint certificate validation
Enforce the blueprint constraint: validate that if a blueprint_cert is selected, it is not currently assigned directly to any device via DeviceCertificate.
The proposal lists the following controller-level validation points:
- Admin/API filtering should prevent already assigned certificates from being selected as blueprint certificates.
Template.clean() should validate that a selected blueprint_cert is not assigned to a device.
DeviceCertificate.clean() should prevent a certificate referenced as a blueprint from being assigned to a device.
Decision to keep open
The proposal mentions an optional naming convention for blueprint certificates in django-x509 admin, for example [TEMPLATE] - ..., if visual distinction is needed. This is not decided here and can be investigated during implementation.
Measurable outcome: 1, 2
Implementation point: 6, 7
Is your feature request related to a problem? Please describe.
Currently, OpenWISP restricts automated X.509 certificate generation exclusively to OpenVPN clients. If an administrator wants to create general-purpose certificates, for example for securing web services or 802.1x, they are forced to attach an unnecessary VPN configuration.
Describe the solution you'd like
Instead of creating a separate template model, I will extend the existing
AbstractTemplatemodel to natively support standalone certificates."cert"to theTYPE_CHOICES.caForeignKeyto thedjango_x509.Camodel.blueprint_certForeignKeyto thedjango_x509.Certmodel.clean()method validation to:auto_cert = Truewhentype == "cert".cawhentype == "cert".caandblueprint_certwhentype != "cert".caandblueprint_cert, following the same_validate_org_relation()pattern already used by template relations.Blueprint certificate validation
Enforce the blueprint constraint: validate that if a
blueprint_certis selected, it is not currently assigned directly to any device viaDeviceCertificate.The proposal lists the following controller-level validation points:
Template.clean()should validate that a selectedblueprint_certis not assigned to a device.DeviceCertificate.clean()should prevent a certificate referenced as a blueprint from being assigned to a device.Decision to keep open
The proposal mentions an optional naming convention for blueprint certificates in django-x509 admin, for example
[TEMPLATE] - ..., if visual distinction is needed. This is not decided here and can be investigated during implementation.Measurable outcome: 1, 2
Implementation point: 6, 7