Description of problem:
Version-Release number of selected component (if applicable):
If I try to search for certificates to revoke through the Revoke Certificates
feature, I get the following error: LDAP operation failure -
netscape.ldap.LDAPException: Bad search filter (89). The same search options in
Search for Certificates section works fine.
Steps to Reproduce:
1. Go to Agent Services and click on "Revoke Certificates"
2. Check the box for "Revoke certificates that fall within the following range"
3. Enter 0x1 in both boxes for lowest and highest serial number
4. Scroll to bottom and click find, receive exception message.
5. Go to Agent Services and click on "Search for Certificates"
6. Check the box for "Show certificates that fall within the following range"
7. Enter 0x1 in both boxes for lowest and highest serial number
8. Scroll to bottom and click find and one certificate is shown.
9. You can then click revoke button if you want to revoke the certificate.
LDAP operation failure - netscape.ldap.LDAPException: Bad search filter (89)
The search to perform successfully.
DS flavor for the CA install is Red Hat DS 8.0 running on a separate server. I
don't see an error 89 show up in the logs of the LDAP server in the error case,
but I see the successful search show up.
Created attachment 301547 [details]
ca debug log while doing a revoke search
Created attachment 301548 [details]
ca debug log while doing a search
It looks like the search filter gets munged in the case of the revoke search.
- 3 lines up from the bottom of attachment 301548 [details] (the good one) it shows the
ldap search filter string "searchCertificateswith time limit filter
- 4 lines up from the bottom of attachment 301547 [details] (the bad one) it shows
"searchCertificateswith time limit filter (&)"
The same thing happens a few more lines up with "queryCertFilter".
Under "Steps to Reproduce:" in the original report, only 1-4 apply.
5-9 are actually the workaround.
*** This bug has been marked as a duplicate of bug 445436 ***
SrchRevokeCert.html did not follow new schema for search filter generation on
the server side. Moving filter generation to the server side fixed