 |
 |
@bbockelm Well, yes, I could do that. However, I would opt for a slightly (though a bit more expensive) approach. I was planning on using the framework's Clone() method to create a new context identical to the global one but with refreshed CRLs and CA certs. I could then extract the X509_store from it use it to set the X509 store in "in use" context and then discard the new context. This does two things a) keeps contexts and connections separated, and b) always uses the same code path to build the new X509_store. So, this keeps it maintainable and dealing with OpenSSL anything that makes it more maintainable is a huge plus. I don't know if you looked at the R5 TLS framework but it completely abstracts out the notion that you are using OpenSSL. We decided to go that route because of ever changing OpenSSL API's and we didn't want to splatter that stuff all over the code. While some of OpenSSL will need to leak into the R4 back port it will be very clean in R5.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1