Ask the Community
Groups
Use of digital certificates to secure Endpoint communication channel - Connect IT Community | Kaseya
<main> <article class="userContent"> <p><strong>QUESTION<br></strong><em><br></em>Why are we now using digital certificates?</p> <p><strong><br>ANSWER</strong></p> <p><em><br>Starting in R9.3, a digital certificate is installed to the personal store of the VSA server and each managed agent.</em></p> <p><span data-mce-mark="1">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, <span data-mce-mark="1">which is the internal system VSA GUID</span>. 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).</span></p> <p><span data-mce-mark="1"><img src="/attachments/token/En4jrffV9WNVqd8B0Df7tub9J/?name=certstore.png" alt="certstore.png" width="837" height="375" class="embedImage-img importedEmbed-img"></img></span></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p><em>NB - It is still recommended to <a href="/home/leaving?allowTrusted=1&target=http%3A%2F%2Fhelp.kaseya.com%2Fwebhelp%2FEN%2FVSA%2F9030000%2Finstall%2F%2318031.htm" rel="noopener nofollow">secure the VSA server</a> with a valid CA signed SSL certificate.</em></p> <h3 data-id="applies-to"><strong>APPLIES TO</strong></h3> <p>Kaseya VSA - R9.3 and above<br>Kaseya Modules - Kaseya Anti-Virus, Kaseya Anti-Malware, Kaseya Cloud Backup, Kaseya Software Management<br>Kaseya Applications - Kaseya Live Connect, Kaseya Remote Control</p> </article> </main>