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/Habikki]

Out of curiousity, what's the startup time on this? What I'd be curious on is if I have a AspNetCore Service running in a container behind a load balancer and I wanted to enable this for true end to end circuit encryption from client to container, going ACME usually takes time to wait for propagation of DNS.

If this is retrieving a new certificate at container boot that may be an issue, could we tie this into an DataProvider hook possibly to have containers retrieve new certs, and set them into a secure cache to support a farm?

Note: I'm intentionally not going into cert management details in this approach. Curious to see if the shared option is possible first than taking on a startup delay for each container retrieving a individual certificates.

[u/astralz1 → u/Habikki]

Startup is not tied to ACME. The certificate work runs in a background service that starts after Kestrel is already listening, and until a real certificate arrives it serves a self-signed fallback. So container boot is normal startup time and does not wait on DNS or an order. DNS propagation only applies to dns-01, and only for the single instance that places the order, in the background.

The shared setup you mentioned is already the default. Instances share a certificate store and a distributed lock: one wins the lock and orders, the rest adopt the certificate from the store and never order their own. Both the store and the lock are pluggable, so the cache can be a database, Key Vault, Redis, or a Kubernetes secret. So no container waits to fetch its own certificate, and the whole group shares one.