EasyManua.ls Logo

Citizen IF1-EFX1 - SSL;TLS Secure Communication Features; Necessity and Overview of SSL;TLS Support

Citizen IF1-EFX1
62 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
43
7. SSL/TLS function
7-1. Overview
Necessity of SSL/TLS support
Encrypted communication is necessary to prevent third parties from eavesdropping on, altering, or
spoofing the communication data flowing over the network. The SSL/TLS protocol has become the
standard for encrypted communication infrastructure.
The http protocol is used to send and receive web data and XML data, and https is the SSL/TLS-
compatible version of it. If https is used for communication between the host and the printer, the
printer must also support SSL/TLS.
Overview of SSL/TLS support
A digitally signed certificate (hereafter referred to as a signed certificate) is required for SSL/TLS
encrypted communication. The server stores the signed certificate, and the client side must confirm
or approve the certificate as trustworthy to enable SSL/TLS encrypted communication.
There are two types of signing certificates: those signed by a public certification authority (CA) and
self-signed certificates signed by the private CA.
In the case of self-signed certificates, the client side must certify that the certificate is trustworthy so
that it can communicate without warning. For this purpose, this board has a function to export a file
that contains the unique information for certification.
This board also allows importing a certificate signed by a public CA for more secure communication.
Differences in procedures for preparing signed certificates between this board and a normal server
For SSL/TLS communication, you will need a signed certificate file and a private key file. The general
procedure for preparing these on a normal server is as follows.
1. The applicant requesting the certificate generates a private key.
2. Applicant creates a certificate signing request (CSR) by entering the applicant's identification
information and adding a signature with the applicant's private key.
3. The applicant submits the CSR to either a self-certification authority prepared by the applicant or
an external public CA.
4. The signing authority generates a certificate with its own private key signature attached to the
CSR and returns it to the applicant. (Depending on the submitted certification authority, the
certification becomes either a self-signed certificate or a public CA signed certificate).
5. The applicant stores and places the signed certificate file and his private key file.
This board has an internal private key and self-certification authority, and if you want to use a self-
signed certificate, you only need to enter the identification information in step 2 above. (For the
detailed procedure, refer to 7-3-1 Creating and exporting a self-signed certificate.

Table of Contents

Related product manuals