SystoLOCK components communicate with SystoLOCK Servers over HTTPS. And since HTTPS requires a certificate to be present on the server side, SystoLOCK Server gets one automatically assigned upon installation.
This certificate is, normally, only trusted within your organization and so the Clients have no problems connecting to the Server.
However, once you involve SystoLOCK Companion, the mobile app, things become more complicated.
There is no easy way to to import a trusted root certificate onto a mobile platform. With some, it is just impossible. The manufactures make it a security concern and just do not allow any other roots, except those, shipping with the OS.
SystoLOCK Companion makes it easier to gain trust for 'foreign' certificates, though, if you want your setup to be strict, a publicly trusted certificates on the SystoLOCK Endpoints is a better choice.
A Letsencrypt certificate would be a good enough choice, though you would need to make sure you renew the certificates and have the necessary infrastructure in place. Otherwise, getting an annually-renewable certificate from an external certification authority is another option.
It is clear that certificate considerations are not much different form those for an internet-facing web site.
When you configured your CA (see Installing AD CS), you prepared your HTTP-endpoints, where your CRLs would reside. In order for SystoLOCK Clients to work from outside your network, you need to make sure your CDPs are accessible from outside under the same domain names, as from inside.
For example, if your internal domain name is
example.local and your CRLs are accessible internally via http://crl.example.local, this would not work from outside, since the domain example.local is not public. You would need to choose a properly routable domain name for both internal and external endpoint naming.