6:44 a.m.
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
1:35 p.m.
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(a)gmail.com>
To: "pki-users(a)redhat.com" <Pki-users(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-users
3:43 p.m.
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(a)gmail.com>
*To: *"pki-users(a)redhat.com" <Pki-users(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-users
_______________________________________________
Pki-users mailing list
Pki-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-users
2:07 a.m.
2015-07-22 22:43 GMT+02:00 Christina Fu <cfu(a)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
11:08 a.m.
On 07/24/2015 12:07 AM, Alexander Jung wrote:
2015-07-22 22:43 GMT+02:00 Christina Fu <cfu(a)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
2:13 a.m.
2015-07-22 20:35 GMT+02:00 Dave Sirrine <dsirrine(a)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
4016
days inactive
4031
days old
5 comments
3 participants
participants (3)
-
Alexander Jung -
Christina Fu -
Dave Sirrine