I don't know how to point the things using openssl to the /usr/local/bin directory. As far as I can tell these programs, perl, apache, and pkg look whereever they look and are not configurable.
They are, but it depends on a few aspects; one of which is the method of installing them.
If you rely on the Ports collection, so building things manually yourself (which you hinted at in your OP (the 'Portmaster comment')) then you can customize quite a bit using both the
config build target on a port (go into the port directory, run
make config
and (de)select whatever you need) or by adding properties to
/etc/make.conf (see also
make.conf(5) and
ports(7)).
The other option of installing is using binary ('precompiled') packages, which
SirDice suggested. However, if you do you need to keep in mind that this software is build against default settings. And a default setting for a port is to build itself against the OpenSSL libraries in the base system.
Note that I said:
libraries, not executables. Stuff such as
libssl.so.9 or
libcrypto.so.9, that's what actually will be used by Apache and other programs.
So just replacing an
openssl executable within the base system is simply a bad thing to do, because it doesn't change anything for your installed software. Not where the actual libraries are concerned:
Code:
peter@zefiris:/home/peter $ ldd /usr/bin/openssl
/usr/bin/openssl:
libssl.so.8 => /usr/lib/libssl.so.8 (0x8008a3000)
libcrypto.so.8 => /lib/libcrypto.so.8 (0x800c00000)
libc.so.7 => /lib/libc.so.7 (0x80106f000)
peter@zefiris:/home/peter $ ldd /usr/local/bin/openssl
/usr/local/bin/openssl:
libssl.so.9 => /usr/local/lib/libssl.so.9 (0x8008a4000)
libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x800c00000)
libthr.so.3 => /lib/libthr.so.3 (0x801080000)
libc.so.7 => /lib/libc.so.7 (0x8012a8000)
I already did do the update, several weeks ago, but it only updated the one in the local/bin directory, but pkg is looking at the bin directory. The make.conf already has the ssl-openssl in it.
So you
are installing software using the ports collection. This is why I mentioned earlier that you should be careful not to mix binary packages with ports.
I am not trying to customize at all.
Yet you are, you just said so yourself with your comments regarding
/etc/make.conf. Anyway, if you have the default version for SSL set to
openssl then that is yet another reason not to touch
/usr/bin/openssl.
By default the ports collection uses SSL from the base system.
I think the one in /usr/bin is because years ago that is where it was located by default, and at some point when I would update it started being put in the local/bin, and the updates would not do anything.
Pardon me being a bit direct but I think that you have no idea what you're doing and how FreeBSD actually works. I mention this because you previously mentioned PCI compliancy and at the risk of sounding harsh but this is
definitely not the way to achieve that.
So, going back to your comment about a version check... Sure, if you just run
openssl you may end up firing up the version from the base system. So what's the problem? The only reason this is happening is because of your search path,
/usr/bin is usually mentioned before
/usr/local/bin. Yet that doesn't automatically imply that the ports are also using it.
Something you can easily check yourself using
ldd (see my examples above).
I was forced to copy it over to the /usr/bin for it to take effect.
No you weren't. You may think you were because you apparently don't understand how the search path works nor do you grasp the concept of binaries which get compiled against libraries. But that doesn't make it true. This was an unnecessary action and one that effecitvely breaks your system. No more, no less:
Code:
peter@zefiris:/home/peter $ pkg info -lx apache24 | grep mod_ssl
/usr/local/include/apache24/mod_ssl.h
/usr/local/include/apache24/mod_ssl_openssl.h
/usr/local/libexec/apache24/mod_ssl.so
peter@zefiris:/home/peter $ ldd /usr/local/libexec/apache24/mod_ssl.so
/usr/local/libexec/apache24/mod_ssl.so:
libssl.so.9 => /usr/local/lib/libssl.so.9 (0x801238000)
libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x801600000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x801a80000)
libthr.so.3 => /lib/libthr.so.3 (0x801c9f000)
libc.so.7 => /lib/libc.so.7 (0x800823000)
My server also uses the OpenSSL port because it allows me to upgrade OpenSSL whenever I need to without having to rely on the next FreeBSD release.
That's how you check for it to be in effect; notice how the ssl and crypto libraries pointing to
/usr/local/lib...
Anyway, my comment still stands. You should definitely undo the damage you did. Not just because you basically broke your system but also because of the potential impact this has on your PCI compliancy. There are also restrictions and regulations set up which apply to the underlying operating system. And if you start meddling in said operating system, up to a point where you perform destructive operations then this definitely has its impact on security as such also on your PCI compliancy.