Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Replace self-signed cert in SW API with fully valid cert

First off, thanks for reading this post.

We have a script that enables/disables monitoring of nodes in SolarWinds via the REST API that works well. However, as the cert is self-signed, we must enable an exception for the command to execute. Our security department is pushing requirements that all services in our environment use fully valid certs from our internal certification authority.

How do I configure the SolarWinds API to use a different certificate that supports both API access and the SolarWinds agent? ?

I followed the instructions in the following post to partial success:

https://thwack.solarwinds.com/t5/NPM-Discussions/Change-SolarWinds-Information-Services-SSL-Certificate/m-p/74604#M4469

After applying the changes, the REST command worked correctly w/o any cert errors. However, all nodes using the Agent failed, reporting errors communicating with the agent. Deploying agents using this new cert failed, where it would not fail before the cert change. After restoring the default, self-signed, certificate, communication with the agent-based nodes was restored... however, the API again reported an invalid CN.

How do I resolve this situation?

Thank you,

-Daniel

Find more posts tagged with

Accepted answers

All comments

sturdyerde

Make sure that you put the fully qualified domain name of your Orion server in the subject of the certificate, and then add all subject alternate names that are relevant: the FQDN (yes, again), the short name of the server, and the name of any load balanced URL that you have in front of the Orion servers. As long as the issuing CA is trusted by your agents and clients, then you should be set.

Example from my environment, with generalized server names:

Cert Subject: orionserver1.example.com
Cert Subject Alternate Names: orionserver1.example.com, orionserver1, orion.example.com, orion

In this case, the certificate is valid for accessing the server directly by name and also valid for accessing Orion through a load balanced URL (orion.example.com).

danielc_asrs

Have you done this yourself? Replaced the self-signed certificate with one generated within your organization?

Whenever we create a cert in this org, we follow the procedure you outlined, so I don't believe that is the issue.
FQDN in the Subject name
FQDN, short name, and any alternate FQDN or DNS entries in the SAN list.