JP6833658B2 - Server equipment, equipment, certificate issuing method, certificate requesting method, certificate issuing program and certificate requesting program - Google Patents

Description

Embodiments of the present invention relate to a server device, a device, a certificate issuing method, a certificate requesting method, a certificate issuing program, and a certificate requesting program.

Technology to prevent spoofing of equipment has been known for some time. For example, a technique for issuing a DV (Domain Validation) certificate that certifies the validity of the domain of a device by a certificate authority has been conventionally known.

Japanese Unexamined Patent Publication No. 2012-049752

ACME (Automatic Certificate Management Environment), [online], [Search on October 24, 2017], Internet <URL: https: // dattracker. IETF. org / doc / draft-ietf-acme-acme />

However, with conventional techniques, it has been difficult to more easily prove the validity of devices connected to different networks.

The server device of the embodiment is a server device connected to the first network, and includes an issue request response unit, a confirmation method response unit, a confirmation request response unit, a device URL response unit, and an issue unit. When the issuance request response unit receives an issuance request for a certificate including the domain of the device and certifying the validity of the domain from a device connected to the second network, the issuance request response unit obtains identification information for identifying the issuance request. Send to the device. When the confirmation method response unit receives the confirmation method acquisition request for which the identification information is specified from the device, the confirmation method response unit transmits a token used for confirmation of the existence of the domain to the device. Said confirmation request response unit from the device, when receiving the domain verification request including the signature data and the token server URL including identification information identifying the issue request and said domain verification request (Uniform Resource Locator) Send to the device. When the device URL response unit receives a connection from the terminal connected to the second network via the server URL and receives a device URL acquisition request to which the specific information is specified from the terminal, the device URL response unit receives the device URL acquisition request from the specific information. The domain and the token are specified, and a device URL including the domain and the token is transmitted to the terminal. When the issuing unit receives a domain confirmation registration request including the token and the signature data acquired from the device URL from the terminal that has succeeded in connecting the device URL, the issuing unit issues the certificate.

The figure which shows the example of the structure of the certificate issuing system of 1st Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 1st Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 1st Embodiment. The figure which shows the example of the structure of the certificate issuing system of 2nd Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 2nd Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 2nd Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 2nd Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 3rd Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 3rd Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 3rd Embodiment. The figure which shows the example of the structure of the certificate issuing system of 4th Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 4th Embodiment. The sequence diagram which shows the operation example of the certificate issuing system of 4th Embodiment. The figure which shows the example of the hardware composition of the main part of the server apparatus, the apparatus and the terminal of 1st to 4th Embodiment.

The server device, the device, the certificate issuing method, the certificate requesting method, the certificate issuing program, and the embodiment of the certificate requesting program will be described in detail with reference to the attached drawings.

(First Embodiment)
First, a web server on the Internet (hereinafter simply referred to as "web service"), a web server operating on a device on a local network (hereinafter simply referred to as "device"), and a web of a terminal accessing the web service. The difficulty of performing encrypted communication based on mutual authentication via a browser will be described. Here, the encrypted communication is a communication using TLS (Transport Layer Security) such as, for example, HTTPS (Hypertext Transfer Protocol Security).

Specifically, it is difficult to solve the following problems without some manual setting by the user.
[Problem 1] The web browser and the front end (interface controlled as a web page) of the web service operating on the web browser cannot find the device on the local network.
[Problem 2] The device does not have a legitimate server certificate. That is, it cannot be verified that the web browser and the front end of the web service running on the web browser are reliable devices.
[Problem 3] The device cannot authenticate and control access to web services, and cannot authenticate and control access to users.

[Problem 1] can be solved by, for example, the following solution. First, the web service prepares a registration interface for registering the IP address of the device. The user then registers the IP address of the device with the web service using the registration interface.

[Problem 2] can be solved by, for example, the following solution. First, the user creates a certificate authority and a root certificate signed by the certificate authority. The user then registers the root certificate created by the user in the web browser as a trusted root certificate. The user then creates a server certificate signed by the certificate authority created by the user. Then, the user sets the server certificate in the device.

[Problem 3] can be solved by, for example, the following solution. First, a user ID and password are set in advance in the device. Then, when the web browser accesses the device, the user ID and password are used for authentication.

However, all of the above solutions force the user to perform manual setting work, and there is a problem in usability. Further, regarding the solutions of the above-mentioned [Problem 2] and [Problem 3], the web service cannot properly verify the validity of the device and the device cannot properly verify the validity of the web service. Therefore, a malicious user can easily communicate with a malicious device or a malicious web service.

The main reason for the above-mentioned [Problem 2] is that the device does not have a reliable server certificate. However, it is common for a legitimate certificate authority to have a globally accessible domain and issue a certificate to a server whose management entity is clear. Therefore, there is no known method of issuing a legitimate server certificate to a device on a local network, which is a network different from the Internet.

Non-Patent Document 1 defines the standard specifications of a certificate authority that issues DV certificates for web services. A DV certificate is a server certificate issued only on the premise of verifying the existence of a domain, and is the least reliable certificate issued by a public certificate authority on the Internet. In other words, domain existence verification can be rephrased as the minimum rule for server certificates issued by public certificate authorities. However, since a certificate authority on the Internet has a relay device having a function such as a firewall or NAT (Network Addless Translation), it is not possible to verify the domain existence of a device on a local network.

When the device behaves as a server, when to give a fixed name (domain) to a local server that has a private address space and also has a variable IP address, and which domain's existence verification is performed. It is difficult to solve the problem of issuing a certificate.

The following description describes how to enable secure (cross-origin) access from a web service to a device on a local network via a web browser. The term "safely" as used herein means that the web browser can verify that the device, the web service, and the user of the web service are legitimate, and can perform encrypted communication.

[Example of certificate issuance system configuration]
FIG. 1 is a diagram showing an example of the configuration of the certificate issuing system 100 of the first embodiment. The certificate issuing system 100 of the first embodiment includes a server device 10, a device 20, a terminal 30, and a relay device 40.

The server device 10 is connected to the first network 501. The first network is a WAN (Wide Area Network) such as the Internet. In the first embodiment, the communication between the server device 10 and the terminal 30 and the communication between the server device 10 and the device 20 are performed via the first network 501. In the first embodiment, the case where the first network 501 is the Internet will be described as an example.

The device 20 and the terminal 30 are connected to the second network 502. The second network 502 is a local network such as a home, an office, or a factory. The medium of the local network is, for example, Ethernet (registered trademark) capable of realizing IP communication by an upper layer protocol, wireless LAN, or the like. As long as the network can realize the same functions as Ethernet (registered trademark) and wireless LAN, a specific medium or higher-level communication protocol does not matter. In the first embodiment, the case where the second network 502 is a local network (home network) constructed by a wireless LAN will be described as an example.

The server device 10 of the first embodiment is a certificate authority that issues a certificate certifying the validity of the domain of the device 20. In the first embodiment, the server device 10 realizes a function of issuing a certificate of the device 20 as a part of a function of a web service on the Internet operated by the manufacturer of the device 20. The server device 10 may be a certificate authority operated by a third party different from the manufacturer of the device 20.

The device 20 of the first embodiment is a device on the second network 502 that is accessed from the web service of the first network 501 via the execution unit 301 (web browser in the first embodiment) of the terminal 30. The device 20 includes an HTTP (HyperText Transfer Protocol) server function. In the first embodiment, the device 20 is a digital television. When the device 20 is a digital television, the web service of the first network 501 is, for example, a television remote control service (television cloud service) that discovers a digital television in a home and provides a television remote control function. In the first embodiment, the case where the TV remote control service is realized as a part of the function of the web service provided by the server device 10 will be described as an example.

The terminal 30 of the first embodiment is a terminal operated by a user. Here, the user is the owner of the device 20 and the terminal 30, and is also a user of the web service provided by the manufacturer of the device 20. In the first embodiment, the terminal 30 is a smart device such as a smartphone and a tablet terminal. The terminal 30 may be a personal computer or the like.

The terminal 30 includes an execution unit 301. The execution unit 301 executes the interface 107 for the server device 10 to provide the function to the terminal 30. The interface 107 of the first embodiment is a web page transmitted from the server device 10 to the terminal 30, and the execution unit 301 of the first embodiment is a web browser that executes the web page. The interface 107 is basically composed of HTML (HyperText Markup Language), CSS (Cascading Style Sheets), and Javascript (registered trademark) code, and has a function of confirming the existence of the domain of the device 20 (domain confirmation unit). 108) is realized. The execution unit 301 is not limited to the web browser, and may be, for example, an application running on the terminal 30. The user uses the device 20 (digital TV in the first embodiment), the execution unit 301 (web browser in the first embodiment) of the terminal 30 (smart device in the first embodiment), and the web of the TV remote control service. Display and operate the screen.

The relay device 40 is a device that relays communication between the server device 10 connected to the first network 501 and the devices 20 and the terminal 30 connected to the second network 502.

Next, the functional configuration of the server device 10 of the first embodiment will be described. The server device 10 of the first embodiment includes a device registration unit 101, a device authentication unit 102, an issue request response unit 103, a confirmation method response unit 104, a confirmation request response unit 105, an interface providing unit 106, an interface 107, and a domain confirmation unit 108. , The device URL response unit 109, the confirmation result reception unit 110, and the issue unit 111. The interface providing unit 106 provides the interface 107 to the terminal 30. The interface 107 includes a domain confirmation unit 108.

The device registration unit 101 registers the device of the device 20 by receiving the request for registering the public key of the key pair (public key and private key) generated by the device 20 from the device 20.

The specific method of device registration may be arbitrary. For example, the device registration unit 101 issues a MAC (Message Authentication Code) key to the device maker in advance. Next, the device maker embeds the MAC key in the device 20 before shipping. Next, the device 20 signs the public key with this MAC key, and transmits a registration request including the signed public key to the device registration unit 101. When the device registration unit 101 receives the registration request from the device 20, the device registration unit 101 verifies the signature to determine whether or not the registration request is from the device 20 that issued the MAC key. When the device registration unit 101 is a registration request from the device 20 that issued the MAC key, the device registration unit 101 registers the public key included in the registration request.

The device authentication unit 102 authenticates the device 20 by referring to the parameters (public key and signature) included in the communication data transmitted from the device 20 registered by the device registration unit 101. Specifically, the device authentication unit 102 authenticates the device 20 when the public key included in the communication data is registered and the signature included in the communication data is correct. The device authentication unit 102 has a function of issuing a random number and a random character string (nonce) to the device 20 to prevent a replay attack.

The issuance request response unit 103 receives a certificate issuance request from the device 20 registered by the device registration unit 101. Specifically, the issuance request response unit 103 receives a CSR (Certificate Signing Request) from the device 20 as a parameter of the issuance request when the device authentication by the device authentication unit 102 is passed. This CSR is a certificate signing request for a domain name (digital_tv.local, digital_tv.home.arpha, etc., hereinafter referred to as "local domain") used on the local network.

The confirmation method response unit 104 receives a domain confirmation method (called a “challenge” in ACME of Non-Patent Document 1) acquisition request from the device 20 that has sent the certificate issuance request, and the CSR is the certificate of the local domain. If it is a signing request, the confirmation method information is returned. The confirmation method information includes type information, identification information and tokens. The type information indicates information (“http-local-01” or the like) indicating that the confirmation method is for the local domain. The identification information indicates a challenge ID. The token includes numerical string data such as random numbers used at the time of domain confirmation, random character string data, and the like.

The confirmation request response unit 105 receives a domain confirmation request from the device 20 including a challenge ID, a token, and a signed public key used at the time of registration (hereinafter, this public key is referred to as "key authorization information"). It responds with a verification URL indicating the address of the interface. The verification URL includes a verification code (specific information) for uniquely identifying the certificate issuance request and the domain confirmation request from the device 20 in the server device 10. Examples of verification URLs include, for example, https://device-ca. sample. com / comfirm_local_domine. html # code = xxxxxxxxx and so on. In this example, device-ca. sample. com is the domain of the server device 10, and xxxxxxxxx corresponds to the verification code.

The interface providing unit 106 provides an interface 107 for confirming the domain of the device 20 on the local net. In the first embodiment, the interface providing unit 106 is a web server. The interface providing unit 106 has a user authentication function. The interface provider 106 responds only to a request from a logged-in user who has already registered as a user. Login authentication generally uses, but is not limited to, Cookie-based user session authentication or access token authentication widely used on the Web. The interface provider 106 responds to the access from a user who is not logged in with a login screen and requests user authentication.

The interface 107 is a front end of the server device 10 realized on the terminal 30. In the first embodiment, interface 107 is a web page.

The domain confirmation unit 108 is a function realized by the interface 107. In the first embodiment, the domain confirmation unit 108 is realized as a Javascript® code in a web page. The domain confirmation unit 108 transmits the verification code included in the above-mentioned verification URL to the server device 10. Next, the domain confirmation unit 108 uses the CSR information and token information (more specifically, the device URL for domain confirmation on the HTTP server of the device (httpt (s): /)) transmitted by the device 20 to the server device 10. /Digital-tv.local/.well-know/acme-challenge/ {token}, etc.) is acquired from the server device 10. Then, the domain confirmation unit 108 accesses the device URL and obtains the token and key authorization information. Obtained from device 20.

The device URL response unit 109 receives a connection from the domain confirmation unit 108 realized as the front end of the server device 10 on the terminal 30 connected to the second network 502 via the verification URL (server URL), and the terminal When the device URL acquisition request for which the verification code (specific information) is specified is received from 30, the domain and the token are specified from the specific information, and the device URL including the domain and the token is transmitted to the terminal 30.

The confirmation result reception unit 110 receives a parameter including a token and key authorization information from the domain confirmation unit 108 that has accessed the device URL.

The issuing unit 111 verifies whether or not the token issued as a challenge can be acquired from the domain of the device 20 that issued the challenge by using the parameters received by the confirmation result receiving unit 110. When the token issued as a challenge can be obtained from the domain of the device 20 that issued the challenge, the issuing unit 111 signs the CSR of the device 20 with the private key of its own server certificate, and the issuing unit 111 of the device 20 Generate a domain certificate. When the issuing unit 111 receives the certificate acquisition request from the device 20, if the domain confirmation is completed and the certificate issuance is completed, the issuing unit 111 sends the certificate to the device 20 in response to the acquisition request. To do.

Next, the functional configuration of the device 20 of the first embodiment will be described. The device 20 of the first embodiment includes an input control unit 201, a registration request unit 202, a domain generation unit 203, a CSR generation unit 204, an issue request transmission unit 205, a confirmation method acquisition request unit 206, a server processing unit 207, and a confirmation request transmission. A unit 208, a display control unit 209, and an acquisition unit 210 are provided.

The input control unit 201 accepts an input operation by the user. The input control unit 201 receives, for example, an input operation for turning on the setting for enabling access from the execution unit 301 (in the first embodiment, the web browser) of the terminal 30.

The registration request unit 202 generates device registration data including the public key generated by the device 20, and makes a registration request to the device registration unit 101 of the server device 10 based on the device registration data. The method of generating the device registration data will be described later with reference to FIG. 2A.

The domain generation unit 203 generates a domain name (domain_name), which is the name of the domain of the device 20.

The CSR generation unit 204 generates a certificate signing request (CSR) proving the validity of the domain name (domain_name) generated by the domain generation unit 203.

The issuance request transmission unit 205 transmits a certificate issuance request for the domain of the device 20 to the server device 10.

The confirmation method acquisition request unit 206 transmits a confirmation method acquisition request (challenge acquisition) to the server device 10 and acquires domain confirmation method (challenge) information. The description of the confirmation method acquisition request and the domain confirmation method (challenge) information will be described later with reference to FIG. 2A.

The server processing unit 207 executes the processing of the HTTP server operated by the device 20. The address of the HTTP server includes the domain name generated by the domain generation unit 203.

The confirmation request transmission unit 208 transmits a confirmation request (challenge selection) for the domain of the device 20 to the server device 10.

When the display control unit 209 receives the verification URL from the server device 10 as a response to the domain confirmation request, the display control unit 209 converts the verification URL into code information such as a QR code (registered trademark) and displays it on the display unit.

The acquisition unit 210 periodically inquires the server device 10 whether or not to issue a certificate when it receives an access for domain confirmation from the interface 107 of the terminal 30. Then, when the acquisition unit 210 acquires the certificate from the issuing unit 111 of the server device 10, the acquisition unit 210 installs the certificate in the device 20.

[Example of operation of certificate issuing system]
Next, an operation example of the certificate issuing system 100 of the first embodiment will be described.

2A and 2B are sequence diagrams showing an operation example of the certificate issuing system 100 of the first embodiment.

First, the preconditions will be described.

[Preliminary condition 1] The server device 10 (the organization that operates the server device 10) issues a MAC key (product_id, product_secret) to the device 20 in advance. The manufacturer of the device 20 embeds this MAC key in the device 20 at the time of manufacture. In the first embodiment, the organization that operates the server device 10 is the manufacturer of the device 20. Although the MAC key is a common key in the first embodiment, it may be an asymmetric key such as a client certificate.

[Precondition 2] The user is the owner of the device 20 (digital TV in the first embodiment), and is a cloud service for TV that realizes remote control of a web service (in the first embodiment, a TV remote control function, etc.). ), For example, the user is registered by the email address and password.

First, the input control unit 201 of the device 20 accepts an input operation for turning on the setting for enabling access from the execution unit 301 (web browser in the first embodiment) of the terminal 30 (step S1). At this time, the input control unit 201 may further accept an input operation for designating the email address registered in the server device 10. Further, when there are a plurality of server devices 10 operating as a certificate authority, the input control unit 201 may further accept an input operation for selecting the server device 10 from the candidates of the plurality of server devices 10.

Next, the registration requesting unit 202 of the device 20 generates a key pair for device registration (public key (clinent_pub) and private key (clinent_secret)) (step S2).

Next, the registration requesting unit 202 of the device 20 requests the server device 10 to issue a nonce for device registration (step S3). When the device authentication unit 102 of the server device 10 receives the nonce issuance request from the registration request unit 202, the device authentication unit 102 generates the nonce and transmits the nonce to the device 20 as a response to the issue request (step S3).

Next, the registration request unit 202 of the device 20 generates device registration data. The device registration data includes at least client_pub and nonce (step S4). At this time, when the device registration unit 101 of the server device 10 accepts only the registration from the product (device 20) for which the MAC key has been issued in advance, the registration request unit 202 of the device 20 has the device registration data. Include product_id in and sign it with product_secret.

Next, the registration request unit 220 of the device 20 makes a registration request to the device registration unit 101 of the server device 10 with the device registration data generated by the process of step S4 (step S5). The device registration unit 101 of the server device 10 verifies the signatures of the MAC, client_pub and nonce by client_secret, and registers the device 20 if it is correct.

The processing of steps S2 to S5 described above is omitted when the device registration to the server device 10 has already been executed.

Next, the domain generation unit 203 of the device 20 generates a domain name (domain_name) (step S6). At this time, the domain generation unit 203 enables mDNS and confirms that the domain name (domain_name) can be used on the second network 502 without collision. For example, as one implementation example, the domain generation unit 203 sets the domain_name to <UUID>. <Domain name of the server device operated by the device manufacturer>. Let it be local. Here, the UUID is a globally unique value generated from a MAC (Media Access Control) address or the like. The domain of the server device 10 is dtv. sample. In the case of com, for example, 2fac1234-31f8-11b4-a222-08002b34c003. dtv. sample. com. It becomes local and so on. This example is just an example, and the domain name generation method may be arbitrary as long as it does not collide with the second network 502.

Next, the CSR generation unit 204 of the device 20 generates a signing request (CSR) for a certificate certifying the validity of the domain_name generated by the process of step S6 (step S7). The CSR generation unit 204 may add the specified user's email address to the CSR contact information.

Next, the issuance request transmission unit 205 of the device 20 transmits a certificate issuance request of the domain of the device 20 to the server device 10 (step S8). The certificate issuance request includes the CSR generated by the process of step S7. When the device 20 is authenticated by the device authentication unit 102, the issuance request response unit 103 of the server device 10 accepts the CSR and transmits the identification information (autz_id) and the path information (cert_uri) to the device 20 as a response. .. The identification information (autz_id) is information for identifying a certificate issuance request. The path information (cert_uri) is information indicating the place where the certificate is placed when the certificate is issued. At this time, the issuance request response unit 103 stores information indicating that the domain name included in the CSR is a local domain together with the CSR. In addition, instead of using the information in the CSR, the certificate issuance request may include a parameter that explicitly indicates that the certificate is issued for the local network.

Next, the confirmation method acquisition request unit 206 of the device 20 transmits a confirmation method acquisition request (challenge acquisition) for which identification information (autz_id) is specified to the server device 10 to acquire domain confirmation method (challenge) information ( Step S9). When the device 20 is authenticated by the device authentication unit 102, the issue request response unit 103 of the server device 10 responds with the challenge information for the local domain. The challenge information for the local domain includes challenge identification information, type information (such as "http-local-01"), and tokens.

Next, the server processing unit 207 of the device 20 transmits the token and the signature data (key authorization information (key_autification)) to the specific path (.well-known / acme-challenge / {token) of the HTTP server that operates the device 20. } Etc.) (step S10). The signature data is data in which the public key (clinent_pub) is subjected to a hash function and encrypted with the private key (clinent_secret).

Next, the confirmation request transmission unit 208 of the device 20 transmits a confirmation request (challenge selection) of the domain of the device 20 to the server device 10 after the HTTP server is prepared by the server processing unit 207 (step S11). When the device 20 is authenticated by the device authentication unit 102, the confirmation request response unit 105 of the server device 10 includes a verification URL (verification_uri) including a temporarily valid verification code (code) for specifying the domain confirmation request as specific information. ) Is answered. This verification URL is the path of the interface (web screen) provided by the server device 10. The verification URL is, for example, https://dtv.com, as described above. sample. com / confirm_local_domine. HTML # code = xxxxxxxxx etc., and the verification code (code) can be referred to from the Javascript (registered trademark) code of the interface.

Next, when the display control unit 209 of the device 20 receives the verification URL from the server device 10 as a response in step S11, the verification URL is converted into code information such as a QR code (registered trademark) and displayed on the display unit. (Step S12). The display control unit 209 may display the character string of the verification URL as it is, but if the user knows the path of the interface 107 in advance, only the verification code may be displayed.

Next, the execution unit 301 of the terminal 30 accesses the verification URL acquired by reading the code information displayed in the process of step S12, and transitions to the interface 107 (domain confirmation web screen) (step S13).

Next, the interface 107 of the terminal 30 accepts a login operation if the user is not logged in (step S14).

Next, the domain confirmation unit 108 on the interface 107 acquires the verification code (code) included in the verification URL as specific information for specifying the domain confirmation request, and the server receives the device URL acquisition request including the verification code as a parameter. It is transmitted to the device 10 (step S15). The device URL response unit 109 of the server device 10 transmits the device URL (device_uri), which is the domain confirmation URL information of the HTTP server of the device 20, to the terminal 30 as a response to the device URL acquisition request.

The device URL (device_uri) includes the domain (domain name) and token of the device. device_uri is, for example, http (s): // {domine_name} /. Well-know / acme-challenge / {token} and the like.

Next, the interface 107 (domain confirmation unit 108) of the terminal 30 passes a parameter including a device URL (device_uri) indicating a path in which the token is installed by the device 20 to the execution unit 301, thereby causing the device to the execution unit 301. Request confirmation of the existence of 20 domains (step S16).

Next, the execution unit 301 of the terminal 30 accesses the device URL, acquires the token and key authorization information, and responds the token and key authorization information to the interface 107 (domain confirmation unit 108) (step S17).

Next, the acquisition unit 210 of the device 20 periodically inquires the server device 10 whether or not to issue a certificate, triggered by the access from the interface 107 of the terminal 30 (step S18).

Next, the interface 107 (domain confirmation unit 108) of the terminal 30 sends a domain confirmation registration request including the token and the key authorization information to the confirmation result reception unit 110 of the server device 10 (step S19).

Next, when the confirmation result receiving unit 110 of the server device 10 receives the token and key authorization information transmitted by the process of step S19, the issuing unit 111 verifies the token and key authorization information (step S20). Specifically, the confirmation result receiving unit 110 receives the device 20 that sent the domain confirmation request by the process of step S11, the token included in the domain confirmation request, and the terminal 30 by the process of step S19. It is verified whether or not the token and the key authorization information (the token and the key authorization information acquired from the HTTP server of the device 20 by the process of step S17) match.

Next, when the verification process of step S20 is successful, the issuing unit 111 of the server device 10 sends the CSR transmitted from the device 20 to the server device 10 in response to the certificate issuance request transmitted in the process of step S8. Sign with the private key and issue the certificate (step S21).

At this time, the issuing unit 111 may optionally return the certificate as a response to the domain confirmation registration request transmitted in the process of step S19. In this case, the interface 107 of the terminal 30 requests the execution unit 301 (in the first embodiment, the web browser) to register the certificate received from the server device 10 as a reliable certificate (step S22). Next, the execution unit 301 registers the certificate requested for registration by the process of step S22 as a trusted certificate (step S23). At this time, the execution unit 301 may also register the domain that handles the certificate registered by the process of step S23 as a trusted certificate so that it cannot be seen as a trusted certificate from other domains.

On the other hand, the acquisition unit 210 of the device 20 confirms that the status information included in the response to the certificate issuance request to be periodically transmitted is "issued" (step S24). Next, when the acquisition unit 210 acquires the certificate from the issuing unit 111 of the server device 10 (step S25), the acquisition unit 210 installs the certificate in the device 20 (step S26).

According to the certificate issuing system 100 of the first embodiment described above, the server certificate accessible from the web service on the first network 501 (Internet) is the device 20 on the second network 502 (local network). It can be issued to the HTTP server.

In the first embodiment, the case where the device 20 is a digital television has been described as an example, but the device 20 is not limited to the digital television. The equipment 20 may be, for example, home appliances other than digital TVs, housing equipment, factory equipment, building equipment, and the like. The certificate issuing system 100 of the first embodiment is expected to have a wide range of applications as a method for safely accessing a device on a local network from a web page on the Internet.

(Second Embodiment)
Next, the second embodiment will be described. In the description of the second embodiment, the same description as that of the first embodiment will be omitted, and the parts different from the first embodiment will be described.

The first embodiment is a method on the premise that the device 20 has an appropriate information display ability capable of displaying code information such as a QR code (registered trademark). The second embodiment describes an embodiment targeting the device 20 in which the above-mentioned verification URL (verification_uri) cannot be transmitted to the terminal 30 by using code information or the like. In the second embodiment, the case where the device 20 is an air conditioner will be described as an example.

[Example of certificate issuance system configuration]
FIG. 3 is a diagram showing an example of the configuration of the certificate issuing system 100 of the second embodiment. The certificate issuing system 100 of the second embodiment includes a server device 10, a device 20, a terminal 30, and a relay device 40.

In the second embodiment, the third network 503 is added. In addition, a communication control unit 211 that communicates with the terminal 30 via the third network 503 is added to the device 20.

The third network 503 is a network through which the device 20 and the terminal 30 can communicate safely (without leaking information). Specifically, the communication method of the third network 503 may be a wired method or a wireless method. In the case of the wired system, for example, USB (Universal Serial Bus), HDMI (registered trademark) (High-Definition Multimedia Interface), SDIO (Secure Digital Input / Output) and the like. In the case of a wireless system, it is a near field communication such as NFC (Near Field Communication) and a highly secure short range wireless communication such as BLE (Bluetooth (registered trademark) Low Energy). In the second embodiment, the case where the communication method of the third network 503 is BLE will be described as an example.

The communication control unit 211 of the device 20 communicates with the terminal 30 via the third network 503. In the second embodiment, the communication control unit 211 controls BLE communication with the terminal 30.

[Example of operation of certificate issuing system]
Next, an operation example of the certificate issuing system 100 of the second embodiment will be described.

4A to 4C are sequence diagrams showing an operation example of the certificate issuing system 100 of the second embodiment. In the first embodiment, the certificate issuance process is started from the device 20 side, but in the second embodiment, the certificate issuance process is started from the terminal 30 side.

Since the description of the prior conditions is the same as that of the first embodiment, the description thereof will be omitted.

First, the user of the terminal 30 loads the screen of the air conditioner operation web service (for example, https: //aircon.sample.com) (step S1).

Next, the server device 10 accepts the user's login via the screen loaded by the process of step S1 (step S2). When the server device 10 accepts the login, the server device 10 transmits the interface 107 (in the second embodiment, the domain confirmation web screen of the device 20) to the terminal 30.

Next, the interface 107 of the terminal 30 inputs a display request for the certificate issuance confirmation screen of the device 20 to the execution unit 301 (web browser) (step S3). At this time, the user information (email address, etc.) of the user logged in by the process of step S2 and the server device information (URL domain name of the server device 10 to which the device 20 sends a certificate issuance request, etc.) are input to the execution unit. You may pass it to 301.

Next, the execution unit 301 of the terminal 30 displays the certificate issuance confirmation screen (step S4). The certificate issuance confirmation screen displays a message such as "Do you want to find the air conditioner on your home network and control it from this page? [OK], [Cancel]".

Next, the execution unit 301 of the terminal 30 accepts the pressing of the OK button on the certificate issuance confirmation screen displayed by the process of step S4 (step S5).

Next, the execution unit 301 of the terminal 30 searches for the device 20 having the HTTP server function by using the BLE communication function of the device 30 (step S6). The search granularity may be arbitrary. The particle size of the search is, for example, a device type indicating an air conditioner, a specific model, or a MAC key ID (product_id) issued from the server device 10 to the device 20.

Next, when the execution unit 301 of the terminal 30 receives the response of the search process in step S6 from the device 20 having the HTTP server function, the execution unit 301 requests to acquire the device information such as the MAC key ID (product_id) and the device name. It is transmitted to the device 20 (step S7).

Next, since the execution unit 301 of the terminal 30 may find a plurality of devices 20, the execution unit 301 displays the device selection screen (step S8).

Next, the execution unit 301 of the terminal 30 accepts the selection of the device via the selection screen displayed by the process of step S8 (step S9).

Next, the execution unit 301 of the terminal 30 uses the BLE communication function of the terminal 30 to transmit a certificate issuance request of the device 20 to the device 20 (step S10). At this time, the execution unit 301 sets the above-mentioned user information and the above-mentioned server device information in the parameters of the certificate issuance request.

Next, the registration requesting unit 202 of the device 20 requests the server device 10 to issue a nonce for device registration (step S11). At this time, the registration requesting unit 202 can verify the server certificate of the server device 10 by using HTTPS communication.

Next, the device 20 notifies the receipt of the issuance request transmitted by the process of step S10 by illuminating the LED (Light Emitting Diode) (step S12).

Next, the device 20 accepts an operation for permitting the issuance of the certificate by pressing a button of the device 20 or the like (step S13). After confirming that the device 20 selected by the execution unit 301 of the terminal 30 matches the actual device 20, the user presses the button of the device 20 to re-authorize the issuance of the certificate.

The description of the process of steps S14 to S22 is the same as the description of step S2 and steps S4 to S11 of the first embodiment, and thus will be omitted.

Next, when the execution unit 301 of the terminal 30 receives the response (ok) of the issuance request transmitted by the process of step S10, the execution unit 301 obtains the verification URL (verification_uri) of the server device 10 by using the BLE function. The verification URL is returned to the interface 107 (step S23).

The description of the process of steps S24 to S35 is the same as the description of steps S15 to S26 of the first embodiment, and thus will be omitted.

According to the certificate issuing system 100 of the second embodiment described above, even when the device 20 does not have the display function, by using secure short-range communication (for example, BLE), the first embodiment The same effect as is obtained.

(Third Embodiment)
Next, the third embodiment will be described. In the description of the third embodiment, the same description as in the first and second embodiments will be omitted, and the parts different from the first and second embodiments will be described.

In the first and second embodiments, it is assumed that the device 20 can communicate with the server device 10 via the relay device 40. In the third embodiment, an embodiment for a device 20 that cannot be connected to the first network 501 such as the Internet will be described.

The configuration of the certificate issuing system 100 of the third embodiment is the same as that of the certificate issuing system 100 of the first embodiment (see FIG. 1).

[Example of operation of certificate issuing system]
Next, an operation example of the certificate issuing system 100 of the third embodiment will be described.

5A to 5C are sequence diagrams showing an operation example of the certificate issuing system 100 of the third embodiment. In the third embodiment, as in the second embodiment, the certificate issuance process of the device 20 is started from the terminal 30 side.

Since the description of the prior conditions is the same as that of the first embodiment, the description thereof will be omitted.

The description of the process of step S1 and step S2 will be omitted because it is the same as the description of steps S1 to S2 of the second embodiment.

Next, the interface 107 of the terminal 30 requests the server device 10 to issue a nonce (step S3).

Next, the interface 107 of the terminal 30 requests the execution unit 301 (in the third embodiment, the web browser) to issue a certificate of the device 20 (step S4). The certificate issuance request includes user information (user_info), a server certificate of the server device 10 (device_ca_info), and a nonce acquired by the process of step S3.

The description of the process of steps S5 to S10 will be omitted because it is the same as the description of steps S4 to S9 of the second embodiment.

Next, the execution unit 301 of the terminal 30 transmits a CSR generation request to the device 20 (step S11). The CSR generation request includes user information (user_info), a server certificate of the server device 10 (device_ca_info), and a nonce acquired by the process of step S3.

Next, the device 20 verifies the server certificate (device_ca_info) included in the CSR generation request transmitted by the process of step S11 (step S12). Specifically, the device 20 verifies the server certificate (device_ca_info) based on the information indicating the certificate of the reliable certificate authority installed in the device in advance.

The description of the process in step S13 will be omitted because it is the same as the description in step S13 of the second embodiment. The description of steps S14 and S15 is the same as the description of steps S17 and S18 of the second embodiment, and will be omitted.

Next, the CSR generation unit 204 of the device 20 generates a signature (MAC) of the CSR and nonce by product_secret (step S16). When the signature (MAC) can be generated, the CSR generation unit 204 of the device 20 transmits the response (ok) of the CSR generation request transmitted by the process of step S11 to the terminal 30.

Next, when the execution unit 301 of the terminal 30 receives the response (ok) of the CSR generation request, it transmits the CSR acquisition request to the device 20 (step S17). The CSR generation unit 204 of the device 20 transmits the CSR, MAC, and product_id to the terminal 30 in response to the CSR acquisition request. The execution unit 301 of the terminal 30 returns the CSR, MAC, and product_id to the interface 107 as a response to the certificate issuance request transmitted by the process of step S4.

Next, the interface 107 of the terminal 30 transmits a certificate issuance request to the server device 10 (step S18). The certificate issuance request includes CSR, MAC, and product_id as parameters.

Next, when the issuance request response unit 103 of the server device 10 verifies the MAC included in the issuance request transmitted by the process of step S18 and confirms that the signature is by the device 20 having the product_secret (step S19). ), Returns a success response. The content of the response is the same as the response of the issuance request in step 8 of the first embodiment.

The description of step S20 is the same as that of step S9 of the first embodiment, except that the request is from the interface 107, not from the device 20.

Next, the interface 107 of the terminal 30 selects the challenge returned as a response to the confirmation method acquisition request (challenge acquisition) transmitted in the process of step S20, and transmits the domain confirmation request of the device 20 to the server device 10. (Step S21). The confirmation request response unit 105 of the server device 10 identifies the CSR received from the terminal 30 by the issuance request of the certificate transmitted in the process of step S18 from the identification information (autz_id) included in the confirmation method acquisition request. The confirmation request response unit 105 transmits the domain name (device_domain), token, and nonce of the device 20 included in the specified CSR to the terminal 30 as a response to the confirmation request.

Next, the interface 107 of the terminal 30 transmits a confirmation request for the domain of the device 20 to the execution unit 301 (step S22). The domain confirmation request includes the domain name, token, and nonce included in the response of the confirmation method acquisition request transmitted by the process of step S21.

Next, the execution unit 301 of the terminal 30 requests the device 20 to start the HTTP server by transmitting a challenge installation request including a token and a nonce to the device 20 by using the BLE function of the terminal 30 (step). S23).

Next, the server processing unit 207 of the device 20 transmits the token and the MAC (hereinafter referred to as "key authorization information") of the data including the nonce and the product_id provided by the server device 10 via its own HPTP server. It is saved in an accessible directory (device URL for domain confirmation), and if necessary, the HTTP server is started or restarted, and a response is returned to the execution unit 301 of the terminal 30 (step S24). The device URL is, for example, http (s): // digital-tv. local /. Well-know / acme-challenge / {token} and the like.

Next, when the execution unit 301 of the terminal 30 receives the response of the challenge installation request transmitted by the process of step S23, it accesses the device URL and is saved by the device 20 by the process of step S23 from the device URL. Acquire the token and key authorization information (step S25). The execution unit 301 returns the token and the key authorization information acquired from the device 20 to the interface 107.

Next, the interface 107 of the terminal 30 transmits a certificate acquisition request to the server device 10 (step S26). The certificate acquisition request includes token and key authorization information.

Next, the issuing unit 111 of the server device 10 verifies the token and key authorization information included in the acquisition request transmitted by the process of step S26 (step S27).

Next, if the issuing unit 111 of the server device 10 can confirm that the data is signed by product_secret as a result of the verification process in step S27, it generates a certificate for the device 20 and obtains the certificate transmitted by the process in step S26. In response to the request, the certificate is transmitted to the terminal 30 (step S28).

Next, the interface 107 of the terminal 30 instructs the execution unit 301 to pass the certificate generated by the process of step S28 to the device 20 (step S29).

Next, the execution unit 301 of the terminal 30 transmits the installation request of the certificate generated by the process of step S28 to the device 20 (step S30).

Next, the acquisition unit 210 of the device 20 installs the certificate included in the installation request transmitted by the process of step S30 (step S31). At this time, the acquisition unit 210 may confirm that the certificate has been signed by the intended certificate authority by verifying the signature.

Next, the execution unit 301 of the terminal 30 may install the certificate generated by the process of step S28 as a reliable certificate after the sequence of the installation request (steps S29 to S31). Good (step S32).

According to the certificate issuing system 100 of the third embodiment described above, it is the same as that of the first embodiment even if the device 20 does not perform communication for connecting to the first network 501 (Internet communication in the third embodiment). The effect of is obtained.

(Fourth Embodiment)
Next, the fourth embodiment will be described. In the description of the fourth embodiment, the same description as in the second and third embodiments will be omitted, and the parts different from the second and third embodiments will be described.

In the first to third embodiments, the case where the terminal 30 accesses the HTTP server of the device 20 by using the web page (interface 107) generated by the server device 10 has been described. In the fourth embodiment, a case where the second interface 122 (see FIG. 6) provided by the third party service accesses the HTTP server of the device 20 will be described. In a specific example of the fourth embodiment, for example, the device 20 is a digital television, the provider of the certificate authority service provided by the server device 10 is a digital television maker, and the operator is different from the digital television maker (third). Person) provides a cloud service for television.

[Example of certificate issuance system configuration]
FIG. 6 is a diagram showing an example of the configuration of the certificate issuing system 100 of the fourth embodiment. The certificate issuing system 100 of the fourth embodiment includes a server device 10, a second server device 12, a device 20, a terminal 30, and a relay device 40. In the fourth embodiment, the second server device 12 is added in addition to the configuration of the second embodiment. Further, the server device 10 has an additional function (client registration unit 112 and client authentication unit 113) for registering and authenticating the second server device 12.

The second server device 12 provides a web service operated by a business operator different from the server device 10 that issues a server certificate to the device 20. The second server device 12 includes a second interface providing unit 121 that provides the second interface 122 to the terminal 30.

The second interface 122 is an interface for the second server device 12 to access the HTTP server of the device 20 via the terminal 30. In the fourth embodiment, the second interface 122 is a web page.

Upon receiving the registration request from the client (second server device 12), the client registration unit 112 of the server device 10 generates a client credential (client ID and client secret) and responds to the client credential. It should be noted that a realization form in which the public key is received from the client and the public key is regarded as the client ID is also conceivable as in the device registration unit 101 described above. Further, it is conceivable that the operator of the second server device 12 issues the credential after registering the user via the web page provided by the server device 10.

The client authentication unit 113 of the server device 10 authenticates the communication from the client (second server device 12) using the client credentials.

[Example of operation of certificate issuing system]
Next, an operation example of the certificate issuing system 100 of the fourth embodiment will be described.

7A and 7B are sequence diagrams showing an operation example of the certificate issuing system 100 of the fourth embodiment.

As the preconditions, in addition to the preconditions 1 and 2 of the second and third embodiments, the following preconditions 3 and 4 are further added.

[Preliminary condition 3] The user has also registered the user in the second server device 12.
[Preliminary condition 4] The second server device 12 (the organization that operates the server device 12) registers the client in the server device 10 and acquires the above-mentioned client credentials in advance.

First, the user of the terminal 30 accesses the second server device 12 and loads the second interface 122 into the execution unit 301 (step S1).

Next, the user of the terminal 30 logs in to the second server device 12 via the second interface 122 (step S2).

Next, the second interface 122 of the terminal 30 performs the same processing as in steps S3 to S23 of the second embodiment to obtain a verification URL (verification_uri) (FIG. 7A, step S3). Alternatively, the second interface 122 of the terminal 30 performs the same processing as in steps S4 to S17 of the third embodiment to obtain a product_id, CSR, and MAC (FIG. 7B, step S3). In either case, the interface unit 122 provides the execution unit 301 with not only the user information (user_info) and the server certificate (device_ca_info) of the server device 10 but also the information of the second server device 12 (domain name (origin)). Etc.) (hereinafter referred to as "web_app_info") may be passed.

Next, in the case of following the second embodiment, the second interface 122 of the terminal 30 passes the URI information (redirect URI) of the screen returned after issuing the certificate to validation_uri to redirect the screen (FIG. 7A, step). S4). Further, in the case of following the third embodiment, when the second server device 12 acquires the product_id, CSR and MAC from the second interface 122, it passes the product_id, CSR and MAC to the server device 10 and obtains the validation_uri as a response. After that, the redirect URI is passed to redirect the screen (FIG. 7B, step S4).

Next, the issuing unit 111 of the server device 10 issues a certificate by performing the same processing as in steps S24 to S32 of the second embodiment when following the second embodiment (FIG. 7A, step). S5). Further, in the case of following the third embodiment, the issuing unit 111 of the server device 10 issues a certificate by performing the same processing as in steps S18 to S32 of the third embodiment (FIG. 7B, step). S5). At this time, the device 20 uses the web_app_info to generate its own domain name and is set to accept access to the HTTP server from the second interface 122 (CORS (Cross Origin Resource Sharing) setting). May be good.

Next, the server device 10 and the interface 107 transition the screen to the above-mentioned redirect URL after issuing the certificate (step S6).

According to the certificate issuing system 100 of the fourth embodiment described above, it is possible to issue a certificate to the device 20 starting from the second interface 122 of the second server device 12.

Finally, an example of the hardware configuration of the main parts of the server device 10, the device 20, and the terminal 30 according to the first to fourth embodiments will be described. The hardware configuration of the main part of the second server device 12 of the fourth embodiment is the same as the hardware configuration of the main part of the server device 10.

[Example of hardware configuration]
FIG. 8 is a diagram showing an example of the hardware configuration of the main parts of the server device 10, the device 20, and the terminal 30 according to the first to fourth embodiments. The server device 10, the device 20, and the terminal 30 of the first to fourth embodiments include a control device 401, a main storage device 402, an auxiliary storage device 403, a display device 404, an input device 405, and a communication device 406. The control device 401, the main storage device 402, the auxiliary storage device 403, the display device 404, the input device 405, and the communication device 406 are connected via the bus 410.

The control device 401 executes the program read from the auxiliary storage device 403 to the main storage device 402. The control device 401 is a general-purpose processor such as a CPU (Central Processing Unit). The main storage device 402 is a memory such as a ROM (Read Only Memory) and a RAM (Random Access Memory). The auxiliary storage device 403 is a memory card, an HDD (Hard Disk Drive), or the like.

The display device 404 displays information. The display device 404 is, for example, a liquid crystal display. The device 20 of the second embodiment (for example, an air conditioner) may not include the display device 404. The input device 405 accepts the input of information. The input device 405 is, for example, a hardware key, a keyboard, a mouse, or the like. The display device 404 and the input device 405 may be a liquid crystal touch panel or the like that has both a display function and an input function. Communication device 406 communicates with other devices.

The programs executed by the server device 10, the device 20, and the terminal 30 of the first to fourth embodiments are files in an installable format or an executable format, such as a CD-ROM, a memory card, a CD-R, and a DVD. It is stored in a computer-readable storage medium such as (Digital Versaille Disk) and provided as a computer program product.

Further, the programs executed by the server devices 10, the devices 20 and the terminals 30 of the first to fourth embodiments are stored on a computer connected to the first network 501 such as the Internet, and downloaded via the first network 501. It may be configured to provide by. Further, the programs executed by the server device 10, the device 20 and the terminal 30 of the first to fourth embodiments may be configured to be provided via the first network 501 such as the Internet without downloading.

Further, the programs executed by the server device 10, the device 20 and the terminal 30 of the first to fourth embodiments may be configured to be provided by incorporating them into a ROM or the like in advance.

The program executed by the server device 10, the device 20 and the terminal 30 of the first to fourth embodiments includes a function that can be realized by the program among the functional configurations of the server device 10, the device 20 and the terminal 30 of the embodiment. It has a modular structure.

The function realized by the program is loaded into the main storage device 402 by the control device 401 reading the program from a storage medium such as the auxiliary storage device 403 and executing the program. That is, the function realized by the program is generated on the main storage device 402.

Note that some of the functions of the server device 10, the device 20, and the terminal 30 of the first to fourth embodiments may be realized by hardware such as an IC (Integrated Circuit).

Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other embodiments, and various omissions, replacements, and changes can be made without departing from the gist of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are also included in the scope of the invention described in the claims and the equivalent scope thereof.

10 Server device 20 Equipment 30 Terminal 40 Relay device 100 Certificate issuance system 101 Equipment registration unit 102 Equipment authentication unit 103 Issuance request response unit 104 Confirmation method response unit 105 Confirmation request response unit 106 Interface provider 107 Interface 108 Domain confirmation unit 109 Equipment URL response unit 110 Confirmation result reception unit 111 Issuer 112 Client registration 113 Client authentication 201 Input control 202 Registration request 203 Domain generation 204 CSR generation 205 Issue request transmission 206 Confirmation method acquisition request 207 Server processing 208 Confirmation request transmission unit 209 Display control unit 210 Acquisition unit 211 Communication control unit 301 Execution unit 401 Control device 402 Main memory device 403 Auxiliary storage device 404 Display device 405 Input device 406 Communication device 410 Bus

Claims (11)

A server device connected to the first network
When a request for issuance of a certificate including the domain of the device and certifying the validity of the domain is received from a device connected to the second network, an issuance request for transmitting identification information identifying the issuance request to the device. Response section and
Upon receiving a confirmation method acquisition request for which the identification information is specified from the device, a confirmation method response unit that transmits a token used for confirmation of the existence of the domain to the device.
When a domain confirmation request including the token and signature data is received from the device, a confirmation request for transmitting a server URL (Uniform Resource Locator) including specific information specifying the issuance request and the domain confirmation request to the device. Response part and
When a connection is received from a terminal connected to the second network via the server URL and a device URL acquisition request for which the specific information is specified is received from the terminal, the domain and the token are obtained from the specific information. A device URL response unit that identifies the device URL and transmits the device URL including the domain and the token to the terminal.
When a domain confirmation registration request including the token acquired from the device URL and the signature data is received from the terminal that has succeeded in connecting the device URL, the issuing unit that issues the certificate and the issuing unit.
A server device that comprises. The signature data is data obtained by applying a hash function to a public key generated by the device and encrypting it with a private key.
The server device according to claim 1. The issuance request includes CSR (Certificate Signing Request).
When the issuing unit receives the domain confirmation registration request from the terminal that has succeeded in connecting the device URL, the issuing unit issues the certificate by signing the CSR with the private key of the server device.
The server device according to claim 1. The first network is the Internet.
The second network is a local area network.
The server device according to claim 1. A device connected to the second network that communicates with a server device connected to the first network and communicates with a terminal connected to the second network.
An issuance request transmission unit that transmits a certificate issuance request certifying the validity of the domain of the device to the server device and receives identification information for identifying the issuance request from the server device.
A confirmation method acquisition request unit that sends a confirmation method acquisition request to which the identification information is specified and receives a token used for confirmation of the existence of the domain from the server device.
A server processing unit that arranges the token and signature data in the device URL including the domain, and
A confirmation request transmission unit that transmits a domain confirmation request including the token and the signature data to the server device, and receives a server URL (Uniform Resource Locator) including specific information that identifies the domain confirmation request from the server device. When,
A reception unit that accepts a connection from the terminal that has acquired a device URL including the domain and the token from the server device via the server URL via the device URL.
When the terminal succeeds in connecting the device URL, the acquisition unit that acquires the certificate from the server device and
Equipment equipped with. A display control unit that displays code information including the server URL on the display unit,
Further prepare
The device according to claim 5. A communication control unit that transmits the server URL to the terminal via the third network.
Further prepare
The device according to claim 5. This is a certificate issuance method for server devices connected to the first network.
When a request for issuance of a certificate including the domain of the device and certifying the validity of the domain is received from the device connected to the second network, the step of transmitting the identification information identifying the issuance request to the device. ,
Upon receiving a confirmation method acquisition request for which the identification information is specified from the device, a step of transmitting a token used for confirmation of the existence of the domain to the device, and
When a domain confirmation request including the token and signature data is received from the device, a step of transmitting a server URL (Uniform Resource Locator) including specific information specifying the issuance request and the domain confirmation request to the device. ,
When a connection is received from a terminal connected to the second network via the server URL and a device URL acquisition request for which the specific information is specified is received from the terminal, the domain and the token are obtained from the specific information. And the step of transmitting the device URL including the domain and the token to the terminal.
When a domain confirmation registration request including the token obtained from the device URL and the signature data is received from the terminal that has succeeded in connecting the device URL, the step of issuing the certificate and the step of issuing the certificate.
Certificate issuance method including. It is a certificate request method for a device connected to the second network, which communicates with a server device connected to the first network and communicates with a terminal connected to the second network.
A step of transmitting a certificate issuance request certifying the validity of the domain of the device to the server device and receiving identification information for identifying the issuance request from the server device.
A step of transmitting a confirmation method acquisition request in which the identification information is specified and receiving a token used for confirmation of the existence of the domain from the server device.
A step of arranging the token and the signature data in the device URL including the domain, and
A step of transmitting a domain confirmation request including the token and the signature data to the server device, and receiving a server URL (Uniform Resource Locator) including specific information specifying the domain confirmation request from the server device.
A reception unit that accepts a connection from the terminal that has acquired a device URL including the domain and the token from the server device via the server URL via the device URL.
When the terminal succeeds in connecting the device URL, the step of acquiring the certificate from the server device and
Certificate request method including. The server device connected to the first network,
When a request for issuance of a certificate including the domain of the device and certifying the validity of the domain is received from a device connected to the second network, an issuance request for transmitting identification information identifying the issuance request to the device. Response section and
Upon receiving a confirmation method acquisition request for which the identification information is specified from the device, a confirmation method response unit that transmits a token used for confirmation of the existence of the domain to the device.
When a domain confirmation request including the token and signature data is received from the device, a confirmation request for transmitting a server URL (Uniform Resource Locator) including specific information specifying the issuance request and the domain confirmation request to the device. Response part and
When a connection is received from a terminal connected to the second network via the server URL and a device URL acquisition request for which the specific information is specified is received from the terminal, the domain and the token are obtained from the specific information. A device URL response unit that identifies the device URL and transmits the device URL including the domain and the token to the terminal.
When a domain confirmation registration request including the token acquired from the device URL and the signature data is received from the terminal that has succeeded in connecting the device URL, the issuing unit that issues the certificate.
A certificate issuing program to function as. A device connected to the second network that communicates with a server device connected to the first network and communicates with a terminal connected to the second network.
An issuance request transmission unit that transmits a certificate issuance request certifying the validity of the domain of the device to the server device and receives identification information for identifying the issuance request from the server device.
A confirmation method acquisition request unit that sends a confirmation method acquisition request to which the identification information is specified and receives a token used for confirmation of the existence of the domain from the server device.
A server processing unit that arranges the token and signature data in the device URL including the domain, and
A confirmation request transmission unit that transmits a domain confirmation request including the token and the signature data to the server device, and receives a server URL (Uniform Resource Locator) including specific information that identifies the domain confirmation request from the server device. When,
A reception unit that accepts a connection from the terminal that has acquired a device URL including the domain and the token from the server device via the server URL via the device URL.
An acquisition unit that acquires the certificate from the server device when the terminal succeeds in connecting the device URL.
A certificate requesting program to function as.

Images