Yesterday, I sat down and finally reviewed the patch that Christopher Bowman provided to fix the SSL-related leak and came up with a reproducible way of demonstrating the leak and verifying the fix (see SF Bug #1160850: nsopenssl leaks SSL obj. mem w/Keep-Alive). It turns out the leak was due to AOLserver not calling the socket driver’s DriverClose callback when a HTTP Keep-Alive connection timed out, which is where nsopenssl does its clean-up of the SSL structure that’s allocated for the connection. So, the fix was in aolserver/nsd/driver.c and not in the nsopenssl module itself. That means the fix will be generally available as part of the next release of AOLserver which will be 4.0.11.
Until 4.0.11 is released, however, if you have a server that is using nsopenssl and you’re seeing this memory leak, you can “work around” the problem by disabling HTTP Keep-Alive, which is unfortunately a server-wide config. option instead of a per-socket driver option. You do this by setting the keepalivetimeout parameter to 0 (zero) in the ns/parameters section, like this:
ns_section "ns/parameters" ns_param keepalivetimeout 0
Again, thanks to everyone who has helped investigate, troubleshoot, provide information about and otherwise participated in the hunt for this leak.
Programmer, husband, father, singer, guitarist, tinkerer, reverse engineer, strange, and living in New Jersey. 
It is possible to use aolserver/nsd/driver.c with the memory leak fixed with the actual 4.0.10 distro?
Also, what side effects might carry?:
ns_param keepalivetimeout 0
At this point, I would suggest just using the tip of the aolserver_v40_bp branch — eventually, that will be tagged and released as AOLserver 4.0.11.
Side-effects of setting “keepalivetimeout” to 0? Just that, well, HTTP Keep-Alive will be disabled. This might result in a small performance impact, as clients will need to initiate full TCP connections to the server per HTTP request rather than reusing an existing connection. This is likely to be a non-issue in real-world sites, though.