Hi All…
I am in a somewhat embarrassing, yet very frustrating situation… Embarrassing because I let it happen. Frustrating because even wM support appears stumped. So I now turn to this group’s vast knowledge and experience.
The story…
We have been using broker servers with certs and ACLs for several years. (We do this to prevent Developers from accessing the production environment as well as prevent them from restarting development/test broker servers.) Well… our certs were about to expire, and we have had some turn over in the developer group and the support groups. So when creating the new certs, we not only removed old DNs and added new, we also changed the field values of the DNs (O, OU, etc).
As we rolled out the new certs, we could not take an outage to restart the broker servers at that time. So we ‘seeded’ the new certs in place (change on restart). All our production broker servers are fine, but some of our test broker servers still show ‘locked’.
Now the embarrassing part: I did not followup and confirm the ACLs (based upon the old DNs) were removed by our support team. At least I feel that is the root of my issue.
The frustrating part: I have been in a expired cert position before, it was resolved by moving the cert file used by the broker servers and restarting the broker servers. Well, yep, I tried this again, but the broker servers remain ‘locked’. So it appears our support group did not use the correct cert file with these broker servers.
My issue: How can I find which cert file is being used by a broker server if it is locked? and may have ACLs containing DNs which do not match the current ‘non expired’ certs DNs…
I am hoping there is an ‘easy’ way to do this. Otherwise, I will have to search for all the certs on my broker host (which has IS instances as well, with users all having uploaded own certs) and rename all those certs and try a restart again.
Thanks!
Ray
