[docs] GSoC26 X.509 Certificate Generator Templates blog section

content/blog/gsoc26-midterm-report.rst

@@ -2,7 +2,7 @@ OpenWISP 26 Midterm Report
 ==========================
 
 :date: 2026-07-07
-:authors: Federico Capoano, Deepanshu Sahu, Mohammed Atif
+:authors: Federico Capoano, Deepanshu Sahu, Mohammed Atif, Sarthak Tyagi
 :tags: gsoc, new-features
 :category: gsoc
 :lang: en
@@ -121,4 +121,50 @@ X.509 Certificate Generator Templates
 
 Video.
 
-Summary of progress.
+In OpenWISP, provisioning X.509 certificates for each device has
+traditionally been a manual process where operators had to create
+certificates individually through the PKI module. This becomes impractical
+at scale. Certificate Generator Templates solves this by introducing a new
+``cert`` template type that automatically generates and manages X.509
+certificates when assigned to devices, with support for blueprint-based
+configuration, context injection, and automatic regeneration on hardware
+changes.
+
+**Template model and DeviceCertificate lifecycle** (`PR #1378
+<https://github.com/openwisp/openwisp-controller/pull/1378>`_): A new
+``cert`` type is added to the Template model with ``ca`` and
+``blueprint_cert`` ForeignKeys referencing a Certification Authority and a
+blueprint certificate. The ``DeviceCertificate`` through-model links
+Config, Template and Cert with an idempotent lifecycle: when a cert
+template is assigned to a device, a certificate is generated automatically
+from the blueprint; when the template is removed, the certificate is
+revoked but preserved in the database. Active templates are locked against
+type, CA, and blueprint changes.
+
+**Context configuration injection** (`PR #1378
+<https://github.com/openwisp/openwisp-controller/pull/1378>`_): Operators
+can reference generated certificates in device configuration using Jinja2
+template variables such as ``{{ cert_<uuid>_path }}`` for the file path,
+``{{ cert_<uuid>_pem }}`` for the PEM-encoded certificate, and ``{{
+cert_<uuid>_key }}`` for the private key. These are resolved at
+configuration preview and generation time.
+
+**Certificate regeneration on hardware drift** (`PR #1378
+<https://github.com/openwisp/openwisp-controller/pull/1378>`_): When a
+device's name or MAC address changes, a Celery task automatically revokes
+the existing certificate and issues a replacement. This can be disabled
+per deployment via the ``REGENERATE_CERTS_ON_HARDWARE_CHANGE`` setting.
+
+**Custom X.509 extensions with ASN.1 DER encoding** (`PR #228
+<https://github.com/openwisp/django-x509/pull/228>`_): The django-x509
+library adds support for custom Object Identifiers (OIDs) in certificate
+extensions. An ASN.1 DER encoder validates and wraps values using the
+``ASN1:<TYPE>:<KIND>:<VALUE>`` syntax. Reserved standard OIDs are
+protected from overriding. Generated device certificates automatically
+include custom extensions for the device MAC address
+(``1.3.6.1.4.1.65901.1``) and UUID (``1.3.6.1.4.1.65901.2``).
+
+In the coming weeks, we will focus on refining the implementation and
+generalizing the certificate template system so it can be relied upon for
+``VpnClient`` as well, ensuring a consistent certificate provisioning
+experience across the entire device configuration pipeline.