From 10387da9630e2e8523b01032bbd4ae24177f9d63 Mon Sep 17 00:00:00 2001 From: stktyagi Date: Mon, 13 Jul 2026 22:05:11 +0530 Subject: [PATCH] [docs] GSoC26 X.509 Certificate Generator Templates blog section Added content for X.509 Certificate Generator templates gsoc project with future work. --- content/blog/gsoc26-midterm-report.rst | 50 ++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/content/blog/gsoc26-midterm-report.rst b/content/blog/gsoc26-midterm-report.rst index b094765..4fc2374 100644 --- a/content/blog/gsoc26-midterm-report.rst +++ b/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 +`_): 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 +`_): Operators +can reference generated certificates in device configuration using Jinja2 +template variables such as ``{{ cert__path }}`` for the file path, +``{{ cert__pem }}`` for the PEM-encoded certificate, and ``{{ +cert__key }}`` for the private key. These are resolved at +configuration preview and generation time. + +**Certificate regeneration on hardware drift** (`PR #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 +`_): 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:::`` 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.