On 2009-06-03 19:16 PDT, Wan-Teh Chang wrote:
That means that you always put the cert and its chain into the client's
cache, and cache the negotiated SSL session, where it will be restarted
by future attempts to connect to the same host/port. This seems
inadvisable.
Yes, that's an issue.
On Thu, Jun 4, 2009 at 1:15 PM, Nelson B Bolyard nel...@bolyard.me wrote:
The SSL client session cache only caches the server cert, not the
server cert chain. So, unless you arrange to save the server cert chain,
the chain will always be incomplete for a session resumption.
At it happens,
On 2009-06-04 16:55 PDT, Wan-Teh Chang wrote:
On Thu, Jun 4, 2009 at 1:15 PM, Nelson B Bolyard nel...@bolyard.me
wrote:
There is a similar function for suspending and restarting the SSL
handshake processing at another point where there may be long delays,
namely, when the user needs to
On 2009-06-02 11:17 PDT, Wan-Teh Chang wrote:
This message is long. Please bear with me.
A mere 73 lines. :)
On 2008-12-18, Dan Kegel reported in this thread that we can't call
SSL_PeerCertificate after the bad-certificate callback function returns
because the peer certificate has been
Nelson,
Thanks a lot for your answer.
On Wed, Jun 3, 2009 at 4:25 PM, Nelson B Bolyard nel...@bolyard.me wrote:
Note: The way Chromium uses NSS to verify SSL server
certificates has changed since Dan Kegel posted that message.
Since certificate verification can block indefinitely while
This message is long. Please bear with me.
On 2008-12-18, Dan Kegel reported in this thread that
we can't call SSL_PeerCertificate after the
bad-certificate callback function returns because the
peer certificate has been destroyed:
6 matches
Mail list logo
