Support downloading OCSP responses #219

New Issue

adam · 2025-12-29T01:19:09+01:00

adam commented

2025-12-29 01:19:09 +01:00

Originally created by @nogweii on GitHub (May 1, 2017).

This is to work around an nginx bug, but perhaps it'd be useful for others, too.

It's be nice to be able to tell dehydrated to also download the OCSP response and keep it up-to-date as part of --cron. That way I can configure nginx (with ssl_stapling_file) to read the response at start. Right now, at least with nginx 1.12.0 on CentOS 7, when nginx starts it does not immediately request the OCSP and so doesn't staple it to the response. With OCSP_MUST_STAPLE enabled, Firefox will complain when you first access the server, and for a few more seconds beyond that too. Saving the response to disk should in theory prevent this problem. Perhaps //etc/dehydrated/certs/domain.name/ocsp.der?

Originally created by @nogweii on GitHub (May 1, 2017). This is to work around an nginx bug, but perhaps it'd be useful for others, too. It's be nice to be able to tell dehydrated to also download the OCSP response and keep it up-to-date as part of `--cron`. That way I can configure nginx (with [`ssl_stapling_file`](https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling_file)) to read the response at start. Right now, at least with nginx 1.12.0 on CentOS 7, when nginx starts it does not immediately request the OCSP and so doesn't staple it to the response. With OCSP_MUST_STAPLE enabled, Firefox will complain when you first access the server, and for a few more seconds beyond that too. Saving the response to disk should in theory prevent this problem. Perhaps `//etc/dehydrated/certs/domain.name/ocsp.der`?

adam closed this issue

2025-12-29 01:19:09 +01:00

adam commented

2025-12-29 01:19:10 +01:00

@txr13 commented on GitHub (May 1, 2017):

I believe that Let's Encrypt only signs the OCSP responses for a few days... Depending on how often a user runs their cron job, the response may expire.

I'd be inclined to write something outside of dehydrated to handle that, to avoid any instances of OCSP responses expiring on folks in between cron jobs.

@txr13 commented on GitHub (May 1, 2017): I believe that Let's Encrypt only signs the OCSP responses for a few days... Depending on how often a user runs their cron job, the response may expire. I'd be inclined to write something outside of dehydrated to handle that, to avoid any instances of OCSP responses expiring on folks in between cron jobs.

adam commented

2025-12-29 01:19:10 +01:00

@nogweii commented on GitHub (May 1, 2017):

For Let's Encrypt, the OCSP responses are valid for 1 week. So users would need to run the cron job at least once every 7 days, probably a little bit more often than that to allow them time to react to failures. Reading up on nginx's behaviour, it seems like if the ocsp response isn't valid any more, it will go and query OCSP on it's own like normal anyways. So if the cron job is missed, it doesn't block the server.

On top of all of that, this is a niche situation. How many people have turned on OCSP Must Staple? And how many of them are using Nginx? I figure the numbers are small enough that it would not be enabled by default, and would be another configuration option. If it's enabled, manage the OCSP response.

Some references online:

@nogweii commented on GitHub (May 1, 2017): For Let's Encrypt, the OCSP responses are valid for 1 week. So users would need to run the cron job at least once every 7 days, probably a little bit more often than that to allow them time to react to failures. Reading up on nginx's behaviour, it seems like if the ocsp response isn't valid any more, it will go and query OCSP on it's own like normal anyways. So if the cron job is missed, it doesn't block the server. On top of all of that, this is a niche situation. How many people have turned on OCSP Must Staple? And how many of them are using Nginx? I figure the numbers are small enough that it would *not* be enabled by default, and would be another configuration option. If it's enabled, manage the OCSP response. Some references online: - https://unmitigatedrisk.com/?p=241 - https://blog.crashed.org/nginx-stapling-busted/ - https://gist.github.com/sleevi/5efe9ef98961ecfb4da8

adam commented

2025-12-29 01:19:11 +01:00

@lukas2511 commented on GitHub (Jul 11, 2017):

I tried to implement this in ee75c5dca7, not sure how well this works, feel free to play around with it. Set OCSP_FETCH="yes" in config to enable, it should write ocsp-$timestamp.der files and link the newest version to ocsp.der.

@lukas2511 commented on GitHub (Jul 11, 2017): I tried to implement this in ee75c5dca7ea6a9f2500137683077a89fb444717, not sure how well this works, feel free to play around with it. Set `OCSP_FETCH="yes"` in config to enable, it should write `ocsp-$timestamp.der` files and link the newest version to `ocsp.der`.

adam commented

2025-12-29 01:19:11 +01:00

@it-can commented on GitHub (Jul 12, 2017):

@lukas2511

I enabled OCSP_FETCH="yes" this option in the config file and regenerated, but no ocsp.der file is showing up...?

Seems you need to add a HOST parameter to the request

https://community.letsencrypt.org/t/ocsp-responses-inconsistent-between-different-ocsp-servers/21927/5

Added a PR #412

@it-can commented on GitHub (Jul 12, 2017): @lukas2511 I enabled ```OCSP_FETCH="yes"``` this option in the config file and regenerated, but no ocsp.der file is showing up...? Seems you need to add a HOST parameter to the request https://community.letsencrypt.org/t/ocsp-responses-inconsistent-between-different-ocsp-servers/21927/5 Added a PR #412

adam commented

2025-12-29 01:19:11 +01:00

@lukas2511 commented on GitHub (Dec 14, 2017):

Closing this as OCSP stapling updates seem to be working fine now.

@lukas2511 commented on GitHub (Dec 14, 2017): Closing this as OCSP stapling updates seem to be working fine now.

adam referenced this issue

2025-12-29 01:29:00 +01:00

[PR #219] [CLOSED] make dependency check work for non-gnu diff #758

Sign in to join this conversation.