4 ms·

> There's no technical reasons I know of why sites like TechCrunch can't use it. Of course there is - a web server that gets a certificate via LE is a single s

> There's no technical reasons I know of why sites like TechCrunch can't use it. Of course there is - a web server that gets a certificate via LE is a single screw. A commercial internet-facing site is a high rise. One does not just replace a screw in a high rise -- it requires ensuring that the right tools are in every toolbelt to manipulate the screws. For Caddy to be useful in a non- oh look ma, i'm on the internet projects, it needs to fit into the tooling system. For example, it should be fetching storing certificates in a database that can be accessed by multiple servers. Rather than doing everything behind the scenes, it should be emitting events indicating its desire to renew a cert and let someone else handle ( maybe a different caddy ) handle the renewals, etc, etc, etc.

mholt 7y ago
Oh I understand that, believe me. That's an operational reason, though, and not as much a technical one. By the way, Caddy CAN store certs in a database accessed by multiple servers. It coordinates cert management when configured as a cluster, automatically. Caddy is the only server that does this (for free).
- notyourday 7y ago
  > That's an operational reason, though, and not as much a technical one. Every single operational reason is a technical reason if it touches operation of the technology. > By the way, Caddy CAN store certs in a database accessed by multiple servers. It coordinates cert management when configured as a cluster, automatically. Caddy is the only server that does this (for free An edge web server should carry no knowledge of a concept of a cluster. It should simply be able to ask something for a cert. Otherwise it is a screw that insists that in order for it be used in high rise, it needs to be used in a specific pattern that the screw designer envisioned. If you want to make Caddy easily adoptable in high rises I suggest the following path: 1. Subscribe to events saying "fetch this cert from here" 2. Emit events saying "Need to renew X" when you need to renew. 3. Create ability to forward renew requests to renew requests processor. 4. Make request processor update the cert store and emit the event that the key pair is available.
  - mholt 7y ago
    > An edge web server should carry no knowledge of a concept of a cluster. Caddy doesn't. That's what's so interesting! > It should simply be able to ask something for a cert. It does. > I suggest the following path: Oh good! That's pretty close to how it actually works already! I'm happy to explain more how Caddy actually works before we start armchairing solutions here. Or, feel free to read the code for yourself: https://github.com/mholt/certmagic/ https://github.com/mholt/certmagic/
  - jrockway 7y ago
    I think the problem that most people have is that they have no way to orchestrate multiple components, so they really want everything built into one binary. Once you can run multiple processes and have service discovery, the need for this stuff goes away. For example, I use cert-manager to get certificates for my Envoy edge proxy. cert-manager runs continuously and updates the TLS certificates in a Kubernetes secret. Kubernetes injects the secret into the Envoy container as files, and then Envoy reads them without any knowledge of where they come from or how they can be renewed. (It could also be configured to get them at runtime with xDS / Universal Data Plane API). This is all very easy and provides infinite interchangeability; there would be no change in cert provisioning necessary if I switched to Nginx or HAProxy. But, most people don't have a setup that supports something like this, so they really need the all-in-one thing or they're just going to say "we don't really need TLS". They get by because nothing in their infrastructure ever changes; certs are new because they require operator intervention every 90 days and that is a new experience. It is unfortunate, but that's where most of the world is at right now.
    - notyourday 7y ago
      Agreed. However if an author of the solution does insist on implementing it in one binary with orchestration step being in the code rather than pulled out into the infrastructure management, the author should not be surprised that no one outside tiny single server operations would consider it to be a contender.
      - mholt 7y ago

mholt 7y ago

Oh I understand that, believe me. That's an operational reason, though, and not as much a technical one. By the way, Caddy CAN store certs in a database accessed by multiple servers. It coordinates cert management when configured as a cluster, automatically. Caddy is the only server that does this (for free).

notyourday 7y ago
> That's an operational reason, though, and not as much a technical one. Every single operational reason is a technical reason if it touches operation of the technology. > By the way, Caddy CAN store certs in a database accessed by multiple servers. It coordinates cert management when configured as a cluster, automatically. Caddy is the only server that does this (for free An edge web server should carry no knowledge of a concept of a cluster. It should simply be able to ask something for a cert. Otherwise it is a screw that insists that in order for it be used in high rise, it needs to be used in a specific pattern that the screw designer envisioned. If you want to make Caddy easily adoptable in high rises I suggest the following path: 1. Subscribe to events saying "fetch this cert from here" 2. Emit events saying "Need to renew X" when you need to renew. 3. Create ability to forward renew requests to renew requests processor. 4. Make request processor update the cert store and emit the event that the key pair is available.
- mholt 7y ago
  > An edge web server should carry no knowledge of a concept of a cluster. Caddy doesn't. That's what's so interesting! > It should simply be able to ask something for a cert. It does. > I suggest the following path: Oh good! That's pretty close to how it actually works already! I'm happy to explain more how Caddy actually works before we start armchairing solutions here. Or, feel free to read the code for yourself: https://github.com/mholt/certmagic/ https://github.com/mholt/certmagic/
- jrockway 7y ago
  I think the problem that most people have is that they have no way to orchestrate multiple components, so they really want everything built into one binary. Once you can run multiple processes and have service discovery, the need for this stuff goes away. For example, I use cert-manager to get certificates for my Envoy edge proxy. cert-manager runs continuously and updates the TLS certificates in a Kubernetes secret. Kubernetes injects the secret into the Envoy container as files, and then Envoy reads them without any knowledge of where they come from or how they can be renewed. (It could also be configured to get them at runtime with xDS / Universal Data Plane API). This is all very easy and provides infinite interchangeability; there would be no change in cert provisioning necessary if I switched to Nginx or HAProxy. But, most people don't have a setup that supports something like this, so they really need the all-in-one thing or they're just going to say "we don't really need TLS". They get by because nothing in their infrastructure ever changes; certs are new because they require operator intervention every 90 days and that is a new experience. It is unfortunate, but that's where most of the world is at right now.
  - notyourday 7y ago
    Agreed. However if an author of the solution does insist on implementing it in one binary with orchestration step being in the code rather than pulled out into the infrastructure management, the author should not be surprised that no one outside tiny single server operations would consider it to be a contender.
    - mholt 7y ago