4 ms·

That's okay, next step is to fold both nginx and the acme client into systemd.

throw_a_grenade 1y ago
Unironicaly, I think having systemd-something util that would provide TLS certs for .services upon encountering specific config knob in [Service] section would be much better that having multitude uncoordinated ACME clients that will quickly burn through allowed rate limits. Even just as a courtesy to LE/ISRG's computational resources.
- Spivak 1y ago
  A systemd-certd would actually kinda slap. One cert store to rule them all for clients, a way to define certs and specify where they're supposed to be placed with automatic reload using the systemd dependency solver, a way to mount certs into services privately, a unified interface for interacting with the cert store.
  - nottorp 1y ago
    So ... not only would your system take ages to boot without the internets(tm) because that's how systemd works, it will be extended in the same spirit to not boot at all if letsencrypt is down. Sounds enterprise. Also, you people forgot that my proposal is to also fold the http server in, and ideally all the scripting languages and all of npm just in case.
    - throw_a_grenade 1y ago
      ExecStart=/usr/bin/python3 -m http.server WorkingDirectory=/srv/www ?
    - Spivak 1y ago
      Well I mean if you configured your system in a manner that requires one of the wait-online services that's kinda on you. It's not required for anything by default. It would be the same for certd. If you configure your system to hold up booting waiting for a cert then that's your choice but there's plenty of ways to have it not.
- jcgl 1y ago
  It wouldn't specifically have to be a systemd project or anything; you could make a systemd generator[0] so that you could list out certs as units in the Requires= of a unit. That'd be really neat, actually. [0] https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html https://www.freedesktop.org/software/systemd/man/latest/syst...
  - throw_a_grenade 1y ago
    I found this: https://github.com/woju/systemd-dehydrated/ https://github.com/woju/systemd-dehydrated/ It essentially creates per-domain units. However, those are timers, not services, because the underlying tool doesn't have long-running daemon, it's designed to run off cron. So I can't depend on them directly, and I also need to add multitude of dropins that will restart or reload services that use certificates (https://github.com/woju/systemd-dehydrated/blob/master/contrib/dehydrated%40.service.d/reload-nginx.conf https://github.com/woju/systemd-dehydrated/blob/master/contr...). Coudn't figure out any way that would automate this better.
    - jcgl 1y ago
      Well, every timer needs a service to activate. And at a cursory glance, this project has oneshot services, which is what I would expect for something like this. So your units (e.g. a webserver) would take After= and Wants=/Requires= on the given oneshot services. This project looks neat! I might give it a try. I had never heard of dehydrated, but I don't particularly love certbot, and would certainly be willing to try.
- 0x69420 1y ago
  multiple services depending on different outputs of a single acme client can be expressed, right now, in 2025, within systemd unit definitions, without deeply integrating a systemd-certd-or-whatever-as-such. which is basically ideal, no? for all the buy-in that the systemd stapling-svchost.exe-onto-cgroups approach asks of us, at the very least we have sufficiently expressive system to do that sort of thing. where something on the machine has a notion of what wants what from what, and you can issue a command to see whether that dependency is satisfied. like. we are there. good. nice. hopefully ops guys are content to let sleeping dogs lie, right? ...right?
devttyeu 1y ago
Careful posting systemd satire here, there is a high likelihood that your comment becomes the reason this feature gets built and PRed by someone bored enough to also read HN comment section.
- devttyeu 1y ago
  [Unit] Description=Whatever [Service] ExecStart=/usr/local/bin/cantDoHttpSvc -bind 0.0.0.0:1234 [HTTP] Domain=https://whatever.net Endpoint=127.1:1234 Yeah this could happen one day
  - 9dev 1y ago
    You know, Tailscale serve basically does this right now, but if I could skip this step and let systemd expose a local socket via HTTPS, automatically attempting to request a certificate for the hostname, with optional configuration in the socket unit file… I would kinda like that actually
    - robertlagrant 1y ago
      Yeah that sounds quite good now you say it.
  - akagusu 1y ago
    I'm sure this will become a dependency of GNOME
  - pta2002 1y ago
    You can basically implement this right now already by using a systemd generator. It’s not even a particularly bad idea, kinda want to try doing it to hook it up to nginx or something, would make adding a reverse proxy route as simple as adding a unit file, and you could depend on it from other units.
arianvanp 1y ago
Okay but hear me out If we teach systemd socket activation to do TLS handshakes we can completely offload TLS encryption to the kernel (and network devices) and you get all of this for free. It's actually not a crazy idea in the world of kTLS to centralize TLS handshaking into systems
- johannes1234321 1y ago
  Oh, I remember my Solaris fanboys praising Kernel-Level TLS as it reduced context switching by a lot. I believe they even had a patched openssl making this transparent to openssl based applications. Linux seems to offer such facilities, too. I never use it to my knowledge, though (might be that some app used it in background?) https://lwn.net/Articles/892216/ https://lwn.net/Articles/892216/
  - reactordev 1y ago
    Why stop there? Why not sign and verify off the mother of all root CA’s, your TPM 2.0 Module EEPROM? (fun to walk down through the trees and the silicon desert of despair, to the land of the ROM, where things can never change)

Unironicaly, I think having systemd-something util that would provide TLS certs for .services upon encountering specific config knob in [Service] section would be much better that having multitude uncoordinated ACME clients that will quickly burn through allowed rate limits. Even just as a courtesy to LE/ISRG's computational resources.

Spivak 1y ago
A systemd-certd would actually kinda slap. One cert store to rule them all for clients, a way to define certs and specify where they're supposed to be placed with automatic reload using the systemd dependency solver, a way to mount certs into services privately, a unified interface for interacting with the cert store.
- nottorp 1y ago
  So ... not only would your system take ages to boot without the internets(tm) because that's how systemd works, it will be extended in the same spirit to not boot at all if letsencrypt is down. Sounds enterprise. Also, you people forgot that my proposal is to also fold the http server in, and ideally all the scripting languages and all of npm just in case.
  - throw_a_grenade 1y ago
    ExecStart=/usr/bin/python3 -m http.server WorkingDirectory=/srv/www ?
  - Spivak 1y ago
    Well I mean if you configured your system in a manner that requires one of the wait-online services that's kinda on you. It's not required for anything by default. It would be the same for certd. If you configure your system to hold up booting waiting for a cert then that's your choice but there's plenty of ways to have it not.
jcgl 1y ago
It wouldn't specifically have to be a systemd project or anything; you could make a systemd generator[0] so that you could list out certs as units in the Requires= of a unit. That'd be really neat, actually. [0] https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html https://www.freedesktop.org/software/systemd/man/latest/syst...
- throw_a_grenade 1y ago
  I found this: https://github.com/woju/systemd-dehydrated/ https://github.com/woju/systemd-dehydrated/ It essentially creates per-domain units. However, those are timers, not services, because the underlying tool doesn't have long-running daemon, it's designed to run off cron. So I can't depend on them directly, and I also need to add multitude of dropins that will restart or reload services that use certificates (https://github.com/woju/systemd-dehydrated/blob/master/contrib/dehydrated%40.service.d/reload-nginx.conf https://github.com/woju/systemd-dehydrated/blob/master/contr...). Coudn't figure out any way that would automate this better.
  - jcgl 1y ago
    Well, every timer needs a service to activate. And at a cursory glance, this project has oneshot services, which is what I would expect for something like this. So your units (e.g. a webserver) would take After= and Wants=/Requires= on the given oneshot services. This project looks neat! I might give it a try. I had never heard of dehydrated, but I don't particularly love certbot, and would certainly be willing to try.
0x69420 1y ago
multiple services depending on different outputs of a single acme client can be expressed, right now, in 2025, within systemd unit definitions, without deeply integrating a systemd-certd-or-whatever-as-such. which is basically ideal, no? for all the buy-in that the systemd stapling-svchost.exe-onto-cgroups approach asks of us, at the very least we have sufficiently expressive system to do that sort of thing. where something on the machine has a notion of what wants what from what, and you can issue a command to see whether that dependency is satisfied. like. we are there. good. nice. hopefully ops guys are content to let sleeping dogs lie, right? ...right?

devttyeu 1y ago

Careful posting systemd satire here, there is a high likelihood that your comment becomes the reason this feature gets built and PRed by someone bored enough to also read HN comment section.

devttyeu 1y ago
[Unit] Description=Whatever [Service] ExecStart=/usr/local/bin/cantDoHttpSvc -bind 0.0.0.0:1234 [HTTP] Domain=https://whatever.net Endpoint=127.1:1234 Yeah this could happen one day
- 9dev 1y ago
  You know, Tailscale serve basically does this right now, but if I could skip this step and let systemd expose a local socket via HTTPS, automatically attempting to request a certificate for the hostname, with optional configuration in the socket unit file… I would kinda like that actually
  - robertlagrant 1y ago
    Yeah that sounds quite good now you say it.
- akagusu 1y ago
  I'm sure this will become a dependency of GNOME
- pta2002 1y ago
  You can basically implement this right now already by using a systemd generator. It’s not even a particularly bad idea, kinda want to try doing it to hook it up to nginx or something, would make adding a reverse proxy route as simple as adding a unit file, and you could depend on it from other units.

arianvanp 1y ago

Okay but hear me out If we teach systemd socket activation to do TLS handshakes we can completely offload TLS encryption to the kernel (and network devices) and you get all of this for free. It's actually not a crazy idea in the world of kTLS to centralize TLS handshaking into systems

johannes1234321 1y ago
Oh, I remember my Solaris fanboys praising Kernel-Level TLS as it reduced context switching by a lot. I believe they even had a patched openssl making this transparent to openssl based applications. Linux seems to offer such facilities, too. I never use it to my knowledge, though (might be that some app used it in background?) https://lwn.net/Articles/892216/ https://lwn.net/Articles/892216/
- reactordev 1y ago
  Why stop there? Why not sign and verify off the mother of all root CA’s, your TPM 2.0 Module EEPROM? (fun to walk down through the trees and the silicon desert of despair, to the land of the ROM, where things can never change)