Why are we now using digital certificates?
Starting in R9.3, a digital certificate is installed to the personal store of the VSA server and each managed agent.
On the VSA server, there will be two certificates. The parent VSA root certificate has the same globally unique identifier (GUID) as the Subject and Issuer, which is the internal system VSA GUID. The second certificate is for the locally installed agent and has the VSA GUID as the Issuer, but the subject is another GUID which is unique to each agent. This agent certificate is present on all managed agents (but each with its own GUID as the Subject).
With the introduction of the new endpoint fabric in v9.3 we also introduced a new public key infrastructure (PKI) that offers both encryption and digital signatures of the payload between the VSA and the endpoint fabric. When the endpoint first registers itself, the VSA will issue a device certificate to that machine so that only that agent can communicate with the VSA as that device's identity.
It allows us to offer mutual authentication so both the VSA and the endpoint fabric can trust each other. It also allows us to encrypt and digitally sign the payload of information so that only the intended recipient can access the data. Why so much extra security? We have seen in the field deployments where VSA administrators are NOT using a transport security layer like SSL. Even though it is our best practices we can't demand our customers to lock down their VSA. So as we threat modeled the type of sensitive information that is now flowing through the endpoint fabric meshed network we decided to defend the data using industry standard crypto with certificates.
The certificates are used for many things. For both AuthN and AuthZ operations. From LiveConnect to edge proxy detection and validation. As we continue to move forward with new capabilities more will flow through the endpoint fabric and automatically gain the security benefits of the encryption and digital signatures.
Certificates show as "cannot be verified" because they are issued privately by the VSA server and not by a public Trusted Root Certification Authority (CA). A CA signed certificate is not necessary because of the way the certificate is used. Only Kaseya software will attempt to validate it, these certificates are never seen by a browser or any user-facing application.
NB - It is still recommended to secure the VSA server with a valid CA signed SSL certificate.
Kaseya VSA - R9.3 and above
Kaseya Modules - Kaseya Anti-Virus, Kaseya Anti-Malware, Kaseya Cloud Backup, Kaseya Software Management
Kaseya Applications - Kaseya Live Connect, Kaseya Remote Control