-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stale OCSP response and "unable to write OCSP staple file" error #6524
Comments
Thanks for opening an issue! We'll look into this. It's not immediately clear to me what is going on, so I'll need your help to understand it better. Ideally, we need to be able to reproduce the bug in the most minimal way possible using the latest version of Caddy. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either. I've attached a template below that will help make this easier and faster! This will require some effort on your part -- please understand that we will be dedicating time to fix the bug you are reporting if you can just help us understand it and reproduce it easily. This template will ask for some information you've already provided; that's OK, just fill it out the best you can. 👍 I've also included some helpful tips below the template. Feel free to let me know if you have any questions! Thank you again for your report, we look forward to resolving it! Template
Instructions -- please heed otherwise we cannot help you (help us help you!)
Example of a tutorial: Create a config file: |
I have a theory. The bug is here, in this very line: https://github.com/caddyserver/certmagic/blob/3bad5b6bb595b09c14bd86ff0b365d302faaf5e2/maintain.go#L364 When When the server is started, the error is logged, but otherwise ignored: https://github.com/caddyserver/certmagic/blob/3bad5b6bb595b09c14bd86ff0b365d302faaf5e2/certificates.go#L331-L334. That explains why Caddy works fine after restarting, but breaks down much later. |
I think the fix is to set |
Please fill out the template as asked. How are you running Caddy, etc? It matters. We can save time that way. |
1. Environment1a. Operating system and version
1b. Caddy version (run
|
Why are you using |
I know. I just don't want to create a user upfront. (in any case, that's likely not a problem - lack of writable home directory is) |
I'm inclined to close this. It's not really a Caddy issue, moreso invalid system configuration. |
Perhaps non-writeable data dir should be a hard error on start? We get confusing issues otherwise. Especially like "this appears to work, but will fail after a week". |
We already do a check on the storage system: |
Aha, I see it's called by |
Oh... that's a good point. And an unusual use case. I think in order to properly fix this we should implement the TODO:
Because OCSP ops are a lot more common than cert renewals. Basically, we should cache/remember the storage checks for... the lifetime of the process, I guess? Or at least a day or something like that. Then this problem would be solved. |
I'm running Caddy with TLS by reusing certificate obtained externally with acmetool:
After a while, Firefox stops opening the site, citing stale OCSP response. Restarting Caddy fixes the problem. Reloading doesn't help.
I noticed the following error in the log file, which might be related to the problem:
The text was updated successfully, but these errors were encountered: