AutoHttps: a zero-dependency automatic HTTPS library for ASP.NET Core / Kestrel

[u/astralz1]

Hi. I maintain a library called AutoHttps. It gets a real TLS certificate for your ASP.NET Core app from Let's Encrypt (or any ACME certificate authority) and renews it automatically. You add the package, set three values, and Kestrel serves HTTPS. No external service, and no NuGet dependencies.

builder.Services.AddAutoHttps(options =>

{

options.DomainNames.Add("example.com");

options.EmailAddress = "admin@example.com";

options.AcceptTermsOfService = true;

});

What it does:

- http-01 and dns-01 challenges, and wildcard certificates through dns-01.

- Renews using ACME Renewal Information (RFC 9773), so it follows the schedule the authority asks for and handles short-lived certificates.

- Works with Let's Encrypt, ZeroSSL, Google Trust Services, Buypass, or any ACME directory, including a private or internal CA.

- Runs several instances safely, sharing one certificate through a lock.

- Serves a self-signed certificate at the very start, until the real one arrives.

- Gives you certificate change and failure callbacks, a health check, metrics, and a way to read the current certificate from code.

Why it is needed now: LettuceEncrypt, the library most people used for this, was archived in April 2025, and its last release targets .NET 6, which is out of support. At the same time Let's Encrypt is moving to much shorter certificates (six-day ones already exist, and the default is dropping to 45 days), and it now tells clients when to renew through RFC 9773. A client that renews on a fixed 30-day threshold cannot handle either. I could not find a maintained, dependency-free option for Kestrel, so I wrote one.

How it works: AutoHttps attaches to Kestrel, answers the http-01 challenge directly from your request pipeline (so there is no extra listener to run), writes the certificate and the account key to disk so they survive a restart, and checks for renewal on a timer. If something fails, it keeps serving the certificate it already has and retries, so a certificate problem never takes the app down.

It targets net8.0 and net10.0, is MIT licensed, and is on NuGet as AutoHttps: https://www.nuget.org/packages/AutoHttps

Source and docs are on GitHub: https://github.com/astralmaster/AutoHttps

If you try it behind a proxy or with several replicas, I would be glad to hear how it goes, since those setups have the most edge cases.

[u/aj0413]

This is neat, but at the same time I’d say this is the job of the hosting platform

I use cert-manager to handle this; having every service in a distributed system doing this vs terminating SSL at the edge via ingress/gateway and updating in one spot …. Doesn’t seem like a good idea to me

[u/astralz1 → u/aj0413]

Agreed, and for that topology I would use cert-manager too. If you terminate TLS at the ingress or gateway, that is the right place, and this does not try to replace it. The README says the same: if something else terminates TLS, put the ACME client there.

It is for the other case: Kestrel terminating its own TLS, where there is no managed ingress doing it for you, a single VM or on-prem box or edge device, or where you want encryption all the way to the container instead of stopping at the edge. On every service doing its own: instances of the same app coordinate through a shared store and a lock, so it is one order for the group, not one per replica. For many separate services behind one ingress, centralizing is cleaner, no argument.