Some of the technical content on this site is only available in English.

Requirements and considerations for installing Space


This section contains technical information regarding installation aspects of the "ProAccess Space" software ("Space" hereafter), such as system requirements, connectivity considerations, etc. It is intended for advanced users (like SALTO distributors working in conjunction with IT teams) who have to deal with the software installation process.

You should read this section of the user guide before attempting to install Space.


Space is an access control software designed and produced by SALTO for managing SALTO-manufactured electronic access points, such as standalone electronic escutcheons, cylinders and online IP and RF locks.

In the diagram below, a basic scheme of the Space access control system is depicted, in which the following main components can be appreciated: the Space server machine, the client machines and the SALTO peripherals and access point devices.

System overview

SALTO components diagramSimplified scheme of the Space access control system.

Network component icons

Space server
Space server
Contains the Space service and the SQL database (SQL DB). It manages and controls, in real-time, all SALTO online devices, for example, online doors that are operated using radio frequency (RF) technology. It also processes requests from Space clients.
Space client
Space client
Runs client applications, for example, Space and the Local IO Bridge.
An encoder is an external device that reads and updates keys with access information, writes access permissions onto cards (keys). Encoders can be enabled for USB or Ethernet connections.
Electronic lock
Electronic lock
Allows or denies access, based on the permissions of the presented key. These access point devices can be online or offline and are battery-powered. BLUEnet-enabled locks are equipped with technology that allows online capability whereas standalone locks need to be updated using a PPD device.
Portable Programming Device (PPD)
Communicates information to the lock such as door identification and configuration details. This device, which communicates with the locks using NFC, can also be physically connected to the locks. It is used to initialize and update offline devices. See PPD for more information.
Online control unit
Provides real-time access control. Managed by the Space server, the controller works as both an online IP door and as a card updater. Controllers can be connected to readers using a RS485 bus.
A device intended to be used with access points where online connectivity is needed. Gateways connect to electronic locks enabling offline access points to become connected. A gateway acts as a bridge transferring information using end-to-end encryption to and from the devices behind it to the software.
Nodes and repeaters
Nodes and repeaters
Also known as extenders, repeaters and nodes allow the distance between a gateway and electronic locks to be increased. A node needs to be physically connected to a gateway using an RS485 cable, whereas SALTO BLUEnet repeaters allow for wireless communication.
JustIN Cloud
JustIN Cloud
Acts as a bridge between the Space backend and the JustIN mobile app.
JustIN app
JustIN app
The SALTO JustIN Mobile app allows users to use their phones as a key. It ensures users can receive their key online, anytime and anywhere.

Important note: all the IP devices (that is, control units and card encoders) open a UDP port at 1100 to communicate with the Space server (see also Communication ports and connectivity considerations).

The following sections explain in more detail the hardware requirements and security issues to consider when installing Space in both the Space server and client machines.

Space server

The Space server represents the heart of the system since it hosts both the SALTO database and the Space service.

The Space DB contains data concerning the installation's access control system, such as cardholder permissions, lock audit trail, locking plan, etc.

Currently supported backend DB systems are MS-SQL Server and MS-LocalDB (more on this later).

The Space service, on the other hand, is a Windows NT service developed for the .NET platform. It provides the following two functionalities:

  1. Performs real-time access control by managing and monitoring the online SALTO devices (both access points and SVN updaters).
  2. Attends and processes requests from Space clients and integrators.

The Space service is configured through a setup tool called "ProAccess Space Configurator".

Hardware and system requirements

The hardware and system requirements for the Space server are as follows:

  • Supported operating systems: Microsoft Windows 10, 11, Windows Server 2016, 2019, 2022. Both 32-bit and 64-bit versions.

  • Database1: Microsoft SQL Server 2012, 2014, 2016, 2017, 2019, 2022 and LocalDB. All editions supported, "Express" included.

Also adhere to the system requirements of the database in use. The current system requirements for Microsoft SQL Server Express can be found at the following link:

  • Microsoft SQL Native Client 11.0 (installed by default by the Space installer program).

  • Minimum hardware: it mainly depends on the amount of IP devices (such as Ethernet encoders, gateways and CU5000) that will be managed by the Space software. As a rule of thumb:

    • Installations with less than 300 IP devices: a dedicated machine with at least two 2.5GHz CPUs and 8 GB RAM is required.
    • Installations with more than or equal to 300 IP devices: a dedicated machine with at least four 2.5GHz CPUs and 16 GB RAM is required.

In addition, a 1024×768 high-color 32-bit display (for working with the GUI webapp via browsers) is recommended.

  • .NET framework 4.6.2 or later (included within the installer).

  • Required hard disk space depends on the size of the locking plan and the purgation policy. A minimum of 5 GB is recommended.

  • Machine name resolver (DNS): Space uses machine names (rather than fixed IP addresses) for inter-machine communications. In this regard, a machine name resolver (such as a Domain Name System or DNS) is required to correctly resolve machine names into the corresponding IP address.

  • The date and time of the server machine must be correctly configured before the Space software is started. Otherwise, the performance of the online devices (such as RF locks) might be negatively affected.

  • Required LDAP controls/extensions:

    • If cardholders or software operators are to be imported from your directory service (DS) to the Space DB via LDAP protocol, make sure that the following LDAP control/extension is supported by your DS or LDAP server: "1.2.840.113556.1.4.319". For example, Microsoft's Active Directory is known to support the specified LDAP control, whereas Oracle Directory Server Enterprise Edition (ODSEE) does not seem to support it.

Virtual machine considerations

In principle, the Space service (and its DB) may be installed and executed in virtual machines. What follows are important considerations to bear in mind:

  • Make sure that enough CPU and RAM resources are dedicated. Any latency due to insufficient resources will negatively affect the interactions between the Space service and the online access control devices and end users.
  • In case your host machine is equipped with more than one physical NIC (network interface controller), make sure that all the IP traffic from/to the Space software flows through the same physical NIC (otherwise you may have communication issues with online devices, such as CU5000).
  • If your system is Windows Server 2012 R2 and have communication issues between the Space server and the SALTO IP devices, consider disabling the VMQ (Virtual Machine Queue) feature on NICs. See the following link for further details:

Communication ports and connectivity considerations

The Space service is not an isolated piece of software. On the contrary, the Space service opens several listening ports for those third-party systems interested in requesting access control resources and services (for example, hotel PMS). The other way around also applies, that's to say, the Space service may establish connections to third-party systems in order to get certain data or services from them (for example, MS-SQL Server or the SALTO cloud).

The diagram below shows all the communication ports managed by the Space service. For TCP/IP ports, the arrow symbol indicates the listening port to which connection is established.

Important: please note that all the port numbers for the TCP/IP ports specified in the below diagram are not fixed values but default ones and can be changed to any other value as desired. On the contrary, the UDP port 1100 opened by SALTO peripherals is fixed and cannot be modified.

The table below enumerates all the possible communication ports (and their default value) that may be used by the Space service depending on the integration type.

Connectivity scheme for Space

Connectivity scheme for the Space serviceConnectivity scheme for the Space service - all the provided values for the TCP/IP ports are software configurable.

Ports and connections from and to the Space service

Type of system to communicate withPort type, protocol and configurationDescription
Database management system (MS-SQLServer)- TCP/IP.
- Configurable from the MS-SQLServer software.
- Defaults to 1433 by Microsoft.
MS-SQL Server® allows different types of connection: TCP/IP, named-pipes or through memory.
TCP/IP is the recommended one. As a general rule, its port number defaults to 1433.

In addition, the SQLServer software (more specifically, the "SQLServer Browser") may open a UDP port for allowing discovery of SQL Server instances (as a general rule, it defaults to 1434).
SALTO IP devices (card encoders, control units, gateways, etc.)- UDP port.
- Proprietary protocol.
- Configurable from the software.
- Defaults to a random value between 5000-10000.
The Space software opens a single UDP port to communicate with all the SALTO IP devices. On the other hand, SALTO IP devices open a fixed UDP port in either 1100 (gateways, control units and card encoders v1) or 4433 (encoders v2).
SALTO frontend (browsers using the Space webapp)
- TCP/IP port in listening mode.
- HTTP(S) protocol.
- Configurable from the software.
- Defaults to 8100.
This is the endpoint of the embedded web server. Browsers must connect to this port in order to access the Space web pages.
The default URL is: http://(machine_name):8100 (note: HTTPS strongly recommended).
Space clients- TCP/IP port in listening mode.
- HTTP(S) protocol.
- Configurable from the software.
- Defaults to 8102.
Certain Space clients, such as the Space webapp or the LocalIOBridge utility, connects to this port for getting real-time notifications.
SALTO frontend clients (graphical-mapping)- TCP/IP port in listening mode.
- SOAP protocol.
- Configurable from the software.
- Defaults to 8099.
This port is only used by the graphical-mapping software.
Hotel PMS: Oracle Hospitality PMS (FIAS) protocol- TCP/IP.
- Oracle Hospitality protocol.
- Configurable from the software.
The Space service may establish a TCP/IP connection to the hotel's PMS.
Hotel PMS: Industry Standard protocol- TCP/IP port in listening mode.
- Industry Standard protocol (proprietary).
- Configurable from the software.
The Space service may open a listening TCP/IP port to which the hotel's PMS is connected. Serial RS232 connection is also supported.
SHIP clients (SHIP protocol)- TCP/IP port in listening mode.
- SHIP protocol (proprietary)
- Configurable from the software.
The Space service may open a listening TCP/port to which SHIP clients connects for requesting access control services.
SHIP host (SHIP protocol)- TCP/IP.
- SHIP protocol (proprietary).
- Configurable from the software.
The Space service may establish a TCP/IP connection to the SHIP Host to request access permissions.
Schindler elevators: "PORT" protocol- TCP/IP
- Schindler's "PORT" protocol
- Configurable from the software
The Space service may establish a TCP/IP connection to the Schindler server.
Thyssenkrupp- UDP port.
- Thyssenkrupp protocol (proprietary).
- Listening ports: 8039 & 8040.
- Destination ports: 8038 & 8041.
- A dedicated NIC for the elevator network is required.
Thyssenkrupp listens for the Space service heartbeats on 8038.
The Space service broadcasts heartbeats on 8038.
Thyssenkrupp transmits unicast heartbeats on 8039.
The Space service listens for Thyssenkrupp heartbeats on 8039.
Thyssenkrupp transmits data messages to the Space service on 8040.
The Space service listens for Thyssenkrupp data messages on 8040.
Thyssenkrupp listens for the Space service data messages on 8041.
The Space service transmits data messages to Thyssenkrupp on 8041.
HTTP(S) webhook- HTTP(S) protocol
- Configurable from the software
The Space service may establish an HTTP(S) connection to a third-party endpoint for sending notifications in real time
Event stream- TCP/IP (client mode) or UDP
- Configurable from the software
The Space service may connect to a third-party machine to which real-time audit trail events are to be sent using a proprietary protocol.
Important note: consider using the "webhook" functionality (see above) rather than the "event stream" one as the former is more standard, flexible, and secure.
Transact's event grid- HTTPS protocol
- Configurable from the software
The Space service may establish a websocket connection to a Microsoft's Event Grid endpoint for receiving Transact commands for DB synchronization.
- REST protocol
- Access to the internet required
The Space service may establish connections with the SALTO cloud located at the following URLs:
- In general: https://*
Note that connections to the SALTO cloud are only needed when using mobile keys through the JustIN Mobile app.
- Destination port: 4433
The Space service may establish TCP/IP (TLS) connections to Ruckus controllers on port 4433 to send communications to SALTO locks through the Ruckus controllers.
- Destination ports: 80 & 443
The Space service may establish websocket connections to communicate with Gantner Gx7 ontrollers.

Some important considerations to bear in mind regarding connectivity:

  • Make sure that the MS-Windows Firewall (or any other similar program with blocking capability, such as anti-virus) does not block the Space service. If necessary, add a new exception entry in the Windows Firewall to avoid blocking the Space service.
  • Some firewalls are configured to automatically shut down TCP/IP connections that have a long period of inactivity, resulting in communication problems within the system. In order to avoid communication problems, make sure the firewall in place does not automatically shut down TCP/IP connections when the inactivity is shorter than:
    • 5 minutes for websocket connections.
    • 105 seconds for the Oracle Hospitality PMS (FIAS) protocol.

Space has been designed for LAN environments only. Do not expose it directly to the internet since it is not a secure environment and can expose the software to potential security risks, such as DoS (denial of service) attacks. You should keep the software within a secure network environment to ensure its safety and reliability. If you need to remotely access the Space web pages through the internet, use a VPN.

  • Space embeds its own web server. No external web server (such as MS-IIS or Tomcat) is required.
  • Support for HTTP proxy: you may configure the Space software so that all the HTTP communications (for instance, to the SALTO cloud) are forwarded to a proxy server.
  • Connections to the SALTO cloud (that is, https://* are only needed if you are to use digital keys through the JustIN Mobile app.
  • If you need to receive real-time notifications, consider using the "webhook" functionality rather than the "event stream" one: the former is more standard, flexible and secure than the latter.

Permission considerations

What follows are the permissions required for the Space software to work:

  1. The Windows account under which the Space service is running (Space account herein) must have total access to the Space DB. The easiest way is to make that Windows account be a member of the DB_OWNER role within the Space DB.
  2. The Space account must have total access to the Space root folder (C:\SALTO\ProAccess Space by default) and below. In addition, any other working folder (for example, used for exporting or importing files) must be also accessible.
  3. In the last instance, in case HTTPS is to be used, the Space account must have access to the corresponding certificate.

The good news is that the setup program manages all the above settings for you out-of-the-box. Note that administrator privileges are required to launch the setup process.

In case of a fresh installation, the default Windows account for running the Space service will be the low-privileged built-in account "Network Service". Well, more precisely, its virtual counterpart:

NT SERVICE\ProAccessSpaceService

On the contrary, in case of a software upgrade, the setup program will be respectful and keep unchanged the current account of the Space service.

This default configuration and other settings may be modified at any time by means of the service configuration tool named "ProAccess Space Configurator". Note, however, that should you change the Windows account of the Space service to another one, you will need to manually grant it permissions to all the resources mentioned above, that is, the Space DB, the Space folders and the HTTPS certificate.

Other security considerations to bear in mind are as follows:

  • It is recommended to use a passwordless account, such as machine built-in accounts like "Network Service". Otherwise, the Space service will stop working on password expiration.
  • In order to use the secure version of HTTP (that is, HTTPS), you will first need to specify a valid certificate (use the "Space Configurator" to select one among the registered certificates within the server machine). Note that the selected certificate must also be valid in the client machines in order to: 1. avoid the "untrusted connection" warning message shown by the browser, 2. browsers to receive real-time notifications (such as door openings) from the server.
  • Further considerations when the SALTO "Graphical Mapping" is used: the Space service will accept connections from the GM software only if it is working under trusted user sessions. In the case of a Windows domain environment, trusted users are members of the same Windows domain as that of the Space server: if the user is not regarded as a valid member by the domain controller, the client (that's to say, graphical mapping) will not be able to connect to the service.

If you do not have a Windows domain environment but a workgroup environment, you will need to create the corresponding user within both the Space server and the client station to have trusted connections.

Database considerations

There should be one, and only one, instance of the Space DB in the premise.

For the sake of performance, it is strongly recommended that both the Space DB and service be installed in the same server machine. Otherwise, any latency between both components will have negative impact on all the interactions with peripherals and frontend sessions.

The Space service may work with two types of DB systems: MS-SQL Server or MS-LocalDB. In the following paragraphs some considerations are explained concerning both DB types.


LocalDB is a minified version of MS SQL Server that offers a fast, zero-configuration installation. It is suitable for small installations (in general, where a single machine is used).

One restriction regarding LocalDB is that only connections from the local machine are accepted. This is not actually an issue since browsers in the client machines do not connect directly to the DB but to the Space service2.

MS SQL Server

What follows are the most important considerations to bear in mind regarding MS-SQL Server database:

  • As stated above, it is strongly recommended to have both the Space DB and software installed in the same machine.
  • Make sure that the Space account is a member of the DB_OWNER role within the Space DB.
  • Make sure that the compatibility level of the Space DB is SQL2005 or higher.
  • Consider enabling SSL connection in the MS-SQL Server instance so that communications between the DB and the Space service are encrypted. This is recommended when the DB is not located in the same machine as the Space service. See Appendix C for further details.

In principle, the setup programs manages the first three settings above for you out-of-the-box.

Best security practices

What follows is a series of best practices for a secure system:

  1. Make sure that the operating system in your server machine and workstations are up-to-date with the latest security patches. Of course, avoid using Windows OS that has been deprecated and for which no more support is provided by the vendor. The same applies for the MS-SQL Server software used for data storage.
  2. Use a low-privileged Windows account for running the Space service. For example, NT SERVICE, or better, NT SERVICE\ProAccessSpaceService (by default in the setup program).
  3. Keep the Space DB isolated by not granting any other user access permission to it. Only the Space service (aside the system admins) should have access to the Space DB.
  4. For the sake of performance as well as security, it is strongly recommended that both the Space DB and service be installed in the same server machine.
  5. In the MS-SQL Server, enable SSL for the DB connections. This is important when both the DB instance and the Space service are not located in the same machine.
  6. Use secure HTTP (HTTPS) when connecting client browsers to the Space web server. Note that configuration of HTTPS is not easy and requires support from IT staff.
    • Use a Certificate Authority (CA) signed certificate. Self-signed certificates should be used for testing purpose only, never for production environments.
    • HTTPS uses SSL/TLS protocols under the hood to provide privacy and data integrity between two parties. There are several SSL/TLS versions but the only one currently supported by the Space software is 1.2. See Appendix A for further details.
    • Behind the scenes, cipher suites, which are sets of instructions that enable secure network connections through SSL/TLS, provide a set of algorithms and protocols required to secure communications between clients and servers. Although there are several cipher suites in existence, the only ones currently supported by Space are the following:
  7. If you need to receive real-time notifications from the Space service, it is strongly recommended to use the HTTPS-based webhook functionality rather than the "event stream" functionality, as the former is more standard, flexible and secure.
  8. If Space authentication is used, make sure an appropriate password policy is enabled (for example, passwords letters, numbers and symbols). You can also consider using LDAP authentication for logging in to the Space software.
  9. For a more secure login, it is recommended to activate the two-factor authentication (2FA) feature3.
  10. Make sure also that the auto-logoff feature is enabled so that the user session is automatically logged off after inactivity is detected for the specified amount of seconds.
  11. Back up the Space database on a regular basis (daily at least).This is essential for disaster recovery, business continuity and information security. It is strongly recommended to store the copies off-site.
  12. Do not expose Space directly to the internet. As it is known, the internet is not an entirely secure environment and can expose the software to potential security risks. Therefore, keep the software within a secure network environment to ensure its safety and reliability. If you need to access Space from remote points through the internet, use VPN instead.

Client machines

Client machines just need a web browser to start interacting with the Space service. There is no need for any extra software except when you need to work with USB devices. The following subsections explain in more detail all the considerations regarding client machines.

The Space webapp

Web browsers are the window from which to interact with the SALTO Space software. The default URL to connect to is:


where {{host_machine_name}} is the name of the server (in which the Space service is running).

Note that you may customize at any time (by means of the configurator utility) this URL and change it, for example, to another port number or make it more secure by selecting HTTPS4 .

What follows are the system requirements for the Space frontend:

  • Web browser: any browser that complies with HTML5. For example: Chrome, Firefox, Edge, Safari, etc. Internet Explorer is also supported though not recommended due to its low performance. No Silverlight required.
  • Hardware: 1-GHz (or higher) CPU and 4 GB of RAM.
  • Operating systems: if your client machine is to manage USB devices (such as PPD or card encoders), then Windows is required since the Bridge program (explained in the next section) only supports Windows machines (Windows 8, 8.1, 10, 11, Server 2012, Server 2016 or higher). Otherwise, if no USB device is to be connected, then any operative system can be used.
  • Adobe Flash Player plugin for the webcam: if you are to use a webcam for making photos to cardholders, chances are you may need to have the Adobe Flash Player plugin installed within your browser. The following table indicates whether you will need the mentioned plugin depending on both the type of browser and the type of http connection.
Browser (Windows)HTTP connectionHTTPS connection
Internet ExplorerFLASH plugin requiredFLASH plugin required
SafariNot supportedNo FLASH plugin required
FirefoxNot supportedNo FLASH plugin required
Edge ChromiumNot supportedNo FLASH plugin required
Edge LegacyNo FLASH plugin requiredNo FLASH plugin required
ChromeNot supportedNo FLASH plugin required

The webcam may require the Adobe Flash Player plugin depending on the type of browser and HTTP connection.

One final consideration to bear in mind is that the Space frontend has been designed for desktop machines. Although it may work OK in iOS or Android mobile devices, the UX experience in these types of devices is far from optimal.

The "bridge" program between the Space service and USB devices

Web browsers impose multiple restrictions (due to security reasons) to web applications when it comes to use local system resources, such as USB ports. This is why the Space webapp cannot get access to USB ports, and thus, to the SALTO USB devices attached to them (like PPDs or card encoders).

SALTO provides a solution for this problem: the so-called "Local IO Bridge" program. This is a tiny Windows NT service that must be installed in only those client machines to which SALTO USB devices must be connected.

The "Local IO Bridge" program can be installed from the Space webapp (that is, from the browser). You can also find a copy of this program under the ..\dist folder in the server.

The "Local IO Bridge" program, as its name implies, works as a "communication bridge" between the Space service and the USB device.

This is accomplished firstly by establishing a TCP/IP connection to the Space service and secondly by opening the USB port to which the SALTO device is connected. Once both endpoints are open, the "Local IO Bridge" does nothing more than retransmit messages from one endpoint to the other. The final result is that USB devices are being remotely controlled by the Space service in the server.

In summary, what follows are the main considerations for the "Local IO Bridge" program:

  • The installer of the "Local IO Bridge" program can be downloaded from the Space webapp (from the web browser). A copy of this program can also be found in the ..\dist folder in the server. Installation is simple and straightforward.
  • The "Local IO Bridge" requires .NET framework 4.0 or later (the installer will automatically install it for you if it is missing). The operating system must be Windows 8, 8.1, 10, 11, Server 2012, Server 2016 or higher.
  • The "Local IO Bridge" can be installed from the command line in silent mode, that is, in an unattended mode5. This helps the automatized deployment of the program in client machines. For this purpose, you must use both the "quiet" and the "installDir" switches, as shown in the example below:

C:\setup_saltolocaliobridge.exe -quiet -InstallDir= "C:\SALTO\ Local IO Bridge"

where the "installDir" switch must be followed by the path of the destination folder.

  • Every time a communication process is needed between the local USB device and the Space service in the server (for example, for reading a card at a SALTO card encoder), a TCP/IP connection is established from the "Local IO Bridge" program to the server. The default target TCP/IP port is 8102 though it can be configured to another value if desired. See also Ports and connections from and to the Space service.
  • In addition, the "Local IO Bridge" program opens two listening ports to which the Space webapp (running within the browser) is connected. Their port numbers can be any value within the range 50000-51000.
  • Make sure that the "Local IO Bridge" program is running (as a Windows NT service) before working with USB SALTO devices. The Space webapp will show you a warning message if it detects that the "Local IO Bridge" program is not available.

Ports and connections from and to the "Local IO Bridge" service

Type of system to communicate withPort type, protocol and configurationDescription
SALTO devices: USB or RS232- USB, RS232
- Configurable from the software
The "Local IO Bridge" service opens the required USB (or RS232) port in order to communicate with the attached SALTO device.
SALTO Space service- TCP/IP.
- HTTP(S) protocol
- Defaults to port 8102
- Configurable from the software
The "Local IO Bridge" service establishes a connection to the Space service every time a communication process with a USB device is needed (for example, read a card in the encoder).
SALTO Space webapp- Two TCP/IP ports in listening mode.
- HTTP and HTTPS protocol
The Space webapp (within the browser) connects to these two ports. This allows the webapp to ask the "Local IO Bridge" for port information and status, and perform actions on the USB devices.

Appendix A: Security protocols and cipher suites for HTTPS

HTTPS uses SSL (Secure Socket Layer) or its newer version TLS (Transport Layer Security) under the hood to provide privacy and data integrity between two parties. The Space software supports SSL/TLS by means of a Microsoft library called Schannel.dll, which is part of the Windows platform (including Windows 10, 11, Server 2012 R2, Server 2016, etc.).

The Schannel library supports several versions of SSL/TLS (including SSL v2.0, SSL v3.0, TLS v1.0, TLS v1.1, TLS v1.2 and TLS 1.3) as well as several cryptographic algorithms.

Irrespective of the SSL/TLS versions that the Schannel library supports, from version 6.7 of Space onwards, the only supported version of TLS is 1.2. Thus, you should configure the Schannel library to use TLS 1.2.

In principle, the Schannel library will automatically choose the best protocol and cryptographic algorithm depending on the capabilities of the client and server. However, you can configure Schannel.dll to control the use of specific version of the SSL/TLS protocol and cipher suites. This configuration is done by setting certain registry keys in the Windows registry as explained in the following Microsoft article:

Note that this security configuration is machine-wide in scope and cannot be configured on a per-application basis. This means that changes in the Schannel configuration will affect all the applications using the Schannel library.

Direct manipulation of the registry keys is not easy. A more comfortable way to configure the security options is to use a tool from the "Nartac Software" company called IISCrypto:

IISCrypto is a free GUI tool (see screenshots below) created to simplify enabling and disabling various protocols and cipher suites.

Screenshot from IISCrypto cipher suite tool

Screenshot from IISCrypto cipher suite tool

Appendix B: Provision of certification for HTTPS

Provision of HTTPS certifications in LAN environments is not an easy task and should be performed by trained IT staff. This section is by no means an exhaustive manual for creating and installing certificates for the Space HTTPS endpoint but rather a simplistic guide. The picture below shows the main steps:

  1. Create a corporate certificate authority (CA). If you don't already have one, start by creating your "root" CA (it will be a self-signed certificate). Specify the values for fields like expiration, keys, hashing algorithm, etc.
  2. Distribute the created corporate CA among client machines. The certificate must be added to the trusted root certification authorities store.
  3. Create the Space certificate and sign it with the corporate CA. The field that matters most within the Space certificate is the "Common Name". That is where you supply the hostname of the Space server ("Server01" in the example)
  4. Install the Space certificate in the Space server. If necessary, grant the Windows account of the Space service access permission to the certificate.
  5. Configure the Space software (with the configurator tool) to use the Space certificate.

Provision of certification for HTTPSProvisioning of HTTPS certifications

Appendix C: Configure MS-SQL Server to force encrypted connections

What follows is the way to configure the server to force encrypted connections with DB clients (see pictures below):

  1. In SQL Server Configuration Manager, expand SQL Server Network Configuration, right-click Protocols for {{server_instance}}, and then select Properties.
  2. In the Protocols for {{instance_name}} Properties dialog box, on the Certificate tab, select the desired certificate from the drop-down for the Certificate box, and then click OK.
  3. On the Flags tab, in the ForceEncryption box, select Yes, and then click OK to close the dialog box.
  4. Restart the SQL Server service

If no certificate has been provisioned in step 2, SQL Server generates a self-signed certificate, which could be more than enough when both the Space service and DB are located in the same machine. The most secure option is of course to use a verifiable certificate, although it involves more complex management.

In case you provide a verifiable certificate, the SQL Server Service Account must have read permissions on the certificate used to force encryption on the SQL Server. For a non-privileged service account, read permissions will need to be added to the certificate. Failure to do so can cause the SQL Server service restart to fail.

Further details:


  1. As of this writing, and according to Microsoft, MS SQL Server cannot be installed on a Windows Server domain controller (see ↩︎

  2. As of this writing, the Graphical Mapping software does establish a direct connection to the Space DB. Thus, it is no good installing the Graphical Mapping software in a machine other than the server. Otherwise, use a MS-SQL Server database instead. ↩︎

  3. You may use any 2FA mobile app that supports the standard algorithm RFC 6238 for the generation of time-based one-time passcodes. For instance, Google Authenticator, Microsoft Authenticator, Twilio's Authy, etc. ↩︎

  4. Make sure that the certificate used by the Space service is also valid in the client machine. Otherwise, the browser will show you a warning message ("untrusted connection"). What is worse, the client machine will not be able to receive real-time notifications from the server (such as door openings in the monitoring window). ↩︎

  5. The "InstallDir" switch (used to specify the destination folder) is supported in Space version or earlier. ↩︎

SALTO SYSTEMS, S. L. uses third-party data storage and retrieval devices in order to allow secure browsing and gain a better understanding of how users interact with the website in order to improve our services. You can accept all cookies by clicking the "Accept cookies" button or reject their use by clicking the "Reject cookies" button. For more information, visit our Cookies Policy