OpenSSL is a toolkit, not a full implementation. More importantly, it is a library, so anyone who can link against it can perform all operations that the library can support, and the library has no concept of role separation built in.
As such, the 'openssl' commandline tool allows the use of any of its subcommands by anyone who can run their executables. This generally includes 'root', which is also usually necessary for manipulating files (keys, certs, and CA cert chains) which are owned by system users, like 'apache'.
There are many openssl subcommands which are useful for standard system and network administrators. s_client and s_server (to verify interoperability and connectivity), x509 (to figure out what's broken and see if it's something the PKI admin needs to deal with, in conjunction with the -noout and -text parameters), verify (to figure out what's wrong with a cert chain to make filing tickets for the pki admin more useful)... the only commands I can really think of off the top of my head that could be legitimately restricted are 'req' and 'ca'. Usually, the 'ca' command is limited by access to the CA key. 'req' generates a new certificate signing request, but doesn't generate a new certificate. The operations for a PKI admin should in all cases include "generate your request, then send the request that you just generated" rather than "submit some request that some other schlub generated", which mitigates that particular potential disaster.
It might be possible to limit the execution of openssl subcommands using SELinux roles and labels, but I don't think anyone's audited the subcommands looking for functionality that should be limited to one role or another. The closest that's been done has been for the FIPS validation, and (to my uncertain understanding) even that applies pretty much only to the building and installation of the module.
If you do perform such an audit, I'd love to see your work. (n.b. I'm not a member of the OpenSSL team, so my opinions are mgmy own and no one else's.)
OpenSSL is a toolkit, not a full implementation.
More importantly, it is a library, so anyone who can link
against it can perform all operations that the library can
support, and the library has no concept of role separation built
Still more importantly, almost everything OpenSSL does is just math
and file manipulation. S_client and s_server add basic network
operations. There's probably some low-level goop for hardware
acceleration, but that's just acceleration.
You can write a program to do those things without needing to
involve OpenSSL, so restrictions on OpenSSL per se aren't very
The way to restrict PKI operations (in a simple configuration) is
through file and directory permissions on the data involved.
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris