Information processing device, control method thereof, and program

Abstract

To solve a problem in which when there are a large number of information processing devices that handle digital certificates, manually adding, updating, and configuring digital certificates for these devices takes a lot of time and effort.SOLUTION: A public key pair is generated in response to a certificate issuance request, a certificate signature request is generated on the basis of the public key pair and sent to an external device, the result of the certificate issuance request and an electronic certificate are obtained from a response sent from the external device in response to the issuance request, and the purpose of the obtained electronic certificate is set.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 personal mobile terminals use public key certificates to ensure secure communication and authentication when communicating with external servers.

[0003] Furthermore, in recent years, multifunction peripherals have not only the ability to simply print and transmit images, but also the ability to store image data internally and provide file services to PCs. As a result, multifunction peripherals have begun to function as information processing devices similar to other server devices on a network. To maintain a safe and secure office environment when these information processing devices are used on a network, it is necessary to authenticate communication using digital certificates. Generally, secure network identification and authentication are achieved using public key infrastructure (PKI) technology that uses digital certificates (see Non-Patent Document 1).

[0004] For example, when an information processing device acts as a client, it can verify the legitimacy of the server by obtaining a server public key certificate from the server and a certificate authority certificate from the certificate authority that issued the server public key certificate. Alternatively, the server can verify the legitimacy of the client by providing the server with the client public key certificate of the information processing device. Furthermore, when an information processing device acts as a server, the client can verify the legitimacy of the information processing device by distributing the server public key certificate of the information processing device to the connecting client. Thus, digital certificates have long been used as an important technology for authenticating and identifying network communications between information processing devices. Examples of communication protocols used in such communications include SSL, TLS, IEEE802.1X, and IPSEC.

[0005] Since this digital certificate needs to be stored and maintained 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 has been done 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 etc. to a specified folder.

[0006] Depending on the communication purpose, a separate digital certificate may be used for each information processing device. For example, in IEEE802.1X and other standards, a separate digital certificate is typically stored for each information processing device to authenticate clients. Furthermore, these digital certificates have an expiration date, and upon expiration, communication using the digital certificate becomes impossible. Therefore, it is necessary to update the digital certificate in the device when or just before the expiration date. Furthermore, when using digital certificates, it is necessary to manually configure each information processing device to determine which digital certificate to use for which communication purpose, such as TLS or IEEE802.1X. [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 these devices.

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

[0010] An object of the present invention is to provide a technique that makes it easy to add or update an electronic certificate 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: a generating means for generating a public key pair in response to a certificate issuance request and generating a certificate signing request based on the public key pair; a transmitting means for transmitting a digital certificate issuance request including a digital certificate signature request to an external device; a receiving means for receiving a response transmitted from the external device in response to the issuance request; a first obtaining means for obtaining the result of the certificate issuance request and the digital certificate included in the response received by the receiving means; and a setting means for setting the use of the electronic certificate acquired by the first acquisition means. [Effects 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 explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a diagram illustrating a network configuration according to a first embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram illustrating the hardware configuration of the multifunction peripheral according to the first embodiment. [Figure 3] FIG. 2 is a block diagram illustrating software modules included in the multifunction peripheral according to the first embodiment. [Figure 4] FIG. 1 is a sequence diagram illustrating the overall processing flow in the system according to the first embodiment, from initial settings related to a request for issuance of an electronic certificate, display of information about the electronic certificate, requesting and receiving the issuance, restarting, and reflecting the electronic certificate. [Figure 5] 5A is a flowchart illustrating the process of obtaining a list of key pairs and electronic certificates and creating display data in S402 of FIG. 4 by a multifunction peripheral according to a first embodiment; and FIG. 5B is a flowchart illustrating the process when a multifunction peripheral according to a first embodiment receives a request from a PC to display detailed information. [Figure 6] 5 is a flowchart for explaining the process of setting up a connection to the certification authority / registration authority in S407 of FIG. 4 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 and acquisition process from S419 to S424 in FIG. 4 performed 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. 2 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. 2 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. 2 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. 2 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. 2 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. 2 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. 10 is a diagram showing an example of detailed information about an electronic certificate displayed on a PC according to the first embodiment. [Figure 17] 3 is a conceptual diagram showing a database of detailed information on key pairs and digital 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 update reservation setting screen for an electronic certificate of a multifunction peripheral according to a second embodiment. [Figure 19] 10 is a flowchart for explaining processing when a multifunction peripheral according to a 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 INVENTION

[0014] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the present invention as claimed, and not all combinations of features described in the embodiments are necessarily essential to the solution of the present invention. Note that the following description will be given taking a multifunction peripheral (digital multifunction peripheral / MFP / Multi Function Peripheral) as an example of an information processing device that uses and manages electronic certificates according to the embodiments. 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] A multifunction peripheral 100 with 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 peripheral 100 also has the ability to perform encrypted communications using TLS, IPSEC, IEEE802.1X, and the like, and stores a public key pair and a digital certificate used for these encryption processes. The multifunction peripheral 100 is an example of an image forming device, but image forming devices are not limited to this and may also function as a facsimile machine, printer, or copier, or may combine these functions. A multifunction peripheral 101 is also connected to the network 110, and this multifunction peripheral 101 has the same functions as the multifunction peripheral 100. While the following description will focus primarily on the multifunction peripheral 100, the exchange of digital certificates can also be performed between multiple multifunction peripherals.

[0017] The certification authority / registration authority 102 has the function of a certification authority (CA) that issues digital certificates and the function of a registration authority (RA) that accepts requests for issuance of digital certificates and performs registration processing. In other words, the certification authority / registration authority 102 is a server device that has the 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 its protocol. An information processing device such as the multifunction peripheral 100 uses this SCEP to communicate with the certification authority / registration authority 102 via the network 110 to request and obtain an issuance of a digital 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 issuance of a digital certificate.

[0018] When the certification authority / registration authority 102 receives a request for issuance of a digital certificate from another information processing device via the network 110, it issues and registers a digital certificate based on the issuance request, and transmits the issued digital certificate as a response to the issuance request. In the first embodiment, the functions of the certification authority and registration authority are implemented by the same server device, but the certification authority and registration authority may be implemented by different server devices, and this is not a particular limitation. In the first embodiment, SCEP is used as the protocol for issuing and obtaining a digital certificate, but any protocol with equivalent functionality may be used, and the present invention is not particularly limited to this. For example, the Certificate Management Protocol (CMP) or the Enrollment over Secure Transport (EST) protocol may also 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 websites published by information processing devices connected to the network 110 .

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

[0021] The administrator of the multifunction peripheral 100 uses a web browser installed on the PC 103 to connect to a web page published by the multifunction peripheral 100 to request and acquire an electronic certificate, and makes settings and gives instructions for executing the process to request and acquire the electronic certificate. The multifunction peripheral 100 requests the certification authority / registration authority 102 to acquire a CA certificate using SCEP and issue an electronic certificate in accordance with the settings and instructions given by the administrator. The multifunction peripheral 100 also acquires the electronic certificate issued by the certification authority / registration authority 102, which is included in the response to the request for issuance of the electronic certificate, and makes settings for using the acquired electronic certificate on the multifunction peripheral 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 peripheral 100 and controls the entire device. The ROM 202 is read-only memory and stores the boot program and fixed parameters of the multifunction peripheral 100. The RAM 203 is random access memory and is used to store programs and temporary data when the CPU 201 controls the multifunction peripheral 100. The HDD 204 is a hard disk drive and stores system software, applications, and various data. The CPU 201 executes the boot program stored in the ROM 202, loads the program stored in the HDD 204 into the RAM 203, and controls the operation of the multifunction peripheral 100 by executing the loaded program. The network I / F control unit 205 controls the sending and receiving 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 printing processing by the printer 210, etc. The panel control unit 208 controls the touch panel type operation panel 212, displays various information, and controls 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 devices are transmitted and received via this bus 209.

[0025] 3 is a block diagram illustrating software modules included in the multifunction peripheral 100 according to the first embodiment. The software modules shown in FIG. 3 are implemented by the CPU 201 executing a program loaded in the RAM 203.

[0026] The network driver 301 controls the network I / F control unit 205 connected to the network 110 to send 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 send and receive data. The communication control unit 303 is a module for controlling multiple communication protocols supported by the multifunction peripheral 100. In the digital certificate acquisition and update process according to the first embodiment, the communication control unit 303 generates and analyzes requests and response data for HTTP protocol communication, 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 according to 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 issuance of a digital certificate and the process for acquiring the same, and controls communications. Web page control unit 304 executes processing in response to a request for displaying a Web page or an instruction to issue and acquire a digital certificate, sent from network driver 301 via communication control unit 303. Web page control unit 304 transmits HTML data of a default Web page stored in RAM 203 or HDD 204, or HTML data generated in accordance with the contents of the display request, as a response to a request from a Web browser.

[0028] The key pair / 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 / certificate acquisition control unit 305 is a module for controlling communication using SCEP, generating and analyzing encrypted data required for SCEP communication such as PKCS#7 and PKCS#10, and storing the acquired electronic certificate and setting its purpose. The encryption processing unit 306 is a module for executing various cryptographic processes such as data encryption and decryption, generating and verifying electronic signatures, and generating hash values. The encryption processing unit 306 executes various cryptographic processes required for generating and analyzing SCEP request and response data in the process of acquiring and updating an electronic certificate according to the first embodiment. The key pair / certificate management unit 307 is a module for managing the public key pairs and electronic certificates held by the multifunction peripheral 100. The key pair / certificate management unit 307 stores the public key pairs and electronic certificate data 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, generating, and deleting public key pairs and digital certificates can also be executed in response to user instructions via the operation panel 212. The operation panel 212 and panel control unit 208 are controlled by a UI control unit 308. 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 digital certificate data to be used is 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 peripheral 100 and for overall control of the multifunction peripheral 100. The device control unit 306 according to the first embodiment controls the power supply of the multifunction peripheral 100 and executes restart processing of the multifunction peripheral 100 in response to an instruction from the web page control unit 304.

[0030] Figure 4 is a sequence diagram that explains the overall processing flow in the system of embodiment 1, 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.

[0031] This sequence is initiated in response to a user's input of an instruction to display the key pair and book selection certificate list. In the first embodiment, an example of processing for one multifunction peripheral 100 is described. However, multiple multifunction peripherals 100 and 101 may be executed in response to a single start instruction. For example, the PC 103 may issue a request to the multifunction peripherals 100 and 101, causing each multifunction peripheral to execute the processing shown in the flowcharts of FIGS. 5 to 9 (described later). In this case, the process of acquiring certificates from the multifunction peripherals 100 and 101 and displaying them for confirmation may be skipped. The multifunction peripheral may then automatically detect expired certificates and transmit their bibliographic information (certificate ID and expiration date) to the PC 103. The PC 103 may then automatically update the expired or expired certificates on the multiple multifunction peripherals. This is known as silent installation.

[0032] First, in S401, when the multifunction peripheral 100 accepts a connection from the PC 103, it receives a request from the PC 103 to display a list of key pairs and digital certificates held by the multifunction peripheral 100. In the first embodiment, the administrator of the multifunction peripheral 100 uses a web browser installed on the PC 103 to connect to a web page format RUI for requesting and obtaining issuance of a digital certificate made public by the multifunction peripheral 100, and performs operations such as issuing instructions. This RUI stands for Remote User Interface, and is a technology that enables the web browser of the PC 103 to remotely request operation screen data for the multifunction peripheral 100 or 101 and display it on the PC 103. In this case, the screen can be implemented using HTML, a servlet, or the like.

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

[0034] Fig. 5A is a flowchart illustrating the process of obtaining a list of key pairs and digital certificates and creating display data in S402 of 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 digital certificates managed by the key pair and certificate management unit 307 , and this database is stored in the HDD 204 of the multifunction peripheral 100 .

[0036] The flowchart in Figure 5(A) will be described. This process begins by receiving a request to acquire a key pair / electronic certificate list. First, in S501, the CPU 201 receives the request to acquire a key pair / electronic certificate list. Next, the process proceeds to S502, where the CPU 201 acquires detailed information about the key pair / electronic certificate managed by the key pair / certificate management unit 307, such as that shown in Figure 17(A). Next, the process proceeds to S503, where the CPU 201 uses the detailed information about the key pair / 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 the RUI web page screen displayed on the PC 103 according to the first embodiment. In S503 of Fig. 5 according to the first embodiment, HTML data for 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 digital certificate list held by the multifunction peripheral 100.

[0038] The electronic certificate information displayed in the list in FIG. 10A includes a certificate name 1011, a purpose 1012, an issuer 1013, an expiration date 1014, and certificate details 1015. The name 1011 is a character string arbitrarily assigned by an operator, such as an administrator of the multifunction peripheral 100, when issuing the key pair and electronic certificate. The purpose 1012 is a setting value indicating that the key pair and electronic certificate will be used for one of TLS, IPSEC, or IEEE802.1X. The issuer 1013 is the distinguished name (DN) of the certification authority that issued the electronic certificate. The expiration date 1014 is information about the expiration date of the electronic certificate. The details 1015 is an icon for displaying detailed information about the electronic certificate. The process then proceeds to step S504, where the CPU 201 transmits the HTML data generated in step S503 to the PC 103 as a response to step S501, thereby terminating this process. In this manner, step S403 in FIG. 4 is executed.

[0039] 4, when the administrator of the multifunction peripheral 100 clicks on the icon for details 1015 in FIG. 10A displayed on the PC 103, a request to display detailed information about the corresponding electronic certificate is sent from the PC 103 to the multifunction peripheral 100. Upon receiving the request, the multifunction peripheral 100 acquires the detailed information about the electronic certificate, generates HTML data for the detailed information about the certificate based on the acquired information, and transmits the generated data to the PC 103 as a response.

[0040] 16, detailed information about the electronic certificate is displayed by the web browser of the PC 103. FIG.

[0041] 5B is a flowchart illustrating the processing performed when the multifunction peripheral 100 according to the first embodiment receives a request to display this detailed information from the PC 103. This processing 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 acquire detailed information about the electronic certificate from the PC 103. Next, the process proceeds to S512, where the CPU 201 acquires detailed information about the key pair and electronic certificate shown in Fig. 17A, which is managed by the key pair and certificate management unit 307. Next, the process proceeds to S513, where the CPU 201 generates HTML data for a Web page screen using the detailed information about the key pair and electronic certificate acquired in S512, 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 a digital certificate according to the first embodiment, and this screen is displayed in a web page format on the PC 103 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 the display process of electronic certificate information in the multifunction device 100 that has received a request to display the key pair / electronic certificate list.

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

[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 setting button 1018 for instructing the setting of the input setting values.

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

[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, it sends the HTML data of the web page screen shown in Figure 11 (A) generated in S407 to the PC 103 as a response.

[0051] 6 is a flowchart for explaining the process of setting up a connection 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 settings included in the connection setting request and saves the acquired settings 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-described processes shown in S406 to S408 and S600 to S604 are control related to the connection setting process in the multifunction peripheral 100.

[0055] 4, the multifunction peripheral 100 receives a request to display a screen for acquiring a CA certificate sent from the browser of the PC 103. In the first embodiment, the administrator of the multifunction peripheral 100 clicks on CA certificate acquisition 1003 in FIG. 10A to acquire a CA certificate issued by the certification authority / registration authority 102, thereby sending a request to display a screen for acquiring a CA certificate to the multifunction peripheral 100.

[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 that instructs acquisition of a CA certificate.

[0058] Next, in S411, the multifunction peripheral 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 peripheral 100 clicks the execute button 1102 in Fig. 11(B) to send a request to acquire a CA certificate to the multifunction peripheral 100.

[0059] Next, in S412, the multifunction peripheral 100 executes processing to generate CA certificate acquisition request data. Then, in S413, the multifunction peripheral 100 transmits the CA certificate acquisition request data generated in S412 to the certification authority / registration authority 102, which is the SCEP server, based on the information set in S407. Then, in S414, the multifunction peripheral 100 receives a response to the CA certificate acquisition request transmitted from the certification authority / registration authority 102. Then, in S415, the multifunction peripheral 100 analyzes the received CA certificate acquisition response, acquires the CA certificate contained in the response, and registers the acquired CA certificate as a CA certificate trusted by the multifunction peripheral 100. Then, in S416, the multifunction peripheral 100 transmits HTML data for the web page screen shown in FIG. 12(A) or 12(B) generated in S415 to the PC 103. FIG. 12(A) shows an example of a screen displayed when the CA certificate has been 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 illustrating 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. 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 requesting acquisition of a CA certificate based on the information about 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 this 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 using 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 successful, the process proceeds to S707, and if 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. The process proceeds to S708, where the CPU 201 determines whether reception of the response data in S707 was successful. If successful, the process proceeds to S709, and if unsuccessful, the process proceeds to S714. In S709, the CPU 201 analyzes the response data received in S708 and acquires the CA certificate data included in the response data. The response data analysis process and CA certificate acquisition process are performed by the cryptographic processing unit 306.

[0064] 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 also 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 successful, the process proceeds to S711; if not, 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 peripheral 100. At this time, the CPU 201 holds the acquired CA certificate in the RAM 203, and also causes the key pair and certificate management unit 307 to store it in a predetermined directory on the HDD 204 for storing CA certificates trusted by the multifunction peripheral 100. The process proceeds to S712, where the CPU 201 determines whether the CA certificate registration process in S711 was successful. If successful, the process proceeds to S713; if not, the process proceeds to S714. In S713, the CPU 201 generates a thumbprint (a hash value using the SHA1 algorithm) of the CA certificate to be displayed in 1201 in FIG. 12A if the CA certificate was successfully acquired. The generation of this thumbprint is executed by the encryption processing unit 306. The process then proceeds to S715, where the CPU 201 generates HTML data for displaying the CA certificate acquisition result shown in FIG. 12A and FIG. 12A from the processing results of S703 to S714. The process then 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. The process then proceeds to S417 in FIG. 4. In the first embodiment, the character string 1201 shown in FIG. 12A is displayed in accordance with the CA certificate acquisition result. Alternatively, if error processing is executed in S714, the character string 1202 shown in FIG. 12B is displayed. Next, we return to the description of FIG. 4.

[0066] In S417, the multifunction peripheral 100 receives a request to display a certificate issuance request screen sent from the browser of the PC 103. In the first embodiment, the administrator of the multifunction peripheral 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 peripheral 100 transmits HTML data of the default certificate issuance request screen shown in Fig. 13A as a response to S417 to the PC 103. As a result, 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 peripheral 100 receives a certificate issuance request including the input and setting information 1301 to 1306 sent from the browser of the PC 103 when the execute button 1307 on the screen in Fig. 13A is clicked. In the first embodiment, the administrator of the multifunction peripheral 100 makes the input and setting of the information 1301 to 1306 in Fig. 13A and clicks the execute button 1307, thereby sending the certificate issuance request from the PC 103.

[0070] Next, in S420, the multifunction peripheral 100 executes processing to generate certificate issuance request data. Then, in S421, the multifunction peripheral 100 transmits the certificate issuance request data generated in S420 to the certification authority / registration authority 102, which is the SCEP server, based on the information set in S407. Then, in S422, the multifunction peripheral 100 receives a response to the certificate issuance request sent from the certification authority / registration authority 102. Next, in S423, the multifunction peripheral 100 analyzes the response to the certificate issuance request received in S422 (performing signature verification according to the settings, obtaining the certificate included in the response, and setting the obtained certificate for the specified purpose). Then, it executes processing to generate a Web page screen that shows the results of the certificate issuance request.

[0071] If the certificate is successfully issued and obtained, the process of S423 stores the digital certificate data and sets its intended use. The intended use setting here refers to a communication function that uses the digital certificate. 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 digital certificates, and a purpose setting is performed for each digital certificate. For example, if the digital certificate used when the multifunction peripheral 100 provides a server service that performs TLS communication as a Web server and the digital certificate used when the multifunction peripheral 100 performs client communication using IEEE802.1X are different, each can be set. However, one digital certificate may be automatically applied to all communication purposes.

[0072] Then, in S424, the multifunction peripheral 100 transmits the 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 indicating 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 displayed when the issuance and acquisition of the certificate is successful, and Fig. 14(A) shows an example of a screen displayed when the issuance and acquisition of the certificate has failed.

[0073] If the certificate is issued and obtained successfully, the digital certificate data is saved and its use is set by the process of S423. The communication control unit 303 according to the first embodiment obtains the digital certificate data used for encrypted communication of TLS, IPSEC, and IEEE802.1X when the multifunction peripheral 100 is started up, so if the use is changed, the multifunction peripheral 100 must be restarted.

[0074] 8 is a flowchart illustrating the certificate issuance request and acquisition process from S419 to S424 in FIG. 4 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.

[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 the certificate name 1301, key length 1302, issuer information input 1303, signature verification 1304, and key usage 1305 information 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 of Fig. 4. Next, the process proceeds to S804, where the CPU 201 performs a key pair generation process based on the name 1301 and key length 1302 information acquired in S802, and generates Certificate Signing Request (CSR) data in PKSC#10 (RFC2986: PKCS #10: Certification Request Syntax Specification) format using the cryptographic processing unit 306 based on the issuer information input 1303 and password 1306 information. 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 if it is determined to be successful, the process proceeds to S806, and if it is not successful, the process proceeds to S823. In S806, the CPU 201 generates certificate issuance request data. This 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 Figure 4.

[0076] Next, the process proceeds to S808, 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 S809, where the CPU 201 determines whether the connection in S808 was successful. 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 using the GET or POST method of the HTTP protocol. Then, in S811, the CPU 201 determines whether the transmission in S810 was successful. 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 certification authority / registration authority 102. The response data defined in SCEP is PKCS#7 format data 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. If successful, the process proceeds to S814, and if not, the process proceeds to S823. In S814, the CPU 201 determines whether signature verification is set to be performed based on the setting of the signature verification 1304 acquired in S802. If so, the process proceeds to S815, and if not, the process proceeds to S817. In S815, the CPU 201 verifies the signature data added 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. If successful, the process proceeds to S817, and if not, the process proceeds to S823.

[0078] In S817, the CPU 201 analyzes the data received in S812 and acquires the certificate data included in the response data. At this time, the cryptographic processing unit 306 analyzes the response data and performs processing to acquire the certificate. Next, the processing proceeds to S818, where the CPU 201 determines whether acquisition of the certificate in S817 was successful. If successful, the processing proceeds to S819; if not, the processing proceeds to S823. In S819, the CPU 201 registers the certificate acquired in S818 as the digital 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 acquired digital certificate in a predetermined directory on the HDD 204 for storing key pairs and digital certificates using the key pair and certificate management unit 307. At this time, the key pair and certificate management unit 307 adds information about the public key pair generated in S804 and the acquired digital certificate to a list of detailed information about the key pair and certificate, as shown in FIG. 17B. In FIG. 17B, a new key pair and certificate Xyz4 have been added.

[0079] Next, the process proceeds to S820, where the CPU 201 determines whether the CA certificate registration process in S819 was successful. If successful, the process proceeds to S821, and if not, the process proceeds to S823. In S821, the CPU 201 sets the certificate usage based on the information in the key usage 1305 acquired in S802. At this time, the key pair and certificate management unit 307 updates the usage information in the list of key pair and certificate detail information, for example, as shown in Figure 17(C). In Figure 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 certificate issuance request result shown in Fig. 13B in accordance with the processing results of 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 of S801, thereby terminating this process.The process then proceeds to S425 in Fig. 4.

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

[0082] This automatic digital certificate update function allows the multifunction device 100 to automatically request and receive digital certificates via the network, and also to set the usage of the received digital certificate, thereby reducing the amount of work required by the user. Returning to the explanation of Figure 4.

[0083] In S425, the multifunction peripheral 100 receives a 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 reboot execution screen shown in Fig. 14B as a response to S425. Next, the process proceeds to S427, and the multifunction peripheral 100 executes the reboot process of the multifunction peripheral 100.

[0085] The multifunction peripheral 100 according to the first embodiment assumes that when a communication purpose such as IEEE802.1X is set for a received digital certificate, the change cannot be reflected without rebooting the device. This is because, for example, a digital certificate such as IEEE802.1X is loaded into the RAM 203 upon startup of the multifunction peripheral 100 and continues to be used, and may not be replaced with the received digital certificate stored in the HDD 204. However, if the multifunction peripheral 100 can switch the digital certificate used for the communication purpose without rebooting, rebooting may not be necessary. For example, if TLS is set as the communication purpose, rebooting may not be necessary. For example, whether or not a reboot is required may be set in advance for each of multiple purposes, and the multifunction peripheral 100 may automatically determine whether or not to reboot based on the reboot requirement information.

[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 multifunction peripheral 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 multifunction peripheral 100 shown in Fig. 14(B) 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 the restart process, and then ends this process.

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

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

[0090] The above is the overall processing flow from the initial setting for the digital certificate issuance request, display of digital certificate information, request for issuance and reception, reboot, and reflection of the digital certificate according to the first embodiment.

[0091] 4 shows a series of operations from connection settings to requesting and reflecting an electronic certificate, but processing related to initial settings such as connection settings may be performed only once for the multifunction peripheral 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 obtaining 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, those settings may be used as is. In other words, when updating an electronic certificate from the second time onwards, only the processing for requesting issuance and receiving an electronic certificate in S419 to S424, the processing related to communication usage settings, and the processing related to restarting and reflecting the settings in S425 to S427 may be performed.

[0092] In the first embodiment, the multifunction peripheral 100 receives instructions for each process from the PC 103 via its own web page-type RUI, and performs control based on those instructions. Instead of the web page-type RUI, an LUI (local UI) using the operation panel 210 of the multifunction peripheral 100 may be used, and there is no particular limitation on the interface through which the administrator receives instructions for the multifunction peripheral 100.

[0093] Furthermore, for a web page-type RUI, instead of the administrator directly operating it manually, the input fields and operation instructions of the web page may be made into templates or rules in advance, and requests may be issued to the multifunction peripheral 100 by automatically inputting instructions from a PC or another management server. In this case, for example, web scraping technology may be used.

[0094] In addition, in embodiment 1, the operations for obtaining and registering the CA certificate are performed by the administrator of the multifunction device 100, but the CA certificate may also be obtained automatically when a request for certificate issuance 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 the certificate issuance request from the certification authority / registration authority 102, but it is also possible to omit this setting and always perform signature verification, or not perform signature verification.

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

[0097] As described above, according to the first embodiment, a request for adding or updating 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 multifunction device, and the use 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 was provided to the user of the multifunction peripheral 100 using the web server function of the multifunction peripheral 100. The user then added or updated a digital certificate and set its purpose by issuing instructions to the multifunction peripheral 100 via the RUI. Since these digital certificates have expiration dates, digital certificates that have passed their expiration date become invalid. An invalid digital certificate cannot authenticate correct communications, which can cause problems with network communications. Therefore, when a device's digital certificate is nearing its expiration date or has expired, it must be updated. However, when there are multiple devices that use digital certificates, it is difficult for the device administrator to update the digital certificates while keeping track of the expiration dates of each digital certificate.

[0099] Therefore, in the second embodiment, a control will be described in which the update function for an electronic certificate is automatically activated at a predetermined date and time, rather than in response to an instruction from a user, in an information processing device having an automatic update function for 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 for key pairs and electronic certificates, the process for setting connection settings, etc. 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, which is displayed as a web page-type RUI like the other screens. The renewal date of the electronic certificate can be set via this electronic certificate renewal reservation setting screen. 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 allows the year, month, date, and time of renewal to be specified. When the current date and time stored 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 remaining until the expiration date of the electronic certificate being used. The automatic renewal function of the electronic certificate is executed when the current date and time stored in the multifunction peripheral 100 becomes closer than the specified number of days from the expiration date. The cycle 1803 executes the automatic renewal function of the electronic certificate at this cycle. In the second embodiment, this cycle can be set as the number of days, a specified date every month, or a specified date every year. In the second embodiment, the settings for the renewal date and renewal cycle of the electronic certificate are referred to as “electronic certificate renewal reservation settings.” When the renewal reservation settings for 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 renewal 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 renewal function of the electronic certificate is reserved using the renewal reservation setting type of the electronic certificate described above, but other date and time or timing may also be specified by any other method, and there are no particular limitations.

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

[0103] First, in S1901, the CPU 201 obtains the renewal reservation settings for the electronic certificate from the HDD 204. Next, the process proceeds to S1902, where the CPU 201 obtains information about the electronic certificate currently in use. This information is the information stored in FIG. 17, for example. Next, the process proceeds to S1903, where the CPU 201 obtains the current date and time managed by the multifunction peripheral 100. Then, the process proceeds to S1904, where the CPU 201 compares the renewal reservation settings for the electronic certificate with the information about the electronic certificate to determine whether the currently used electronic certificate needs to be renewed. If it is determined here that the electronic certificate does not need to be renewed, the process returns to S1901. On the other hand, if it is determined that the electronic certificate needs to be renewed, the process proceeds to S1905, where control shifts to the "certificate issuance request process" in FIG. 8. Then, when the processing in FIG. 8 is completed, the process shifts to S1906.

[0104] The above process enables automatic renewal of digital certificates according to the specified renewal date and renewal cycle without manual instruction from the user. This allows digital certificates to be renewed at the desired timing, without the need for the device administrator to know the expiration date of each digital certificate, and with reduced effort on the part of the user.

[0105] Next, in S1906, the CPU 201 determines whether or not the multifunction peripheral 100 needs to be restarted when the digital 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, the process ends. This control is used to perform a restart only when necessary, for example, in a network configuration where a restart is not required in TLS but is required in IEEE802.1X when the digital certificate used by the multifunction peripheral 100 is switched.

[0106] As described above, according to the second embodiment, by reserving the timing for updating the digital certificate, the multifunction device can automatically send a request for issuing the digital certificate and update and register the digital certificate without the user's instruction. This prevents the digital certificate from becoming invalid due to the expiration date of the digital certificate even if the user does not know the expiration date of the digital certificate, which can cause problems in network communication.

[0107] (Other embodiments) The present invention can also be realized by supplying a program that realizes one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and having one or more processors in the 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 realizes one or more 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 peripheral, 102... certification authority / registration authority, 103... PC, 304... web page control unit, 305... key pair / certificate acquisition control unit, 306... encryption processing unit

Claims

1. a generating means for generating a public key pair in response to a certificate issuance request and generating a certificate signing request based on the public key pair; a transmitting means for transmitting a digital certificate issuance request including a digital certificate signature request to an external device; a receiving means for receiving a response transmitted from the external device in response to the issuance request; a first obtaining means for obtaining the result of the certificate issuance request and the digital certificate included in the response received by the receiving means; a setting unit for setting a use of the digital certificate acquired by the first acquisition unit; An information processing device comprising:

2. further comprising a verification means for verifying a digital signature included in the response; 2. The information processing device according to claim 1, wherein the first acquisition means acquires the electronic certificate included in the response when the verification means verifies that the certificate included in the response was issued by the external device.

3. The method further includes a second acquisition means for acquiring a CA certificate from the external device, 3. The information processing apparatus according to claim 2, wherein the verification means performs signature verification using the CA certificate acquired by the second acquisition means.

4. 4. The information processing apparatus according to claim 1, wherein the certificate issuance request is received from a second information processing apparatus connected to the information processing apparatus via a network.

5. a connection setting unit that displays a screen for setting a connection with the external device and performs connection setting with the external device in accordance with the content set on the screen; 2. The information processing apparatus according to claim 1, wherein the transmitting means transmits a request for issuing an electronic certificate including a request for signing the electronic certificate to the external device set by the connection setting means.

6. a display control unit that causes the second information processing device to display a screen for requesting issuance of the digital certificate; 5. The information processing apparatus according to claim 4, wherein said transmission means and said setting means are activated in response to an instruction input via said screen.

7. 7. The information processing apparatus according to claim 1, further comprising a reflecting unit that reflects the setting of the electronic certificate in the information processing apparatus.

8. a designation means for designating the timing of updating the digital certificate; 8. The information processing device according to claim 1, further comprising: an update unit that, when the update timing specified by the designation unit arrives, activates the transmission unit, the reception unit, and the first acquisition unit to update the electronic certificate.

9. 9. The information processing apparatus according to claim 8, wherein the designation unit designates the timing of the update by at least one of an update date, the number of days based on the expiration date of the electronic certificate, and an update cycle.

10. A control method for controlling an information processing device that performs communication using a digital certificate, comprising: a generating step of generating a public key pair in response to a certificate issuance request and generating a certificate signing request based on the public key pair; a transmitting step of transmitting a digital certificate issuance request including a digital certificate signature request to an external device; a receiving step of receiving a response transmitted from the external device in response to the issuance request; an acquiring step of acquiring the result of the certificate issuance request and the digital certificate contained in the response received in the receiving step; a setting step of setting a use of the digital certificate acquired in the acquisition step; 1. A method for controlling an information processing device, comprising:

11. A program for causing a computer to function as each of the means of the information processing apparatus according to any one of claims 1 to 9.

Images