I wanted to follow up on this. Flyspray did not let me add a comment since the bug is closed, so I'm posting to the mailing list.

1. I tried using CRLpath (and setting up the symbolic link properly to the hashed value), but that had the same behavior as CRLfile. It only reads the actual CRL once. If I update the file on disk, it never re-reads the file. So I don't see how this is a workaround. Am I missing something?

2. As I mentioned in my initial report, it is a significant disruption for existing stunnel processes to be killed. If it were possible just to kill the main daemon without also killing the child processes (i.e. like sshd), that could be a workaround. But currently, killing the main stunnel process also kills all child stunnel processes.

I guess I don't understand what else one could do in this situation, apart from having the application properly reread the CRL on a regular basis. (OCSP is not yet available). When you say that "that's how openssl works", are you saying that the API does not allow you to reread/reload the CRL file? That seems rather odd. It seems like there should be some kind of way to refresh the OpenSSL data structures that store the CRL.

Any thoughts/suggestions would be appreciated.

Thanks,

-Kartik

Michal.Trojnara@mirt.net wrote:

Notice from stunnel

Michal Trojnara (mtrojnar) has closed the following task. You are receiving this because you are on the notification list.

Task #7: CRLfile is never refreshed The reason for closing is: Not a bug That's how OpenSSL work. There are two workarounds:

1. Use CRLpath instead of CRLfile (I recommend it).
2. Restart stunnel after the CRL file modification.

You can get more information about this task at the following URL: http://stunnel.mirt.net/flyspray/index.php?do=details&id=7