SolarWinds N-central uses an SSL connection to communicate between the SolarWinds N-central server and all monitored devices. By default, the URL of a secure central server begins with HTTPS.
Certificates are only available for System or Product Administrator level accounts. Service Organization and Customer or Site level accounts will not be able to access this feature.
Before you can access SolarWinds N-central over a secure connection, you need to generate a server key and SSL certificate. A generated SSL certificate is a self-signed certificate. If you would like the certificate signed by a certificate signing authority, you can download the certificate and send it to the authority. Once the signed certificate has been received, you can upload it to SolarWinds N-central.
SSL certificates are used by HTTPS to validate the identity of servers. To make a secure connection, a client needs a mechanism to ensure that the server is valid and SSL certificates serve that purpose.
An individual certificate must be signed by a recognized and trusted signing authority. These authorities are commonly referred to as CAs with popular examples including Verisign and Go-Daddy. The principle is similar to what you might do when you are told something new. If a random person passes on some information, ordinarily you would not trust it unless the person can tell you the source of their information. You would then consider how trustworthy that source is and evaluate the validity of the information based on that trustworthiness. This is often referred to as a "chain of trust".
The SSL certificate chain of trust is composed of a:
- Root certificate,
- one or more Intermediate certificates, and
- the server SSL certificate.
Intermediate certificates exist for a number of reasons. The validity and authoritativeness of a root certificate would be diluted if it were to sign all certificates itself and so intermediate certificates are delegated to be the signing authority. In some cases, the CAs will also generate intermediate certificates based on the purpose of the certificates they are signing. For example, temporary certificates are signed using one intermediate certificate while long term certificates are signed using another.
For a web client to validate certificates, it must include a list of all certificates used to sign the certification offered by a web site. As there can be a very large number of intermediate certificates involved, most web servers do not offer only their own certificate. Instead, they present all or most of the certificates obtained between themselves and the root certificate. This bundle of certificates is referred to as a certificate chain. Web browsers have their own certificate stores which contain most, if not all, of the root certificates as well as a number of intermediate certificates which are trusted by default. When a client connects using HTTPS, the client receives the certificate chain from the server and follows it back to a trusted certificate in order to determine the validity of the received certificate.
As with any technology, changes have been made to the certificate system. Some issued certificates are condensed certificates that include all levels as one individual certificate rather than as a chain of certificates. While this is growing in popularity, SolarWinds N-central does not support condensed certificates at this time but relies on a chain of individual certificates.
The signed certificate will be added to the end of the final chained certificate file.
Wildcard Certificates are certificates assigned to a domain, such as
.example.com, and can be applied on any third-level address (
home.example.com) using the same certificate. The issue with this type of certificate is that in order to get it to work with SolarWinds N-central it would need to be signed with the CSR generated by SolarWinds N-central. In theory, it would work to have SolarWinds N-central signed, however, we do not export our private key and therefore you will not be able to use this to get the other servers signed.
Certificate bundles can be obtained from any of the following:
- AlphaSSL (http://www.alphassl.com/)
- Comodo (http://www.comodo.com/)
- DigiCert (https://www.digicert.com/)
- Gandi (http://www.gandi.net/)
- GeoTrust (https://www.geotrust.com/)
- Globalsign (https://www.globalsign.eu/)
- GoDaddy (http://www.godaddy.com/)
- Network Solutions (http://www.networksolutions.com/)
- RapidSSL (https://www.rapidssl.com/)
- Register (https://www.register.com/)
- Starfield (https://www.starfieldtech.com/)
- Thawte (http://www.thawte.com/)
- Trustwave (https://ssl.trustwave.com/)
- Verisign (http://www.verisign.com/)