WebExpress 2.0.0‑alpha – Native Certificate Management

One of the strengths of WebExpress has always been its ability to operate efficiently across a wide range of environments, from small Raspberry Pi installations to larger server deployments. HTTPS support based on Kestrel has been part of the framework for years, and certificates can already be configured directly on endpoints using PFX files. This simple and reliable approach has served WebExpress well, particularly in lightweight and self hosted environments.

As the platform continues to evolve, certificate management is becoming increasingly important. Today, HTTPS endpoints are directly coupled to certificate files defined in configuration. While this works perfectly for smaller deployments, it limits future scenarios such as automated certificate management, centralized certificate stores, cloud integrations, and dynamic multi domain hosting.

To address these challenges, WebExpress is introducing a native certificate management infrastructure. The objective is to treat X.509 certificates as first class platform resources that can be centrally managed and consumed throughout the framework. Instead of allowing applications and hosting components to access PFX files directly, a new CertificateManager will become responsible for loading, validating, monitoring, and providing certificates to all consumers within the platform.

The first implementation focuses on the existing deployment model used by WebExpress. Certificates remain stored as password protected PFX files on the local filesystem. During startup, the CertificateManager scans the configured certificate locations, validates all available certificates, collects metadata such as issuer information and expiration dates, and registers the certificates for use by HTTPS endpoints. Existing installations can therefore benefit from the new infrastructure without requiring any changes to their deployment procedures.

A key design principle of the implementation is the separation of certificate consumption from certificate storage. Hosting components no longer need to know where certificates are physically located or how they are loaded. Instead, certificates are resolved through a unified API using aliases or host names. This abstraction creates a stable foundation for future extensions while preserving compatibility with existing WebExpress deployments.

The infrastructure is also designed to support multiple certificates from the outset. This allows certificates to be associated with specific host names and prepares the framework for future Server Name Indication scenarios where different domains hosted by the same WebExpress instance can automatically receive the appropriate certificate.

Beyond simply loading certificates, the CertificateManager will continuously monitor certificate validity. Information such as issuer, thumbprint, expiration date, and operational state becomes available through a centralized API. Certificates approaching their expiration date can automatically generate warnings through the platform's logging infrastructure, helping administrators identify potential issues before service disruptions occur.

Perhaps the most important aspect of this initiative is extensibility. While the first version focuses exclusively on filesystem based certificate storage, the architecture is intentionally designed around abstraction interfaces rather than concrete implementations. Future extensions may introduce automated ACME certificate provisioning, Let's Encrypt integration, certificate renewal services, DNS and HTTP based validation challenges, Azure Key Vault support, and additional certificate providers without requiring changes to existing applications or hosting components.

With this effort, WebExpress takes an important step toward a modern and extensible security infrastructure. The initial goal is not to automate certificate issuance but to establish a robust and platform wide certificate foundation on which future TLS features can be built.

As with every major architectural component of WebExpress, community feedback and contributions are highly appreciated. If you are interested in platform architecture, security infrastructure, certificate management, cloud native hosting, or TLS automation, we invite you to join the discussion. Challenge assumptions, share ideas, propose improvements, or contribute implementations. The best frameworks are built through collaboration, and every architectural perspective helps shape a stronger future for WebExpress.

Location: Cottbus, Deutschland

Comments

Post a Comment

Popular posts from this blog

WebExpress 0.0.10-alpha – A Step Back for Reflection

Image
With version 0.0.10-alpha of WebExpress , a new development phase begins for TableCtrl. The previous solution was certainly rich in features, but its structure was monolithic, complex, and error-prone. It combined both data presentation and editing into a single component and offered a wide range of features: declarative configuration via HTML, client-side row sorting, column reordering with persistent configuration storage, manual row movement, hierarchical nesting, cell templates, inline editors, per-row options menus, row icons, and row URLs. Derived classes even added dynamic data loading, search, paging, and row editing and deletion. However, this abundance of functionality led to blurred responsibilities and reduced maintainability, even though existing controls were used to display cells. The reason this realignment wasn’t undertaken earlier lies primarily in the pragmatic and pressure-driven nature of the original development. The goal was to quickly deliver a broad spectrum of...
Read more

WebExpress 0.0.10-alpha – The REST APIs as the Foundation of the Table Architecture

Image
Tables in WebExpress are far more than simple display tools. They form a dynamic, modular and fully API‑driven interface that can be integrated flexibly into any website. Their essential design principle is the strict separation of data and layout. While the layout defines how a table looks and which interactions are possible, all content and structural descriptions come from the REST API. When a dynamic table is loaded, WebExpress calls the table REST API and receives both the table data and the metadata that define its structure. This metadata contains templates that specify how individual cells are displayed and edited. A template describes the visual representation, the type of interaction and the logic applied during editing. This keeps the table fully flexible, because the layout can change without requiring any modification to the underlying data. Column configuration is also managed through the API and can be adjusted dynamically without altering the layout itself. The intera...
Read more

WebExpress 0.0.11‑alpha – The Light Theme and Beyond

Image
The introduction of a light theme for the built‑in icons in WebExpress marks a significant step in the visual and technological evolution of the framework. While the well‑known FontAwesome symbols were previously used, whose design is based on filled shapes and therefore creates a high visual density, the new icon set expands the visual repertoire with a contour‑based representation. These icons consist exclusively of lines and create a particularly flat and modern appearance that aligns with contemporary design principles and integrates harmoniously into minimalist user interfaces. Examining the two icon styles shows that they fulfill different roles not only aesthetically but also functionally. Filled icons have a stronger visual presence and are particularly suitable for interactions that require a clear call to action, as closed shapes are perceived more quickly as compact forms. Contour icons, on the other hand, appear lighter and more restrained, making them better suited for c...
Read more