What certificates do I need?
Encryption can be used for sending print jobs from ThinPrint Engine to ThinPrint Client. It uses Transport Layer Security (TLS 1.x) or Secure Socket Layer (SSL 3.0). This requires three different certificates.
- for client machines:
- a certificate that serves for server authentication
- for ThinPrint servers:
- a certificate that serves for server authentication
- the accompanying issuer certificate, which originates from a root or intermediate certification authority
The server certificates are signed by the issuer certificate (from a root or intermediate certification authority). A server certificate is installed onto the computer or the ThinPrint Hub on which ThinPrint Client is running. Another server certificate and the issuer certificate are installed on the ThinPrint server. Encryption is set for each ThinPrint Port.
A certification authority is set up on the certification server and a root certificate is created. Then, server certificates can be requested from the certification server.
The root certificate can be obtained, either by download or importing, and then distributed to all servers in a farm.
You can set up your own certification server or else purchase certificates from an official root certification authority. Root certificates from recognized certificate authorities are, in most cases, already integrated into the operating system and do not have to be created or imported. It is only necessary then to request server certificates from the relevant provider.
Encrypted printing by exchanging certificates
Print data is compressed and then encrypted and sent from the ThinPrint Engine to the ThinPrint Client – regardless of the protocol in use (TCP/IP, ICA or RDP). In other words, the data is encrypted by ThinPrint independently of and in addition to (ICA/RDP) virtual channel encryption. ThinPrint encrypts the individual print jobs, whereas terminal sessions encrypt the (ICA/RDP) channel. ThinPrint encryption especially makes sense where data is sometimes sent via TCP/IP, as in when using a central print server. Print data is encrypted by the ThinPrint server and decrypted by the ThinPrint Client.
Encryption prevents:
- third parties from spying
- print data from being sent to the wrong recipient
Print data should not be sent to the wrong client. That means that the client machine must prove that it is authorized to receive print data from the server. This is ensured by the certificate, which is signed by the issuer certificate.
The following illustration depicts the communication between server and client (called handshaking) that precedes the transmission of encrypted print data. Please note that this is a simplified illustration of the communication; the main focus is on the use of certificates.
server-client communication flow for sending encrypted print data (simplified illustration)
The server notifies the client that an encrypted print job is waiting. The client answers and confirms whether it can accept encrypted data and which cryptographic algorithm it understands (e. g., TLS 1.2). The server then sends its server certificate and its own list of the algorithms it understands. The server certificate of the ThinPrint Engine is only necessary for the so-called handshake, whereby client and server authenticate each other. In addition, the server demands the certificate from the ThinPrint Client. The client sends its certificate with the public key. The server checks whether this certificate has been signed by the issuer or root certificate.
The server now creates a session key. This is a temporary key that is created anew for each print job and loses its validity once the print data has been delivered. This key is composed of different, random numbers created by the client and server. The server encrypts this session key with the public key that it sent to the client. The client, in turn, can decode the session key using its private key (asymmetric encryption). The entire print data transmission is now encrypted with the new session key. This is already begun with the announcement of a pending packet and the header information.
Where do I find suitable certificates?
There are three ways to get the right certificates:
- Create the certificates yourself (described below).
- Obtain certificates from a certification authority.
- Request your own certification authority.
Certificates can be purchased from one of the recognized certificate authorities. For larger companies, it might be more economical to request your own (sub) certification authority so that additional certificates can be created and signed independently.
We recommend the first option; namely, creating the certificates yourself. In addition to being less expensive, it is also safer because a certificate that is already found in the browser’s root directory could pose a security threat. Within the currently familiar operating systems, this directory contains several dozen certificates by default. Before establishing a secure connection, the server first checks whether it has signed the client certificate. Because all clients that have received a certificate signed by this certification authority meet this criterion, an unauthorized client may also receive data from a foreign server. To do so though, this client must also be configured to a port that sends encrypted print data. Rerouting print data to an incorrect client would also require server manipulation.
For this reason, we recommend creating certificates yourself.
How do I create certificates?
The certificates are based on the X.509 norm. There are various tools that can be used to create them, such as OpenSSL or the certificate services from Microsoft. Create both a root certificate and a server certificate. The latter, usually available as a .pem or .der file (with OpenSSL), must be signed by the root certificate and then converted to .p12, .pfx, or .crt or another file format that is understood by Microsoft. Specify the encryption depth when creating the certificate).
Then, similarly to the first server certificate, you generate as many more certificates as you need for your environment, for example one certificate per server and one general certificate for all client machines. The more certificates you use, the more secure the transmission. For ThinPrint, you need a minimum of two certificates: the issuer and/or root certificate as well as a server certificate, which must be signed by the issuer certificate, and which you can use on the ThinPrint servers as well as on the clients.
Note! In a productive environment we recommend to increase safety by:
- creating an individual certificate for each ThinPrint server and/or ThinPrint Client
- requesting the certificates directly on the server or client from the certificate server, and to deactivate the option Mark keys as exportable
- using a key length of at least 2048
- using the hash algorithm SHA256 or a higher one.
What key length is considered safe?
When you create certificates yourself or purchase them, the encryption depth influences the security. The longer the key, the more work it takes for unauthorized people to decode it.
TLS and SSL encryption combine symmetric and asymmetric encryption methods, which require different key lengths. Symmetric means that sender and recipient both use the same key; with asymmetric encryption, they use different ones.
The session key with which print data is encrypted is a symmetrical key. Here, a key length of 128 is assumed to be safe.
The session key itself is encrypted asymmetrically and sent with the print data. For this transmission, a key length of 2048 is assumed to be safe. This message is decoded with the client’s private key, which was saved in the certificate store on the client machine when the certificate was created.