Information processing device, control method thereof, and program

Abstract

To solve a problem in which it takes a lot of time and effort to manually add, update, and set digital certificates for a large number of information processing devices that handle digital certificates when there are the information processing devices.SOLUTION: An information processing device that communicates using digital certificates transmits a request for issuing a digital certificate to an external device, and receives the digital certificate from an external device in response to the issuance request. Then, the digital certificate stored in a storage unit is updated with the received digital certificate. The issuance request is transmitted to the external device at timing based on the date for updating the digital certificate set via a screen and the interval for updating the digital certificate.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present invention relates to an information processing apparatus, a control method thereof, and a program. [Background technology]

[0002] Personal computers (PCs) connected to networks in offices, etc., and mobile terminals owned by individuals use public key certificates to ensure secure communication and authentication when communicating with external servers.

[0003] Furthermore, recent multifunction devices do not simply print and transmit images, but also have the function of storing image data in the multifunction device and providing file services to PCs. As a result, multifunction devices are beginning to play the role of information processing devices similar to other server devices on a network. In order to maintain a safe and secure office environment while these information processing devices are used on a network, it is necessary to perform authentication using digital certificates for communication. Generally, the identification and authentication of a secure network is realized by the technology of public key infrastructure (PKI) using these digital certificates (see Non-Patent Document 1).

[0004] For example, when an information processing device becomes a client, the server public key certificate obtained from the server and the certificate authority certificate of the certificate authority that issued the server public key certificate can be obtained to verify the authenticity of the server. In addition, the server can verify the authenticity of the client by providing the client public key certificate of the information processing device to the server. When the information processing device becomes a server, the client can verify the authenticity of the information processing device by distributing the server public key certificate of the information processing device to the client that connects to the server. Thus, electronic certificates have been used as an important technology for authenticating and identifying network communications between information processing devices. For example, communication protocols used in such communications include SSL, TLS, IEEE802.1X, IPSEC, and the like.

[0005] Since this digital certificate needs to be stored and held in the information processing device, conventionally, the digital certificate issued by the certification authority was manually stored in the storage of the information processing device by the user. This storage method is performed by downloading it from the certification authority that issues the digital certificate, copying it from external storage such as USB memory, or copying the digital certificate received by e-mail or the like to a specified folder.

[0006] Depending on the purpose of communication, a different electronic certificate may be used for each information processing device. For example, in IEEE802.1X, it is common for an individual electronic certificate to be stored for each information processing device in order to authenticate a client. In addition, this electronic certificate has an expiration date, and when the expiration date is reached, communication using the electronic certificate becomes impossible. Therefore, it is necessary to update the electronic certificate in the device when the expiration date is reached or immediately before the expiration date. Furthermore, when using electronic certificates, it is necessary to manually configure for each information processing device which electronic certificate to use for which communication purpose, such as TLS or IEEE802.1X, is to be used. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] RFC3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework Summary of the Invention [Problem to be solved by the invention]

[0008] However, when there are a large number of information processing devices that handle digital certificates, it takes a lot of time and effort for the user to manually add, update, and set digital certificates for those devices.

[0009] An object of the present invention is to solve the problems of the prior art.

[0010] An object of the present invention is to provide a technique for facilitating the addition and updating of electronic certificates in an information processing device. [Means for solving the problem]

[0011] In order to achieve the above object, an information processing device according to one aspect of the present invention has the following configuration. An information processing device that performs communication using an electronic certificate, a transmitting means for transmitting a request for issuing a digital certificate to an external device; a receiving means for receiving an electronic certificate from the external device in response to the issuance request; an updating means for updating the electronic certificate stored in the storage unit with the received electronic certificate, The transmitting means transmits the issuance request to the external device at a timing based on the date for updating the electronic certificate and the interval for updating the electronic certificate, which are set via a screen. Effect of the Invention

[0012] According to the present invention, it is possible to easily add or update an electronic certificate in an information processing device. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 is a diagram for explaining a network configuration according to a first embodiment of the present invention. [Diagram 2] FIG. 2 is a block diagram illustrating the hardware configuration of the multifunction peripheral according to the first embodiment. [Diagram 3] FIG. 2 is a block diagram for explaining software modules included in the multifunction peripheral according to the first embodiment. [Figure 4] FIG. 11 is a sequence diagram for explaining the overall processing flow, from initial settings related to an electronic certificate issuance request, display of electronic certificate information, issuance request and reception, reboot, and reflection of the electronic certificate, in the system of the first embodiment. [Diagram 5] 5A is a flowchart illustrating the process of obtaining a list of key pairs and electronic certificates and creating display data at S402 in FIG. 4 by a multifunction peripheral according to a first embodiment; and FIG. 5B is a flowchart illustrating the process when the multifunction peripheral according to the first embodiment receives a request to display detailed information from a PC. [Figure 6] 5 is a flowchart for explaining a process of setting a connection to a certification authority / registration authority in S407 of FIG. 4, performed by the multifunction peripheral according to the first embodiment. [Figure 7] 5 is a flowchart for explaining the CA certificate acquisition and registration process shown in S412 to S416 in FIG. 4 by the multifunction peripheral according to the first embodiment. [Figure 8] 5 is a flowchart for explaining the certificate issuance request / acquisition process from S419 to S424 in FIG. 4 by the multifunction peripheral according to the first embodiment. [Figure 9] 5 is a flowchart for explaining the process of restarting the multifunction peripheral 100 from S424 to S427 in FIG. 4, performed by the multifunction peripheral according to the first embodiment. [Figure 10] FIG. 4 is a diagram showing an example of a web page screen of an RUI displayed on a PC according to the first embodiment. [Figure 11] FIG. 4 is a diagram showing an example of a web page screen of an RUI displayed on a PC according to the first embodiment. [Figure 12] FIG. 4 is a diagram showing an example of a web page screen of an RUI displayed on a PC according to the first embodiment. [Figure 13] FIG. 4 is a diagram showing an example of a web page screen of an RUI displayed on a PC according to the first embodiment. [Figure 14] FIG. 4 is a diagram showing an example of a web page screen of an RUI displayed on a PC according to the first embodiment. [Figure 15] FIG. 4 is a diagram showing an example of a web page screen of an RUI displayed on a PC according to the first embodiment. [Figure 16] FIG. 13 is a diagram showing an example of detailed information of an electronic certificate displayed on a PC according to the first embodiment. [Figure 17] 4 is a conceptual diagram of a database of detailed information on key pairs and electronic certificates managed by a key pair and certificate management unit of the multifunction peripheral according to the first embodiment. FIG. [Figure 18] FIG. 11 is a diagram showing an example of an electronic certificate renewal reservation setting screen of the multifunction peripheral according to the second embodiment. [Figure 19] 10 is a flowchart for explaining a process performed when the multifunction peripheral according to the second embodiment executes an automatic update function for an electronic certificate based on an update reservation setting for the electronic certificate. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, an embodiment of the present invention will be described in detail with reference to the attached drawings. Note that the following embodiment does not limit the present invention according to the claims, and not all of the combinations of features described in the present embodiment are necessarily essential to the solution of the present invention. Note that a multifunction peripheral (digital multifunction peripheral / MFP / Multi Function Peripheral) will be described as an example of an information processing device that uses and manages electronic certificates according to the embodiment. However, the scope of application is not limited to multifunction peripherals, and any information processing device that can use electronic certificates will suffice, and the scope of application is not limited to multifunction peripherals.

[0015] [Embodiment 1] FIG. 1 is a diagram illustrating a network configuration according to a first embodiment of the present invention.

[0016] The multifunction device 100 having a printing function can transmit and receive print data, scanned image data, device management information, and the like to and from other information processing devices via a network 110. The multifunction device 100 also has a function for performing encrypted communication such as TLS, IPSEC, IEEE802.1X, and holds a public key pair and an electronic certificate used for the encryption processing. Here, the multifunction device 100 is an example of an image forming device, and the image forming device is not limited to this, and may be a device having a single function of a facsimile machine, a printer, or a copier, or a device having a combination of these functions. A multifunction device 101 is also connected to the network 100, and this multifunction device 101 has the same functions as the multifunction device 100. The following description will be mainly focused on the multifunction device 100, but the exchange of electronic certificates may also be performed for a plurality of multifunction devices.

[0017] The certificate authority / registration authority 102 has a function of a certificate authority (CA) that issues digital certificates, and a function of a registration authority (RA) that accepts requests for issuing digital certificates and performs registration processing. That is, the certificate authority / registration authority 102 is a server device that has a function of distributing CA certificates and issuing and registering digital certificates via a network 110. In the first embodiment, the network 110 uses the Simple Certificate Enrollment Protocol (SCEP) as a protocol for this network 110. An information processing device such as the multifunction peripheral 100 uses this SCEP to communicate with the certificate authority / registration authority 102 via the network 110 to request and obtain an electronic certificate. The multifunction peripheral 100 according to the first embodiment has a web server function and exposes a web page type RUI (Remote UI) function on the network 110 that can execute processes for requesting and obtaining an electronic certificate.

[0018] When the certification authority / registration authority 102 receives an issuance request for an electronic certificate from another information processing device via the network 110, it issues and registers the electronic certificate based on the issuance request, and transmits the issued electronic certificate as a response to the issuance request. In the first embodiment, the functions of the certification authority and the registration authority are realized by the same server device, but the certification authority and the registration authority may be realized by different server devices, and there is no particular limitation. In the first embodiment, SCEP is used as a protocol for requesting and acquiring an electronic certificate, but any protocol having equivalent functions may be used, and there is no particular limitation to the present invention. For example, CMP (Certificate Management Protocol) or EST (Enrollment over Secure Transport) protocol may be used.

[0019] The PC 103 is a personal computer that is equipped with a Web browser function, and is capable of viewing and using HTML documents and Web sites published by information processing devices connected to the network 110 .

[0020] Next, an overview of the process of obtaining and updating a digital certificate according to the first embodiment will be described.

[0021] The administrator of the multifunction device 100 uses a web browser installed in the PC 103 to connect to a web page published by the multifunction device 100 to request and acquire an electronic certificate, and makes settings and gives instructions for requesting and executing the process to acquire the electronic certificate. The multifunction device 100 requests the certification authority / registration authority 102 to acquire a CA certificate by SCEP and issue an electronic certificate in accordance with the settings and instructions given by the administrator. The multifunction device 100 also acquires the electronic certificate issued by the certification authority / registration authority 102 and included in the response to the request to issue the electronic certificate, and makes settings for using the acquired electronic certificate in the multifunction device 100.

[0022] Next, the hardware configuration of the multifunction peripheral 100 according to the first embodiment will be described.

[0023] FIG. 2 is a block diagram illustrating the hardware configuration of the multifunction peripheral 100 according to the first embodiment.

[0024] The CPU 201 executes the software program of the multifunction device 100 and controls the entire device. The ROM 202 is a read-only memory that stores the boot program and fixed parameters of the multifunction device 100. The RAM 203 is a random access memory that is used to store programs and temporary data when the CPU 201 controls the multifunction device 100. The HDD 204 is a hard disk drive that stores system software, applications, and various data. The CPU 201 executes the boot program stored in the ROM 202, expands the program stored in the HDD 204 into the RAM 203, and controls the operation of the multifunction device 100 by executing the expanded program. The network I / F control unit 205 controls the transmission and reception of data to and from the network 110. The scanner I / F control unit 206 controls the reading of documents by the scanner 211. The printer I / F control unit 207 controls the printing process by the printer 210. The panel control unit 208 controls a touch panel type operation panel 212, and controls the display of various information and the input of instructions from the user. A bus 209 interconnects the CPU 201, ROM 202, RAM 203, HDD 204, network I / F control unit 205, scanner I / F control unit 206, printer I / F control unit 207, and panel control unit 208. Control signals from the CPU 201 and data signals between the various devices are transmitted and received via the bus 209.

[0025] Fig. 3 is a block diagram for explaining software modules included in the multifunction peripheral 100 according to the embodiment 1. The software modules shown in Fig. 3 are realized by the CPU 201 executing a program loaded in the RAM 203.

[0026] The network driver 301 controls the network I / F control device 205 connected to the network 110 to transmit and receive data to and from the outside via the network 110. The network control unit 302 controls communication below the transport layer in a network communication protocol such as TCP / IP to transmit and receive data. The communication control unit 303 is a module for controlling a plurality of communication protocols supported by the multifunction peripheral 100. In the process of acquiring and updating an electronic certificate according to the first embodiment, the communication control unit 303 generates and analyzes requests and response data for HTTP protocol communication, and controls data transmission and reception, and executes communication with the certification authority / registration authority 102 and the PC 103. The communication control unit 303 also executes encrypted communication of TLS, IPSEC, and IEEE802.1X supported by the multifunction peripheral 100.

[0027] Web page control unit 304 is a module that generates HTML data for displaying a Web page that can execute a request for issuing an electronic certificate and a process for acquiring the same, and controls communication. Web page control unit 304 executes processing in response to a request for displaying a Web page sent from network driver 301 via communication control unit 304, and an instruction to issue and acquire an electronic certificate. Web page control unit 304 transmits HTML data of a default Web page stored in RAM 203 or HDD 204, or HTML data generated according to the contents of the display request, as a response to a request from a Web browser.

[0028] The key pair and certificate acquisition control unit 305 is a module for executing the process of acquiring an electronic certificate based on an instruction from the Web page control unit 304. The key pair and certificate acquisition control unit 305 is a module for performing communication control by SCEP, generation and analysis of encrypted data required for communication by SCEP such as PKCS#7 and PKCS#10, storage of acquired electronic certificates, and processing such as setting of usage. The encryption processing unit 306 is a module for performing various encryption processes such as data encryption and decryption, generation and verification of electronic signatures, and generation of hash values. The encryption processing unit 306 performs each encryption process required for generation and analysis of SCEP request and response data in the acquisition and update processing of electronic certificates according to the first embodiment. The key pair and certificate management unit 307 is a module for managing the public key pair and electronic certificates held by the multifunction peripheral 100. The key pair and certificate management unit 307 stores the data of the public key pair and electronic certificate together with various setting values ​​in the RAM 203 or the HDD 204. Although not shown in the first embodiment, processes such as displaying details of a public key pair and an electronic certificate, generating, deleting, etc., can also be executed by a user's instruction via the operation panel 212. The operation panel 212 and the panel control unit 208 are controlled by a UI control unit 308. Incidentally, in encrypted communication processes such as TLS, IPSEC, and IEEE802.1X executed by the communication control unit 303, encryption processing is also performed by an encryption processing unit 306, and public key pair and electronic certificate data to be used are obtained from a key pair and certificate management unit 307.

[0029] The print / read processing unit 309 is a module for executing functions such as printing by the printer 210 and reading of documents by the scanner 211. The device control unit 310 is a module for generating control commands and control data for the multifunction device 100 and for overall control of the multifunction device 100. The device control unit 306 according to the first embodiment controls the power supply of the multifunction device 100 and executes restart processing of the multifunction device 100 in response to an instruction from the Web page control unit 304.

[0030] FIG. 4 is a sequence diagram explaining the overall processing flow in the system of embodiment 1, from initial settings regarding an electronic certificate issuance request, display of electronic certificate information, issuance request and reception, reboot, and reflection of the electronic certificate.

[0031] This sequence is started in response to a display instruction for the key pair and the book selection certificate list being input by the user. In the first embodiment, an example of processing for one multifunction device 100 will be described, but multiple multifunction devices 100 and 101 may be executed in response to one start instruction. For example, the PC 103 may issue a request to the multifunction devices 100 and 101, and each of the multifunction devices may execute the processing shown in the flowcharts of Figs. 5 to 9 described later. In this case, the process of acquiring the certificates from the multifunction devices 100 and 101 and displaying them for confirmation may be skipped. Then, the multifunction device may automatically detect an expired certificate, transmit its bibliographic information (certificate ID and expiration date) to the PC 103, and the PC 103 may automatically update the certificates that are about to expire or have expired on the multiple multifunction devices. This is so-called silent installation.

[0032] First, in S401, when the multifunction device 100 accepts a connection from the PC 103, it receives a request sent from the PC 103 to display a list of key pairs and electronic certificates held by the multifunction device 100. In the first embodiment, the administrator of the multifunction device 100 uses a web browser installed in the PC 103 to connect to a web page format RUI for requesting and acquiring issuance of electronic certificates made public by the multifunction device 100, and performs operations such as issuing instructions. This RUI stands for remote user interface, and is a technology that allows the operation screen data of the multifunction device 100 or 101 to be remotely requested and displayed on the PC 103 using the web browser of the PC 103. At this time, the screen can be implemented using HTML, a servlet, or the like.

[0033] Next, in S402, the multifunction device 100 acquires data for displaying a list of key pairs and digital certificates held by the multifunction device 100, and generates a Web page screen for displaying the data.

[0034] Fig. 5A is a flowchart for explaining the process of obtaining a list of key pairs and digital certificates and creating display data in S402 in Fig. 4. This process is achieved by the CPU 201 executing a program loaded in the RAM 203.

[0035] FIG. 17 is a conceptual diagram of a database of detailed information on key pairs and electronic certificates managed by the key pair and certificate management unit 307 . This database is stored in the HDD 204 of the multifunction device 100 .

[0036] The flowchart in Fig. 5(A) will be described. This process starts by receiving a request to acquire a list of key pairs and electronic certificates. First, in S501, the CPU 201 receives the request to acquire a list of key pairs and electronic certificates. Next, the process proceeds to S502, where the CPU 201 acquires detailed information on the key pair and electronic certificate managed by the key pair and certificate management unit 307, for example, as shown in Fig. 17(A). Next, the process proceeds to S503, where the CPU 201 uses the detailed information on the key pair and electronic certificate acquired in S502 to generate HTML data for a Web page screen to be provided as an RUI.

[0037] 10 to 15 are diagrams showing examples of a web page screen of the RUI displayed on the PC 103 according to the first embodiment. In S503 in Fig. 5 according to the first embodiment, HTML data of the web page screen shown in Fig. 10(A) is generated, and this is displayed by the web browser of the PC 103. This makes it possible for the PC 103 to check the key pair and electronic certificate list held by the multifunction device 100.

[0038] The information of the electronic certificate displayed in the list of FIG. 10A includes the certificate name 1011, the purpose 1012, the issuer 1013, the validity end date 1014, and the certificate details 1015. The name 1011 is a character string arbitrarily given by an operator such as an administrator of the multifunction device 100 when the key pair and the electronic certificate are issued. The purpose 1012 is a setting value indicating that the key pair and the electronic certificate are used for any of TLS, IPSEC, and IEEE802.1X. The issuer 1013 is the distinguished name (DN: Distinguished Name) of the certificate authority that issued the electronic certificate. The validity end date 1014 is information on the date on which the validity of the electronic certificate ends. The details 1015 are an icon for displaying the detailed information of the electronic certificate. Then, the process proceeds to S504, where the CPU 201 transmits the HTML data generated in S503 to the PC 103 as a response to S501, and ends this process. In this manner, S403 in FIG. 4 is executed.

[0039] Although not shown in the sequence diagram of Fig. 4, when the administrator of multifunction device 100 clicks on the icon of details 1015 in Fig. 10(A) displayed on PC 103, a display request for detailed information on the corresponding electronic certificate is sent from PC 103 to multifunction device 100. Receiving the display request, multifunction device 100 acquires the detailed information on the electronic certificate, generates HTML data for the detailed information on the certificate based on the acquired information, and transmits the generated data to PC 103 as a response.

[0040] As a result, detailed information on the electronic certificate is displayed by the web browser of the PC 103, for example, as shown in Fig. 16. Fig. 16 is a diagram showing an example of detailed information on the electronic certificate displayed on the PC 103.

[0041] 5B is a flowchart for explaining the process when the multifunction peripheral 100 according to the first embodiment receives a request to display this detailed information from the PC 103. This process is achieved by the CPU 201 executing a program loaded in the RAM 203.

[0042] First, in S511, the CPU 201 receives a request to obtain detailed information about the electronic certificate from the PC 103. Next, the process proceeds to S512, where the CPU 201 obtains detailed information about the key pair and electronic certificate shown in Fig. 17A, which are managed by the key pair and certificate management unit 307. Next, the process proceeds to S513, where the CPU 201 uses the detailed information about the key pair and electronic certificate obtained in S512 to generate HTML data for a Web page screen, and transmits this to the PC 103 in S514.

[0043] FIG. 16 is a diagram showing an example of a display screen for detailed information on an electronic certificate according to the first embodiment. This screen is displayed on the PC 103 in a Web page format as an RUI.

[0044] Returning to the explanation of FIG. 4, in S403, the multifunction peripheral 100 transmits HTML data of the Web page screen shown in FIG. 10A, which was generated in S402, to the PC 103 as a response.

[0045] The processes shown in S401 to S403 in FIG. 4 and S501 to S504 and S511 to S514 in FIG. 5 indicate control processes related to display processing of electronic certificate information in the multifunction device 100 that has received a display request for the key pair / electronic certificate list.

[0046] Then, in S404, the multifunction peripheral 100 receives a display request for a connection setting screen of the SCEP server from the PC 103. In the first embodiment, the administrator of the multifunction peripheral 100 transmits a display request for the connection setting screen to the multifunction peripheral 100 by clicking on connection setting 1002 in Fig. 10(A) in order to perform connection settings with the certification authority / registration authority 102.

[0047] Next, in S405, the multifunction peripheral 100 transmits HTML data of the default SCEP server connection setting screen shown in FIG. 10B to the PC 103 as a response to S404.

[0048] The connection setting screen shown in Figure 10 (B) includes input fields for server name 1016 and port number 1017 for inputting the host name and destination port number of the SCEP server, and a set button 1018 for instructing the setting of the input setting values.

[0049] Next, in S406, the multifunction device 100 receives a setting instruction request for connection settings from the PC 103. The administrator of the multifunction device 100 in the first embodiment inputs server name 1016 and port number 1017 in Fig. 10(B) from the PC 103, and transmits this setting instruction request to the multifunction device 100 by clicking a setting button 1018.

[0050] Next, in S407, the multifunction device 100 executes a process for setting the connection settings and a process for generating a Web page screen showing the setting results, and in S408, transmits the HTML data of the Web page screen shown in FIG. 11(A) generated in S407 to the PC 103 as a response.

[0051] 6 is a flowchart for explaining the process of setting the connection settings to the certification authority / registration authority 102 in S407 of FIG. 4 by the multifunction peripheral 100 according to the first embodiment. This process is achieved by the CPU 201 executing a program loaded in the RAM 203.

[0052] First, in S601, the CPU 201 receives a connection setting request from the PC 103. Next, the process proceeds to S602, where the CPU 201 acquires the host name and port number setting values ​​included in the connection setting request, and stores the acquired setting values ​​in the RAM 203 or HDD 204. Next, the process proceeds to S603, where the CPU 201 generates HTML data for a Web page screen, for example, as shown in FIG. 11A. Then, the process proceeds to S604, where the CPU 201 transmits the HTML data generated in S603 as a response to S601, and ends this process. Then, the process proceeds to S408.

[0053] As a result, on the PC 103, as shown in FIG. 11(A), a character string 1101 indicating that the settings have been reflected is displayed.

[0054] The above-mentioned processes shown in S406 to S408 and S600 to 604 are the control related to the connection setting process in the multifunction device 100.

[0055] 4, the multifunction device 100 receives a display request for a CA certificate acquisition screen sent from the browser of the PC 103. In the first embodiment, the administrator of the multifunction device 100 transmits a display request for a CA certificate acquisition screen to the multifunction device 100 by clicking CA certificate acquisition 1003 in FIG.

[0056] As a result, in S410, the multifunction peripheral 100 transmits HTML data of the default CA certificate acquisition screen shown in FIG. 11B as a response to S409.

[0057] The connection setting screen in FIG. 11(B) includes an execute button 1102 for instructing acquisition of a CA certificate.

[0058] Next, in S411, the multifunction device 100 receives a request to acquire a CA certificate sent from the browser of the PC 103 when the execute button 1102 in Fig. 11(B) is clicked. In the first embodiment, it is assumed that the administrator of the multifunction device 100 clicks the execute button 1102 in Fig. 11(B) to send a request to acquire a CA certificate to the multifunction device 100.

[0059] Next, in S412, the multifunction device 100 executes a process of generating data for requesting acquisition of a CA certificate. Then, the process proceeds to S413, where the multifunction device 100 transmits the data for requesting acquisition of a CA certificate generated in S412 to the certification authority / registration authority 102, which is a SCEP server, based on the information set in S407. Then, the process proceeds to S414, where the multifunction device 100 receives a response to the request for acquiring a CA certificate transmitted from the certification authority / registration authority 102. As a result, the process proceeds to S415, where the multifunction device 100 analyzes the received response for acquiring the CA certificate, acquires the CA certificate contained in the response, and registers the acquired CA certificate as a CA certificate trusted by the multifunction device 100. Then, the process proceeds to S416, where the multifunction device 100 transmits HTML data of the Web page screen shown in FIG. 12(A) or FIG. 12(B), generated in S415, to the PC 103. FIG. 12(A) shows an example of a screen that is displayed when the CA certificate is successfully acquired and registered as a CA certificate. On the other hand, FIG. 12(B) shows an example of a screen that is displayed when acquisition of a CA certificate fails.

[0060] 7 is a flowchart for explaining the CA certificate acquisition and registration process shown in S412 to S416 in Fig. 4 by the multifunction peripheral 100 according to the first embodiment. Note that this process is achieved by the CPU 201 executing a program loaded in the RAM 203.

[0061] First, in S701, the CPU 201 receives a request to acquire a CA certificate from the PC 103. Next, the process proceeds to S702, where the CPU 201 generates a message for requesting to acquire a CA certificate based on the information on the connection settings to the certification authority / registration authority 102 acquired in S407. The following is an example of an acquisition request message generated in the first embodiment. In the first embodiment, SCEP is used as the communication protocol, and the message is a request message for using this protocol.

[0062] xxxxxxx / yyyyy?operation=GetCAXyz&message=CAIdentifier Next, the process proceeds to S703, where the CPU 201 connects to the certification authority / registration authority 102, which is the SCEP server, using the TCP / IP protocol based on the connection settings to the certification authority / registration authority 102 acquired in S407 of Fig. 4. Next, the process proceeds to S704, where the CPU 201 determines whether the connection in S703 was successful, and if successful, the process proceeds to S705, and if unsuccessful, the process proceeds to S714.

[0063] In S705, the CPU 201 transmits the CA certificate acquisition message generated in S702 to the certification authority / registration authority 102 by the GET or POST method of the HTTP protocol. Next, the process proceeds to S706, where the CPU 201 determines whether the transmission in S705 was successful. If it was successful, the process proceeds to S707, and if it was unsuccessful, the process proceeds to S714. In S707, the CPU 201 receives response data from the certification authority / registration authority 102 in response to the CA certificate acquisition request. Then, the process proceeds to S708, where the CPU 201 determines whether the reception of the response data in S707 was successful. If it was successful, the process proceeds to S709, and if it was unsuccessful, the process proceeds to S714. In S709, the CPU 201 analyzes the response data received in S708, and acquires the data of the CA certificate included in the response data. The analysis process of the response data and the acquisition process of the CA certificate are performed by the encryption processing unit 306.

[0064] In addition, the response data in the first embodiment is binary data in X.509 (RFC5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) format. However, for example, data in PKCS#7 (RFC5652: Cryptographic Message Syntax) format may be sent as a response, and the data format is not limited.

[0065] Next, the process proceeds to S710, where the CPU 201 determines whether the CA certificate was successfully acquired in S709. If the CA certificate was successfully acquired, the process proceeds to S711. If the CA certificate was not successfully acquired, the process proceeds to S714. In S711, the CPU 201 registers the CA certificate acquired in S709 as a CA certificate trusted by the multifunction device 100. At this time, the CPU 201 holds the acquired CA certificate in the RAM 203, and also stores the acquired CA certificate in a predetermined directory in the HDD 204 for storing CA certificates trusted by the multifunction device 100 by the key pair and certificate management unit 307. Then, the process proceeds to S712, where the CPU 201 determines whether the CA certificate registration process in S711 was successful. If the CA certificate was successfully acquired, the process proceeds to S713. If the CA certificate was not successfully acquired, the process proceeds to S714. In S713, the CPU 201 generates a thumbprint (a hash value based on the SHA1 algorithm) of the CA certificate to be displayed in 1201 in FIG. 12A when the CA certificate was successfully acquired. The generation of the thumbprint is executed by the encryption processing unit 306. Then, the process proceeds to S715, where the CPU 201 generates HTML data for display data of the CA certificate acquisition result in FIG. 12(A) and FIG. 12(A) from the processing results from S703 to S714. Then, the process proceeds to S716, where the CPU 201 transmits the HTML data generated in S715 to the PC 103 as a response to S701, and ends this process. Then, the process proceeds to S417 in FIG. 4. In the first embodiment, the character string 1201 in FIG. 12(A) is displayed according to the CA certificate acquisition result. Alternatively, if error processing is executed in S714, the character string 1202 in FIG. 12(B) is displayed. Next, the description of FIG. 4 is returned to.

[0066] In S417, the multifunction device 100 receives a display request for a certificate issuance request screen transmitted from the browser of the PC 103. In the first embodiment, the administrator of the multifunction device 100 clicks on the certificate issuance request 1004 in Fig. 10(A) to request and obtain a certificate from the certification authority / registration authority 102.

[0067] Next, in S418, the multifunction device 100 transmits HTML data of a default certificate issuance request screen shown in Fig. 13A as a response to S417 to the PC 103. In response to this, the PC 103 performs display control to display the screen shown in Fig. 13A.

[0068] 13(A) includes a certificate name 1301, key length 1302 for setting the key length of the key pair to be generated, an input field 1303 for issuing destination information, signature verification 1304 for setting whether to verify the signature attached to the response to the certificate issuance request sent from the certification authority / registration authority 102, key usage 1305 for setting the usage of the issued certificate, a password 1306 to be included in the certificate issuance request, and an execute button 1307 for executing the certificate issuance request. Usage 1305 is a checkbox, indicating that multiple usages can be set for one certificate.

[0069] Next, in S419, the multifunction device 100 receives a certificate issuance request including the input / setting information 1301 to 1306 transmitted from the browser of the PC 103 when the execute button 1307 on the screen in Fig. 13(A) is clicked. In the first embodiment, the administrator of the multifunction device 100 performs the input / settings 1301 to 1306 in Fig. 13(A) and clicks the execute button 1307 to transmit the certificate issuance request from the PC 103.

[0070] Next, in S420, the multifunction device 100 executes a process for generating certificate issuance request data. Then, in S421, the multifunction device 100 transmits the certificate issuance request data generated in S420 to the CA / registration authority 102, which is the SCEP server, based on the information set in S407. Then, in S422, the multifunction device 100 receives a response to the certificate issuance request transmitted from the CA / registration authority 102. Next, in S423, the multifunction device 100 performs processing for analyzing the response to the certificate issuance request received in S422 (performing signature verification according to settings, acquiring the certificate included in the response, and setting the acquired certificate for a specified purpose). Then, processing for generating a Web page screen showing the result of the certificate issuance request is executed.

[0071] If the certificate is successfully issued and acquired, the electronic certificate data is saved and its purpose is set by the process of S423. The purpose setting here refers to a communication function that uses the electronic certificate, and in the first embodiment, encrypted communication such as TLS, IPSEC, and IEEE802.1X can be set. The multifunction peripheral 100 according to the first embodiment can have multiple electronic certificates, and the purpose is set for each electronic certificate. For example, when the electronic certificate used when the multifunction peripheral 100 provides a server service that performs TLS communication as a Web server and the electronic certificate used by the multifunction peripheral 100 to perform client communication using IEEE802.1X are different, each can be set. However, one electronic certificate may be automatically applied to all communication purposes.

[0072] Then, in S424, the multifunction device 100 transmits HTML data of the Web page screen shown in Fig. 13(B) or Fig. 14(A) generated in S423 to the PC 103. Note that depending on the result of the certificate issuance request, a character string of the setting result is displayed as shown in 1308 in Fig. 13(B) or 1401 in Fig. 14(A). Fig. 13(B) shows an example of a screen when the issuance and acquisition of the certificate are successful, and Fig. 14(A) shows an example of a screen when the issuance and acquisition of the certificate are unsuccessful.

[0073] If the certificate is issued and obtained successfully, the electronic certificate data is saved and its purpose is set by the process of S423. Since the communication control unit 303 according to the first embodiment obtains the data of the electronic certificate used in encrypted communication of TLS, IPSEC, and IEEE802.1X when the multifunction device 100 is started, if the purpose is changed, the multifunction device 100 must be restarted.

[0074] 8 is a flowchart for explaining the certificate issuance request / acquisition process from S419 to S424 in Fig. 4 by the multifunction peripheral 100 according to the first embodiment. Note that this process is achieved by the CPU 201 executing a program loaded in the RAM 203.

[0075] First, in S801, the CPU 201 receives a certificate issuance request from the PC 103. Next, the process proceeds to S802, where the CPU 201 acquires information on the certificate name 1301, key length 1302, issuer information input 1303, signature verification 1304, and key usage 1305 included in the certificate issuance request received in S801. Next, the process proceeds to S803, where the CPU 201 acquires the CA certificate acquired in S412 to S415 in Fig. 4. Then, the process proceeds to S804, where the CPU 201 generates, by the cryptographic processing unit 306, a key pair generation process based on the information on the name 1301 and key length 1302 acquired in S802, and generates Certificate Signing Request (CSR) data in the PKSC#10 (RFC2986: PKCS #10: Certification Request Syntax Specification) format based on the information on the issuer information input 1303 and password 1306. Next, the process proceeds to S805, where the CPU 201 determines whether the generation of the key pair and certificate signing request in S804 was successful, and proceeds to S806 if it is determined to be successful, and proceeds to S823 if it is unsuccessful. In S806, the CPU 201 generates certificate issuance request data. The acquisition request data generated in S806 is data in the PKCS#7 format defined by SCEP, based on the connection settings to the certification authority / registration authority 102 acquired in S407 of FIG.

[0076] Next, the process proceeds to S808, and the CPU 201 connects to the CA / registration authority 102, which is the SCEP server, using the TCP / IP protocol based on the connection setting to the CA / registration authority 102 acquired in S407 of FIG. 4. Next, the process proceeds to S809, and the CPU 201 determines whether the connection in S808 was successful, and if successful, the process proceeds to S810, and if unsuccessful, the process proceeds to S823. In S810, the CPU 201 transmits the certificate issuance request data generated in S806 by the GET or POST method of the HTTP protocol. Then, in S811, the CPU 201 determines whether the transmission in S810 was successful, and if successful, the process proceeds to S812, and if unsuccessful, the process proceeds to S823. In S812, the CPU 201 receives response data to the certificate issuance request from the CA / registration authority 102. The response data defined in SCEP is data in PKCS#7 format that is transmitted as a response.

[0077] Next, the process proceeds to S813, where the CPU 201 determines whether the response data was successfully received in S812, and if successful, the process proceeds to S814, and if unsuccessful, the process proceeds to S823. In S814, the CPU 201 determines whether the signature verification is set to be performed based on the setting of the signature verification 1304 acquired in S802, and if so, the process proceeds to S815, and if not, the process proceeds to S817. In S815, the CPU 201 verifies the signature data attached to the data received in S812 using the public key included in the CA certificate acquired in S803. Then, the process proceeds to S816, where the CPU 201 determines whether the signature verification in S815 was successful, and if successful, the process proceeds to S817, and if unsuccessful, the process proceeds to S823.

[0078] In S817, the CPU 201 analyzes the data received in S812 and obtains the certificate data included in the response data. At this time, the encryption processing unit 306 performs the analysis of the response data and the process of obtaining the certificate. Next, the process proceeds to S818, where the CPU 201 determines whether the acquisition of the certificate in S817 was successful. If it was successful, the process proceeds to S819, and if it was unsuccessful, the process proceeds to S823. In S819, the CPU 201 registers the certificate obtained in S818 as the electronic certificate corresponding to the key pair generated in S804. At this time, the CPU 201 stores the public key pair generated in S804 and the obtained electronic certificate in a predetermined directory of the HDD 204 that stores the key pair and electronic certificate by the key pair and certificate management unit 307. At this time, the key pair and certificate management unit 307 adds the information of the public key pair generated in S804 and the obtained electronic certificate to the list of the detailed information of the key pair and certificate, as shown in FIG. 17B. In FIG. 17B, a new key pair and certificate Xyz4 are added.

[0079] Next, the process proceeds to S820, where the CPU 201 determines whether the registration process of the CA certificate in S819 was successful, and if successful, the process proceeds to S821, and if unsuccessful, the process proceeds to S823. In S821, the CPU 201 sets the purpose of the certificate based on the information of key purpose 1305 acquired in S802. At this time, the key pair and certificate management unit 307 updates the information of purpose in the list of detailed information on the key pair and certificate, for example, as shown in Fig. 17(C). In Fig. 17(C), the key pair and certificate used in TLS have been changed from Xyz1 to Xyz4.

[0080] Next, the process proceeds to S824, where the CPU 201 generates HTML data of the result of the certificate issuance request shown in Fig. 13B in accordance with the results of the processes from S801 to S823, and in S825 transmits the HTML data generated in S824 to the PC 103 as a response to the certificate issuance request in S801, thereby terminating this process.Then, the process proceeds to S425 in Fig. 4.

[0081] The above-mentioned processes of S419 to S424 and S801 to S825 constitute the control related to the issuance request, reception process, and communication purpose setting of the electronic certificate in the multifunction device 100. In this embodiment 1, the processes of the issuance request, reception process, and communication purpose setting are collectively referred to as the "automatic update function of the electronic certificate."

[0082] This automatic digital certificate update function allows the multifunction device 100 to automatically perform issuance requests and reception processes for digital certificates via the network, and further allows the user to set the usage of the received digital certificate, reducing the amount of work required by the user. Returning to the explanation of FIG. 4.

[0083] In S425, the multifunction peripheral 100 receives the request to restart the multifunction peripheral 100. In the first embodiment, it is assumed that the administrator of the multifunction peripheral 100 clicks the restart button 1309 in FIG.

[0084] Next, the process proceeds to S426, and the multifunction peripheral 100 transmits HTML data of the default restart execution screen shown in Fig. 14B as a response to S425. Next, the process proceeds to S427, and the multifunction peripheral 100 executes the multifunction peripheral 100 restart process.

[0085] The MFP 100 according to the first embodiment assumes that when a communication purpose such as IEEE802.1X is set for a received electronic certificate, the setting cannot be reflected unless the MFP 100 is restarted. This is because, for example, an electronic certificate such as IEEE802.1X is expanded in the RAM 203 when the MFP 100 is started and continues to be used, and may not be replaced with the received electronic certificate stored in the HDD 204. However, if the MFP 100 can switch the electronic certificate used for the communication purpose without restarting, restart may not be necessary. For example, when the purpose is set to TLS, restart may not be necessary. For example, the necessity of restarting may be set in advance for each of a plurality of purposes, and the MFP 100 may automatically determine whether or not to restart according to the information on necessity of restart.

[0086] 9 is a flowchart for explaining the process of restarting the multifunction peripheral 100 from S424 to S427 in FIG. 4, which is performed by the multifunction peripheral 100 according to the first embodiment. This process is achieved by the CPU 201 executing a program loaded in the RAM 203.

[0087] First, in S901, the CPU 201 receives a request to restart the MFP 100 from the PC 103. Next, the process proceeds to S902, where the CPU 201 transmits HTML data of the default request to restart the MFP 100 shown in Fig. 14B to the PC 103 as a response to S501. Next, the process proceeds to S903, where the CPU 201 instructs the device control unit 310 to start a restart process, and ends this process.

[0088] Through the above series of operations, the multifunction device 100 after rebooting uses the electronic certificate obtained from the certification authority / registration authority 102 .

[0089] FIG. 15 shows an example of a screen that appears when the key pair and electronic certificate list is displayed again by processing S401 if the certificate is successfully issued and obtained, and information 1501 about the certificate (Xyz4) issued by the certification authority / registration authority 102 has been added.

[0090] The above is the flow of the entire process from the initial settings regarding the issuance request of the electronic certificate, display of information on the electronic certificate, issuance request and reception, reboot, and reflection of the electronic certificate according to the first embodiment.

[0091] 4 shows a series of operations from connection settings to requesting and reflecting an electronic certificate, but the processing related to the initial settings such as connection settings may be performed only once for the multifunction device 100. For example, the processing for displaying electronic certificate information in S401 to S403, the processing for connection settings in S406 to S408, and the processing for acquiring a CA certificate in S409 to S418 are set only the first time. Then, when requesting issuance of an electronic certificate from the second time onwards, the settings may be used as they are. In other words, when updating an electronic certificate from the second time onwards, only the processing for requesting issuance of an electronic certificate and receiving the electronic certificate in S419 to S424, the processing related to the settings for communication use, and the processing related to restarting and reflecting the electronic certificate in S425 to S427 may be executed.

[0092] In the first embodiment, the MFP 100 receives instructions for each process from the PC 103 via its own Web page type RUI, and performs control based on the instructions. Instead of the Web page type RUI, an LUI (local UI) using the operation panel 210 of the MFP 100 may be used, and there is no particular limit to the interface that receives instructions from the administrator to the MFP 100.

[0093] Furthermore, for a Web page type RUI, instead of the administrator directly and manually operating it, the input area and operation instructions of the Web page may be made into templates and rules in advance, and the input instructions may be automatically input from a PC or another management server to issue a request to the multifunction device 100. In this case, for example, a Web scraping technology may be used.

[0094] In addition, in the first embodiment, the operations for obtaining and registering the CA certificate are performed by an administrator of the multifunction device 100, but the CA certificate may also be obtained automatically when a request for issuance of the certificate is made.

[0095] In addition, in the first embodiment, a setting is provided to select whether to perform signature verification included in the response to a certificate issuance request from the certification authority / registration authority 102. However, this setting may not be provided, and signature verification may always be performed, or signature verification may not be performed.

[0096] In the first embodiment, a password is input in the data of the certificate issuance request, and the password is included in the certificate signing request. However, a password may not be required.

[0097] As described above, according to the first embodiment, a request to add or update a certificate can be issued to an external device that is a certification authority or registration authority using the automatic certificate update protocol based on an instruction from the RUI. Then, in response to the request, the certificate can be received and registered in the MFP, and the purpose of the certificate can be set.

[0098] [Embodiment 2] Next, a second embodiment of the present invention will be described. In the first embodiment described above, a web page type RUI is provided to the user of the multifunction device 100 using the web server function of the multifunction device 100. The user adds or updates the electronic certificate and sets the purpose by instructing the multifunction device 100 via the RUI. Since the electronic certificate has an expiration date, the electronic certificate becomes invalid after the expiration date. The invalid electronic certificate does not authenticate correct communication, which causes a problem in network communication. Therefore, when the electronic certificate of a device is nearing the expiration date or has expired, the electronic certificate needs to be updated. However, when there are multiple devices that use electronic certificates, it is difficult for the device administrator to update the electronic certificate after understanding the expiration date of each electronic certificate.

[0099] In this embodiment, the second embodiment describes control for automatically starting the update function of an electronic certificate at a specified date and time, rather than in response to an instruction from a user, in an information processing device having an automatic update function of an electronic certificate as in the first embodiment. Note that in the second embodiment, the network configuration, the hardware configuration and software configuration of the multifunction device 100 which is the information processing device, the list display process of key pairs and electronic certificates, the process of setting connection settings, and the like are the same as those in the first embodiment described above, and therefore description thereof will be omitted.

[0100] FIG. 18 is a diagram showing an example of an electronic certificate renewal reservation setting screen of the multifunction peripheral 100 according to the second embodiment, and is displayed by a web page type RUI like other screens. The renewal date of the electronic certificate can be set via this renewal reservation setting screen of the electronic certificate. In the second embodiment, three settings can be made to specify the renewal date and renewal interval: renewal date 1801, expiration date 1802, and cycle 1803. The renewal date 1801 can specify the year, month, day, and time of renewal, and when the current date and time held in the multifunction peripheral 100 becomes the date and time of this renewal date 1801, the automatic renewal function of the electronic certificate is executed. The expiration date 1802 specifies the number of days until the expiration date of the electronic certificate being used is reached. When the current date and time held in the multifunction peripheral 100 becomes shorter than the specified number of days from the expiration date, the automatic renewal function of the electronic certificate is executed. The cycle 1803 executes the automatic renewal function of the electronic certificate at this cycle. In the second embodiment, the cycle can be set to the number of days, a specified date every month, or a specified date every year. In the second embodiment, the settings of the renewal date and renewal cycle of the electronic certificate are referred to as “electronic certificate renewal schedule settings.” When the renewal schedule settings of the electronic certificate are updated, the CPU 201 stores them in the HDD 204.

[0101] 18 shows an example of a screen in which the automatic update function of the electronic certificate is set to be executed 14 days before the expiration date in the expiration date 1802. In the second embodiment, the automatic update function of the electronic certificate is reserved using the above-mentioned type of electronic certificate update reservation setting, but a different date and time or timing may be specified by any method without any particular limitation.

[0102] Fig. 19 is a flowchart for explaining the processing when the multifunction device 100 according to the second embodiment executes the automatic update function of the electronic certificate based on the update reservation setting of the electronic certificate. Fig. 19 is set for the multifunction device 100. By first specifying multiple multifunction devices (different time settings can be set for each multifunction device), it is also possible to execute the instructions that can be input in Fig. 19 for multiple multifunction devices. In this case, the processing in Fig. 19 is executed in parallel in the multiple multifunction devices. Note that this processing is achieved by the CPU 201 executing a program expanded in the RAM 203.

[0103] First, in S1901, the CPU 201 acquires the update reservation setting of the electronic certificate from the HDD 204. Next, the process proceeds to S1902, where the CPU 201 acquires information on the electronic certificate currently being used. This information is information such as that held in FIG. 17. Next, the process proceeds to S1903, where the CPU 201 acquires the current date and time managed by the multifunction device 100. Then, the process proceeds to S1904, where the CPU 201 compares the update reservation setting of the electronic certificate with the information on the electronic certificate to determine whether or not the currently used electronic certificate needs to be updated. If it is determined that the electronic certificate does not need to be updated, the process returns to S1901. On the other hand, if it is determined that the electronic certificate needs to be updated, the process proceeds to S1905, where the process shifts to the control of the "certificate issuance request process" in FIG. 8. Then, when the process in FIG. 8 is completed, the process shifts to S1906.

[0104] The above process enables automatic renewal of electronic certificates according to the designated renewal date and renewal cycle without manual instruction from the user. This allows electronic certificates to be renewed at the desired timing, without the need for the device administrator to know the expiration date of each electronic certificate, while reducing the user's effort.

[0105] Next, in S1906, the CPU 201 determines whether or not it is necessary to restart the multifunction device 100 when the electronic certificate is updated. If the CPU 201 determines that a restart is necessary, the process proceeds to S1907, where the "restart / settings reflection process" shown in Fig. 9 is executed. On the other hand, if the CPU 201 determines that a restart is not necessary, this process ends. This is a control for restarting only when necessary in a network configuration in which, for example, when the electronic certificate used by the multifunction device 100 is switched, restart is not necessary in TLS, but is mandatory in IEEE802.1X.

[0106] As described above, according to the second embodiment, by reserving the timing for updating the electronic certificate, the multifunction device can automatically send an issuance request for the electronic certificate and update and register the electronic certificate without the user's instruction. This makes it possible to prevent the electronic certificate from becoming invalid due to the expiration date of the electronic certificate even if the user does not know the expiration date of the electronic certificate, causing problems in network communication.

[0107] (Other embodiments) The present invention can also be realized by a process in which a program for implementing one or more of the functions of the above-described embodiments is supplied to a system or device via a network or a storage medium, and one or more processors in a computer of the system or device read and execute the program. The present invention can also be realized by a circuit (e.g., ASIC) that implements one or more of the functions.

[0108] The present invention is not limited to the above-described embodiments, and various modifications and variations can be made without departing from the spirit and scope of the present invention. Therefore, the following claims are appended to apprise the public of the scope of the present invention. [Explanation of symbols]

[0109] 100, 101... multifunction device, 102... certification authority / registration authority, 103... PC, 304... Web page control unit, 305... key pair / certificate acquisition control unit, 306... encryption processing unit

Claims

[Claim 1] An information processing device that performs communication using an electronic certificate, a transmitting means for transmitting a request for issuing a digital certificate to an external device; a receiving means for receiving an electronic certificate from the external device in response to the issuance request; an updating means for updating the electronic certificate stored in the storage unit with the received electronic certificate, The information processing apparatus according to claim 1, wherein the transmitting means transmits the issuance request to the external device at a timing based on a date for renewing the electronic certificate and an interval for renewing the electronic certificate, which are set via a screen.

Images