Bug 1302910 - rfe idm/ipa pki ldap backend, control the number of certificates a host or device can enroll to keep manageable db size
rfe idm/ipa pki ldap backend, control the number of certificates a host or de...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core (Show other bugs)
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Matthew Harmsen
Asha Akkiangady
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2016-01-28 18:38 EST by Marc Sauton
Modified: 2018-01-01 20:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marc Sauton 2016-01-28 18:38:32 EST
Description of problem:

It is possible to enroll, unenroll a host or device, and repeat in a loop, for the same host or device, without any limit.
The challenge is overtime, there will be a large number of requests and associated certificates stored in the Dogtag LDAP backend.
This does not seem a serious issue, until that backed store 10's of thousands such requests and certificates for dozens of host.
Not only the LDAP backend db will be for example between 6 and 16GB for more than 500K certs plus at least 2GB of indexes, but it becomes impossible to create new IdM/IPA replica.
A large CRL attribute value can be worked around by increasing the nsslapd-maxbersize value in dse.ldif of the LDAP backend, but replica install will be very difficult, and replication will also be difficult with cloned CA's (plus state info from nscpentrywsi will accumulate), and lead to more issues with performance as the cache may not be tuned anymore for the amount of available RAM and volume of disk i/o.

We need to find a way to limit this to "reasonable" size that do not break replication for masters, not unlimited 100's of thousands certificates and request per device, may be with a new user configurable CS.cfg or IPA parameter if that amount is really really needed.

Example, an edited ist from a real IdM/IPA deployment:

number of certs and subject names
     31 subjectName: CN=test-cms-drupal02.example.com,O=EXAMPLE.COM
     54 subjectName: CN=test-cms-drupal01.example.com,O=EXAMPLE.COM
     69 subjectName: CN=autonomy-test.example.com,O=EXAMPLE.COM
  14271 subjectName: CN=host1.example.com,O=EXAMPLE.COM
  16585 subjectName: CN=host2.example.com,O=EXAMPLE.COM
  16717 subjectName: CN=host3.example.com,O=EXAMPLE.COM
  16737 subjectName: CN=host4.example.com,O=EXAMPLE.COM
  26664 subjectName: CN=host5.example.com,O=EXAMPLE.COM
  33933 subjectName: CN=host6.example.com,O=EXAMPLE.COM
  35699 subjectName: CN=host7.example.com,O=EXAMPLE.COM
  36376 subjectName: CN=host8.example.com,O=EXAMPLE.COM
  36821 subjectName: CN=host9.example.com,O=EXAMPLE.COM
  36920 subjectName: CN=host10.example.com,O=EXAMPLE.COM
  39688 subjectName: CN=host11.example.com,O=EXAMPLE.COM
  75834 subjectName: CN=host12.example.com,O=EXAMPLE.COM

Version-Release number of selected component (if applicable):
was reported on RHEL 6 with IPA 3, but also applies to RHEL 7 and IPA 4

How reproducible:

Steps to Reproduce:
1. have RHEL and IPA master
2. either enroll, unenroll a host, loop for days, weeks, or build up an LDIF to import in the Dogtag LDAP backend
3. try to create a replica

Actual results:
example, replica install failure, LDAP error after manual tune up for
nsslapd-maxbersize: 300000000
nsslapd-cachememsize: 300000000

[26/Jan/2016:18:33:52 +0000] - ERROR bulk import abandoned
[26/Jan/2016:18:33:52 +0000] - import ipaca: Aborting all Import threads...

error before the manual tuning of the maxbersize, as the masterCRL attribute value is getting large:

[21/Jan/2016:02:27:16 +0000] - import ipaca: WARNING: skipping entry "cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca"
[21/Jan/2016:02:27:16 +0000] - import ipaca: REASON: entry too large (205449005 bytes) for the import buffer size (8388608 bytes). Try increasing nsslapd-cachememsize.
[21/Jan/2016:02:27:16 +0000] - slapi_start_bulk_import: failed; error = -1
[21/Jan/2016:02:27:16 +0000] - ERROR bulk import abandoned

initial error

1833 2016-01-21T07:01:03Z CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ...
...snip...returned non-zero exit status 255
1834 2016-01-21T07:01:03Z INFO   File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script
1835     return_value = main_function()
1837   File "/usr/sbin/ipa-replica-install", line 467, in main
1838     (CA, cs) = cainstance.install_replica_ca(config)
1840   File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 1617, in install_replica_ca
1841     subject_base=config.subject_base)
1843   File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 617, in configure_instance
1844     self.start_creation(runtime=210)
1846   File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 358, in start_creation
1847     method()
1849   File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 879, in __configure_instance
1850     raise RuntimeError('Configuration of CA failed')
1852 2016-01-21T07:01:03Z INFO The ipa-replica-install command failed, exception: RuntimeError: Configuration of CA failed

( missing matching CA debug log and LDAP error log files)

Expected results:

Additional info:
Comment 3 Matthew Harmsen 2016-02-16 13:30:19 EST
Per discussions in PKI Upstream Release Planning Meeting of 02/16/2016 - Moving this bug to RHEL 7.4.

Note You need to log in before you can comment on or make changes to this bug.