
ACME Support in Apache HTTP Server Project - jaas
https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html
======
cholmon
I'm curious how renewals will be handled. According to
[https://github.com/icing/mod_md/wiki#no-auto-restart-when-
st...](https://github.com/icing/mod_md/wiki#no-auto-restart-when-started-as-
root)

"...you have to manually restart httpd for any certificate changes to take
effect."

It's easy enough to have a daily cronjob that just reloads Apache
unconditionally, but that feels dirty.

~~~
ridruejo
Apache supports graceful restarts, in which new children processes are spawned
and old ones replaced without dropping existing connections

~~~
jldugger
This doesn't affect certain portions of Apache, like the part that handles
TLS.

~~~
ridruejo
Recent versions of Apache (2.4.x) do support it

~~~
jldugger
Ah, guess I should review the documentation more frequently.

------
baby
About the elephant in the room: Let’s Encrypt is becoming too big to fail.
Wasn’t the point of open sourcing the whole protocol so that we could have
multiple CAs like Lets Encrypt?

~~~
diafygi
It seems that running a free CA doesn't really have a business model, so
capitalism isn't going to produce viable competitors.

Additionally, other impact-focused people (non-profits, etc.), who would
otherwise be willing to make a free CA, probably think Let's Encrypt is doing
good enough, so why waste valuable time making the same thing when you could
focus on having an impact elsewhere?

I suspect this is a pretty common end result in public-good tasks that don't
have business models. They naturally grow to be too big to fail. Some
governments try to solve this by just absorbing the task and making it a part
of the government's responsibilities. I doubt this would happen for Let's
Encrypt, so I guess we'll be stuck with a too-big-to-fail non-profit until it
fails, starts to suck too much, gets absorbed by the government, or someone
figures out a business model.

~~~
Touche
I would think (hope) that big ad companies like Google and Facebook would find
that the proliferation of https is good for business and provide a free CA

~~~
diafygi
Both Facebook and Chrome/Google are top-level sponsors of Let's Encrypt. So I
guess you are correct and they have?

------
Ajedi32
This is going to be huge for HTTPS adoption on the web. In the future all web
servers should have this feature.

I wonder which will be next? IIS? Nginx?

~~~
icebraining
Klaus Krapfenbauer, a participant of Mozilla Winter Of Security, already
implemented a PoC module for Nginx: [https://github.com/mozilla/mwos-
letsencrypt-2015](https://github.com/mozilla/mwos-letsencrypt-2015)

Unfortunately, it seems to be very dead.

~~~
apple4ever
That sucks. Besides the dumb low cert expiration length, built in support for
Nginx is why I haven't adopted Let's Encrypt.

~~~
jjeaff
The low cert expiration date is by design. If you don't have a script renewing
it automatically, you aren't doing it right.

------
jpb0104
This is awesome. We're having early success with [https://github.com/GUI/lua-
resty-auto-ssl](https://github.com/GUI/lua-resty-auto-ssl) \+
[https://openresty.org/](https://openresty.org/) to support thousands of
custom domains.

------
throwaway0071
This is why I think projects like caddy/traefik shouldn't get too comfortable
thinking Let's Encrypt / HTTPS support by default alone is going to
differentiate them too much. They're one PR away from having their major
selling point becoming irrelevant in the face of the competition.

[https://news.ycombinator.com/item?id=15433463](https://news.ycombinator.com/item?id=15433463)

~~~
hannob
Caddy is written in a memsafe language.

(I don't use caddy, but I always saw the "HTTPS by default" thing more as a
nice thing to have, but not hugely important given that you can have the same
with external scripts in apache or nginx. But being memsafe is the real
distinguisher and one that certainly isn't reachable with a pull req in apache
or nginx.)

~~~
kuschku
Caddy doesn’t even adhere to the URL RFCs.

The URL RFCs specifically say that a DNS name in a URL can be written
relatively, or absolutely with the root zone.

These are valid URLs: [https://google.com/](https://google.com/) and
[https://google.com./](https://google.com./) As you notice, both work fine.
Same with every major site, and every major webserver.

Now, you’ll notice that [https://caddyserver.com/](https://caddyserver.com/)
works, but [https://caddyserver.com./](https://caddyserver.com./) doesn’t.
Caddy, the server, doesn’t support it, but you have to enter every domain
twice manually. And caddy, the website, doesn’t support it either.

This was closed as a WONTFIX, despite every implementation of a webserver
except for traefik and caddy doing it the same way.

~~~
chrismorgan
> Same with every major site, and every major webserver.

I last tried this a few years back (probably around 2011). I found that a
substantial fraction of major sites did _not_ support it, and a substantial
fraction of those that seemed to support it produced web pages that were at
least partially broken.

~~~
kuschku
I tried it in 2016 again, and under the alexa top million sites, I found
basically all supported it, even if just with a redirect.

Mostly because nowadays every CDN, nginx, Apache2, IIS and HAProxy all support
it by default.

~~~
icebraining
IIS might support it, but Microsoft doesn't (universally):
social.technet.microsoft.com, live.com, bing.com, office.com, skype.com all
fail to properly load or redirect. As does instagram.com and linkedin.com.

------
convefefe
It's good to see that Apache gets native support for this, I sincerely hope
NGINX will follow.

------
lol768
I'm curious, which email does it use to register with? I didn't see one in the
config file.

~~~
jaas
Supplying an email address to Let's Encrypt is optional.

~~~
tialaramex
... but if you don't supply one of course Let's Encrypt won't notify you about
anything.

So if you aren't paying attention you may get blind-sided by any future
change, particularly if your use case is weird e.g. you can only pass http-01
by HTTP 301 redirecting to a machine with a completely different hostname,
works today, could get outlawed as dangerous one day and they'd have the
records to show you're going to be affected, but no way to automatically warn
you.

~~~
mholt
I recommend always monitoring server logs as a last line of defense (or first,
honestly) for these kinds of things.

~~~
Ajedi32
Do Apache's server logs notify you if your cert is about to expire, but hasn't
yet?

~~~
majewsky
Expiration dates on your TLS certs is usually something that you want to
monitor and alert on anyway. I'd actually build the monitoring separately from
the renewal process, just in case that the renewal process doesn't notice that
it fails.

------
muppetman
Gosh I can't believe how embarrassing this post is for the LE team. All that
time, effort and hard work let down by using the "nano" editor in the Youtube
video.

(This is of course, fantastic news and great to see it'll be even easier for
non-technical people to use HTTPS with little effort)

------
thresh
Are there any other CAs that support ACME?

Is ACME an Internet standard yet?

Is that turning into monoculture?

~~~
tialaramex
Other CAs have made interested noises. Big ones have indicated to m.d.s.policy
or CA/B that they are, at least, paying attention to the RFC process and some
are participating in standardisation.

ACME is at Working Group Last Call. Which means the IETF Working Group (people
who thought this was interesting/ important) thinks it's finished but await
feedback from outsiders who might not have realised this was coming or are too
busy to look at in-progress designs. It will be published as a Standards Track
RFC making it an "Internet Standard" in due course.

A monoculture is at least an improvement over the Wild West we had prior to
the Ten Blessed Methods. As recently as last year any CA could decide (on its
own recognizance) that any method it chose was adequate to verify Domain
Control, under a heading "Any Other Method" in the Baseline Requirements. If
your CA was happy with a method so dumb nobody should possibly have used it,
we'd have to find out about that, explain why it's dumb, and then you'd get
told to stop doing it, often taking several weeks to achieve. A list of just
ten explicit methods was written, the Ten Blessed Methods, and now CAs must
use one or more of those. ACME implements three today, and is designed to be
extensible. Some methods involve things like human lawyers writing physical
letters, it is unlikely ACME will embrace that sort of manual process
directly, but methods involving email or the WHOIS system could end up in
there.

------
dtzur
Now if they could only catch that Road Runner!

