A step in the right direction. Support for http-01 challenges only for now. Figured folks here might care if not already aware.
12 Likes
Lol, came here to post the same thing, I'll have to test this out.
Certify Management Hub recently got an experimental ACME proxy API which let's non-DNS capable ACME clients transparently use pre-configured "managed challenges", so now I'm trying all the ACME clients to see which ones work and which don't.
{edit: nah they don't support EAB, we might add client specific URLs in the future but I'm not a fan of those]
3 Likes
Enters newbie. Scratches his head. Holds his chin pensively. "Hey, is this a good idea?" "What are the use cases for this?"
I suppose it will make the certificate acquisition and deployment easy, but do we want to introduce a certification dependency on the choice of Web server? I expect Windows people don't much care about violating the Unix philosophy of doing one thing well, but that hoary philosophy is at the crux of my question.
For the Linux crowd, we remember the systemd brouhaha. The init process 'systemd' has a ton of functionality that, as I understand it, is justified/motivated/required by the prevalence of multi-core CPUs and the potential they have for parallel processing, which makes timing a fundamental and highly developed capacity of systemd.
The newbie grins and quoth, "Have you recently bought any physical books of woody pulp?"
I ask the luminaries of this interwebs outpost to record their opinions on this speculative matter. Will integration of an ACME client in Web servers obsolete or at least dominate other ACME clients?
Caddy (with integrated ACME) has existed for several years, as have things like mod_md for Apache. So there's been the option to have the web server take control of it's own cert renewal for a while. Where this is different is nginx is arguably the most popular web server, so it's a common default choice. However, if it requires config then it's adoption will be far less than if it auto-configured by default.
The idea of "doing one thing well" is relevant and noble, but in my experience the majority of website operators are not purists nor are then even necessarily experienced. They just do it because they have to, so for them if you can make the process more auto-magical or hold their hand for the difficult parts then they'll only be pleased about it, until it goes wrong, then we'll see them here.
3 Likes
It will definitely not make them obsolete, since there are many other important uses of certificates next to HTTPS, like IMAPS, POP3S, SMTPS, XMPP, and probably a myriad other protocols that are based upon TLS.
I guess they have a chance to dominate though, since even if it's not enabled by default, it should be easier to set up (at least for CAs where you don't need EAB, like Let's Encrypt) than installing and setting up an ACME client. It might take some years though.
2 Likes
Do you really need to ask this question? Because the use case seems blindingly obvious: the application that uses the certificate, gets the certificate. Just like Caddy has always done (or been able to do). Just as Apache with mod_md does. Just as Traefik does. Just to give a few examples.
3 Likes
Yes, it is a very welcome development.
Many. Anyone running nginx that terminates TLS is a candidate
What dependency are you concerned about? This is an optional feature after all.
As webprofusion noted Caddy server has done this for some time. And Apache's mod_md feature as well. I am very happy to see nginx joining them in offering this feature.
Further, major CDNs all do this for the TLS between the user-agent and their edge servers. The TLS between that edge and the origin can be handled various ways. Cloudflare offers an Origin CA cert to make that easier.
CDNs handle the vast majority of traffic on the internet.
Load balancers of various kinds do that as well.
Making HTTPS easier to implement is always welcome.
2 Likes
Obsolete? Never. There will always be edge cases that require a standalone client. Dominate? Sure, but that's a weird and unnecessarily adversarial way to frame it.
The goal of all this is to ensure everyone can easily obtain and use certs to secure their stuff. ISRG/Let's Encrypt and the ACME protocol took the first big step by making certs free of monetary cost. This is only possible because they removed the need for human interaction at the CA level.
But obtaining a cert is only the first step. Standalone clients are great at obtaining certs and some have decent integrations with various web servers and other software to deploy those certs. But that's a constantly moving target for the client dev and there are multitudes of ways those integrations fail. It still forces users into a position where they need a relatively uncommon knowledge set and the time to figure out how to make everything work.
It's a much more streamlined story for the app dev to embrace the ACME protocol natively. Then obtaining and deploying a cert is just a normal configurable option in that app. This was always the plan. As more apps embed native ACME functionality, the most popular ACME client will eventually and inevitably be tied to the most popular (probably web server) software that uses certificates.
It's just the natural evolution of the ecosystem. Who cares about the most popular client being used as long as everyone can secure their stuff easily?
5 Likes
Plus nginx only has 20% of the web server market share (and declining), and it takes years for people to upgrade. It's good that they're adding ACME, but there will always be hundreds of ACME clients.
1 Like
Source?
2 Likes
According to this:
nginx is the most popular web server, accounting for almost 35% of sites.
3 Likes
@ webprofusion, I like your informative, logical answer. That's what I was looking for. In short, market segmentation a lot like operating systems. Interesting.
@felixf, I was thinking something like that. I need a key-certs chain for Postfix email server and separate key and certs files for nginx. I tried a key and chain file with nginx, and it did not work. As I recall, the documentation did not say what position the key goes in. I tried key first and key last. Did not work for me. Only separate key file worked for me.
Not trying to start a web server flame war it was just the first thing that came up for my googling.
3 Likes
Yeah, I thought that's what you were quoting. I don't find their stats credible. They apparently only look at the "server" response header. My guess is they also only probe the home page which can easily mislead in today's complex CDN and related infrastructures.
Using Jul 2025 numbers, they have "Cloudflare web servers" handling 15% of active sites. Now, Cloudflare CDN "edge servers", sure, but not "web servers". Ignoring the origin server behind a CDN, any CDN, skews the data considerably.
Their largest category of "web server" is "Other" at 36%. I assume this is a mix of obscure servers along with ones that don't send a "server" response header at all. If so, they should split that into "Other" and "Unknown". It isn't plausible that 36% of websites are using obscure "other" web servers. It is more plausible that some popular web servers are configured to not send a "server" response header at all and are called "Other" by them. Or, possibly they are other large CDNs which skew the data as noted already for Cloudflare.
Interestingly, since 2020 their "Other" category has gone up from 13% to 36% while nginx dropped from 38% overall to 21%. What is this extremely popular "Other"? 
It is telling that they haven't identified the composition. Given how large this group is removing "Unknown" from the mix would increase the proportions for the rest.
A minor nit but OpenResty is built with the core nginx. It's only 3% though.
Hey, you were the one making an explicit bold claim I found it suprising which is why I asked. No worries. No war.
2 Likes
A lot of cloud based hosting doesn't terminate on a conventional web server anymore and stuff sits behind other generic proxying layers, e.g. Azure Application gateway etc.
Unless discounted from the stats it only takes one large domain parking service to migrate from one to to another to complete change the numbers, 70-80% of registered domains are parked (based on https://www.crazydomains.com/learn/domain-parking-types-and-benefits/).
3 Likes
Agreed. CDNs carry a vast amount of traffic, for example. But that doesn't mean a traditional web server isn't used behind those outer layers. It just isn't as easy to determine what that is.
My main point with "Other" was that if your largest category in a survey is "Other" that you need to design a better survey
Fair point on parking. Which makes surveys that include those sites even less meaningful.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.