Certify The Web for Windows Certificate Management

Certify The Web's Certificate Management Scope

Certify The Web addresses the recurring work involved in obtaining and maintaining TLS certificates. The README describes automatic certificate requests, installation, and continuous renewal for Windows and IIS, as well as for other services that require a certificate. It is aimed at administrators who need a visible certificate workflow rather than issuing a certificate through a one-off command. The application supports single-domain certificates, SAN certificates, and wildcard certificates such as `*.example.com`.

The project connects to ACME certificate authorities, including Let's Encrypt, Google Trust Services, ZeroSSL, and Martini Security for STIR/SHAKEN certificates. It also supports private ACME servers, with DigiCert, smallstep, and Keyon true-Xtender named as examples. A one-time ACME workflow can issue a certificate, but it does not provide the same recurring management model. Certify The Web retains certificate configuration and runs renewal work through a background service. The README also states that a single instance can be configured to manage thousands of certificates in the licensed version.

Certify The Web's IIS Request and Renewal Flow

The documented IIS workflow begins when an administrator selects an existing IIS site or enters hostnames manually. Certify The Web can detect binding hostnames, request the certificate, install it, and configure the SSL binding. A preview mode is available to show the actions that would be performed, including bindings that would be added or updated. That preview matters because an unattended certificate operation can otherwise make changes to IIS configuration that an administrator has not inspected.

Renewal is handled by a background service. The renewal frequency is configurable, so certificate acquisition and later maintenance are separate steps rather than requiring an administrator to submit every renewal manually. Deployment Tasks can run before or after a request. The README lists deployment targets such as Exchange, RDS, multi-server deployments, CCS, Apache, nginx, file export, webhooks, HashiCorp Vault, and Azure KeyVault. These tasks extend the operation beyond IIS, although the main application still has Windows-specific requirements. PowerShell 5.1 or higher is listed as necessary for functionality such as Deployment Tasks and some DNS providers.

Certify The Web's HTTP and DNS Validation Paths

Certify The Web supports validation through HTTP or DNS challenges. The application includes a built-in HTTP Challenge Server to make challenge response configuration easier. DNS validation can use more than 30 supported APIs, including Azure DNS, Alibaba Cloud, AWS Route53, Cloudflare, DnsMadeEasy, GoDaddy, OVH, and SimpleDNSPlus. Some providers are implemented through the Posh-ACME project.

Certify DNS is also listed as a cloud-managed DNS challenge validation service that permits DNS validation through any DNS provider. The README additionally documents `dns-persist-01` persistent DNS validation. Multiple authorizations can be associated with one managed certificate, allowing different domain validation settings within the same certificate workflow. This is useful when domains use different DNS providers or when an organization cannot apply one validation method uniformly.

Stored credentials, including API access keys, are protected by the Windows Data Protection API. That protection is tied to Windows and distinguishes the main desktop client from the self-hosted Management Hub described as cross-platform. The README does not explain how Windows Data Protection API credentials are migrated to a machine running another operating system. An operator considering the Hub should therefore not assume that credential storage is portable.

Installing Certify The Web for the First IIS Certificate

The normal installation route is the download page at `https://certifytheweb.com/`. The README also provides a Chocolatey command for users who already use that package manager. The main application requires 64-bit Windows. PowerShell 5.1 or higher is required for documented functionality such as Deployment Tasks and some DNS providers, and supported operating systems are limited to those Microsoft currently supports.

After installation, select `New Certificate`. Choose an IIS site when the certificate will be attached to one. Certify The Web can detect the site's binding hostnames, or the administrator can enter them manually. Save the settings and select `Request Certificate`. The README states that the certificate will renew automatically after this workflow. Before the request, inspect the preview and verify the selected validation and deployment settings, especially when the operation will alter IIS bindings.

For Chocolatey users, the documented installation command is:

choco install certifytheweb

After the package installation completes, continue with the `New Certificate` workflow. The README does not document command-line options for requesting, installing, or binding the first production certificate, so the documented UI sequence is the appropriate starting point.

Building Certify The Web's Service and UI

Source builds are for contributors working across several repositories rather than the normal installation path. The README calls for a shared directory such as `C:\git\certify_dev`. The main repository and `certify-plugins` belong there. A `libs` subdirectory is also required for `anvil` and the trimmed `bc-csharp` branch. The dependency clone command shown in the README is:

git clone --branch 2.2-trimmed https://github.com/webprofusion/bc-csharp

Once the repositories and dependencies are present, build the service and UI solutions separately:

dotnet build Certify.Core.Service.sln
dotnet build Certify.UI.sln

The service solution contains the backend needed by the application, while the UI solution builds the graphical client. The README states that the UI needs the service running for normal operation. Plugin development has an additional deployment requirement: the plugin and its dependencies must be copied to the debug `\plugins\` location for the service to load them. This creates setup work beyond building the two main solutions. The repository has no GitHub releases, so the GitHub release page is not a documented source for packaged binaries.

Certify The Web's Licensing and Maintenance Boundaries

The main boundary is operating-system scope. The desktop application is described as a Windows ACME client, requires 64-bit Windows, and depends on PowerShell 5.1 or higher for documented features. The Management Hub is presented as cross-platform and self-hosted, but the README does not state that it replaces every part of the Windows application. An organization that needs the full Windows client on Linux or macOS would find no such support in the published requirements.

The README says the application is free to download and evaluate, with no feature restrictions and no time limit. It also says license keys are available for commercial organizations, users who want to support development, or users who require support. GitHub classifies the repository license as custom, and the project identifies `LICENSE` and `eula.txt` as relevant files. Commercial operators must inspect those terms directly to determine permitted use and feature access. This article does not interpret them as legal advice.

The repository is not archived. Its last push was on 2026-10-15. That date records development activity, but it does not establish compatibility with a particular ACME provider or custom deployment pipeline. Maintenance effort can involve updating Windows, PowerShell, DNS APIs, certificate authority behavior, deployment scripts, and custom plugin dependencies. The README links to a separate changelog, but the repository contains no GitHub releases from which an upgrade path can be established.

Certify The Web Compared with One-Time ACME Issuance

A real alternative is to issue a certificate through a separate ACME workflow and manage installation and renewal outside Certify The Web. The difference is operational. Certify The Web keeps certificate requests, IIS binding changes, renewal scheduling, validation configuration, and deployment tasks in one administrative application. A one-time workflow leaves later installation, renewal, and deployment activities to an administrator or another automation system.

That trade-off does not always favor a GUI-based application. Certify The Web adds dependencies on supported Windows versions, PowerShell, its background service, and its stored configuration. An organization with an established certificate pipeline may prefer to keep issuance, deployment, secrets, and monitoring inside that pipeline. The Windows client is more relevant when an administrator wants IIS hostname detection, a preview of binding changes, multiple validation options, and scheduled renewal. It is a weaker fit when the required workflow depends on behavior not documented in the README or when cross-platform operation is required without the separate Management Hub.

Editorial conclusion

Adopt Certify The Web when a Windows administrator needs repeatable ACME issuance and renewal for IIS or another certificate-dependent service. Do not treat it as a native cross-platform certificate agent, because the main application requires 64-bit Windows and PowerShell 5.1 or higher. Verify the certificate authority, validation method, deployment tasks, custom license terms, and background service configuration first; those choices determine whether its stored settings and scheduled actions match the intended infrastructure.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. webprofusion/certify on GitHub