This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Untrusted certificate presented by PM console

When I connect to the patch manager console for the first time, I am asked to trust a certificate signed by an untrusted CA (the patch manager server itself). Can I make the PM server use a certificate signed by our AD Certificate Authority instead?

pastedImage_0.png

  • This is a normal-and-expected dialog, and no, you cannot use a certificate from ADCS for this purpose.

    The Patch Manager PAS is the Certificate Authority for the certificate system used within the entire Patch Manager infrastructure owned by that PAS. All secondary PM servers, and all console connections, are secured, authenticated, and encrypted via certificates. The PAS issues those certificates. This ensures that only servers and consoles 'registered' with that PAS can actually establish a communications channel with the PAS. You get this dialog because the Patch Manager ROOT CA is not yet in the Certificate store of this particular system.

    Understand that an "untrusted certificate" or "untrusted CA" is just a euphamism for a certificate that "this computer doesn't know about yet". But in reality, the Root CA is "trusted", because you own the computer system where that Root CA was created. The "Certificate Authority" is unique to each PAS installed globally; it's not a certificate held by SolarWinds. That is to say, the "Root CA" on your PAS is a completely different certificate than the "Root CA" on my PAS.

    You can view the certificates on the "Server Certificates" tab of the Security and User Management node of the console. (They're stored in the Certificate Store of the PAS, and they can also be viewed with the Microsoft Certificiates MMC snap-in.)

    If you select "Yes" on this dialog (the recommended action), the Patch Manager Root Certificate and the Application Server's server certificate will be added to this system's trusted store, and all future console connections will be automatically established using that certificate.

    If you select "No", the certificates will still be used (no way around this), but they just won't be installed into the system's local store, and you'll get this prompt every time you establish a console connection from this system.

    If you select "Cancel", of course, the console connection attempt will be aborted.

  • Thank you for the explanation, but I'm afraid that I don't understand why it is not supported to replace this self-signed certificate with one signed by my own CA which would be automatically trusted by client computers. It seems that this would not only prevent the certificate warning, but would be much more secure as well.

    Generally, instructing a user to blindly trust a security certificate is bad practice, since it is not always easy to distinguish between those that should be trusted and those that should not. Trusting an illegitimate certificate could create serious security issues, including granting a third party the ability to intercept encrypted communications. It's much better to ensure that legitimate systems are using certs that are already trusted implicitly, such as those signed by a trusted certificate authority.