It's always selinux ;-)
If you install the selinux utilities (policycoreutils-python) then you can use them to set up the security polices. Look in /var/log/audit/audit.log for the offending lines and then use commands like this, for example this is what I had to do to allow mysqld to run:
sudo audit2allow -a -m mysqld > /tmp/mysqld.te sudo checkmodule -M -m /tmp/mysqld.te -o /tmp/mysqld.mod sudo semodule_package -o /tmp/mysqld.pp -m /tmp/mysqld.mod sudo semodule -i /tmp/mysqld.pp
Well always when you step outside normal practices...
Where did you install that mysql from by the way as the base policy has mysql contexts and policies in place...
In general your advice would work but it's bad practice...
The above assumes what you want the application is trying to do is what you want to happen - this is probably not quite the case.
For the OP it's likely to be the context of the certificates where you put them... copy them (not move) to somewhere like /etc/httpd so they get the context httpd_etc_t (in the alternative make a dedicated /etc/httpd/certs directory to support multiple certs for virtualhosts with a context of cert_t as this howto describes http://www.freeipa.org/page/Apache_SNI_With_Kerberos)...
The http_t domain has permission to read that context type so that will work properly and the various bits restricted appropriately...
As for your mysql I'm guessing it installed to /opt or /usr/local or had a version number in place such as /var/lib/mysql55 which took the files out of the standard locations and consequently the file contexts would have been incorrect as they would have inherited from those other locations probably resulting in mysqld in the wrong domain too (initrc_t perhaps or bin_t depending how it was started). Using the audit2allow -a -M etc method outlined above would then result in mysqld having too broad access or possibly other processes getting access to the mysql database files or config files improperly (depending on how the auto generated rule went).
To fix that scenario given that the base selinux policy already has rules for mysql all you need to do is ensure that the right file contexts are on the files in the improper locations.
First use semanage fcontext -l | grep mysql to get a list of all file contexts related to mysql.
Then for each of these (there's only about 21) check to see where you custom install has put the equivalent file (eg /usr/libexec/mysqld might be in /usr/local/bin/mysqld or /opt/mysql/bin/msqld).
With that knowledge in hand simply copy and paste the context to the new file for example:
original from the list above: /usr/libexec/mysqld regular file system_u:object_r:mysqld_exec_t:s0
Add your new path: semanage fcontext -a -t mysqld_exec_t '/usr/local/bin/mysqld' && restorecon -Rv /usr/local/bin/mysqld
With the correct contexts on the files you should then be able start the service and it'll be properly confined in its correct domain.