Bug 1027265

Related thread and reply from Alexander.
https://www.redhat.com/archives/freeipa-users/2013-November/msg00040.html

IMO his reply can be a foundation for the man page change.

Probably worth mentioning the existence of /etc/pki/tls/certs and and /etc/pki/tls/private for cert/key storage on Fedora/RHEL systems. I don't know what the equivalent is on Debian-based distros.

I think that Rob Crittenden solution is the best! I have checked it out, everything works fine!
So there should be just a note in documentation with recommendations to store keys and certificates here.
here is my example:

# ipa-getcert request -f /etc/pki/tls/certs/postgresql.crt
-k /etc/pki/tls/private/postgresql.key -K
postgresql/postgresql.example.com -N CN=postgresql.example.com -D
postgresql.example.com

# ipa-getcert list
Request ID '20131107050729':
	status: MONITORING
	stuck: no
	key pair storage:
type=FILE,location='/etc/pki/tls/private/postgresql.key'
	certificate: type=FILE,location='/etc/pki/tls/certs/postgresql.crt'
	CA: IPA
	issuer: CN=Certificate Authority,O=EXAMPLE.COM
	subject: CN=postgresql.example.com,O=EXAMPLE.COM
	expires: 2015-11-08 05:07:29 UTC
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes

after I've changed owner:
# chown postgres /etc/pki/tls/certs/postgresql.crt
# chown postgres /etc/pki/tls/private/postgresql.key
# ll /etc/pki/tls/certs/postgresql.crt 
-rw-------. 1 postgres root 1318 Ноя  7
11:07 /etc/pki/tls/certs/postgresql.crt
# ll /etc/pki/tls/private/postgresql.key 
-rw-------. 1 postgres root 1704 Ноя  7
11:07 /etc/pki/tls/private/postgresql.key

it seems to be starting well!

We should have 'see also' pointers to the (somewhat dry) certmonger_selinux(8) page in all of the section 1 and 8 man pages now, and the getcert-request(1) and getcert-start-tracking(1) man pages also now include:

NOTES
       Locations specified for key and certificate storage need to be accessi‐
       ble to the certmonger daemon process.  When run as a system daemon on a
       system which uses a mandatory access control mechanism such as SELinux,
       the system policy must ensure that the daemon is allowed to access the
       locations where certificates and keys that it will manage will be
       stored (these locations are typically labeled as cert_t or an equiva‐
       lent).  More SELinux-specific information can be found in the
       selinux.txt documentation file for this package.

The referenced selinux.txt reads:

I'm running SELinux.  What is certmonger allowed to access?

If your copy of certmonger runs confined, you can read the label which
should be applied to its binary file with:

  # matchpathcon /usr/sbin/certmonger
  /usr/sbin/certmonger	system_u:object_r:certmonger_exec_t:s0

Meanwhile, you can read the label which is currently applied to its
binary file with:

  # ls --scontext /usr/sbin/certmonger 
  system_u:object_r:certmonger_exec_t:s0 /usr/sbin/certmonger

If the results differ, use "restorecon" to reset the label of the
file to value that your configuration says it should have:

  # restorecon /usr/sbin/certmonger 

You can query which domain the process will be run in, when the binary
is started by the init system, with:

  # sesearch -T -t certmonger_exec_t
  Found 2 semantic te rules:
     type_transition init_t certmonger_exec_t : process certmonger_t;
     type_transition initrc_t certmonger_exec_t : process certmonger_t;

You can then query which types and attributes (loosely, groups of type)
of directories a process running as "certmonger_t" will be allowed to
create files in, and what sorts of files it will be able to create and
write to:

  # sesearch --allow -s certmonger_t -c dir -p add_name
     allow certmonger_t cert_type : dir { ioctl read write getattr lock add_name remove_name search open } ;
     allow certmonger_t certmonger_var_lib_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ;
     allow certmonger_t certmonger_var_run_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ;
     ...

  # sesearch --allow -s certmonger_t -c file -p create,write
     allow certmonger_t cert_type : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
     allow certmonger_t certmonger_t : file { ioctl read write getattr lock append open } ;
     allow certmonger_t certmonger_var_lib_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
     allow certmonger_t certmonger_var_run_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
     ...

By convention, type names end with "_t", but attribute names don't.
Attribute names can be resolved to the list of types to which they're
applied with:

  # seinfo -x --attribute=cert_type
     cert_type
        pki_tomcat_cert_t
        dovecot_cert_t
        home_cert_t
        cert_t
        slapd_cert_t

Each of those types, in turn, will be applied to one or more files or
directories by default when packages are installed, when the system was
installed, or when the "restorecon" command is used to relabel files and
directories.  To obtain a list of which path patterns are configured to
receive a particular type, you can use a command :

  # semanage fcontext -l | grep :cert_t:
  /etc/httpd/alias(/.*)?               all files system_u:object_r:cert_t:s0
  /etc/pki(/.*)?                       all files system_u:object_r:cert_t:s0
  /etc/ssl(/.*)?                       all files system_u:object_r:cert_t:s0
  /usr/share/ca-certificates(/.*)?     all files system_u:object_r:cert_t:s0
  /usr/share/pki/ca-certificates(/.*)? all files system_u:object_r:cert_t:s0
  /usr/share/pki/ca-trust-source(/.*)? all files system_u:object_r:cert_t:s0
  /usr/share/ssl/certs(/.*)?           all files system_u:object_r:cert_t:s0
  /usr/share/ssl/private(/.*)?         all files system_u:object_r:cert_t:s0
  /var/named/chroot/etc/pki(/.*)?      all files system_u:object_r:cert_t:s0

In enforcing mode, locations which fit these patterns are the locations
which the certmonger daemon will be allowed to read and write.

Feedback welcome.

There are couple of observations from my side.

(1)Man page for certmonger_selinux(8) is missing.
(2)An example in file selinux.txt will be helpful.
   like mkdir /tmp/certs ; chcon -t cert_t /tmp/certs

Verified.

certmonger_selinux man page provided by selinux-policy-doc pkg.

certmonger_selinux pointers exits in getcert* and certmonger* man pages.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1512.html