There are many SSL_() functions that produce return codes with more
information from SLL_get_error() and/or ERR_get_error(). Those need
to be grouped in an atomic section to ensure thread safety at the
level of Racket threads.
Using the functions on a port triggers renegotiation of the
connection, which s useful for cases such as a web server that
requires a certificate only for certain paths. This functionality
also allows better testing of the SSL library.
Read and write actions on an SSL port can trigger internal write
and read actions (i.e., the opposite direction). On the read side,
write pumping was performed too early before returning a "wait
for new input" event; SSL operations between the pumping and
return could trigger the need for pumping, but it never happened
because the socket was waiting for new input before taking any
new actions.
The problem would shows up specifically when Apache renegotiates
a connection to demand certificates from a client after first
determining the target of the request (i.e., when a certificate
is required ony for specific locations on the server).
Thenks to Sergey Pinaev, Timur Sufiev, and Neil Van Dyke.
This enables an ssl server the option to communicate with both verified and unverified peers with the same listener.
Supporting API calls...
ssl-peer-verified? -> returns #t if an ssl-port's peer has presented a valid and verified certificate
ssl-peer-subject-name -> returns the subject field of the certificate presented by an ssl-port's peer
ssl-peer-issuer-name -> returns the issuer field of the certificate presented by an ssl-port's peer
