partition dogtag data in the ldap server?
Hi, we have a rather large dogtag install here and the ldap-info is getting hard to handle (right now in the ~75Gb range). Are there any recomended ways to partition the data ? I am thinking of migrating all expired and revoked certificates to a chainend ldap-instance and keep only the "valid" certificates data in direct access to the CA instances. The migration from the "valid" partition to the "expired" partition will have to be done outside of dogtag and the 389ds-ldaps, probably by a script at night (it probably could be integrated into the expire runs the dogtag does, although) Has a thing like this been done yet? What were the experiences ? What sould I look out for ? Mit freundlichen Grüßen, Alexander Jung
Alexander, Can you define "hard to handle"? What version of Dogtag are you using? Are you running into performance degradation? Unfortunately, it likely won't be too easy to segregate this data. In dogtag 10.2 there should be a scheduled job that regularly runs through and removes all expired certs: jobsScheduler.impl.UnpublishExpiredJob.class=com.netscape.cms.jobs.UnpublishExpiredJob jobsScheduler.job.unpublishExpiredCerts.cron=0 0 * * 6 Thanks in advance. -- Dave ----- Original Message -----
From: "Alexander Jung" <alexander.w.jung@gmail.com> To: "pki-users@redhat.com" <Pki-users@redhat.com> Sent: Thursday, July 9, 2015 7:44:17 AM Subject: [Pki-users] partition dogtag data in the ldap server?
Hi,
we have a rather large dogtag install here and the ldap-info is getting hard to handle (right now in the ~75Gb range).
Are there any recomended ways to partition the data ? I am thinking of migrating all expired and revoked certificates to a chainend ldap-instance and keep only the "valid" certificates data in direct access to the CA instances.
The migration from the "valid" partition to the "expired" partition will have to be done outside of dogtag and the 389ds-ldaps, probably by a script at night (it probably could be integrated into the expire runs the dogtag does, although)
Has a thing like this been done yet? What were the experiences ? What sould I look out for ?
Mit freundlichen Grüßen,
Alexander Jung
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
Thank you Dave for bringing this email to my attention...somehow it got slipped by me. I just want to point out that if you do choose to "remove" certs from the internal ldap repository, please do not remove any certs that are revoked but not yet expired. Doing so will cause your CRL generation to miss the revoked certificates, and render them valid when checked upon by clients. It would be a big security violation of PKI. regards, Christina On 07/22/2015 11:35 AM, Dave Sirrine wrote:
Alexander,
Can you define "hard to handle"? What version of Dogtag are you using? Are you running into performance degradation? Unfortunately, it likely won't be too easy to segregate this data. In dogtag 10.2 there should be a scheduled job that regularly runs through and removes all expired certs:
jobsScheduler.impl.UnpublishExpiredJob.class=com.netscape.cms.jobs.UnpublishExpiredJob jobsScheduler.job.unpublishExpiredCerts.cron=0 0 * * 6
Thanks in advance.
-- Dave
------------------------------------------------------------------------
*From: *"Alexander Jung" <alexander.w.jung@gmail.com> *To: *"pki-users@redhat.com" <Pki-users@redhat.com> *Sent: *Thursday, July 9, 2015 7:44:17 AM *Subject: *[Pki-users] partition dogtag data in the ldap server?
Hi,
we have a rather large dogtag install here and the ldap-info is getting hard to handle (right now in the ~75Gb range).
Are there any recomended ways to partition the data ? I am thinking of migrating all expired and revoked certificates to a chainend ldap-instance and keep only the "valid" certificates data in direct access to the CA instances.
The migration from the "valid" partition to the "expired" partition will have to be done outside of dogtag and the 389ds-ldaps, probably by a script at night (it probably could be integrated into the expire runs the dogtag does, although)
Has a thing like this been done yet? What were the experiences ? What sould I look out for ?
Mit freundlichen Grüßen,
Alexander Jung
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
2015-07-22 22:43 GMT+02:00 Christina Fu <cfu@redhat.com>:
Thank you Dave for bringing this email to my attention...somehow it got slipped by me.
I just want to point out that if you do choose to "remove" certs from the internal ldap repository, please do not remove any certs that are revoked but not yet expired. Doing so will cause your CRL generation to miss the revoked certificates, and render them valid when checked upon by clients. It would be a big security violation of PKI.
Yes, I am planing to move only the expired (or revoked-expired certs). While we do not really use the CRL any more (OCSP is the thing nowadays :-), we keep it for compatibility... Mit freundlichen Grüßen, Alexander Jung
On 07/24/2015 12:07 AM, Alexander Jung wrote:
2015-07-22 22:43 GMT+02:00 Christina Fu <cfu@redhat.com <mailto:cfu@redhat.com>>:
Thank you Dave for bringing this email to my attention...somehow it got slipped by me.
I just want to point out that if you do choose to "remove" certs from the internal ldap repository, please do not remove any certs that are revoked but not yet expired. Doing so will cause your CRL generation to miss the revoked certificates, and render them valid when checked upon by clients. It would be a big security violation of PKI.
Yes, I am planing to move only the expired (or revoked-expired certs). While we do not really use the CRL any more (OCSP is the thing nowadays :-), we keep it for compatibility...
Good to know. Though as far as Dogtag goes, OCSP gets its CRL from the CA, where CA generates its CRL from the certs in its internal ldap db. CA needs to keep its CRL accurate and updated for the whole PKI to work properly.
Mit freundlichen Grüßen,
Alexander Jung
2015-07-22 20:35 GMT+02:00 Dave Sirrine <dsirrine@redhat.com>:
Alexander,
Can you define "hard to handle"?
Hard to handle is a stock of over 4 Million certificates, of which about 10% are valid ones. The ldap database is with the indexes in the 100Gb range, LDIF Backups take more than three hours and might fail if too many changes occur during the night time we run them.
What version of Dogtag are you using?
10.1. something (= the version that came out in February this year, but the history in that ldap is migrated since around 2007)
Are you running into performance degradation?
Yes, we had a perfomenace degradation , but that was a lookup error in the code (I really have to get around to send our fixes here back to you) Unfortunately, it likely won't be too easy to segregate this data. In
dogtag 10.2 there should be a scheduled job that regularly runs through and removes all expired certs:
jobsScheduler.impl.UnpublishExpiredJob.class=com.netscape.cms.jobs.UnpublishExpiredJob jobsScheduler.job.unpublishExpiredCerts.cron=0 0 * * 6
Thanks for the pointer, I'll try to attach to this one. Mit freundlichen Grüßen, Alexander Jung
participants (3)
-
Alexander Jung -
Christina Fu -
Dave Sirrine