With public TLS certificate lifetimes shrinking to just 47 days by 2029, administrators must find ways to automate certificate enrollment and renewal for workloads that require them. One of the most common is Microsoft Internet Information Services (IIS). I’ve been using CertKit.io to handle this process for workloads like Always On VPN and DirectAccess, so it made sense to migrate my public-facing IIS servers to this solution as well. The migration went smoothly, but I encountered an unexpected issue when deploying a new IIS server using CertKit.
CertKit Agent
CertKit Agents make loading certificates on the server a breeze. The CertKit agent automatically detects installed software (e.g., Terminal Services, RRAS, DirectAccess, IIS, etc.) and handles the server-side process of assigning the TLS certificate to the application. For RRAS and DirectAccess, it works perfectly. For an IIS server with an HTTPS binding and TLS certificate already configured, it works without issue as well. However, I ran into a snag when I tried to deploy a certificate to a brand-new IIS server.
New Server
After installing the CertKit agent on an IIS server, it searches for existing HTTPS web bindings to identify the workload. However, on a freshly installed IIS server, no HTTPS bindings have been configured yet, so the agent doesn’t recognize the IIS workload.
Of course, you could create an HTTPS web binding before installing the agent, but you’ll need a TLS certificate first. This introduces the classic “chicken and egg” scenario. 🤪 Fortunately, there are a few ways to resolve the issue.
Windows Certificate Store
With this method, you configure the CertKit agent to download and install the certificate into the local computer certificate store on the IIS server. Once complete, you can create the HTTPS binding in the IIS Manager console or by using PowerShell. After that, restart the CertKit agent service by running the following PowerShell command.
Restart-Service -Name certkit-agent -PassThruThe IIS workload will now appear in the agent’s Software list. At that point, you can delete the Windows certificate store configuration and replace it with the IIS configuration.
Self-Signed Certificate
Using this method before installing the CertKit agent allows the agent to automatically discover IIS after installation, which can be helpful when deploying IIS servers programmatically. First, create a short-lived certificate (one day in this example) and configure the IIS site binding by running the following PowerShell commands.
$Hostname = 'www.example.net'$Certificate = New-SelfSignedCertificate -DnsName $Hostname -CertStoreLocation 'Cert:\LocalMachine\My' -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm SHA256 -NotAfter (Get-Date).AddDays(1) -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.1')$Params = @{ Name = 'Default Web Site' BindingInformation = '*:443:' Protocol = 'https' CertificateThumbPrint = $Certificate.Thumbprint CertStoreLocation = 'Cert:\LocalMachine\My' }New-IISSiteBinding @ParamsOnce complete, run iisreset.exe to apply the changes. Now, when you install the CertKit agent, it will automatically detect IIS, and you can assign your public TLS certificate accordingly. You can delete the old self-signed certificate later if desired.
Summary
If you’re automating server builds, the self-signed certificate approach is typically the easiest because it enables IIS discovery immediately. For ad-hoc deployments, installing to the Windows certificate store first is usually the quickest option.
Additional Information
CerKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates
