N-able N-central uses an SSL connection to communicate between the N-able N-central server and all monitored devices. By default, the URL of a secure central server begins with HTTPS.
Certificates are only available at the System Level for the 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 N-able 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. After your receive the signed certificate, you can upload it to N-able 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 comprises:
- a root certificate
- one or more Intermediate certificates
- 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 website. 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, N-able 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.
You cannot generate or export a wildcard certificate using your N-able N-central server.
The N-able N-central server is able to upload a certificate, but the certificate must already be in a PKCS12 format (.p12 or .pfx), which is password protected and contains the bundle and private key of that server. It will not accept any other format. See Upload a certificate.
Certificate bundles can be obtained from any of the following SSL providers:
- 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/)