Hello Rob, 

Thanks for these answers. It seems to be much worse than I thought : ipa 
host-show shows every certificates issued for the host, and each certificate 
issued has its own request in LDAP (54K entries in ou=ca,ou=requests,o=ipaca)

I believe the correct way would be : 
* Get the serial of currently used cert on each host.  
* For each cert present in LDAP, that has been issued during the loop : 
** Remove it from the host with ipa host-remove-cert (this will revoke the cert)
** Get the requestID and delete the request from LDAP
** Delete the cert from LDAP

Once this is done, the ldap changelog db will likely be huge. From what I see 
in [2], I can reduce nsslapd-changelogmaxage to force the trim, and set 
nsslapd-changelogcompactdb-interval to a low value to force the compaction of 
the db. 

Do you see anything I'm forgetting ? 

Kind regards,
François PICOT 

[2] http://www.port389.org/docs/389ds/FAQ/changelog-trimming.html 


-----Original Message-----
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: lundi 13 novembre 2017 19:28
To: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
Cc: Francois Picot <francois.pi...@homesend.com>
Subject: Re: [Freeipa-users] Re: Delete certificates from Dogtag PKI

Francois Picot via FreeIPA-users wrote:
> Hello all,
> 
> I'm not sure this is the correct list to post in, but it seems to be more of 
> a PKI issue. I'm wondering if there is a clean/easy way to delete 
> certificates from IPA CA/PKI.  
> 
> For a little context.. One of our systems has an IPA pair, which issues 
> certificates for internal use via dogtag PKI. Two weeks ago, we found that 
> some certificates were renewed without DNS SAN. After a few searches, I found 
> this thread [1] which helped us import the profile into LDAP and everything 
> seemed to go back to normal.
> 
> However, some servers in this system went mad a few days later, and 
> certmonger looped on renewal of some certificates. 
> In /var/log/messages, we can see these two lines repeating every few seconds 
> : 
> Nov  8 14:22:14 srv-01 certmonger: Certificate in file "/etc/httpd/httpd.crt" 
> is no longer valid.
> Nov  8 14:22:14 srv-01 certmonger: Certificate in file "/ etc/httpd/httpd.crt 
> " issued by CA and saved.

Were these cut-n-pasted? The space looks very strange.

> After restarting certmonger, the loop stopped. 
> 
> The problem now is we have 54K certificates in IPA CA. Some hosts have up to 
> 2400 certificates issued. The dirsrv file id2entry.db is 1.3GB. The backup 
> process needs about 8GB to run and produce 3,5GB backups (up from ~100MB). 
> Almost all ipa commands time out because of the huge number of certificates. 
> 
> I would like to avoid revoking the certificates for two reasons : 
> * They are for an exclusively internal use, and I'm absolutely 
> positive that they have not been compromised,
> * It's likely it wouldn't solve the backup size problem. 
> 
> Is there another way than manually deleting them from LDAP ? I couldn't find 
> any command that would simply delete the certs. 
> If not, is it safe to delete them ? 

Normally I'd say no, don't delete the certificates, but given the circumstances 
it may be worthwhile. I'm not sure how much space will be reclaimed when the 
entries are deleted.

You will want to be extremely careful not to delete the current certificate 
associated in IPA unless you also remove that entry. When a new certificate is 
issued in IPA it will try to revoke the current one and if that cert isn't in 
the store it will fail.

The certificates themselves are stored in ou=certificateRepository,ou=ca,o=ipaca

You may also need to look in ou=ca,ou=requests,o=ipaca. I'm guessing that this 
will be a reasonable value since the same CSR should have been used with each 
request.

I can't say that this will be easy. I'd create a list of dns and pass that to 
ldapdelete to do the cleanup.

rob
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to