[GSoC] X.509 Certificate Generator Templates

[nemesifier]

Official thread for this GSoC idea, ask questions and announce your interest here.

[devangpratap]

The spec says the referenced certificate object is used "exclusively as a template" and is "never issued or assigned to devices
directly" — but it still lives in the same Cert table as real certificates. What's the plan to distinguish template certs from
live ones? Is there a flag on the model, or is that distinction purely enforced at the controller level?

[nemesifier]

Good question, I am open for suggestions, we could add a flag for this if it makes implementing validation checks easier.

[devangpratap]

Adding is_template = models.BooleanField(default=False) to AbstractCert looks like the right level as CAs dont need this distinction and the BaseX509/AbstractCert split already draws that line cleanly
With the flag we get:

• A clean() override on AbstractCert that blocks a device_id from being set if
  is_template=True which is hard DB-level prevention, not just UI convention.
• Admin queryset filtering to hide template certs from the active cert list by
  default
• Template certs still go through _generate() and hold real X.509 data ,the
  flag is purely a lifecycle guard not a generation skip

[nemesifier]

Detail this in your proposal.

[stktyagi]

In the project description it is mentioned that

Custom x509 extensions stored in the existing extensions JSON field, using private OIDs

This is with reference to MAC address and uuid but currently, the _add_extensions function depends on predefined extension classes and doesn’t support parsing arbitrary cryptography.x509.ObjectIdentifier values from strings. Because of this limitation, should we open a small issue to patch this? It would only need small changes in the else block of _add_extensions.

[devangpratap]

Thanks. The problem that would come after parsing the OID string is that
_add_extensions already uses x509.UnrecognizedExtension for
nsComment/nsCertType which requires raw DER encoded bytes. So the else block
needs to define how arbitrary OID values get encoded too ,thats the part
worth speccing carefully. Since private OID support for MAC/UUID is a hard
requirement in the GSoC spec, Ill draft a PR for that this week with a
defined encoding approach, so there's something concrete to review before the
proposal phase @nemesifier can you ensure I have the correct understanding

[nemesifier]

We can change what is needed to reach the goals described in the project idea.

Detail your concerns and your proposed solution in your proposal.

Regarding PRs, I am sorry but can't promise I'll be able to reply in a timely manner due to the high volume of pull requests we have been receiving.

[devangpratap]

The spec says a template cert's non unique fields are copied when generating per device certs. validity_start and validity_end on BaseX509 are absolute DateTimeField values , so a template created 6 months ago with validity_end = now + 1 year would give a device cert only 6 months of validity at assignment time not 1 year.
And even if the absolute copy is intentional, BaseX509.renew() unconditionally resets validity_end to default_cert_validity_end() (lines 664 in base/models.py) discarding whatever the template specified. So the template's custom validity window survives only the initial generation every renewal reverts to the system default.
Should the template store an explicit validity duration (like in days) instead of relying on absolute timestamps, so both initial generation and renewals can apply a consistent window from the template? Can you please tell me if I'm missing something?

[nemesifier]

@devangpratap we have the creation date right? So the difference between the creation date and the validity_start and validity_end can be used as the validity to use for new certs, or am I missing something?

[devangpratap]

Thank you it makes sense now. Deriving the duration as validity_end - validity_start is cleaner than adding a new field .
One small follow-up: renew() currently resets validity_end to default_cert_validity_end() unconditionally, so even if initial generation uses derived duration correctly, renewals would still revert to the system default. What I believe is happening is renew() hardcodes the default_cert_validity_end() without looking what the values are on the cert.
Would it make sense for renew() to also reapply the template's derived duration or is that out of scope for this feature?

[nemesifier]

@devangpratap I think we must make renewals consistent with the duration used in the cert template

[stktyagi]

I am interested in pursuing this project.

The project idea page mentions two things:-

Certificates are generated when a certificate template is assigned to a device, following the same lifecycle semantics as existing OpenVPN client certificates.

Assignment generates a new certificate

Unassignment deletes the certificate

Renewal regenerates the certificate

No standalone certificates are generated without device assignment

1. It says to follow the "same lifecycle semantics as existing OpenVPN client certificates."
2. It also says "Unassignment deletes the certificate."

While tracing the execution path for existing OpenVPN clients, I noticed that unassignment actually revokes the underlying Cert object (leaving it in the database for the CRL) rather than deleting it. Which makes sense, so instead of deleting the certificate shouldnt we be leaving it in the db for the CRL.

Used in openwisp-controller/openwisp_controller/config/base/vpn.py

@classmethod
    def post_delete(cls, instance, **kwargs):
        """Receiver of ``post_delete`` signal.

        Automatically deletes related certificates
        and ip addresses if necessary.
        """
        # only invalidates, does not regenerate the cache
        # to avoid generating high load during bulk deletes
        instance.vpn._invalidate_peer_cache()
        # Zt network member should leave the
        # network after deletion of vpn client object
        if instance.vpn._is_backend_type("zerotier"):
            instance.vpn._remove_zt_network_member(instance.zerotier_member_id)
        try:
            # For OpenVPN, the related certificates are revoked, not deleted.
            # This is because if the device retains a copy of the certificate,
            # it could continue using it against the OpenVPN CA.
            # By revoking the certificate, it gets added to the
            # Certificate Revocation List (CRL). OpenVPN can then use this
            # CRL to reject the certificate, thereby ensuring its invalidation.
            if instance.cert and instance.auto_cert:
                instance.cert.revoke()
        except ObjectDoesNotExist:
            pass
        try:
            if instance.ip:
                instance.ip.delete()
        except ObjectDoesNotExist:
            pass

[nemesifier]

Your observation is correct, I forgot about this detail while writing the idea, thanks! Corrected it: openwisp/openwisp-docs@4ea8cfe.