When linking to OpenSSL (or other cryptographic libraries) would it be more secure to use a shared library and have address space layout randomization, or to use a static library and not have ASLR?
ASLR and such things are ways to try to cope with consequences of a buffer overflow -- they are an hide&seek game so that attackers find it harder to turn a buffer overflow into remote code execution. For proper security, it is better to make it so that buffer overflows don't occur in the first place.
... and for that, dynamic linking is better. The reason is the following: it would be inordinately optimistic to believe that any given piece of code written in C does not have any buffer overflow (especially OpenSSL, which has a rather long history on that subject). Thus, the best that you can do is to be able to promptly fix known security holes by replacing the faulty part. If you use dynamic linking, this is easy: just replace the DLL, and be done with it. If the DLL is provided by the OS (the normal case in Linux systems) then this will be done naturally when you apply security updates from the OS vendor. However, if you use static linking, then the patches won't make it into your application until you recompile (or at least relink) that specific application with the patched OpenSSL.
In practice, static linking means that security fixes on the library will take longer to be applied to the application -- or, more often than not, won't be applied at all. This is bad. Therefore, use dynamic linking.
I'm late to the party, but I just wanted to throw in some opinions in case anyone else passes by. The accepted answer is accurate in that static linking makes it more difficult to do an in-place upgrade. For example, if you're using OpenSSL with your app, you could just deploy the new libcrypto.dll (assuming it's backward compatible with your app) over the old DLL, and you'll be good.
However, in regard to exploits and other nasty stuff, I would argue static linking is a little more secure. Basically, there's no DLL external to your application that can be swapped with a tainted version of the same DLL or even a shim (DLL proxy and the like...)
Additionally, and this isn't really an argument against either, but if your external library has an exploit neither static or dynamic is going to be safer as it's exploited at run-time when it's already linked in to your application.
I agree with their advice on making it easier to match current OpenSSL versions and for the most part would suggest dynamic linking, but you know your application best, and since the original question asked which is safer (while deployed on a box, I assume), you should also think about tampering.