Monday, June 17, 2013

ILM, ADAM, LDS, TLS, WTF

So lets say that you have an ILM instance and the load balanced ADAM servers have a cert that expired..1am is not the best time to be creating a playbook! A few engineers took swipes at it and ended up with some kind of corrupt private/public key pair situation, along with multiple certificates matching the same subject name. We ended up taking notes of what was done, backing it out, and walking through it slowly with Microsoft Support's blessing.

To replace an ADAM certificate that already expired..

1) Locate, document, and remove existing certificate (hint, check service account's cert store..)
2) Create new web server template based certificate request (hint, check SAN attribute)
3) Create response from CA
4) Import response from requesting computer and export the resulting .pfx with public & private key.
5) Import public+private key to ADAM server
6) Grant rights to the account ADAM is running as for the private key of the cert via certificates MMC ideally. In our case we found the old cert in a service account store, but it was running as Network Service. Placing the new cert in the local machine store + granting Network Service access to the private key worked in this case. Others may have a functional/used domain service account & related key store.
7) ADAM should resume accepting connections on 636. Events in the ADAM log should confirm.

Note: If using SAN attribute on cert, be sure subject name is matched. If the subject name changes some apps (Weblogic, lookin' at you!) will not honor the SAN attribute and reject the connection. Thankfully you can disable host name validation if needed, so it seems.

No comments:

Post a Comment