Lighttpd

Or would it make more sense to have similar reload mechanism as with the OCSP Stapling file - that is, have `mod_openssl_handle_trigger` check if the CRL file requires refresh or not?

I am the lighttpd developer who wrote the current TLS implementations in lighttpd (mod_openssl, mod_gnutls, mod_mbedtls, mod_nss, mod_wolfssl)

In #3193, I used the words "citation/data required (explain)".
I am not interested in your groundless thought experiments. To be blunt: beyond this response, I will not continue to respond to your groundless postulates.

As an option for this, doing a graceful restart in background was suggested. This seems to be an experimental feature.

SIGUSR1 to lighttpd is not experimental. Maybe you read the word "experimental" with server.feature-flags "server.graceful-restart-bg". I have not removed the word "experimental" that was originally posted with that extended feature only because there are constraints upon some lighttpd configuration which would preclude use of "server.graceful-restart-bg", e.g FastCGI backends started with "bin-path". (Solution: use PHP-FPM instead.)

But also requires additional glue to have someone send the restart signal on CRL update.

So? Your argument is weak. If you are updating and potentially distributing a CRL file, then you should be able to handle this. Note: I agree that "it would be convenient" to have automatic detection. That is not the point of debate. I am pointing out that your argument for anything beyond convenience is very weak.

Given that the CRL files can change often (even if content does not change, the file is updated due to the expires timestamp updated), and that one can have a CRL per virtual host. If I have lot of virtual hosts, it might mean reload very often (practically every few minutes).

It seems unlikely to me that you have tested the performance of lighttpd graceful restarts in the limited time between my post in #3193 and your post here. Please do not post any further until you do, as you everything you have said thus far remains unsubstantiated.

I am considering writing a patch to use inotify to monitor the CRL file, and reload them on change. Would this approach be acceptable for inclusion?

I would suggest that you write a shell script to do that, test that it works, and call it a day.

That said, I make an effort to provide a code review and technical feedback on any submission for which someone has made an effort. Before making such an effort, please try the practical route of a shell script and graceful restart of lighttpd. If your backends are independent of lighttpd (e.g. lighttpd.conf is not configured to start backends with "bin-path"), then try with server.feature-flags "server.graceful-restart-bg" enabled.

A patch would be more likely to be accepted if supported across all lighttpd TLS modules supporting CRLs, but an initial patch may be submitted for review during prototyping. If you do go this route, please post in the lighttpd Development forum. Note: any patch must meet other requirements, including being functional across all platforms on which lighttpd runs (which is many), or at least the additional code must not interfere with or cause regressions on other platforms. Note: inotify is Linux-specific.

Or would it make more sense to have similar reload mechanism as with the OCSP Stapling file - that is, have `mod_openssl_handle_trigger` check if the CRL file requires refresh or not?

That approach might be more portable to other platforms, but (for you) is not as instant as file monitoring. Then again, if you are using CRL files, instant update is not a thing. If you require up-to-date CRLs to the second, then you should add a reverse proxy in front of lighttpd. The reverse proxy (not lighttpd) should be able to be configured to perform TLS termination and to check your CRL server for validity for each and every certificate -- every connection hits the CRL server; no distributed CRL file.

There are tradeoffs for caching and performance. Your obsession with instant updates to a CRL file suggests to me that you are not analyzing more practical considerations of the big picture. Again, you have not shared any actual data or more detailed scenarios.

I would suggest that you write a shell script to do that, test that it works, and call it a day.

gstrauss wrote in RE: Feature request: CRL file should be reloaded on change:

As an option for this, doing a graceful restart in background was suggested. This seems to be an experimental feature.

SIGUSR1 to lighttpd is not experimental. Maybe you read the word "experimental" with server.feature-flags "server.graceful-restart-bg". I have not removed the word "experimental" that was originally posted with that extended feature only because there are constraints upon some lighttpd configuration which would preclude use of "server.graceful-restart-bg", e.g FastCGI backends started with "bin-path". (Solution: use PHP-FPM instead.)

Yes, the wiki comment about graceful-restart-bg being experimental is what I referred to.

But also requires additional glue to have someone send the restart signal on CRL update.

So? Your argument is weak. If you are updating and potentially distributing a CRL file, then you should be able to handle this. Note: I agree that "it would be convenient" to have automatic detection. That is not the point of debate. I am pointing out that your argument for anything beyond convenience is very weak.

For me this is already a big argument. But seems our priorities are different.

Given that the CRL files can change often (even if content does not change, the file is updated due to the expires timestamp updated), and that one can have a CRL per virtual host. If I have lot of virtual hosts, it might mean reload very often (practically every few minutes).

It seems unlikely to me that you have tested the performance of lighttpd graceful restarts in the limited time between my post in #3193 and your post here. Please do not post any further until you do, as you everything you have said thus far remains unsubstantiated.

Graceful restart performance is not the problem. The problem is that it may terminate active connections.

While the servers do have quiet time. There will busy times, where there will be continuous long transfers (part due to data size, part due to some clients having slow network). Tearing down those connections will break things. On the other hand, not being able to reload CRL, or stalling new connections for too long will prevent new connections and break things also.

For me, Graceful Reload (when not using the graceful-restart-bg) by user action is acceptable, because we have control when the potential connection disruptions / tiny down time window comes (e.g. when we actually change the config files and know it's good time to reload), but doing it via automated script is not.

I am considering writing a patch to use inotify to monitor the CRL file, and reload them on change. Would this approach be acceptable for inclusion?

I would suggest that you write a shell script to do that, test that it works, and call it a day.

In fact. We did this originally long ago. When "server.graceful-restart-bg" was not yet available. It killed the system due to aborting connections. That's when we implemented an ugly local patch to do the CRL reload, but now that we are upgrading things I'm looking into whether I invest time into something upstreamable or not.

The fact that server.graceful-restart-bg is not as experimental as the wiki implied, is enough for me to audit the code and retest this approach.

That approach might be more portable to other platforms, but (for you) is not as instant as file monitoring. Then again, if you are using CRL files, instant update is not a thing. If you require up-to-date CRLs to the second, then you should add a reverse proxy in front of lighttpd. The reverse proxy (not lighttpd) should be able to be configured to perform TLS termination and to check your CRL server for validity for each and every certificate -- every connection hits the CRL server; no distributed CRL file.

I will then be better of with something else than lighttpd. The main function of lighttpd is to do the TLS termination and serve static files.

There are tradeoffs for caching and performance. Your obsession with instant updates to a CRL file suggests to me that you are not analyzing more practical considerations of the big picture. Again, you have not shared any actual data or more detailed scenarios.

It does not need to be instant. But it needs to happen sufficiently fast. If almost instant is possible without too much effort, it's a bonus.

I am having my developer+sysadmin hat on to figure out how to make this maintainable long-term yet keeping balance on time invested and how much we get return on the time invested:
1) keep the local ugly patch
2) work with upstream to improve lighttpd to support this scenario
3) audit the server.graceful-restart-bg to consider potential implications on my setup, work to make the system level glue, test that things don't break. adjust logging monitoring to understand all new graceful restart events.

Unfortunately I cannot share too much specific details on this. I somehow was hoping slightly more welcoming spirit for a developer willing to submit improvements. The posting come also with offer to implement thing. Even if it's considered a convenience from your end.

The responses so far indicate that you are not interested on this too much. So option 2 is probably not worth the effort. Given that I need to run the system in places I have sysadmin access, and locations where I do not have, I'm slightly concerned on doing option 3 also. So I'll probably end up keeping the ugly patch even if it means rebasing it occasionally.