Providing and installing digital certificates

Abstract

The invention relates to providing and installing digital certificates. The invention relates to providing a digital certificate to a device. It comprises receiving a device identification data set, the device identification data set uniquely identifying the device. It further comprises determining a key creation data set comprising a certificate identifier, the certificate identifier being based on the device identification data set. It further comprises sending the key creation data set to the device. It further comprises receiving a certificate creation request from the device based on the key creation data set, the certificate creation request relating to a first domain name, wherein the first domain name comprises the certificate identifier. It further comprises sending the certificate creation request or a modified certificate creation request to a certificate authority. It further comprises providing the digital certificate to the device, wherein the digital certificate is a wildcard certificate based on the first domain name signed by the certificate authority. The invention further relates to installing a digital certificate on a device.

Description

Technical Field

[0001] The present invention generally relates to providing and installing digital certificates, and more specifically, to a computer-implemented method for providing digital certificates to a device, a computer-implemented method for installing digital certificates on a device, a server configured to provide digital certificates to a device, a device for installing digital certificates, a computer program product, and a computer-readable storage medium. Background Technology

[0002] The security of information technology (IT) devices or systems is typically based on digital certificates (or "anchors of trust") that can be used for secure communication between different devices, such as those based on HTTPS (Hypertext Transfer Protocol Security) or FTPS (File Transfer Protocol Security). Specifically, digital certificates can be used for client-server communication.

[0003] The security of IT systems is crucial for medical technology, both because it is necessary to protect medical-related systems from malicious attacks (to ensure that patients are not harmed by compromised data or damaged hardware), and because patient data is personal data and should not be exposed to the public for data privacy reasons.

[0004] Several existing solutions exist for creating and distributing digital certificates within local IT infrastructures, particularly within hospital IT infrastructures.

[0005] For example, a self-signed certificate (signed by the corresponding device manufacturer or signed within the local IT infrastructure) can be used for each device in the local IT infrastructure to enable secure communication between local devices. However, self-signed certificates are not trusted by modern internet browsers and can cause communication to be blocked by the browser or at least display a security warning to the end user.

[0006] Alternatively, an internal trust authority can be used within the local IT infrastructure, such as on a dedicated server. However, establishing such an internal trust authority is complex and can be very costly.

[0007] For many on-premises IT infrastructures, it is desirable for a service provider to offer certificate infrastructure (in the sense of "secure communications as a service" or "digital certificates as a service"). The provided digital certificates may be based on domains controlled by the service provider (e.g., "abc.service-provider.com"); however, requests to these domains (e.g., HTTPS requests) cannot be resolved to local IP addresses within the on-premises IT infrastructure. Alternatively, the provided digital certificates may be based on domains controlled by the on-premises IT infrastructure (e.g., "abc.hospital-xyz.com"); however, the service provider cannot request certificates based on such domains because it cannot prove ownership, for example, based on the ACME protocol.

[0008] Furthermore, it would be desirable if the service could be initiated and controlled by users or administrators from their local IT infrastructure as a self-service facility, minimizing the amount of work that needs to be performed at the service provider's location. Summary of the Invention

[0009] The problem with this invention is to enable the creation and provision of digital certificates by a server outside the local IT infrastructure for devices within the local IT infrastructure. Specifically, the local IT infrastructure corresponds to the IT infrastructure of a healthcare provider such as a hospital.

[0010] The problem is solved according to the independent claims. Other advantageous embodiments and additional advantageous features are described in the dependent claims and the specification.

[0011] In the following, the solution according to the invention is described with respect to the claimed system and the claimed method. Features, advantages, or alternative embodiments described herein can be assigned to other corresponding claimed objects, and vice versa. In other words, the system can be improved using features described or claimed in the context of the corresponding method. In this case, the functional characteristics of the method are embodied by the target unit of the system.

[0012] Furthermore, the solutions according to the present invention are described below with respect to different methods and systems (devices and servers) for providing and installing digital certificates. The features, advantages, or alternative embodiments described herein can be assigned to other corresponding methods and systems, and vice versa. In other words, the first method and / or first system for providing or installing digital certificates can be improved using features described or claimed in the context of a second method and / or second system for providing or installing digital certificates.

[0013] In the following text, the term "specifically" is used to indicate optional and / or advantageous additional features. Furthermore, the terms "send," "provide," or "transmit" at least one object to an entity may mean sending, providing, or transmitting at least one object directly to a receiving entity, or sending, providing, or transmitting at least one object using at least one intermediate entity that forwards and / or processes the object. Similarly, the term "receive" at least one object from an entity may mean receiving at least one object directly from the entity, or receiving at least one object using at least one intermediate entity that forwards and / or processes the object.

[0014] In one aspect, the present invention relates to a computer-implemented method for providing a digital certificate to a device. The method includes receiving a device identification dataset that uniquely identifies the device. The method further includes determining a key creation dataset including a certificate identifier based on the device identification dataset. The method further includes sending the key creation dataset to the device. The method further includes receiving from the device a certificate creation request associated with a first domain name based on the key creation dataset, wherein the first domain name includes the certificate identifier. The method further includes sending a certificate creation request or a modified certificate creation request to a certificate authority. The method further includes providing a digital certificate to the device, wherein the digital certificate is a wildcard certificate based on the first domain name signed by a certificate authority.

[0015] Specifically, the method for providing a digital certificate to the device is executed by the server. Specifically, the step of receiving the device identification dataset is executed by an interface, specifically by the server's interface. Specifically, the step of determining the key creation dataset is executed by a computing unit, specifically by the server's computing unit. Specifically, the step of sending the key creation dataset to the device is executed by an interface, specifically by the server's interface. Specifically, the step of receiving a certificate creation request is executed by an interface, specifically by the server's interface. Specifically, the step of sending a certificate creation request is executed by an interface, specifically by the server's interface. Specifically, the step of providing the digital certificate is executed by an interface, specifically by the server's interface.

[0016] Specifically, the device identification dataset is a set of information identifying the device to which the method will provide a digital certificate. The device identification dataset may include information directly related to the device as well as information related to the device's environment (e.g., the healthcare facility where the device is located). Specifically, the device identification dataset may be stored in a database, manually entered by a system user, or stored directly within the device.

[0017] Specifically, a digital certificate is an electronic document that can be used to prove ownership of a public key. The terms "public key certificate" and "identity certificate" can be used synonymously with the term "digital certificate." Specifically, a digital certificate includes a public key and / or information about the public key, the digital certificate subject, and the digital signature of the issuer. Specifically, the subject of a digital certificate can be the owner of the digital certificate and / or information related to the owner of the digital certificate. Specifically, the issuer is the entity that has verified the content of the certificate. Specifically, the issuer can be a certificate authority.

[0018] Specifically, a digital certificate can be an X.509 certificate. A digital certificate being an X.509 certificate means that it conforms to the X.509 standard.

[0019] Specifically, a digital certificate can be a TLS (Transport Layer Security) or SSL (Secure Sockets Layer) server certificate. Specifically, the body of a TLS or SSL server certificate is a hostname and / or domain name. In the following text, the term "server certificate" may be used as a synonym for the term "TLS or SSL server certificate".

[0020] Specifically, a wildcard digital certificate is a server certificate that includes an asterisk in the hostname and / or domain name. In particular, the asterisk can be replaced with any other valid string. For example, a wildcard digital certificate with the body "*.example.com" will also work for "abc.example.com" and "def.example.com".

[0021] Specifically, a certificate identifier is a string that can be used to identify a specific certificate or a specific set of certificates. Specifically, a certificate identifier can be a unique certificate identifier, such that for a single unique certificate identifier, there is no more than one (unrevoked) certificate identified by that unique certificate identifier. Specifically, a certificate identifier can be a hash value. Specifically, a certificate identifier can be a hash of a device identifier dataset. Alternatively, a certificate identifier can be based on publicly available information about the certificate's subject (e.g., based on the material number and / or serial number of the device authorized by the certificate). Certificates can be revoked in certain circumstances, such as after a period of time, or if they are compromised because their respective private keys become public. In these cases, for example, based on the method according to the invention, a new certificate is created based on a new pair of public and private keys. Such a new certificate can be based on the same certificate identifier as the previously revoked certificate. This has the advantage that the domain name stored in other communication devices does not need to be changed.

[0022] Specifically, the key creation dataset includes the information required for the device to initiate the creation of a digital certificate. Specifically, the key creation dataset may include a certificate identifier, which will subsequently be used to identify and verify the certificate. Furthermore, the key creation dataset may include a pre-shared secret, which will be transmitted from the device back to the server at a later stage and can be used to authenticate the request to create the certificate. Instead of transmitting the pre-shared secret along with the key creation dataset, the pre-shared secret may also be stored in the device during the manufacturing stage at the manufacturer. Additionally, the key creation dataset may include a certificate request domain name, which corresponds to a URL (an abbreviation for "Uniform Resource Locator"), a URI (an abbreviation for "Uniform Resource Identifier"), and / or an IP address (an abbreviation for "Internet Protocol"), specifically an IPv4 or IPv6 address.

[0023] Specifically, a certificate request domain or certificate request domain name is a domain name used to request a digital certificate. Specifically, a certificate request domain can be a URL associated with a certificate authority and / or a URL associated with an Enrollment over Secure Transport (EST) server.

[0024] Specifically, the certificate creation request includes information required for the server to verify and forward the creation of the digital certificate after the device initiates the creation process. Specifically, the certificate creation request may include a public key corresponding to a private key stored within the device, such that the public key and the private key form an asymmetric key pair. Furthermore, the certificate creation request may include a pre-shared secret, which is equivalent to the pre-shared secret transmitted to the device and can be used to authenticate the certificate creation request. Specifically, the certificate creation request may include a first domain name containing a certificate identifier. Specifically, the modified certificate creation request may be identical to the certificate signing request disclosed in this specification.

[0025] Specifically, a domain name is an identifier string that defines a domain of administrative autonomy, authority, or control within the Internet. In particular, a domain name identifies a network domain or a resource on the Internet (associated with an IP address), such as a server or network service.

[0026] Specifically, a domain name consists of an ordered set of tags (the term "level" can be used as a synonym for the term "tag"), each separated by a special character (the dot "."). The rightmost level represents the top level and can be a country code top level (e.g., "de", "uk", "nl") or a generic top level (e.g., "com", "org", "net").

[0027] Domain names can include asterisks (the character "*"). Such domain names can be represented as wildcard domain names. Wildcard domain names represent a larger set of domain names, where each domain name in the larger set has the asterisk character replaced by a string or tag.

[0028] A fully qualified domain name (FQDN) is a domain name that is fully specified using all tags in the domain name system hierarchy, without omitting any parts. Specifically, FQDNs can be resolved by DNS servers (the abbreviation for "domain name system"). Notably, FQDNs do not include wildcards.

[0029] If the domain name is a wildcard domain name and if the fully qualified domain name can be created from the domain name by replacing the asterisk with a string or tag, then the fully qualified domain name is represented as specifying a domain name. Conversely, if the domain name is a fully qualified domain name that specifies the wildcard domain name, then the wildcard domain name is represented as representing a domain name.

[0030] A Certificate Authority (or sometimes “certification authority”) is an entity that issues digital certificates that verify ownership of a public key through the name of the digital certificate's subject. Specifically, the issuance of a digital certificate is based on signing the certificate using the certificate authority's private key. This allows others (the relying party) to rely on the signature or the authentication made regarding the private key corresponding to the verified public key. The certificate authority acts as a trusted third party—trusted by both the digital certificate's subject (owner) and the party relying on the digital certificate.

[0031] The inventors recognized that, using the described method, digital certificates can be provided to devices in a self-service mode. Specifically, by receiving device identification information that can be entered in various ways, the process of providing digital certificates can begin with hospital staff, without interference from the service owner.

[0032] According to another aspect of the invention, the device identification dataset includes at least one of the device's serial number, the device's material number, the device's supplier name, and / or the device's model name.

[0033] Specifically, the material number is an alphanumeric string that identifies all devices with the same attributes (i.e., identical devices). Specifically, the serial number is an alphanumeric string that distinguishes all devices with the same attributes (i.e., identical devices). Specifically, the serial number can also be an alphanumeric string that distinguishes all devices from a particular supplier. The supplier name of the equipment can be an alphanumeric string that identifies the supplier or manufacturer of the equipment. The model name of the equipment can be an alphanumeric string that identifies a group of material numbers (e.g., a model series) with different material numbers.

[0034] The inventors recognized that using these elements as a device identification dataset could uniquely identify devices. Furthermore, because some of these elements are redundant, security checks could be performed to ensure that the device identification dataset was actually valid.

[0035] According to another aspect of the invention, the method further includes: querying information related to the device from a database, and receiving from the database the device's serial number, material number, supplier name, and / or model name. Specifically, the steps of querying the database and receiving the serial number can be performed by a computing unit, particularly by the computing unit of the providing system, or by an interface, particularly by the interface of the providing system. The database can be external to the providing system or a component of the providing system. Specifically, information contained only in a device identification dataset can be received from the database.

[0036] The inventors realized that by retrieving the corresponding data elements from the database, user input was eliminated, which reduced the likelihood of errors when manually entering these data elements.

[0037] According to another aspect of the invention, the device identifier dataset includes an organization identifier, wherein the organization identifier identifies the organization hosting the device, and wherein the organization identifier is determined based on the credentials of an active user.

[0038] Specifically, the organization identifier can be an alphanumeric string. Specifically, an active user's credentials can correspond to the active user's username. Specifically, an active user is the user currently logged into the system. Specifically, there can be a unique mapping from user credentials to organization identifiers stored in the database, but for a single organization identifier, there can be several user credentials (i.e., a 1:n relationship exists between organization identifiers and user credentials).

[0039] The inventors recognized that by using the organization identifiers in the device identifier dataset, a relationship could be established between the organization requesting the certificate and the device identifier dataset. In particular, the validity of the device identifier dataset could be determined based on whether the organization was eligible to request the certificate.

[0040] Specifically, the equipment identification dataset includes an organization identifier. Specifically, the equipment identification dataset includes the equipment model name. Specifically, the equipment identification dataset includes the equipment model name and organization identifier. Specifically, the equipment identification dataset includes the equipment supplier name. Specifically, the equipment identification dataset includes the equipment supplier name and organization identifier. Specifically, the equipment identification dataset includes the equipment supplier name and equipment model name. Specifically, the equipment identification dataset includes the equipment supplier name, equipment model name, and organization identifier. Specifically, the equipment identification dataset includes the equipment material number. Specifically, the equipment identification dataset includes the equipment material number and equipment model name. Specifically, the equipment identification dataset includes the equipment material number, equipment model name, and organization identifier. Specifically, the equipment identification dataset includes the equipment material number and equipment supplier name. Specifically, the equipment identification dataset includes the equipment material number, equipment supplier name, and organization identifier. Specifically, the equipment identification dataset includes the equipment material number, equipment supplier name, equipment model name, and organization identifier. Specifically, the equipment identification dataset includes the equipment serial number. Specifically, the equipment identification dataset includes the equipment's serial number and organization identifier. Specifically, the equipment identification dataset includes the equipment's serial number and model name. Specifically, the equipment identification dataset includes the equipment's serial number, model name, and organization identifier. Specifically, the equipment identification dataset includes the equipment's serial number and supplier name. Specifically, the equipment identification dataset includes the equipment's serial number, supplier name, and organization identifier. Specifically, the equipment identification dataset includes the equipment's serial number, supplier name, and model name. Specifically, the equipment identification dataset includes the equipment's serial number, supplier name, model name, and organization identifier. Specifically, the equipment identification dataset includes the equipment's serial number and material number. Specifically, the equipment identification dataset includes the equipment's serial number, material number, and model name. Specifically, the equipment identification dataset includes the equipment's serial number, material number, model name, and organization identifier. Specifically, the equipment identification dataset includes the equipment's serial number, material number, supplier name, and organization identifier. Specifically, the equipment identification dataset includes the equipment's serial number, material number, supplier name, and organization identifier. Specifically, the equipment identification dataset includes the equipment's serial number, material number, supplier name, and model name, as well as the organization identifier.

[0041] According to another aspect of the invention, the certificate identifier is a hash of the device identifier dataset. The inventors recognized that, using a hash function, the certificate identifier can have the same length even for device identifier datasets of different sizes. Furthermore, the hash function is a one-way function, making it impossible to extract the device identifier dataset again based solely on the hash, which increases the security and privacy of the method.

[0042] Specifically, a hash value is the result of applying a hash function to a dataset. Furthermore, the hash function can take additional parameters, such as a seed.

[0043] Typically, a hash function is a function that maps data of arbitrary size to data of fixed size. Specifically, a hash function is a cryptographic hash function. Specifically, a cryptographic hash function is a deterministic function; specifically, the output of a hash function depends only on its inputs. Specifically, a cryptographic hash function can be computed quickly for all input values. Specifically, a cryptographic hash function is only brute-force reversible, meaning that given the output of a cryptographic hash function, the corresponding inputs can only be computed for a large number of input values ​​(i.e., a brute-force attack). In other words, finding the input value corresponding to the output value of a cryptographic hash function is a tricky problem. Specifically, finding the first and second input values ​​of a cryptographic hash function that result in the same output value is a tricky problem.

[0044] According to another aspect of the invention, the key creation dataset further includes a pre-shared secret and / or a certificate request domain name. Specifically, the pre-shared secret may be based on at least one of the following: a pre-shared one-time password, a pre-shared key, and / or a pre-shared hardware token. In particular, the pre-shared secret may be installed on the device during manufacturing and / or installation.

[0045] Specifically, a shared secret is data that is shared beforehand between the communicating parties in secure communication, and is known only to the participants. A pre-shared one-time cipher can be a string (also known as a "passphrase"), a number, or an array of numbers (specifically, an array of bits or bytes). The pre-shared one-time cipher can be distributed directly between the communicating partners for authentication of one of them. Alternatively, a pre-shared one-time cipher can be used to determine other data to be exchanged between the communicating partners (e.g., as the basis for a hash value). The pre-shared one-time key can be a symmetric or asymmetric key that can be used to encrypt and / or decrypt communications between the communicating partners.

[0046] Specifically, the hardware token stores secret information that can be used to prove identity. The hardware token can be a static cryptographic token, where it contains a physically hidden (invisible to the owner of the static cryptographic token) password that is transmitted with each authentication. The hardware token can be a synchronous dynamic cryptographic token, where a timer is used to rotate through various combinations generated by a cryptographic algorithm. The hardware token can be an asynchronous cryptographic token, where a one-time password is generated without using a clock based on a one-time pad or a cryptographic algorithm. The hardware token can be a challenge-response token, where the server encrypts the challenge (typically a random number, or at least data with some random component) using a public key, and the device connected to the challenge-response token and / or the challenge-response token itself proves that it possesses a copy of the matching private key by providing the decrypted challenge.

[0047] The inventors recognized that secure communication can be established based on a pre-shared secret, resulting in only qualified devices being able to receive the first digital certificate. Specifically, interference from third parties in the process can be detected and prevented. Furthermore, by using a pre-shared hardware token, the pre-shared secret cannot even be extracted by the physical owner of the device, thus preventing non-compliant behavior by the owner. Moreover, by using a certificate request domain in the key creation dataset, the necessary data for requesting a certificate can be transmitted, eliminating the need for a publicly available registry from a certificate authority or EST server.

[0048] According to another aspect of the invention, the certificate creation request is a Secure Transmission Registration (EST) request.

[0049] EST (Employment Registration via Secure Transmission) is an encrypted protocol that describes the X.509 certificate management protocol for public key infrastructure clients that require access to both the client's certificate and the associated certificate authority's certificate. EST is described in RFC 7030 (https: / / datatracker.ietf.org / doc / html / rfc7030). Specifically, an EST request is a request made according to Section 4.2 of the RFC 7030 standard.

[0050] The inventors recognized that using RFC requests could improve interoperability with existing information technology infrastructure.

[0051] According to another aspect of the invention, the key creation dataset includes a pre-shared secret, wherein the certificate creation request includes another pre-shared secret, and the method further includes: in response to receiving the certificate creation request, performing a check to see if the other pre-shared secret of the certificate creation request matches the pre-shared secret of the key creation dataset, wherein the step of sending the certificate creation request is performed only if the check is positive. In particular, the step of executing the request can be performed by a computing unit, specifically by the computing unit providing the system. The inventors recognize that by performing the described check, it can be ensured that only entities that have received the pre-shared secret can create a valid certificate creation request. This ensures that unauthorized entities are not allowed to request certificates, thereby preventing damage to the certificate system.

[0052] According to another aspect of the invention, the certificate creation request includes a certificate identifier, wherein performing the check further includes checking whether another pre-shared secret of the certificate creation request is related to the certificate identifier.

[0053] The inventors recognized that knowledge of both datasets, by examining the association between the certificate identifier and the pre-shared secret, is necessary for creating a valid certificate creation request. In particular, access to arbitrary pre-shared secrets is insufficient. Therefore, this additional aspect enhances the security of the method.

[0054] According to another aspect of the invention, sending a key creation dataset to a device includes: automatically transmitting the key creation dataset to the device via a secure communication channel. According to another aspect of the invention, providing a key creation dataset to a device includes: storing the key creation dataset on a portable storage medium and transmitting the key creation dataset to the device via the portable storage medium. The portable storage medium is a storage medium that can be removed from a computer during operation. Examples are optical discs (CDs), digital video discs (DVDs), Blu-ray discs, and floppy disks and Universal Serial Bus (USB) sticks.

[0055] The inventors recognized that the certificate generation process could be accelerated by automatically transmitting the key creation dataset if a secure communication channel to the device existed. Alternatively, the key creation dataset could also be transmitted to the device even without a secure communication channel, using a portable storage medium.

[0056] According to another possible aspect of the invention, the first domain name includes an asterisk tag, wherein the asterisk tag is the last tag of the first domain name, and wherein the first certificate identifier is a tag of the first domain name that is different from the last tag of the first domain name, in particular, wherein the first certificate identifier is the penultimate tag of the first domain name.

[0057] The inventors recognized that by using an asterisk label as the last label of the first domain, a single DNS entry could be used to forward or send information to a device. If the first certificate identifier is used as the penultimate label of the first domain, a single DNS entry can be used for several certificates for several clients, because the asterisk in the DNS entry (specifically, the asterisk in the resource record of the DNS entry) can represent all possible first certificate identifiers.

[0058] According to another possible aspect of the invention, the method includes proving ownership of the domain associated with the first domain name. Specifically, this step is performed by a server, and particularly by the server's interface and / or computing unit.

[0059] In particular, the process of proving ownership may include at least one of the following sub-steps:

[0060] - Receive inquiries from certificate authorities,

[0061] - Determine the response related to the challenge, where the response indicates control over the domain associated with the first domain.

[0062] - Provide a response to the certificate authority.

[0063] - The certificate authority has been notified that it has provided a response.

[0064] The inventors recognized that by having the server prove ownership, such proof does not need to be implemented by the device itself. In particular, by centrally performing proof for multiple potential devices at the server, the operation and maintenance of the entire system can be performed more efficiently.

[0065] According to another possible aspect of the invention, the method includes creating a DNS resource record for a first domain name and / or a modified first domain name. Specifically, the method may include: creating a first DNS A resource record or AAAA resource record for the first domain name and creating a DNS CNAME resource record for the modified first domain name, or creating a first DNS A resource record or AAAA resource record for the modified first domain name and creating a DNS CNAME resource record for the first domain name. Specifically, the DNS resource record may be a wildcard resource record. Specifically, the DNS resource record may be stored in a zone file. Specifically, the DNS resource record may include type, expiration time, category, and type-specific data.

[0066] The inventors recognized that by creating DNS resource records, communication directed to the service based on the first domain name and / or a modified first domain name could be enabled.

[0067] According to another possible aspect of the invention, the method includes creating a DICOM node configuration based on a first digital certificate and / or a second digital certificate. The step of creating the DICOM node configuration can be performed by a server, device, and / or client.

[0068] Specifically, creating a DICOM node configuration may include creating entries in the DICOM configuration corresponding to the device and / or client to enable encrypted communication based on a first digital certificate and / or a second digital certificate.

[0069] The inventors recognized that encrypted DICOM communication could be established between several DICOM nodes by creating a DICOM node configuration based on a first digital certificate and / or a second digital certificate.

[0070] According to another aspect of the invention, the method for providing a digital certificate to a device further includes: determining a modified certificate creation request based on the certificate creation request. In this aspect of the invention, the modified certificate creation request is sent to a certificate authority. Specifically, the modified certificate creation request does not contain a pre-shared secret.

[0071] The inventors recognized that by defining and sending a modified certificate creation request to the certificate authority, the leakage of internal information could be avoided. By removing data not directly needed by the certificate authority to create the certificate, unnecessary information was not provided to the certificate authority.

[0072] In another aspect, the present invention relates to a computer-implemented method for installing a digital certificate on a device. The method includes: receiving from a server a key creation dataset including a certificate identifier based on a device identifier dataset associated with the device. The method further includes: determining a certificate creation request associated with a first domain name based on the key creation dataset, wherein the first domain name includes the certificate identifier. The method further includes: sending the certificate creation request to a certificate authority via the server. The method further includes receiving a digital certificate, wherein the digital certificate is a wildcard certificate based on the first domain name signed by a certificate authority. The method further includes installing the digital certificate.

[0073] Specifically, the step of receiving the key to create the dataset is performed by the interface, specifically by the device's interface. Specifically, the step of determining the certificate creation request is performed by the computing unit, specifically by the device's computing unit. Specifically, the step of sending the certificate creation request is performed by the interface, specifically by the device's interface. Specifically, the step of receiving the digital certificate is performed by the interface, specifically by the device's interface. Specifically, the step of installing the digital certificate is performed by the computing unit, specifically by the device's computing unit.

[0074] According to another aspect, the present invention relates to a server configured to provide digital certificates to devices, the server being configured to:

[0075] - Receive a device identifier dataset, which uniquely identifies the device.

[0076] - Determine a key creation dataset that includes a certificate identifier based on a device identifier dataset.

[0077] - Send the key to the device to create the dataset.

[0078] - Receive a certificate creation request associated with the first domain name from the device, based on a key-based dataset.

[0079] The first domain name includes the certificate identifier.

[0080] - Send a certificate creation request to the certificate authority.

[0081] - Provide digital certificates to the device,

[0082] Digital certificates are wildcard certificates based on the first domain name, signed by a certificate authority.

[0083] Specifically, the server can be configured to perform a method for providing digital certificates to devices according to the present invention and its aspects. Specifically, the server may include an interface and a computing unit. The server is configured to execute the method and its aspects through its interface and its computing unit, the interface and the computing unit being configured to perform corresponding method steps.

[0084] According to another aspect, the present invention relates to a device for installing digital certificates, the device being configured to:

[0085] - Receive a key creation dataset from the server, including a certificate identifier based on a device identifier dataset associated with the device.

[0086] - Identify the certificate creation request associated with the first domain name for creating a dataset based on the key.

[0087] The first domain name includes the certificate identifier.

[0088] - Send a certificate creation request to the certificate authority via the server.

[0089] - Receive digital certificates, where the digital certificate is a wildcard certificate based on the first domain name signed by a certificate authority.

[0090] - Install digital certificate.

[0091] Specifically, the device can be configured to perform a method for installing a digital certificate according to the present invention and its aspects. Specifically, the device includes an interface and a computing unit. Specifically, the device is configured to perform the method and its aspects through its interface and its computing unit, the interface and the computing unit being configured to perform corresponding method steps.

[0092] The present invention is also based on a computer program product including instructions that, when executed by a computer, cause the computer to perform a method for providing a digital certificate to a device and / or a method for installing a digital certificate on a device according to the present invention and its aspects.

[0093] The present invention is also based on a computer-readable storage medium including instructions that, when executed by a computer, cause the computer to perform a method for providing a digital certificate to a device and / or a method for installing a digital certificate on a device according to the present invention and its aspects.

[0094] Implementing the present invention or any aspect thereof through a computer program product and / or computer-readable medium has the advantage that existing servers, devices, and clients can be easily adapted to operate in accordance with the recommendations of the present invention through software updates.

[0095] The computer program product may be, for example, a computer program or may include other elements besides a computer program. These other elements may be hardware, such as a memory device on which the computer program is stored, a hardware key for using the computer program, etc., and / or software, such as a software key or documentation for using the computer program.

[0096] According to another possible aspect, the present invention relates to a computer-implemented method for providing digital certificates to a device. The method is based on receiving authentication data from the device via a secure communication channel. Specifically, the authentication data can be used to ensure the identity of the device and the reliability and security of communication. Furthermore, the method is based on receiving a first certificate identifier from the device or determining the first certificate identifier by a server. Specifically, the first certificate identifier is a hash value. In other words, the step of receiving the first certificate identifier from the device or determining the first certificate identifier by the server is performed. A further step of the method is to verify the authentication data and receive a first public key created by the device from the device.

[0097] The method is also based on sending a first certificate signing request, based on a first public key, to a certificate authority for a first domain name. Here, the first domain name includes a certificate identifier, and the domain associated with the first domain name is controlled by the server. Specifically, the first domain name is a wildcard domain. Specifically, the first domain name includes the certificate identifier if it is a substring of the first domain name. Advantageously, the certificate identifier can be identical to exactly one tag of the first domain name. Specifically, the domain is controlled by the server if the domain associated with the first domain name is at least a subdomain of a domain or an equivalent domain to which the server can prove ownership.

[0098] The method is also based on: receiving a first digital certificate from a certificate authority, wherein the first digital certificate is a wildcard certificate signed by the certificate authority based on a first domain name and a first public key; and providing the first digital certificate to the device.

[0099] Specifically, the step of receiving the first certificate identifier is performed by the server, specifically by the server's interface. Specifically, the step of verifying the authentication data is performed by the server, specifically by the server's computing unit. Specifically, the step of receiving the first public key is performed by the server, specifically by the server's interface. Specifically, the step of sending the first certificate signing request is performed by the server, specifically by the server's interface. Specifically, the step of receiving the first digital certificate is performed by the server, specifically by the server's interface. Specifically, the step of providing the first digital certificate is performed by the server, specifically by the server's interface.

[0100] The inventors recognize that, based on the proposed method, a first digital certificate can be created by a server and provided to a client, allowing the client to operate without involvement in the certificate generation process and / or interaction with the certificate authority. Specifically, the server can assert ownership of the first domain name and be qualified to create a digital certificate for that domain.

[0101] Additionally, by using a wildcard certificate associated with a domain name marked with an asterisk (e.g., at the lowest level), supplementary information can be provided to requests (e.g., DNS requests) that allow resolution or forwarding to the device's first domain. For example, the asterisk in a DNS request can be replaced with an encoded IP address and / or an encoded domain name associated with the device, allowing a DNS response that redirects to the device's associated IP address and / or decoded domain name to be provided based on the submitted supplementary information. Typically, DNS is an acronym for "Domain Name System," as defined in standard RFC 1035 "Domain Names - Specification and Implementation" at https: / / tools.ietf.org / html / rfc1035 or any subsequent standards.

[0102] In particular, by using this wildcard certificate, valid HTTPS communication can be established with the device, even if the first digital certificate is related to the server's domain rather than the device's domain.

[0103] Furthermore, wildcard certificates are valid regardless of which information is used to replace the asterisk, i.e., for each encoded domain name and / or encoded IP address used. However, by using a device-specific first certificate identifier in the certificate, the certificate can only be used to authenticate a specific device, and not another device associated with a different first certificate identifier.

[0104] As another advantage, based on the use of authentication data and / or secure communication channels, the device can be authenticated by the server even if the device does not have a digital certificate installed. This allows the server to provide a certificate to the device without human interaction to authenticate the device (e.g., via telephone call).

[0105] Specifically, a secure communication channel is a communication channel with technical means to prevent the corresponding communication from being manipulated and / or eavesdropped on. For example, a secure communication channel may be a VPN (an abbreviation for "Virtual Private Network") connection or an SRS (an abbreviation for "Smart Remote Service," a product of Siemens Healthineers).

[0106] Asymmetric encryption is based on key pairs, which include a public key that can be widely distributed and a private key known only to the owner. Specifically, a message to be sent to the recipient can be encrypted using the recipient's public key, and the encrypted message can only be decrypted using the private key. Furthermore, a message to be transmitted can be signed using the sender's private key to prove authorship, and the signature can be verified using the sender's public key.

[0107] Specifically, a certificate signing request is a dataset sent to a certificate authority (in a public key infrastructure) to request a digital certificate. Specifically, a certificate signing request includes the public key for which a digital certificate should be issued, identification information (e.g., a domain name), and integrity protection (e.g., a digital signature). Certificate signing requests can be based on the RFC 2968 standard (“PKCS#10: Authentication Request Syntax Specification”, https: / / tools.ietf.org / html / rfc2986) or the “Signing Public Keys and Challenges” standard (SPKAC).

[0108] Specifically, a certificate signing request can be included in a certificate creation request as defined above. Specifically, a certificate signing request can be identical to a modified certificate signing request.

[0109] According to another possible aspect of the invention, the authentication data includes a pre-shared secret.

[0110] According to another possible aspect of the invention, the authentication data includes a device identifier, specifically, wherein the device identifier is based on the device's material number and / or the device's serial number. Specifically, the device identifier is a unique device identifier, implying a one-to-one correspondence between devices and their respective device identifiers. Specifically, the combination of the device's material number and the device's serial number is a unique device identifier.

[0111] The inventors recognized that by using a device identifier, a provided digital certificate can be assigned to a device. Furthermore, the security of the method can be improved by using the device identifier in the authentication data, as it enables the server to issue certificates only to known devices. In particular, the security of the method can be further improved if the authentication data includes both the device identifier and the pre-shared secret, because it enables the server to issue certificates only to known devices that store the pre-shared secret.

[0112] According to another possible aspect of the invention, the method further includes: sending a modified first certificate signing request based on a first public key to a modified first domain name, wherein the modified first domain name includes a certificate identifier. A further step is receiving a modified first digital certificate from the certificate authority, wherein the modified first digital certificate is a wildcard certificate signed by the certificate authority based on the modified first domain name and the first public key. A further step is providing the modified first digital certificate to a device.

[0113] Specifically, the modified first domain name includes an additional tag, or the modified first domain name has exactly one tag that is different from the corresponding tag of the first domain name, and the modified first domain name and the first domain name are different in exactly one tag.

[0114] Specifically, a primary domain name can be used in conjunction with a DNS A or AAAA resource record, while a modified domain name can be used in conjunction with a DNS CNAME resource record, and vice versa. Specifically, a DNS A resource record resolves DNS requests to IPv4 addresses (an abbreviation for "Internet Protocol, Version 4"), while a DNSAAAA resource record resolves DNS requests to IPv6 addresses (an abbreviation for "Internet Protocol, Version 6"). Specifically, a DNS CNAME resource record resolves DNS requests to another domain name (in other words, it can be interpreted as a referral).

[0115] The inventors recognized that by issuing a modified first digital certificate, in addition to the first digital certificate, based on the domain name used in the communication (e.g., in a DNS request), it is possible to determine the expected response to the communication solely based on the domain name. For example, based on the domain name, it can be determined whether the sender of the DNS request expects an A / AAAA resource record or a CNAME resource record.

[0116] According to another possible aspect of the invention, the method further includes storing usage information associated with the authentication data to prevent reuse of the authentication data. Specifically, the usage information can be stored by storing the authentication data in a database, wherein the database is checked during the authentication data verification step to determine whether the authentication data is already in the database. Alternatively, the usage information can be stored by storing a flag associated with the authentication data in a database of all authentication data, the flag indicating that a particular piece of authentication data has been used. This flag can then be checked during the authentication data verification step to determine whether the authentication data has been used.

[0117] The inventors recognized that storing usage information could prevent the same authentication data from being used twice. This improves system security by disallowing the issuance of two digital certificates for the same set of authentication data.

[0118] According to another possible aspect of the invention, the method further includes an optional step of authenticating the device based on a first digital certificate. Furthermore, the method includes: receiving registration data from the device, wherein the registration data includes a second certificate identifier; and receiving a second public key created by a client of the device. In particular, the registration data may include additional data, such as a token provided from the device to the client.

[0119] Furthermore, the method includes: sending a second certificate signing request based on a second public key and associated with a second domain name to a certificate authority, wherein the second domain name includes a second certificate identifier; and receiving a second digital certificate from the certificate authority, wherein the second digital certificate is a wildcard certificate based on the second domain name signed by the certificate authority. The method also includes providing the second digital certificate to devices and / or clients.

[0120] In particular, the additional steps of the described method can be performed after the first digital certificate is provided, and more specifically, they can be performed over a longer time span after the first digital certificate is provided.

[0121] The inventors recognized that, based on these additional steps, a second digital certificate can be created for a client trusted by the device or authenticated at the device, without direct interaction between the server and the client. Specifically, in this process, the device can authenticate at the server using the first digital certificate. By using this method, for example, a pre-shared secret for authentication is not required at the client. If the pre-shared secret in the previously described method is already included during the manufacturing of the device (where manufacturing may include compiling specific code at the server side), the digital certificate can be distributed to the client even if the client is not accessible during manufacturing. For example, a vendor can use this method to distribute digital certificates to third-party clients.

[0122] According to another possible aspect of the invention, the second certificate identifier includes the first certificate identifier and a client identifier associated with the client.

[0123] The inventors recognized that by using a second certificate identifier based on a first certificate identifier and a client identifier, both the corresponding first digital certificate of the device (and possibly already used to authenticate the device to create the second digital certificate) and the corresponding client can be identified separately based on the second certificate identifier. This can be useful in cases where the second digital certificate has been corrupted and needs to be revoked, or in identifying improper use of the device by the user.

[0124] According to another possible aspect of the invention, the second domain name includes an asterisk tag, wherein the asterisk tag is the last tag of the second domain name, wherein the first certificate identifier is the penultimate tag of the second domain name, and wherein the client identifier is the penultimate tag of the second domain name. According to an alternative aspect of the invention, the second domain name includes an asterisk tag, wherein the asterisk tag is the last tag of the second domain name, wherein the client identifier is the penultimate tag of the second domain name, and wherein the first certificate identifier is the penultimate tag of the second domain name.

[0125] The inventors recognized that by using a first certificate identifier and a client identifier in the name presented within the second domain, the structure of devices and their clients can be represented within the second domain. By using the structure of DNS resource records associated with the defined domain structure, such a structure in the domain can be preferably used by geographically distributed servers based on the location of the corresponding device to ensure fast response times.

[0126] In another possible aspect, the present invention relates to a computer-implemented method for providing a DNS response. The method is based on: receiving from a requester a DNS request for resolving a fully qualified domain name, wherein the fully qualified domain name includes an encoded domain name as a label. The method further includes: determining a decoded domain name based on the encoded domain name; and providing a DNS response to the requester, wherein the DNS response includes the decoded domain name. Specifically, the DNS response includes a CNAME resource record based on the decoded domain name.

[0127] Specifically, the method for providing DNS responses is executed by the server. Specifically, the steps of receiving DNS requests and providing DNS responses are executed by the interface, specifically by the server's interface. Specifically, the step of determining the decoded domain name is executed by the computing unit, specifically by the server's computing unit.

[0128] Specifically, an encoded domain name is a domain name in which special characters in the DNS system are replaced with one or more mask characters. Specifically, an encoded domain name cannot be directly used as the basis for a valid DNS request within the DNS system. Specifically, an encoded domain name can be used as a single tag or a single level within a fully qualified domain name.

[0129] An example of a special character in the DNS system is the dot "." that separates different levels or tags of a domain name. Specifically, an encoded domain name is a domain name in which each dot "." is replaced by the character "--" (double dash) or "---" (triple dash).

[0130] Decoded domain names are based on encoded domain names. Specifically, a decoded domain name can be determined by replacing one or more mask characters within the encoded domain name with corresponding special characters in the DNS system. Furthermore, the decoded domain name can be directly used as the basis for valid DNS requests within the DNS system.

[0131] The inventors recognized that, by using the described method, DNS requests directed to a fully qualified domain name (FQDN) including an encoded domain can be resolved to a decoded domain. Specifically, the FQDN can be associated with a server other than the decoded domain, and the decoded domain does not need to be a publicly resolvable domain, but can correspond to a local domain that can only be resolved within an internal network. Furthermore, by using this method, secure communication can be established based on a digital certificate issued using the FQDN, but then the communication can be directed to the (potentially local) decoded domain.

[0132] In alternative solutions, encoded IP addresses and decoded IP addresses can be used instead of encoded domain names and decoded domain names. However, using encoded and decoded domain names has the following advantages: static IP addresses are not necessary in the (potentially local) network associated with the decoded domain name.

[0133] According to another possible aspect of the invention, the fully qualified domain name may include an encoded IP address as an alternative to the encoded domain name. In this regard, the method for providing a DNS response further includes: determining, based on the fully qualified domain name, whether the DNS request relates to an A resource record, an AAAA resource record, or a CNAME resource record. If the determination indicates that the DNS request relates to a CNAME resource record, a decoded domain name is determined based on the encoded domain name, and a DNS response is provided to the requester, wherein the DNS response includes the CNAME resource record, and wherein the DNS response includes the decoded domain name. If the determination indicates that the DNS request relates to an A resource record or an AAAA resource record, a decoded IP address is determined based on the encoded IP address, and a DNS response is provided to the requester, wherein the DNS response includes an A resource record or an AAAA resource record, and wherein the DNS response includes the decoded IP address.

[0134] Specifically, an encoded IP address is an IP address in which special characters in the DNS system and / or TCP / IP system are replaced with one or more mask characters. Specifically, an encoded IP address cannot be directly used as the basis for a valid TCP / IP request (such as a valid HTTP or HTTPS request) within a TCP / IP system. Specifically, an encoded IP address can be used as a single tag or single level within a fully qualified domain name.

[0135] An example of a special character in the DNS system is the dot ".", which separates different levels or labels of domain names and also separates different components of an IP address (within the IPv4 standard). Specifically, an encoded IP address is one where each dot "." is replaced by the character "-" (dash), the character "--" (double dash), or the character "---" (triple dash). In the IPv6 standard, the special character ":" can be replaced in a similar manner as needed.

[0136] Decoding an IP address is based on an encoded IP address. Specifically, a decoded IP address can be determined by replacing one or more mask characters within the encoded IP address with corresponding special characters within the DNS system and / or TCP / IP system. In particular, the decoded IP address can be directly used as the basis for valid TCP / IP requests (such as valid HTTP or HTTPS requests) within the TCP / IP system.

[0137] The inventors recognized that, based on the proposed method, requests pointing to domain names (resulting in CNAME resource records) and requests pointing to IP addresses (resulting in A or AAAA resource records) can be handled. By determining which resource record is requested based on the fully qualified domain name, the type of the encoded domain name and / or encoded IP address does not need to be checked, which could be an erroneous step. Furthermore, through this determination, ambiguity can be resolved by the method (in cases where a label in the fully qualified domain name can correspond to both an encoded IP address and an encoded domain name).

[0138] According to another possible aspect, the step of determining whether a DNS request relates to an A resource record, an AAAA resource record, or a CNAME resource record is based on the presence and / or content of a tag that is not the lowest-level tag of the fully qualified domain name. In an alternative, this step is based on the content of the lowest-level tag of the fully qualified domain name.

[0139] The inventors recognized that wildcard domain names could be more easily used in DNS systems by determining the label that is not the lowest-level label. By determining the label that serves as the lowest-level label, only the qualifying part of the fully qualified domain name needs to be examined, rather than the entire fully qualified domain name.

[0140] In another possible aspect, the invention relates to a server for providing a first digital certificate to a device, the server including an interface and a computing unit.

[0141] - Configured to receive authentication data from the device via a secure communication channel

[0142] - Configured to receive a first certificate identifier from a device or determined by a server, specifically, where the first certificate identifier is a hash value or a random value.

[0143] - Configured for use in verifying authentication data

[0144] - Configured to receive the first public key created by the device from the device.

[0145] - Configured to send a first certificate signing request based on the first public key and associated with the first domain name to a certificate authority.

[0146] The first domain name includes the certificate identifier.

[0147] Furthermore, the domain associated with the first domain name (DN-1) is controlled by the server.

[0148] - Configured to receive the first digital certificate from a certificate authority

[0149] The first digital certificate is a wildcard certificate signed by a certificate authority, based on the first domain name and the first public key.

[0150] - Configured to provide the first digital certificate to the device.

[0151] Specifically, the server can be configured to perform a method for providing a first digital certificate according to the present invention and its aspects. The server is configured to perform the method and its aspects through its interface and computing unit, the interface and the computing unit being configured to perform corresponding method steps.

[0152] In another possible aspect, the invention relates to a device including an interface and a computing unit, the device being configured for:

[0153] - Determine the authentication data used to authenticate the device at the server.

[0154] - Optionally, a first certificate identifier is sent to the server, specifically, where the first certificate identifier is a hash value or a random value.

[0155] - Create a first asymmetric key pair, which includes a first public key and a first private key.

[0156] - Send the first public key to the server.

[0157] - Receive the first digital certificate and install the first digital certificate on the device.

[0158] Specifically, the device can be configured to perform corresponding steps of a method for providing a first digital certificate according to the present invention and its aspects. The device is configured to perform the method and its aspects through its interface and computing unit, the interface and the computing unit being configured to perform the corresponding method steps.

[0159] In another possible aspect, the invention relates to a client comprising an interface and a computing unit, the client being a client of a device, the client being configured to:

[0160] -Confirm registration data,

[0161] - Send registration data to the device.

[0162] - Create a second asymmetric key pair, which includes a second public key PBK-2 and a second private key.

[0163] - Send the second public key to the device.

[0164] - Receive and install the second digital certificate.

[0165] Specifically, the client can be configured to perform corresponding steps of the method for providing a first digital certificate according to the present invention and its aspects. The client is configured to execute the method and its aspects through its interface and computing unit, which are configured to perform the corresponding method steps.

[0166] In another aspect, the present invention relates to a system comprising a server according to and aspects thereof, an apparatus according to and aspects thereof, and optionally a client according to and aspects thereof. In particular, the client and apparatus are located within an intranet.

[0167] In another possible aspect, the invention relates to a DNS server including an interface and a computing unit, the DNS server being configured to:

[0168] - Receive the request from the requester for resolving the fully qualified domain name.

[0169] Among them, fully qualified domain names include coded domain names used as tags.

[0170] - Determine the decoding domain name based on the encoded domain name.

[0171] - Provide a DNS response to the requester, where the DNS response includes the decoded domain name.

[0172] Specifically, the DNS server can be configured to perform corresponding steps of the method for providing DNS responses according to the present invention and its aspects. The DNS server is configured to perform the method and its aspects through its interface and computing unit, the interface and the computing unit being configured to perform the corresponding method steps.

[0173] In another possible aspect, the present invention relates to a computer program product comprising instructions that, when executed by a computer, cause the computer to perform one of the methods according to the present invention and its aspects. Furthermore, the present invention relates to a computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform one of the methods according to the present invention and its aspects.

[0174] Implementing the present invention or any aspect thereof through a computer program product and / or computer-readable medium has the advantage that existing servers, devices, and clients can be easily adapted to operate in accordance with the recommendations of the present invention through software updates.

[0175] The computer program product may be, for example, a computer program or may include other elements besides a computer program. These other elements may be hardware, such as a memory device on which the computer program is stored, a hardware key for using the computer program, etc., and / or software, such as a software key or documentation for using the computer program. Attached Figure Description

[0176] The features, characteristics, and advantages of the invention described above, as well as the ways in which they are realized, become clearer and more readily understood from the following detailed description and embodiments, which will be presented in the context of the accompanying drawings. The following description does not limit the invention to the included embodiments. In different drawings, the same parts or portions may be labeled with the same reference numerals. Generally, these drawings are not drawn to scale.

[0177] The numbering and / or order of the method steps are intended for ease of understanding, and unless otherwise expressly stated or implicitly stated, the numbering and / or order of the method steps should not be construed as meaning that the specified steps must be performed according to the numbering of their reference numerals and / or their order in the drawings. In particular, some or even all of the method steps may be performed simultaneously, in an overlapping manner, or sequentially.

[0178] In the following figures:

[0179] Figure 1 A first data flow diagram of a method for providing a first digital certificate according to an embodiment of the present invention is shown;

[0180] Figure 2 A modified first data flow diagram of a method for providing a first digital certificate according to an embodiment of the present invention is shown;

[0181] Figure 3 A second data flow diagram is shown for a method of providing a first digital certificate according to an embodiment of the present invention, or for a method of providing a second digital certificate according to an embodiment of the present invention;

[0182] Figure 4 A first process flowchart of a method for providing a first digital certificate according to an embodiment of the present invention is shown;

[0183] Figure 5 A second process flowchart of a method for providing a first digital certificate according to an embodiment of the present invention is shown;

[0184] Figure 6 A process flowchart of a method for installing a first digital certificate according to an embodiment of the present invention is shown;

[0185] Figure 7A third process flowchart of a method for providing a first digital certificate according to an embodiment of the present invention is shown;

[0186] Figure 8 A fourth process flowchart of a method for providing a first digital certificate according to an embodiment of the present invention is shown;

[0187] Figure 9 A process flowchart of a method for providing a second digital certificate according to an embodiment of the present invention is shown;

[0188] Figure 10 A first process flowchart of a method for installing a second digital certificate according to an embodiment of the present invention is shown;

[0189] Figure 11 A fifth process flowchart of a method for providing a first digital certificate according to an embodiment of the present invention is shown;

[0190] Figure 12 A data flow diagram of a method for providing DNS responses according to an embodiment of the present invention is shown;

[0191] Figure 13 A first process flowchart of a method for providing a DNS response according to an embodiment of the present invention is shown;

[0192] Figure 14 A second process flowchart of a method for providing a DNS response according to an embodiment of the present invention is shown;

[0193] Figure 15 A third process flowchart of a method for providing a DNS response according to an embodiment of the present invention is shown;

[0194] Figure 16 The domain names used in different embodiments of the present invention are shown;

[0195] Figure 17 The fully qualified domain names used in different embodiments of the present invention are shown;

[0196] Figure 18 A third data flow diagram is shown, illustrating a method for providing a digital certificate and / or a method for installing a digital certificate according to an embodiment of the present invention;

[0197] Figure 19 A sixth process flowchart of a method for providing a digital certificate according to an embodiment of the present invention is shown;

[0198] Figure 20 A second process flowchart of a method for installing a first digital certificate according to an embodiment of the present invention is shown;

[0199] Figure 21 A seventh process flowchart of a method for providing a digital certificate according to an embodiment of the present invention is shown;

[0200] Figure 22 A first embodiment of a server, device, certificate authority, and client according to an embodiment of the present invention is shown;

[0201] Figure 23 A second embodiment of the server, device, certificate authority, and client according to an embodiment of the present invention is shown;

[0202] Figure 24 A third embodiment of the server, device, certificate authority, and client according to an embodiment of the present invention is shown;

[0203] Figure 25 A fourth embodiment of the server, device, and certificate authority according to an embodiment of the present invention is shown. Detailed Implementation

[0204] Figure 1 A first data flow diagram of a method for providing a first digital certificate CERT-1 according to an embodiment of the present invention is shown. In this embodiment, data is exchanged between a server SRV, a device DEV, and a certificate authority CA. Furthermore, in this embodiment, the server SRV includes a broker BRK that can be used for certain parts of the communication of the server SRV.

[0205] In this embodiment, the device DEV sends authentication data AD to the server SRV. Here, the authentication data AD includes the device identifier IDF-DEV of the device DEV and a one-time password OTP. Alternatively, the authentication data AD may include other components that allow authentication of the device DEV using the server SRV. In this embodiment, the device identifier IDF-DEV is based on the device DEV's material number and / or serial number. In this embodiment, the device identifier IDF-DEV includes the material number and / or serial number as plaintext; alternatively, the device identifier IDF-DEV may include the material number and / or serial number in an encoded manner, for example, the device identifier IDF-DEV may include a hash value based on the material number and / or serial number.

[0206] In addition, the device DEV sends a first certificate identifier, IDF-CERT-1, to the server SRV. Alternatively, the first certificate identifier IDF-CERT-1 may be created by the server SRV instead of being received from the device DEV. In this embodiment, the first certificate identifier IDF-CERT-1 is a unique identifier, for example, a hash value based on a random number or the device DEV's material number and / or serial number. Typically, the first certificate identifier IDF-CERT-1 and the device identifier IDF-DEV are different; alternatively, the first certificate identifier IDF-CERT-1 and the device identifier IDF-DEV may be the same.

[0207] In addition, the device sends a first public key PBK-1 to the server. The first public key PBK-1 corresponds to a first private key PRK-1 stored on the device DEV. The first public key PBK-1 and the first private key PRK-1 form a first asymmetric key pair. This first asymmetric key pair is created by the device DEV. The first private key PRK-1 can be used to prove ownership of any digital certificate based on the first public key PBK-1.

[0208] In the illustrated implementation, the first certificate identifier IDF-CERT-1 and the first public key PBK-1 are sent independently from the device DEV to the server SRV. Alternatively, the first certificate identifier IDF-CERT-1 and the first public key PBK-1 may be part of a first certificate signing request CSR-1 created by the device DEV and sent to the server SRV.

[0209] In this first data flow diagram, the server SRV sends a first certificate signing request (CSR-1) to the certificate authority (CA). In this embodiment, the certificate signing request CSR-1 includes a first public key PBK-1 and a first domain name DN-1. The first domain name DN-1 includes an asterisk label AL and a first certificate identifier IDF-CERT-1.

[0210] In response, the Certificate Authority (CA) sends a first digital certificate, CERT-1, to the server SRV. The first digital certificate CERT-1 includes a first domain name, DN-1, and specifically, the first domain name, DN-1, is the body of the first digital certificate CERT-1. Furthermore, the first digital certificate CERT-1 includes a signature based on the first public key, PBK-1, signed using the CA's private key, PRK-CA.

[0211] Server SRV receives the first digital certificate CERT-1 and sends it to device DEV. Alternatively, Certificate Authority (CA) can directly provide the first digital certificate CERT-1 to device DEV.

[0212] Figure 2 It shows Figure 1 The modified first data flow graph shown is as follows, in which, Figure 2 Only the data flow between the server SRV and the certificate authority CA is shown.

[0213] Compared to the first data flow diagram, in the modified flow diagram, the modified first certificate signing request CSR-1' (other than the first certificate signing request CSR-1) is sent from the server SRV to the certificate authority CA, and in response, the certificate authority CA sends the modified first digital certificate CERT-1' (other than the first digital certificate CERT-1) to the server SRV. The modified first digital certificate CERT-1' can also be provided by the server SRV to the device DEV. The modified first certificate signing request CSR-1' and the modified first digital certificate CERT-1' correspond to the same first public key PBK-1 as the first certificate signing request CSR-1 and the first digital certificate CERT-1, but correspond to the modified first domain name DN-1'. In this embodiment, both the modified first domain name DN-1' and the first domain name DN-1 include the same first certificate identifier IDF-CERT-1.

[0214] Two first digital certificates, CERT-1 and CERT-1', are required for the same device DEV due to the following facts: Generally, wildcard certificates are only accepted for a single level of domain name, and DNS requests for wildcard domains can only be answered consistently by either a CNAME resource record (corresponding to a domain name) or an A resource record (corresponding to an IP address), not both simultaneously. Typically, the domain name server synthesizes the answer to a query based on the query type. The resolver will always request an A or AAAA resource record. If the server responds with a CNAME resource request, the resolver will follow the domain in the response until it receives an A or AAAA resource record. Therefore, the domain name space that should be the answer for a CNAME must be separate from the space that should be the answer for an A or AAAA record.

[0215] Figure 3 A second data flow diagram is shown for a method of providing a first digital certificate CERT-1 according to an embodiment of the present invention, or for providing a second digital certificate CERT-2 according to an embodiment of the present invention. In this embodiment, data is exchanged between a server SRV, a device DEV, a client CLT associated with the device DEV, and a certificate authority CA.

[0216] The data flow based on the second data flow diagram can be compared with... Figure 1 The first data flow graph and / or Figure 2 The data flows shown in the modified first data flow diagram occur together, or they can be independent of each other. Figure 1The first data flow graph and / or Figure 2 The modified first data flow diagram shows the independent data flow of the data flow.

[0217] For this data flow diagram, it can be assumed that the client CLT is authenticated and authorized to interact with the device DEV, and the device DEV is authenticated and authorized to interact with the server SRV, for example, through the first digital certificate CERT-1 and / or the modified first digital certificate CERT-1'.

[0218] In the illustrated data flow diagram, the client CLT sends a second certificate identifier IDF-CERT-2 to the device DEV. Alternatively, the device DEV and / or the server SRV can create the second certificate identifier IDF-CERT-2, for example, as a hash value. Specifically, the device DEV and / or the server SRV can create the second certificate identifier IDF-CERT-2 based on the client CLT's client identifier IDF-CLT and the first certificate identifier IDF-CERT-1. Specifically, the second certificate identifier IDF-CERT-2 can include both the client identifier IDF-CLT and the first certificate identifier IDF-CERT-1. For example, the client identifier IDF-CLT can be the client CLT's material number and / or serial number, or the hostname of the client CLT in the local network environment in which both the client CLT and the device DEV operate, or a hash value based on those input values. The second certificate identifier IDF-CERT-2 can be the same as the client identifier IDF-CLT. Specifically, the first certificate identifier IDF-CERT-1 and the second certificate identifier IDF-CERT-2 are different. The client CLT may also receive a token from the device DEV, which can be used by the client CLT to interact directly with the server SRV.

[0219] Furthermore, the client CLT sends a second public key PBK-2 directly or indirectly to the server SRV via the device DEV. The second public key PBK-2 corresponds to a second private key PRK-2 stored on the client CLT. The second public key PBK-2 and the second private key PRK-2 form a second asymmetric key pair. This second asymmetric key pair is created by the client CLT. The second private key PRK-2 can be used to prove ownership of any digital certificate based on the second public key PBK-2.

[0220] In the illustrated implementation, the second certificate identifier IDF-CERT-2 and the second public key PBK-2 are independently sent from the client CLT to the server SRV via the device DEV. Furthermore, the second certificate identifier IDF-CERT-2 is part of the registration data RD. Specifically, the registration data RD may be the same as the second certificate identifier IDF-CERT-2; alternatively, the registration data RD may include the second certificate identifier IDF-CERT-2 and additional data. Specifically, the additional data may relate to the authentication between the device DEV and the client. Specifically, the registration data RD may include both the second certificate identifier IDF-CERT-2 and the second public key PBK-2.

[0221] Alternatively, the second certificate identifier IDF-CERT-2 and the second public key PBK-2 may be part of a second certificate signing request CSR-2 created by the device DEV and / or the client and sent to the server SRV. Specifically, the registration data RD may include or be identical to the second certificate signing request CSR-2.

[0222] In this second data flow diagram, the server SRV sends a second certificate signing request (CSR-2) to the certificate authority (CA). In this embodiment, the second certificate signing request (CSR-2) includes a second public key (PBK-2) and a second domain name (DN-2). The second domain name (DN-2) includes an asterisk label (AL) and a second certificate identifier (IDF-CERT-2).

[0223] In response, the Certificate Authority (CA) sends a second digital certificate, CERT-2, to the server SRV. The second digital certificate CERT-2 includes a second domain name, DN-2, which is specifically the body of the second digital certificate CERT-2. Furthermore, the second digital certificate CERT-2 includes a signature based on the second public key, PBK-2, signed using the CA's private key, PRK-CA.

[0224] The server SRV receives the second digital certificate CERT-2 and sends it to the device DEV and / or the client CLT. Alternatively, the certificate authority (CA) may provide the second digital certificate CERT-2 directly to the client CLT, either directly or through the device DEV.

[0225] Figure 4 A first process flowchart of a method for providing a first digital certificate CERT-1 from a server SRV to a device DEV according to an embodiment is shown. The first process flowchart is... Figure 1 The first data flow graph shown corresponds to this.

[0226] The initial steps of this method are: receiving REC-AD authentication data AD from device DEV via a secure communication channel, and receiving REC-PBK-1, a first public key PBK-1 created by device DEV. In this embodiment, the authentication data includes a client identifier IDF-CLT and a one-time password OTP. Specifically, the client identifier IDF-CLT is based on the material number and / or serial number of the client CLT. Specifically, the client identifier IDF-CLT and / or the one-time password OTP may have already been stored on the device at the manufacturing location.

[0227] Another step is to verify the VRF-AD authentication data (AD). In this implementation, the VRF-AD authentication data (AD) includes checking whether the device database stores the client identifier (IDF-CLT) associated with the one-time password (OTP). Optionally, a flag in the database can be checked, indicating whether the combination of the client identifier (IDF-CLT) and the one-time password has been used in previously received authentication data (AD). If the VRF-AD verification step yields a positive result, the method continues; otherwise, further execution of the method is stopped.

[0228] The method further includes the steps of receiving the REC-IDF-CERT first certificate identifier IDF-CERT-1 from the device DEV or the server determining the REC-IDF-CERT first certificate identifier IDF-CERT-1. In this embodiment, the first certificate identifier IDF-CERT-1 corresponds to a hash value based on a random number. Alternatively, the first certificate identifier IDF-CERT-1 may be based on the client identifier IDF-CLT of the client CLT or a hash of the client identifier IDF-CLT. Hereinafter, it will be assumed that the first certificate identifier IDF-CERT-1 is the string "ca1d5f5f7ba45".

[0229] Another step in the illustrated implementation is to send a first certificate signing request (CSR-1) based on the first public key PBK-1 and associated with the first domain name DN-1 to the Certificate Authority (CA), wherein the first domain name DN-1 includes the certificate identifier IDF-CERT-1. In the following, it will be assumed that the first domain name DN-1 is the string “*.ca1d5f5f7ba45.cert.example.com”. Specifically, the first domain name DN-1 is a wildcard domain name. In this implementation, the domain name comprises five levels: the first level (also called the top-level) is the tag “com”, the second and third levels are “example” and “cert”, the penultimate level is the certificate identifier IDF-CERT-1, and the last level is the asterisk character “*”.

[0230] The illustrated method also includes the step of receiving a first digital certificate CERT-1 (REC-CERT-1) from a certificate authority (CA), wherein the first digital certificate CERT-1 is a wildcard certificate signed by the CA based on a first domain name (DN-1) and a first public key (PBK-1). In this embodiment, the subject of the first digital certificate CERT-1 is equivalent to the first domain name (DN-1), which in this example is “*.ca1d5f5f7ba45.cert.example.com”.

[0231] The final step of the illustrated method is to provide the device DEV with the PROV-CERT-1 first digital certificate CERT-1. Providing the PROV-CERT-1 first digital certificate CERT-1 may include sending the first digital certificate CERT-1 directly to the device DEV and / or making the first digital certificate CERT-1 downloadable by the device DEV.

[0232] Figure 5 A second process flowchart of a method for providing a first digital certificate CERT-1 according to an embodiment of the present invention is shown. The second process flowchart includes... Figure 4 All steps of the first process flowchart shown, and the data structures describing those steps, may include... Figure 4 All advantageous implementations and features described herein.

[0233] The second process flowchart also includes an optional step to prove ownership (PRV-OWN) of the domain associated with the first domain name DN-1. Specifically, the step of proving ownership (PRV-OWN) is performed via the ACME protocol (an acronym for "Automatic Certificate Management Environment," described in RFC 8555, https: / / tools.ietf.org / html / rfc8555).

[0234] In this implementation, the step of proving ownership (PRV-OWN) includes the following sub-steps: receiving a REC-CLG challenge from a Certificate Authority (CA); determining a DET-RSP response related to the challenge, wherein the response indicates control over the domain associated with the first domain name DN-1; providing a PROV-RSP response to the CA; and notifying the CA (INF-CA) that the CA has provided a response.

[0235] In this implementation, the challenge involves creating a file with given content at a location accessible on the server based on the domain "ca1d5f5f7ba45.cert.example.com", such as creating an HTML file at "http: / / ca1d5f5f7ba45.cert.example.com / authentication.html". The response determines whether the file is actually created and made publicly accessible. Alternatively, the ACME method DNS-01 can be used, where the challenge needs to be included in the TXT resource record for the specified domain.

[0236] In the illustrated embodiment, the proof of ownership (PRV-OWN) step is performed after the step of sending the SND-CSR-1 first certificate signing request (CSR-1). Alternatively, the proof of ownership (PRV-OWN) step can be performed first, followed by the step of sending the SND-CSR-1 first certificate signing request (CSR-1).

[0237] according to Figure 5 The process diagram shown also includes an optional step of creating a CRT-DNS DNS resource record for the first domain name DN-1. The synonym for "DNS resource record" is "resource record". Specifically, the DNS resource record can be of type "A" (resolves to an IPv4 address), type "AAAA" (resolves to an IPv6 address), or type "CNAME" (resolves to another domain name).

[0238] according to Figure 5 The process diagram shown also includes an optional step of storing usage information related to the STR-USG and authentication data AD to prevent the reuse of the authentication data AD. In this embodiment, a flag is stored in the database storing qualified authentication data AD to indicate that a certain authentication data has been used.

[0239] Figure 6 A process flowchart of a method for installing a first digital certificate CERT-1 according to an embodiment of the present invention is shown.

[0240] According to the illustrated embodiment, the method further includes: a step whereby the device DEV determines authentication data for authenticating the device at the server SRV using DET-AD; a step whereby the device DEV sends SND-AD authentication data to the server via a secure communication channel; a step whereby the device DEV sends the first certificate identifier IDF-CERT-1 (SND-IDF-CERT-1) to the server SRV; a step whereby the device DEV creates a first asymmetric key pair (CRT-AKP-1), the asymmetric key pair including a first public key PBK-1 and a first private key PRK-1; and a step whereby the device DEV sends the first public key PBK-1 (SND-PBK-1) to the server SRV. Additionally, the method includes a step whereby the device DEV installs the first digital certificate CERT-1 (INST-CERT-1) on the device DEV.

[0241] Figure 7 A third process flowchart of a method for providing a first digital certificate CERT-1 according to an embodiment of the present invention is shown. The third process flowchart includes... Figure 4 The first process flowchart shown and Figure 5 All steps of the second process flowchart shown, those steps, and the data structures describing those steps may include Figure 4 and Figure 5 All advantageous implementation methods and features described herein. Furthermore, the third process flowchart includes... Figure 6 The flowchart shown illustrates all the steps of the method for installing the first digital certificate CERT-1, including those steps and the data structures described about those steps. Figure 6 All advantageous implementations and features described herein. Although Figure 4 and Figure 5 The steps performed by the server SRV are described, and Figure 6 The corresponding steps performed by the device DEV are described, but Figure 7 It also includes the corresponding steps performed by the Certificate Authority (CA).

[0242] In this embodiment, the method further includes: receiving the REC-CSR-1 first certificate signing request CSR-1 by the Certificate Authority (CA). Furthermore, the method includes: receiving information from the Certificate Authority (CA) that the REC-INF has been responded to by the server SRV; verifying the VRF-RSP response provided by the server SRV by the Certificate Authority (CA); creating a CRT-CERT-1 first digital certificate based on the first public key PBK-1 and the first domain name DN-1; and sending the SND-CERT-1 first digital certificate CERT-1 to the server SRV by the Certificate Authority (CA).

[0243] Figure 8A fourth process flowchart of a method for providing a first digital certificate CERT-1 according to an embodiment of the present invention is shown. The fourth process flowchart includes elements already referenced... Figure 4 and Figure 5 The steps described. Those steps and the data structures described about those steps may include... Figure 4 and Figure 5 All advantageous implementations and features described herein.

[0244] The fourth process flowchart is an extension of the previously described process flowchart, allowing the distribution of additional digital certificates to the client CLTs of the device DEV. If the creation of the first digital certificate CERT-1 is based on a pre-shared secret stored at the device DEV, this additional process step can be used to provide a second digital certificate CERT-2 to the client CLTs of the device DEV based on the client CLTs authenticated at the device DEV and known to the device DEV. In other words, a chain of trust is established on the one hand between the server SRV and the device DEV, and on the other hand between the device DEV and the client CLTs. Specifically, this process can be used if the client CLTs are created by a manufacturer different from the owner of the server SRV. In particular, the method steps described below can be performed on several client CLTs of the device DEV.

[0245] The fourth process flowchart also includes an optional step of authenticating device DEV (AUTH-DEV) based on the first digital certificate CERT-1. In this embodiment, authenticating device DEV (AUTH-DEV) is based on a challenge-response process. For example, this can be based on the TLS (Transport Layer Security) handshake protocol or other types of handshake protocols.

[0246] An additional step is to receive REC-RD registration data RD from the device DEV, wherein the registration data RD includes a second certificate identifier IDF-CERT-2. In this embodiment, the second certificate identifier IDF-CERT-2 includes the first certificate identifier IDF-CERT-1 and the client identifier CLT-IDF of the client CLT. In an alternative embodiment, the second certificate identifier IDF-CERT-2 may be independent of the first certificate identifier IDF-CERT-1 and the identifier CLT-IDF of the client CLT.

[0247] Another step is to receive REC-PBK-2, a second public key PBK-2 created by the client CLT of device DEV. Specifically, the second public key PBK-2 corresponds to a second private key PRK-2, and both PBK-2 and PRK-2 are created by the client CLT as a second asymmetric key pair. Specifically, the second private key PRK-2 is stored on the client CLT and can be used later to verify the client CLT's identity based on a second digital certificate.

[0248] An additional step in the fourth process flowchart is to send a second certificate signing request (CSR-2) based on the second public key PBK-2 and associated with the second domain name DN-2 to the Certificate Authority (CA) in the form of SND-CSR-2. Here, the second domain name DN-2 includes the second certificate identifier IDF-CERT-2. Specifically, the second domain name DN-2 can be generated by replacing the first certificate identifier IDF-CERT-1 within the first domain name DN-1 with the second certificate identifier IDF-CERT-2 based on the first domain name DN-1 (wherein, the first certificate identifier IDF-CERT-1 and / or the second certificate identifier IDF-CERT-2 may include several tags or levels of the domain name, and specifically, where the first certificate identifier IDF-CERT-1 and the second certificate identifier IDF-CERT-2 may include different numbers of tags or levels of the domain name). Examples of the corresponding first domain name DN-1 and second domain name DN-2 are provided in... Figure 16 It is shown in the middle.

[0249] After sending the SND-CSR-2 second certificate signing request (CSR-2) to the Certificate Authority (CA), the process includes receiving the REC-CERT-2 second digital certificate (CERT-2) from the CA. Here, the second digital certificate (CERT-2) is a wildcard certificate based on the second domain name (DN-2) signed by the CA. For the second certificate signing request (CSR-2), there may be a format similar to... Figure 5 and Figure 7 The steps shown are additional steps for proving PRV-OWN'.

[0250] The final step in the illustrated flowchart is to provide the PROV-CERT-2 second digital certificate CERT-2 to the device DEV and / or the client CLT. Specifically, the second digital certificate CERT-2 can be sent directly to the device DEV and / or the client CLT, or it can be made available for download by the device DEV and / or the client CLT.

[0251] Figure 9A flowchart illustrating a method for providing a second digital certificate CERT-2 according to an embodiment of the present invention is shown. The method includes: an optional step of authenticating a device DEV (AUTH-DEV) based on a first digital certificate CERT-1; a step of receiving REC-RD registration data RD from the device DEV; a step of receiving REC-PBK-2, a second public key PBK-2 created by the client CLT of the device DEV; a step of sending SND-CSR-2, a second certificate signature request CSR-2 based on the second public key PBK-2 and associated with a second domain name DN-2, to a certificate authority (CA); a step of receiving REC-CERT-2, the second digital certificate CERT-2, from the certificate authority (CA); and a step of providing the PROV-CERT-2, the second digital certificate CERT-2, to the device DEV and / or the client CLT. All these steps may include... Figure 8 The fourth process flowchart describes the advantageous and alternative implementation methods and features.

[0252] Specifically, the process flowchart for providing the second digital certificate CERT-2 corresponds only to the steps for creating and providing the second digital certificate CERT-2, and can be executed independently of the method steps for providing the first digital certificate CERT-1.

[0253] Figure 10 A first process flowchart of a method for installing a second digital certificate CERT-2 according to an embodiment of the present invention is shown.

[0254] According to the illustrated implementation, the method includes the following steps: the client CLT determines the DET-RD registration data RD; the client CLT sends the SND-RD registration data RD to the device DEV; the client CLT creates a second asymmetric key pair CRT-AKP-2, the second asymmetric key pair including a second public key PBK-2 and a second private key PRK-2; the client CLT sends the SND-PBK-2 second public key PBK-2 to the device DEV; and the client CLT installs the INST-CERT-2 second digital certificate CERT-2.

[0255] Figure 11 A fifth process flowchart of a method for providing a first digital certificate CERT-1 according to an embodiment of the present invention is shown. The fifth process flowchart can be understood as... Figure 7 The third process flowchart is an extension of the previous one, or can be understood as an independent process flowchart. In the latter case, the steps of providing the PROV-CERT-1 first digital certificate CERT-1 and installing the INST-CERT-1 first digital certificate CERT-1 are optional steps.

[0256] The fifth process flowchart also includes Figure 8 The steps and flow chart of the fourth process shown are as follows: Figure 10 The flowchart illustrates the steps of a method for installing a second digital certificate, CERT-2. These steps may include all the advantageous features and implementations described with reference to the corresponding figures.

[0257] The fifth process flowchart also includes the following optional steps: the device DEV sends TRM-RD registration data RD to the server; the device DEV sends TRM-PBK-2, the second public key PBK-2 created by the client CLT of the device DEV, to the server SRV; and the device DEV sends TRM-CERT-2, the second digital certificate, to the client CLT.

[0258] The fifth process flowchart also includes an optional step to prove ownership of the domain associated with the second domain name DN-2, PRV-OWN'. Specifically, the step of proving ownership PRV-OWN' is performed via the ACME protocol (an acronym for "Automatic Certificate Management Environment," described in RFC 8555, https: / / tools.ietf.org / html / rfc8555).

[0259] In this implementation, the step of proving ownership PRV-OWN' includes the following sub-steps: receiving a REC-CLG' challenge from a certificate authority (CA); determining a DET-RSP' response related to the challenge, wherein the response indicates control over the domain associated with the second domain name DN-2; providing a PROV-RSP' response to the certificate authority (CA); and notifying the INF-CA' that the certificate authority (CA) has provided a response.

[0260] In this implementation, the challenge involves creating a file with given content at a location accessible on the server based on the domain "ca1d5f5f7ba45.cert.example.com," such as creating an HTML file at "http: / / ca1d5f5f7ba45.cert.example.com / authentication.html." The response determines whether the file is actually created and made publicly accessible. Alternatively, the ACME method DNS-01 can be used.

[0261] In the illustrated embodiment, the step of proving ownership (PRV-OWN) is performed after the step of sending the second certificate signing request (CSR-2) (SND-CSR-2). Alternatively, the step of proving ownership (PRV-OWN) can be performed first, and then the step of sending the second certificate signing request (CSR-2) (SND- ...

[0262] In this embodiment, the method further includes receiving a REC-CSR-2 second certificate signing request (CSR-2) from a Certificate Authority (CA). Furthermore, the method includes: receiving information from the Certificate Authority (CA) that a response to REC-INF' has been provided by the server SRV; verifying the response to VRF-RSP' provided by the server SRV from the Certificate Authority (CA); creating a CRT-CERT-2 second digital certificate (CERT-2) based on the second public key PBK-2 and the second domain name DN-2; and sending the SND-CERT-2 second digital certificate (CERT-2) to the server SRV from the Certificate Authority (CA).

[0263] Figure 12 A data flow diagram of a method for providing a DNS response DNS-RSP according to an embodiment of the present invention is shown. In the illustrated embodiment, the requester REQ desires a DNS response with a domain name D-DN associated with the device DEV to establish encrypted communication based on the device DEV's digital certificate CERT-1.

[0264] exist Figure 12 The document describes the data flow for interactions with device DEV based on the first digital certificate CERT-1. The same data flow can be applied without significant modification to interactions with client CLT based on the second digital certificate CERT-2.

[0265] In this implementation, the requester REQ creates a DNS request DNS-REQ and sends it to the server. The DNS request DNS-REQ aims to resolve the first fully qualified domain name FQDN-1. The first fully qualified domain name FQDN-1 includes the encoded domain name E-DN of the device DEV and the first certificate identifier IDF-CERT-1 owned by the device DEV and associated with the first digital certificate CERT-1.

[0266] Upon receiving a DNS request (DNS-REQ), the server responds with a DNS response (DNS-RSP). In this implementation, the DNS response is a CNAME resource record that includes the decoded domain name D-DN. An example of the encoded domain name E-DN and its corresponding decoded domain name D-DN is provided below. Figure 17 Describe it.

[0267] Based on the DNS response DNS-RSP, the requester REQ can establish a secure connection between itself and the client CLT. Specifically, the requester REQ can send an authentication request AUTH-REQ to the device DEV and receive an authentication response AUTH-RSP from the device DEV, where the AUTH-RSP indicates that it knows the first private key PRK-1 at the device DEV. An example of this process is the HTTPS handshake. After authentication, a secure connection can be established, and data DAT can be exchanged cryptographically between the requester REQ and the device DEV.

[0268] Figure 13 A first process flowchart of a method for providing a DNS response DNS-RSP according to an embodiment of the present invention is shown.

[0269] The first step of the illustrated implementation is to receive a DNS request (DNS-REQ) from the requester (REQ) for resolving the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2'. Here, the fully qualified domain names (FQDN-1, FQDN-2, FQDN-1', and FQDN-2') include the encoded domain name E-DN as a label. The step of receiving the DNS request (DNS-REQ) is performed by the device server (SRV), specifically by the server's interface (SRV.IF).

[0270] The second step of the illustrated implementation is to determine the DET-D-DN decoding domain name D-DN based on the encoded domain name E-DN. In this implementation, the step of determining the DET-D-DN decoding domain name D-DN is performed by the server SRV. Specifically, the decoding domain name D-DN can be obtained from the encoded domain name E-DN by replacing the special character "--" or "---" with the dot character "." to separate the different levels in the domain name.

[0271] The final step of the illustrated implementation is to provide the requester REQ with a PROV-DNS-RSP DNS response DNS-RSP, wherein the DNS response DNS-RSP includes the decoded domain name D-DN. Specifically, the step of providing the PROV-DNS-RSP DNS response DNS-RSP is performed by the server SRV. Specifically, the DNS response DNS-RSP corresponds to a CNAME resource record.

[0272] Figure 14 A second process flowchart of a method for providing DNS response DNS-RSP according to an embodiment of the present invention is shown.

[0273] Second process flowchart and Figure 13The first process flowchart shown corresponds to the second process flowchart, but the second process flowchart indicates the corresponding steps performed by the requester REQ.

[0274] Figure 15 A third process flowchart of a method for providing a DNS response DNS-RSP according to an embodiment of the present invention is shown. The third process flowchart is... Figure 13 The first process flowchart shown and Figure 14 The second process flowchart shown is a combination of steps, and additionally includes steps performed by the device DEV.

[0275] Figure 16 The domain names DN-1, DN-2, DN-1', and DN-2' used in different embodiments of the present invention are shown. In particular, the domain names DN-1, DN-2, DN-1', and DN-2' are wildcard domain names and are used as the body in the digital certificates CERT-1, CERT-2, CERT-1', and CERT-2'.

[0276] In this implementation, the first domain name DN-1 is equivalent to the string "*.ca1d5f5f7ba45.cert.example.com". The first domain name DN-1 includes the asterisk label "*", the first certificate identifier IDF-CERT-1 ("ca1d5f5f7ba45"), the domain portion DMN-PRT ("cert.example"), and the top-level domain "com". The first domain name DN-1 does not include the DNS type identifier DNS-TYP. In an alternative implementation, the first domain name DN-1 does include the DNS type identifier DNS-TYP ("a", indicating that a DNS request will be resolved to an A resource record). In this alternative implementation, the first domain name DN-1 can be equivalent to either the string "*.ca1d5f5f7ba45.a.cert.example.com" or the string "*.a.ca1d5f5f7ba45.cert.example.com" because the order of the first certificate identifier IDF-CERT-1 and the DNS type identifier DNS-TYP can be interchanged. However, it should be noted that in any case, different strings in the first domain name DN-1 will correspond to different first digital certificates CERT-1, because the first domain name DN-1 is usually included as the body of the first digital certificate CERT-1.

[0277] In the illustrated implementation, the second domain name DN-2 is equivalent to the string "*.ca1d5f5f7ba45.client-abc.cert.example.com". The second domain name DN-2 includes an asterisk "*", a first certificate identifier IDF-CERT-1 ("ca1d5f5f7ba45"), a client identifier IDF-CLT "client-abc", a domain portion DMN-PRT ("cert.example"), and a top-level domain "com". Specifically, the domain portion DMN-PRT ("cert.example") and the top-level domain "com" are equivalent to the corresponding portions of the first domain name DN-1. Like the first domain name DN-1, the second domain name DN-2 may optionally include a DNS type identifier DNS-TYP. The first certificate identifier IDF-CERT-1 ("ca1d5f5f7ba45") and the client identifier IDF-CLT "client-abc" form the second certificate identifier IDF-CERT-2.

[0278] In an alternative embodiment (not shown), the second domain name DN-2 may include a second certificate identifier IDF-CERT-2 (here, "6c15b0f00a08") that is different from and does not include the first certificate identifier IDF-CERT-1. Specifically, in this alternative embodiment, the second domain name DN-2 does not include the client identifier CLT-IDF. In this alternative embodiment, the second domain name DN-2 is equivalent to the string "*.6c15b0f00a08.cert.example.com".

[0279] In this implementation, the modified first domain name DN-1' is equivalent to the string "*.ca1d5f5f7ba45.cname.cert.example.com". The modified first domain name DN-1' includes the asterisk label "*", the first certificate identifier IDF-CERT-1 ("ca1d5f5f7ba45"), the domain portion DMN-PRT ("cert.example"), the top-level domain "com", and the DNS type identifier DNS-TYP' ("cname", indicating that a DNS request will be resolved to a CNAME resource record). In an alternative implementation, the modified first domain name DN-1' can also be equivalent to the string "*.cname.ca1d5f5f7ba45.cert.example.com", because the order of the first certificate identifier IDF-CERT-1 and the DNS type identifier DNS-TYP' can be interchanged. However, it should be noted that in any case, different strings as the modified first domain name DN-1' will correspond to different modified first digital certificates CERT-1', because the modified first domain name DN-1' is usually included as the body of the modified first digital certificate CERT-1'.

[0280] In the illustrated embodiment, the modified second domain name DN-2' is equivalent to the string "*.ca1d5f5f7ba45.client-abc.cname.cert.example.com". The modified second domain name DN-2' includes the asterisk label "*", the first certificate identifier IDF-CERT-1 ("ca1d5f5f7ba45"), the client identifier IDF-CLT "client-abc", the domain portion DMN-PRT ("cert.example"), and the top-level domain "com". Specifically, the domain portion DMN-PRT ("cert.example") and the top-level domain "com" are equivalent to the corresponding portions of the first domain name DN-1. Like the modified first domain name DN-1', the modified second domain name DN-2' includes the DNS type identifier DNS-TYP'. The first certificate identifier IDF-CERT-1 ("ca1d5f5f7ba45") and the client identifier IDF-CLT "client-abc" form the second certificate identifier IDF-CERT-2.

[0281] In an alternative embodiment (not shown), the modified second domain name DN-2' may include a second certificate identifier IDF-CERT-2 (here, "6c15b0f00a08") that is different from and does not include the first certificate identifier IDF-CERT-1. Specifically, in this alternative embodiment, the modified second domain name DN-2' does not include the client identifier CLT-IDF. In this alternative embodiment, the modified second domain name DN-2' is equivalent to the string "*.6c15b0f00a08.cname.cert.example.com".

[0282] Figure 17 The fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2' used in different embodiments of the invention are shown. In particular, the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2' are used in DNS requests.

[0283] The first fully qualified domain name FQDN-1 and the second fully qualified domain name FQDN-2 are based on the first domain name DN-1 and the second domain name DN-2, wherein the asterisk label AL in the first domain name DN-1 and the second domain name DN-2 are replaced with the encoded domain name E-DN. The modified first fully qualified domain name FQDN-1' and the modified second fully qualified domain name FQDN-2' are based on the modified first domain name DN-1' and the modified second domain name DN-2', wherein the asterisk label AL in the modified first domain name DN-1' and the modified second domain name DN-2' are replaced with the encoded IP address name E-IP.

[0284] The encoded domain name (E-DN) is based on the corresponding decoded domain name (D-DN). Specifically, all dot characters "." in the decoded domain name (D-DN) (which separate different levels of the decoded domain name) need to be replaced with special characters or sequences of special characters (e.g., double dashes "--" or triple dashes "---") to ensure that the encoded domain name (E-DN) does not cross different levels of the corresponding fully qualified domain name (FQDN-1, FQDN-2). For example, if the decoded domain name (D-DN) corresponds to the string "pacs.hospital-abc.com", then the encoded domain name (E-DN) could correspond to the string "pacs--hospital-abc--com" or "pacs---hospital-abc---com".

[0285] The encoded IP address E-IP is based on the corresponding decoded IP address D-IP. Specifically, all dot characters "." in the decoded IP address D-IP (which separate different subnets of the decoded IP address D-IP) need to be replaced with special characters or sequences of special characters (e.g., a single hyphen "-") so that the encoded IP address E-IP does not cross different levels of the corresponding fully qualified domain names FQDN-1', FQDN-2'. For example, if the decoded IP address D-IP corresponds to the string "192.168.2.1", then the encoded IP address E-IP could correspond to the string "192-168-2-1".

[0286] In the illustrated implementation, to determine which DNS response type to use, the presence and / or content of the DNS type identifiers DNS-TYP and DNS-TYP' in the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2' are used, wherein the DNS type identifiers DNS-TYP and DNS-TYP' are separate labels for the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2'. Alternatively, the DNS type identifiers DNS-TYP and DNS-TYP' may also be part of the encoded IP address E-IP and / or encoded domain name E-DN. In particular, the DNS type identifiers DNS-TYP and DNS-TYP' may be part of the lowest level of the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2'. For example, the first two characters of the lowest label can correspond to the characters "ip" to indicate that an A record resource or an AAAA record resource is expected in the response, and the first two characters of the lowest label can correspond to the characters "dn" to indicate that a CNAME record resource is expected in the response.

[0287] Figure 18 A third data flow diagram is shown for a method of providing and / or installing a digital certificate CERT-1 according to an embodiment of the present invention. In this embodiment, data is exchanged between the server SRV, the device DEV, and the certificate authority CA.

[0288] In this implementation, the server SRV receives a device identifier dataset DID. The third data flow diagram indicates three possibilities for receiving the device identifier dataset DID. The first possibility is that the device identifier dataset DID is stored in a database DB accessible to the server SRV. The second possibility is that the device identifier dataset DID is input by the user USR using the web client WB-CLT. The third possibility is that the device identifier dataset DID is transmitted from the device DEV to the server SRV. The different parts of the device identifier dataset DID can also be combined, for example, by receiving the sequence number DEV-SNR via the web client WB-CLT, and the remaining information stored in the database DB can also be accessed based on the sequence number DEV-SNR received as an index column.

[0289] In this implementation, the Equipment Identification Dataset (DID) comprises five components: the serial number (DEV-SNR) of the equipment (DEV), the material number (DEV-MNR) of the equipment (DEV), the supplier (DEV-VEN) of the equipment (DEV), the model name (DEV-MOD) of the equipment (DEV), and the organization identifier (DEV-INST) associated with the equipment (DEV). Alternatively, the Equipment Identification Dataset (DID) may include only a subset of these five components, and may also include additional elements beyond these five.

[0290] Furthermore, the Key Creation Dataset (KCD) is transferred from the server SRV to the device DEV. The transfer of the KCD can be accomplished via a direct connection between the server SRV and the device DEV, or manually using a removable data storage device. In this embodiment, the KCD includes a Certificate Identifier (IDF-CERT-1), a Pre-Shared Secret (KCD-OTP), and a Certificate Request Domain Name (CRDN). In alternative embodiments, the KCD may include only a subset of these elements, and may also include additional elements. In this embodiment, the Certificate Identifier (IDF-CERT-1) is a hash value based on the Device Identifier Dataset (DID), such as the SHA256 hash of the DID. Furthermore, the Pre-Shared Secret (KCD-OTP) is a random one-time password used to verify the device DEV's response. Specifically, the Certificate Request Domain Name (CRDN) is a domain from which certificates can be requested; in this embodiment, the CRDN is a domain that can be used to access the server SRV. In particular, when the Key Creation Dataset (KCD) is manually transmitted via a removable data storage device, the Certificate Request Domain Name (CRDN) can be used because the device (DEV) may not be able to infer the domain of the server (SRV).

[0291] Furthermore, the Certificate Creation Request (CCR) is transmitted from the device (DEV) to the Certificate Authority (CA). In this embodiment, the CCR is transmitted from the device (DEV) to the server (SRV), and a modified CCR' is transmitted from the server (SRV) to the CA. Alternatively, the unmodified CCR can be transmitted from the server (SRV) to the CA. Alternatively, the certificate creation request can be transmitted directly from the device (DEV) to the CA without routing through the server (SRV).

[0292] In this implementation, the Certificate Creation Request (CCR) includes a public key PBK-1. The public key PBK-1 corresponds to a private key PRK-1 stored in the device DEV. The public key PBK-1 and the private key PRK-1 form an asymmetric key pair. This asymmetric key pair is created by the device DEV. The private key PRK-1 can be used to prove ownership of any digital certificate based on the public key PBK-1. The CCR also includes a pre-shared secret CCR-OTP, which is identical to the pre-shared secret KCD-OTP within the Key Creation Dataset (KCD). The CCR also includes a domain name DN-1. The domain name DN-1 includes an asterisk label AL and a certificate identifier IDF-CERT-1. Specifically, the domain name DN-1 may have the structure described with respect to the preceding figures. In alternative implementations, the CCR may include only a subset of these elements, and the CCR may also include additional elements.

[0293] In this implementation, the server SRV modifies the Certificate Creation Request (CCR) and creates a modified Certificate Creation Request (CCR)'. Here, the modified CCR' no longer includes the pre-shared secret CCR-OTP, because the check on the pre-shared secret CCR-OTP is performed at the server SRV. The modified CCR' is transmitted to the Certificate Authority. Specifically, the modified CCR' can be a Certificate Signing Request (CSR) or CSR-1 as described in the preceding figures.

[0294] In response, the Certificate Authority (CA) sends the digital certificate CERT-1 to the server SRV. The digital certificate CERT-1 includes the domain name DN-1, and specifically, the domain name DN-1 is the body of the digital certificate CERT-1. Furthermore, the digital certificate CERT-1 includes a signature SGN(PBK-1,PRK-CA) based on the device DEV's public key PBK-1, signed using the CA's private key PRK-CA.

[0295] The server SRV receives the digital certificate CERT-1 and sends it to the device DEV. Alternatively, the certificate authority (CA) can directly provide the digital certificate CERT-1 to the device DEV.

[0296] Figure 19 A sixth process flowchart of a method for providing a digital certificate CERT-1 according to an embodiment of the present invention is shown. The sixth process flowchart shown is based on... Figure 18 The data flow diagram is shown. Specifically, the Device Identifier dataset DID, Key Creation dataset KCD, and Certificate Creation dataset CCD can have related data. Figure 18 The same advantageous implementation methods and features are described.

[0297] The first step of the illustrated implementation is to receive the REC-DID device identifier dataset (DID), which uniquely identifies the device (DEV). In this implementation, this step is performed by the interface SRV.IF of the server SRV.

[0298] In the illustrated embodiment, the step of receiving the REC-DID device identifier dataset DID includes the following optional steps: querying the QRY-DB database from the database DB to obtain information related to the device DEV; and receiving from the database DB the REC-DEV device DEV serial number DEV-SNR, device DEV material number DEV-MNR, device DEV supplier name DEV-VEN, and / or device DEV model name DEV-MOD.

[0299] Alternatively, or additionally, the distinct elements of the Device Identifier Dataset (DID) can also be input by the user (USR) using the web client WB-CLT. Alternatively, or additionally, the distinct elements of the Device Identifier Dataset (DID) can also be received directly from the device (DEV).

[0300] In the illustrated implementation, the Device Identifier Dataset (DID) also includes an Organization Identifier (DEV-INST), which identifies the organization hosting the device (DEV). Here, the Organization Identifier (DEV-INST) is determined based on the credentials of an active user (USR). Specifically, an association may exist between user credentials stored in a database (DB) and the Organization Identifier (DEV-INST).

[0301] Another step in the illustrated implementation is to determine the DET-KCD key creation dataset KCD, which includes the certificate identifier IDF-CERT-1 based on the device identifier dataset DID. Specifically, the step of determining the DET-KCD key creation dataset KCD is performed by the computation unit SRV.CU of the server SRV. In this implementation, the certificate identifier IDF-CERT-1 is a hash of the device identifier dataset DID, such as SHA256(DID). Specifically, a salted hash function can be used. To compute the hash value, the device identifier dataset DID can be stored as a file with a standardized format. For example, JSON format, a text file format, can be used. The hash of the device identifier dataset DID is then equivalent to the hash of a file within the file system and / or equivalent to the hash of a string representing a text file.

[0302] Another step in the illustrated implementation is: specifically, sending the SND-KCD key to create a dataset KCD to the device DEV via the interface SRV.IF of the server SRV. In response to sending the SND-KCD key to create the dataset KCD, the next step in the illustrated implementation is: specifically, receiving a certificate creation request CCR associated with the first domain name DN-1 from the device DEV via the REC-CCR interface SRV.IF of the server SRV. Here, the first domain name DN-1 includes the certificate identifier IDF-CERT-1. In this implementation, the certificate creation request CCR is an EST (“Enrollment over Secure Transport”) request. Specifically, the certificate identifier IDF-CERT-1 can be used as the username within the EST request, and the pre-shared secret CCR-OTP can be used as the password within the EST request.

[0303] In this embodiment, the sending of the SND-KCD key creation dataset KCD to the device DEV can have different optional sub-steps depending on whether a pre-existing secure communication channel SCC exists between the server SRV and the device DEV. If a pre-existing secure communication channel SCC exists between the server SRV and the device DEV, the step of sending the SND-KCD key creation dataset includes: automatically transmitting the ATRM-KCD key creation dataset KCD to the device DEV via the secure communication channel SCC. If there is no pre-existing secure communication channel SCC between the server SRV and the device DEV, the step of sending the SND-KCD key creation dataset includes: storing the STR-KCD key creation dataset KCD on a portable storage medium, and specifically, transmitting the MTRM-KCD key creation dataset KCD to the device DEV via the portable storage medium by the user USR.

[0304] Another optional step in the illustrated method is to determine the modified Certificate Creation Request CCR (DET-CCR) based on the Certificate Creation Request CCR. Specifically, the modified Certificate Creation Request CCR does not contain another pre-shared secret CCR-OTP.

[0305] Another step in the illustrated method is to send the SND-CCR certificate creation request CCR or a modified certificate creation request CCR' to the Certificate Authority (CA). Specifically, if an optional step to determine the DET-CCR' exists, the modified certificate creation request CCR' is sent to the CA. Specifically, if an optional step to determine the DET-CCR' does not exist, the (unmodified) certificate creation request CCR is sent to the CA. Specifically, the step of sending the SND-CCR certificate creation request CCR or the modified certificate creation request CCR' may include, as per [the relevant information]... Figure 4 and Figure 5 All advantageous features and implementation methods of the steps described for sending the SND-CSR-1 First Certificate Signing Request CSR-1.

[0306] Another optional step of the illustrated method is: in response to receiving a Certificate Creation Request (CCR), perform a CHK check to see if another pre-shared secret CCR-OTP of the Certificate Creation Request CCR matches the pre-shared secret KCD-OTP of the Key Creation Dataset (KCD). In this case, the subsequent step of sending the SND-CCR Certificate Creation Request CCR or a modified Certificate Creation Request CCR' is performed only if the check is positive. Advantageously, the Certificate Creation Request CCR includes a certificate identifier IDF-CERT-1, and performing the CHK check also includes checking if the other pre-shared secret CCR-OTP of the Certificate Creation Request CCR is associated with the certificate identifier IDF-CERT-1. This can be done by comparing with the association stored in the database DB. In particular, the check is positive only if the other pre-shared secret CCR-OTP of the Certificate Creation Request CCR matches the pre-shared secret KCD-OTP of the Key Creation Dataset (KCD) and is associated with the certificate identifier IDF-CERT-1.

[0307] Another optional step in the illustrated implementation is to receive the digital certificate CERT-1 from a Certificate Authority (CA), wherein the digital certificate CERT-1 is a wildcard certificate based on the first domain name DN-1 signed by the CA. Specifically, this step may include, as per [the relevant information]... Figure 4 All advantageous implementations and features of the steps for receiving the REC-CERT-1 first digital certificate CERT-1 are described.

[0308] Another step in the illustrated implementation is to provide the device DEV with a PROV-CERT-1 digital certificate CERT-1, wherein the digital certificate CERT-1 is a wildcard certificate based on the first domain name DN-1, signed by a Certificate Authority (CA). Specifically, this step may include, as per [the relevant information]... Figure 4 All advantageous implementations and features of the steps described for providing the PROV-CERT-1 first digital certificate CERT-1.

[0309] Figure 20 A second process flowchart of a method for installing a digital certificate CERT-1 according to an embodiment of the present invention is shown. The second process flowchart shown is based on... Figure 18 The data flow diagram is shown. Specifically, the Device Identifier dataset DID, Key Creation dataset KCD, and Certificate Creation dataset CCD can have related data. Figure 18 The same advantageous implementation methods and features are described. Furthermore, the second process flowchart shown is when the server SRV executes as follows: Figure 19 The method shown is a supplementary process performed by the device DEV.

[0310] The first step of the method shown is to receive a key creation dataset KCD, including a certificate identifier IDF-CERT-1, from the server SRV. The certificate identifier IDF-CERT-1 is based on the device identifier dataset DID associated with the device DEV. Specifically, the key creation dataset KCD is received by the device DEV's interface DEV.IF.

[0311] Another step in the illustrated method is to determine the Certificate Creation Request CCR (CCR) associated with the first domain name DN-1 based on the Key Creation Dataset KCD (DET-CCR), where the first domain name DN-1 includes the certificate identifier IDF-CERT-1. The step of determining the DET-CCR certificate creation request CCR is performed by the computing unit DEV.CU of the device DEV. In this embodiment, the certificate creation request CCR is an EST (“Enrollment over Secure Transport”) request. Specifically, the certificate identifier IDF-CERT-1 can be used as the username within the EST request, and another pre-shared secret CCR-OTP contained in the Key Creation Dataset KCD can be used as the password within the EST request.

[0312] Another step in the illustrated method is to send an SND-CCR certificate creation request (CCR) to the Certificate Authority (CA) via the server SRV. In this embodiment, the certificate creation request (CCR) is transmitted from the device (DEV) to the server SRV, and a modified certificate creation request (CCR') is transmitted from the server SRV to the Certificate Authority (CA). Alternatively, the unmodified certificate creation request (CCR) can be transmitted from the server SRV to the Certificate Authority. Alternatively, the certificate creation request (CCR) can be transmitted directly from the device (DEV) to the Certificate Authority (CA) without routing through the server SRV.

[0313] Another step in the illustrated method is to receive the REC-CERT-1 digital certificate CERT-1, wherein the digital certificate CERT-1 is a wildcard certificate based on the first domain name DN-1 signed by a Certificate Authority (CA); and to install the INST-CERT-1 digital certificate CERT-1. The step of receiving the REC-CERT-1 digital certificate CERT-1 is performed by the interface DEV.IF of the device DEV, and the step of installing the INST-CERT-1 digital certificate CERT-1 is performed by the computing unit DEV.CU of the device DEV.

[0314] Figure 21 A seventh process flowchart of a method for providing a digital certificate according to an embodiment of the present invention is shown. The seventh process flowchart is as follows: Figure 19 As shown and about Figure 19The steps performed by the server SRV in the sixth process flowchart described above are as follows: Figure 20 As shown and about Figure 20 The combination of the described second process flowchart. In particular, individual method steps can have [related information]. Figure 19 and Figure 20 The same advantageous implementation methods and features are described.

[0315] Figure 22 A first embodiment of the server SRV, device DEV, certificate authority CA, requester REQ, and client CLT according to an embodiment of the present invention is shown. Figure 23 A second embodiment of the server SRV, device DEV, certificate authority CA, requester REQ, and client CLT according to an embodiment of the present invention is shown. Figure 24 A third embodiment of the server SRV, device DEV, certificate authority CA, requester REQ, and client CLT according to an embodiment of the present invention is shown.

[0316] exist Figure 22 The first embodiment shown and Figure 23 In the second embodiment shown, the server SRV is configured to perform the method according to the invention for providing a first digital certificate CERT-1 and / or to perform the method according to the invention for providing a DNS response DNS-RSP. Optionally, Figure 22 or Figure 23 The system shown may include a proxy BRK. The proxy BRK can be interpreted as part of the server SRV and is configured to receive authentication data AD and / or to verify authentication data AD. The proxy BRK may reside on the internal network of the server SRV, or it may be a physical part of the server SRV (e.g., Figure 22 As shown), alternatively, the agent BRK can be a device located within the intranet INTR of the device DEV (e.g., Figure 23 (As shown).

[0317] exist Figure 24 In the third embodiment shown, the server SRV includes two separate entities: a registration server SRV.REG, which is configured to perform the method according to the invention for providing a first digital certificate CERT-1; and a DNS server SRV.DNS, which is configured to perform the method according to the invention for providing a DNS response DNS-RSP.

[0318] exist Figure 22 , Figure 23 and Figure 24In the illustrated implementation, the device DEV, the client CLT, and the requester REQ are located within the intranet network INTR. Alternatively, the requester REQ may be located outside the intranet network INTR.

[0319] The server SRV, registry server SRV.REG, DNS server SRV.DNS, device DEV, certificate authority CA, proxy BRK, requester REQ, and / or client CLT can be a (personal) computer, workstation, virtual machine running on host hardware, microcontroller, or integrated circuit. Specifically, the server SRV, registry server SRV.REG, DNS server SRV.DNS, device DEV, certificate authority CA, proxy BRK, and / or client CLT can be mobile devices, such as smartphones or tablets. Alternatively, the server SRV, registry server SRV.REG, DNS server SRV.DNS, device DEV, certificate authority CA, proxy BRK, and / or client CLT can be a group of real or virtual computers (the technical term for a group of real computers is "cluster," and the technical term for a group of virtual computers is "cloud").

[0320] Device DEV and server SRV can communicate via a secure communication channel SCC and / or another network NETW. The network NETW can be implemented as a LAN ("local area network"), specifically a WiFi network, or any other local connection. Alternatively, the network NETW can be the Internet. The secure communication channel SCC can be part of a connection via the network NETW, or the secure communication channel SCC can be separate from the network. In particular, the secure communication channel SCC can be implemented as a VPN ("virtual private network").

[0321] Each of the following components may include: server SRV, registration server SRV.REG, DNS server SRV.DNS, device DEV, certificate authority CA, proxy BRK, and / or client CLT. The interfaces SRV.IF, DEV.IF, and CLT.IF may be hardware interfaces or software interfaces (e.g., PCI bus, USB, or FireWire). The computing units SRV.CU, DEV.CU, and CLT.CU may include hardware and software components such as a microprocessor, CPU (central processing unit), GPU (graphical processing unit), FPGA, or ASIC (application-specific integrated circuit). The computing units SRV.CU, DEV.CU, and CLT.CU can be configured for multi-threading, meaning that the computing units can simultaneously manage different computing processes, execute them in parallel, or switch between active and passive computing processes.

[0322] Figure 25 A fourth embodiment of a server SRV, device DEV, and certificate authority CA according to an embodiment of the present invention is shown. The server SRV and device DEV are configured to perform methods for providing and / or installing digital certificate CERT-1 according to the present invention and its embodiments. (See also: Regarding...) Figure 22 , Figure 23 and Figure 24 The server SRV and device DEV shown and described may include interfaces SRV.IF, DEV.IF, computing units SRV.CU, DEV.CU, and storage units SRV.MU, DEV.MU. Figure 25 (Not shown in the image).

[0323] In the fourth embodiment, the server SRV is located within the cloud environment CLD and includes an EST server EST-SRV as a submodule. Specifically, the EST server EST-SRV can be a software module installed on the server SRV.

[0324] In the fourth embodiment, a database DB is located within the cloud environment CLD. The database can be a dedicated hardware module or installed as a software module on standard hardware within the cloud environment CLD. The database DB stores information related to different device EVs, such as the serial number DEV-SNR and / or material number DEV-MNR of different device EVs. The database DB can be accessed from the server SRV to access information related to a specific device EV.

[0325] In the fourth embodiment, a service module SVC-MOD is located within the cloud environment CLD. The service module SVC-MOD can be a dedicated hardware module or can be installed as a software module on standard hardware within the cloud environment CLD. The service module SVC-MOD can be used to establish a secure communication channel SCC with the device DEV, for example, to establish remote access to the device DEV for maintenance purposes. The service module SVC-MOD can implement remote desktop protocols for communicating with the device DEV, such as Apple Remote Desktop Protocol (ARD), PC-over-IP (PCoIP), Remote Desktop Protocol (RDP), and / or X Window System (X11).

[0326] In the fourth embodiment, the device DEV is located within an intranet INTR, which may be the intranet INTR of a hospital or hospital group. In this embodiment, the device DEV includes a medical modality MDLT, such as an imaging modality (e.g., a computed tomography (CT) scanner, X-ray machine, magnetic resonance imaging (MRI) machine, C-arm CT scanner), laboratory diagnostic modality, point-of-care diagnostic modality, electrocardiogram (ECG) modality, or ventilator. Specifically, the device DEV may be identical to the medical modality MDLT, or the device DEV may be a sub-component of the medical modality MDLT. Furthermore, the device DEV includes an EST client EST-CLT as a sub-module. Specifically, the EST client EST-CLT may be a software module installed on the device DEV.

[0327] In the fourth embodiment, a gateway GTW is located within the intranet INTR. The gateway GTW can be a dedicated hardware module or can be installed as a software module on standard hardware within the intranet INTR. Specifically, the gateway GTW can be an edge device managed by the server SRV. In particular, communication between the device DEV and the server SRV can be routed through the gateway GTW.

[0328] In the fourth implementation, the cloud CLD, intranet INTR, and certificate authority CA are connected via network NTW, particularly via the Internet.

[0329] In the fourth embodiment, a web client, WB-CLT, is provided that can be used by the user USR to interact with the server SRV. The web client WB-CLT can be a dedicated hardware module or can be installed as a software module (e.g., as a browser) on the user USR's standard hardware. For example, the web client WB-CLT can be used to input device identification information (DID) to the server SRV. Specifically, the interaction between the web client WB-CLT and the server SRV can be based on the Hypertext Transfer Protocol (HTTP).

[0330] Terms and Conditions

[0331] The following terms are also part of this disclosure:

[0332] Clause 1.1: A computer-implemented method for providing a first digital certificate CERT-1 from a server SRV to a device DEV, comprising:

[0333] - Receive REC-AD authentication data AD from the device DEV via the secure communication channel SCC.

[0334] - Receive REC-IDF-CERT from the device DEV or determine DET-IDF-CERT by the server SRV. The first certificate identifier IDF-CERT-1 is specifically a hash value.

[0335] - Verify the authentication data AD stated in VRF-AD.

[0336] - Receive REC-PBK-1, the first public key PBK-1 created by the device DEV, from the device DEV.

[0337] - Send SND-CSR-1, a first certificate signing request (CSR-1) based on the first public key PBK-1 and associated with the first domain name DN-1, to the Certificate Authority (CA).

[0338] Wherein, the first domain name DN-1 includes the first certificate identifier IDF-CERT-1,

[0339] - Receive the first digital certificate CERT-1 (REC-CERT-1) from the Certificate Authority (CA).

[0340] Wherein, the first digital certificate CERT-1 is a wildcard certificate signed by the Certificate Authority (CA) based on the first domain name DN-1 and the first public key PBK-1.

[0341] - Provide the device DEV with the first digital certificate CERT-1, PROV-CERT-1.

[0342] Clause 1.2: The method described in Clause 1.1, wherein the first domain name DN-1 includes the asterisk label AL.

[0343] Clause 1.3: The method described in Clause 1.2, wherein the asterisk label AL is the last label of the first domain name DN-1.

[0344] Clause 1.4: The method according to Clause 1.1 or Clause 1.2, wherein the first certificate identifier IDF-CERT-1 is a tag of the first domain name DN-1 that is different from the last tag of the first domain name DN-1.

[0345] Clause 1.5: The method according to Clause 1.4, wherein the first certificate identifier IDF-CERT-1 is the penultimate tag of the first domain name DN-1.

[0346] Clause 1.6: The method described pursuant to any one of Clauses 1.1 to 1.4 further comprises:

[0347] -Prove ownership of the domain associated with the first domain name DN-1 (PRV-OWN).

[0348] Clause 1.7: The method described in Clause 1.6, wherein the step of proving ownership (PRV-OWN) includes at least one of the following sub-steps:

[0349] - Receive REC-CLG challenge from the Certificate Authority (CA).

[0350] - Determine the response of DET-RSP related to the challenge, wherein the response indicates control over the domain associated with the first domain name DN-1.

[0351] - Provide the PROV-RSP response to the Certificate Authority (CA).

[0352] - Notify INF-CA that the Certificate Authority (CA) has provided the response.

[0353] Clause 1.8: The method according to any one of Clauses 1.1 to 1.7, wherein the authentication data AD includes a pre-shared secret, and in particular, wherein the pre-shared secret is based on at least one of the following:

[0354] -Pre-shared one-time password

[0355] -Pre-shared key

[0356] -Pre-shared hardware token.

[0357] Clause 1.9: The method according to any one of Clauses 1.1 to 1.8, wherein the authentication data AD includes the device identifier IDF-DEV of the device DEV, and in particular, wherein the device identifier IDF-DEV is based on the material number of the device DEV and / or the serial number of the device DEV.

[0358] Clause 1.10: The method described pursuant to any one of Clauses 1.1 to 1.9 further comprises:

[0359] - Send SND-CSR-1', a modified first certificate signature request CSR-1' based on the first public key PBK-1 and associated with the modified first domain name DN-1', to the Certificate Authority (CA).

[0360] The modified first domain name DN-1' includes the first certificate identifier IDF-CERT-1.

[0361] - Receive the modified first digital certificate CERT-1' from the Certificate Authority (CA).

[0362] The modified first digital certificate CERT-1' is a wildcard certificate signed by the Certificate Authority (CA) based on the modified first domain name DN-1' and the first public key PBK-1.

[0363] - Provide the device DEV with the modified first digital certificate CERT-1'.

[0364] Clause 1.11: The method described pursuant to any one of Clauses 1.1 to 1.10 further comprises:

[0365] - Create CRT-DNS DNS resource records for the first domain name DN-1 and / or the modified first domain name DN-1'.

[0366] Clause 1.12: The method described pursuant to any one of Clauses 1.1 to 1.11 further comprises:

[0367] - Store the usage information of the STR-USG associated with the authentication data AD to prevent the reuse of the authentication data AD.

[0368] Clause 1.13: The method described pursuant to any one of Clauses 1.1 to 1.12 further comprises:

[0369] - Optionally, the device DEV is authenticated as AUTH-DEV based on the first digital certificate CERT-1.

[0370] - Receive REC-RD registration data RD from the device DEV.

[0371] The registration data RD includes the second certificate identifier IDF-CERT-2.

[0372] - Receive REC-PBK-2, a second public key PBK-2 created by the client CLT of the device DEV.

[0373] - Send SND-CSR-2, a second certificate signing request CSR-2 based on the second public key PBK-2 and associated with the second domain name DN-2, to the Certificate Authority (CA).

[0374] Wherein, the second domain name DN-2 includes the second certificate identifier IDF-CERT-2,

[0375] - Receive the REC-CERT-2 second digital certificate CERT-2 from the Certificate Authority (CA).

[0376] The second digital certificate, CERT-2, is a wildcard certificate based on the second domain name, DN-2, signed by the Certificate Authority (CA).

[0377] - Provide the PROV-CERT-2 second digital certificate CERT-2 to the device DEV and / or the client CLT.

[0378] Clause 1.14: The method according to Clause 1.13, wherein the second certificate identifier IDF-CERT-2 includes the first certificate identifier IDF-CERT-1 and the client identifier IDF-CLT associated with the client CLT.

[0379] Clause 1.15: The method according to Clause 1.14, wherein the second domain name DN-2 includes an asterisk label AL, wherein the asterisk label AL is the last label of the second domain name DN-2, wherein the first certificate identifier IDF-CERT-1 is the penultimate label of the second domain name DN-2, and wherein the client identifier IDF-CLT is the penultimate label of the second domain name DN-2.

[0380] Clause 1.16: The method according to Clause 1.14, wherein the second domain name DN-2 includes an asterisk label AL, wherein the asterisk label AL is the last label of the second domain name DN-2, wherein the first certificate identifier IDF-CERT-1 is the third to last label of the second domain name DN-2, and wherein the client identifier IDF-CLT is the second to last label of the second domain name DN-2.

[0381] Clause 1.17: The method described pursuant to any one of Clauses 1.1 to 1.16 further comprises:

[0382] - Create a DICOM node configuration based on the first digital certificate CERT-1 and / or the second digital certificate CERT-2.

[0383] Clause 2.1: A computer-implemented method for installing a first digital certificate CERT-1 on a device DEV, comprising:

[0384] - The authentication data used by the device DEV to authenticate the device DEV at the server SRV, as determined by DET-AD.

[0385] The authentication data SND-AD is sent by the device DEV to the server SRV via the secure communication channel SCC.

[0386] The authentication data AD, REC-AD, is received by the server SRV via the secure communication channel SCC.

[0387] - The authentication data AD of VRF-AD is verified by the server SRV.

[0388] - The device DEV sends the first certificate identifier IDF-CERT-1 (SND-IDF-CERT-1) to the server SRV.

[0389] Specifically, the first certificate identifier IDF-CERT-1 is a hash value or a random value.

[0390] - The server SRV receives the first certificate identifier IDF-CERT-1 from REC-IDF-CERT.

[0391] - The device DEV creates a first asymmetric key pair, CRT-AKP-1, which includes a first public key PBK-1 and a first private key PRK-1.

[0392] - The device DEV sends the first public key PBK-1, SND-PBK-1, to the server SRV.

[0393] - The server SRV receives REC-PBK-1, which is the first public key PBK-1 created by the device DEV.

[0394] - The server SRV sends a first certificate signing request CSR-1, based on the first public key PBK-1 and associated with the first domain name DN-1, to the certificate authority CA.

[0395] The first domain name DN-1 includes the first certificate identifier IDF-CERT-1.

[0396] - The server SRV receives the first digital certificate CERT-1 (REC-CERT-1) from the certificate authority (CA).

[0397] Wherein, the first digital certificate CERT-1 is a wildcard certificate signed by the Certificate Authority (CA) based on the first domain name DN-1 and the first public key PBK-1.

[0398] - The server SRV provides the device DEV with the first digital certificate CERT-1, PROV-CERT-1.

[0399] - The first digital certificate CERT-1 is installed on the device DEV by INST-CERT-1.

[0400] Clause 2.2: The method described in Clause 2.1, wherein the first domain name DN-1 includes the asterisk label AL.

[0401] Clause 2.3: The method described in Clause 2.2, wherein the asterisk label AL is the last label of the first domain name DN-1.

[0402] Clause 2.4: The method described in accordance with Clause 2.1 or Clause 2.2, wherein the first certificate identifier IDF-CERT-1 is a tag of the first domain name DN-1 that is different from the last tag of the first domain name DN-1.

[0403] Clause 2.5: The method described in accordance with Clause 2.4, wherein the first certificate identifier IDF-CERT-1 is the penultimate tag of the first domain name DN-1.

[0404] Clause 2.6: The method described pursuant to any one of Clauses 2.1 to 2.4 further comprises:

[0405] -Prove ownership of the domain associated with the first domain name DN-1 (PRV-OWN).

[0406] Clause 2.7: The method described in Clause 2.6, wherein the step of proving ownership (PRV-OWN) includes at least one of the following sub-steps:

[0407] - Receive REC-CLG challenge from the Certificate Authority (CA).

[0408] - Determine the response of DET-RSP related to the challenge, wherein the response indicates control over the domain associated with the first domain name DN-1.

[0409] - Provide the PROV-RSP response to the Certificate Authority (CA).

[0410] - Notify INF-CA that the Certificate Authority (CA) has provided the response.

[0411] Clause 2.8: The method according to any one of Clauses 2.1 to 2.7, wherein the authentication data AD includes a pre-shared secret, and in particular, wherein the pre-shared secret is based on at least one of the following:

[0412] -Pre-shared one-time password

[0413] -Pre-shared key

[0414] -Pre-shared hardware token.

[0415] Clause 2.9: The method according to any one of Clauses 2.1 to 2.8, wherein the authentication data AD includes the device identifier IDF-DEV of the device DEV, and in particular, wherein the device identifier IDF-DEV is based on the material number of the device DEV and / or the serial number of the device DEV.

[0416] Clause 2.10: The method described pursuant to any one of Clauses 2.1 to 2.9 further comprises:

[0417] - The server SRV sends a modified first certificate signature request CSR-1' based on the first public key PBK-1 and associated with the modified first domain name DN-1' to the certificate authority CA.

[0418] The modified first domain name DN-1' includes the first certificate identifier IDF-CERT-1.

[0419] - The server SRV receives the modified first digital certificate CERT-1' (REC-CERT-1') from the certificate authority (CA).

[0420] The modified first digital certificate CERT-1' is a wildcard certificate signed by the Certificate Authority (CA) based on the modified first domain name DN-1' and the first public key PBK-1.

[0421] - The modified first digital certificate CERT-1' is provided by the server SRV to the device DEV.

[0422] - The modified first digital certificate CERT-1' is installed on the device DEV by the device DEV.

[0423] Clause 2.11: The method described pursuant to any one of Clauses 2.1 to 2.10 further comprises:

[0424] - Create CRT-DNS DNS resource records for the first domain name DN-1 and / or the modified first domain name DN-1'.

[0425] Clause 2.12: The method described pursuant to any one of Clauses 2.1 to 2.11 further comprises:

[0426] - Store the usage information of the STR-USG associated with the authentication data AD to prevent the reuse of the authentication data AD.

[0427] Clause 2.13: The method described pursuant to any one of Clauses 2.1 to 2.12 further comprises:

[0428] - Optionally, the device DEV is authenticated as AUTH-DEV based on the first digital certificate CERT-1.

[0429] - The device DEV sends TRM-RD registration data RD to the server SRV, wherein the registration data RD includes a second certificate identifier IDF-CERT-2.

[0430] - The registration data RD is received by the server SRV from the device DEV via REC-RD.

[0431] - The device DEV sends TRM-PBK-2, a second public key PBK-2 created by the client CLT of the device DEV, to the server SRV.

[0432] - The server SRV receives REC-PBK-2, the second public key PBK-2.

[0433] - The server SRV sends a second certificate signing request CSR-2, based on the second public key PBK-2 and associated with the second domain name DN-2, to the certificate authority CA.

[0434] Wherein, the second domain name DN-2 includes the second certificate identifier IDF-CERT-2,

[0435] - The server SRV receives the REC-CERT-2 second digital certificate CERT-2 from the certificate authority CA.

[0436] The second digital certificate, CERT-2, is a wildcard certificate based on the second domain name, DN-2, signed by the Certificate Authority (CA).

[0437] - The server SRV provides the PROV-CERT-2 second digital certificate CERT-2 to the device DEV and / or the client CLT, optionally including the device DEV sending the TRM-CERT-2 second digital certificate to the client CLT.

[0438] Clause 2.14: The method described pursuant to Clause 2.14 further includes:

[0439] - The registration data RD is determined by the client CLT using DET-RD.

[0440] - The client CLT sends the registration data RD (SND-RD) to the device DEV.

[0441] - The client CLT creates a second asymmetric key pair, CRT-AKP-2, which includes a second public key PBK-2 and a second private key PRK-2.

[0442] - The client CLT sends the second public key PBK-2, SND-PBK-2, to the device DEV.

[0443] - The second digital certificate CERT-2 is installed by the client CLT.

[0444] Clause 2.15: The method according to Clause 2.13 or 2.14, wherein the second certificate identifier IDF-CERT-2 includes the first certificate identifier IDF-CERT-1 and the client identifier IDF-CLT associated with the client CLT.

[0445] Clause 2.16: The method according to Clause 2.15, wherein the second domain name DN-2 includes an asterisk label AL, wherein the asterisk label AL is the last label of the second domain name DN-2, wherein the first certificate identifier IDF-CERT-1 is the penultimate label of the second domain name DN-2, and wherein the client identifier IDF-CLT is the penultimate label of the second domain name DN-2.

[0446] Clause 2.17: The method according to Clause 2.15, wherein the second domain name DN-2 includes an asterisk label AL, wherein the asterisk label AL is the last label of the second domain name DN-2, wherein the first certificate identifier IDF-CERT-1 is the third to last label of the second domain name DN-2, and wherein the client identifier IDF-CLT is the second to last label of the second domain name DN-2.

[0447] Clause 2.18: The method described pursuant to any one of Clauses 2.1 to 2.17 further comprises:

[0448] - Create a DICOM node configuration based on the first digital certificate CERT-1 and / or the second digital certificate CERT-2.

[0449] Clause 3.1: A method for providing a second digital certificate to a client CLT and / or a device DEV, comprising:

[0450] - Optionally, the device DEV can be authenticated as AUTH-DEV based on the first digital certificate CERT-1.

[0451] - Receive REC-RD registration data RD from the device DEV.

[0452] The registration data RD includes the second certificate identifier IDF-CERT-2.

[0453] - Receive REC-PBK-2, a second public key PBK-2 created by the client CLT of the device DEV.

[0454] - Send a second certificate signing request (CSR-2) to the Certificate Authority (CA) based on the second public key (PBK-2) and associated with the second domain name (DN-2), named SND-CSR-2.

[0455] Wherein, the second domain name DN-2 includes the second certificate identifier IDF-CERT-2,

[0456] - Receive the REC-CERT-2 second digital certificate CERT-2 from the Certificate Authority (CA).

[0457] The second digital certificate, CERT-2, is a wildcard certificate based on the second domain name, DN-2, signed by the Certificate Authority (CA).

[0458] - Provide the PROV-CERT-2 second digital certificate CERT-2 to the device DEV and / or the client CLT.

[0459] Clause 3.2: The method according to Clause 3.1, wherein the second certificate identifier IDF-CERT-2 includes the first certificate identifier IDF-CERT-1 and the client identifier IDF-CLT associated with the client CLT.

[0460] Clause 3.3: The method according to Clause 3.2, wherein the second domain name DN-2 includes an asterisk label AL, wherein the asterisk label AL is the last label of the second domain name DN-2, wherein the first certificate identifier IDF-CERT-1 is the penultimate label of the second domain name DN-2, and wherein the client identifier IDF-CLT is the penultimate label of the second domain name DN-2.

[0461] Clause 3.4: The method according to Clause 3.2, wherein the second domain name DN-2 includes an asterisk label AL, wherein the asterisk label AL is the last label of the second domain name DN-2, wherein the first certificate identifier IDF-CERT-1 is the third to last label of the second domain name DN-2, and wherein the client identifier IDF-CLT is the second to last label of the second domain name DN-2.

[0462] Clause 3.5: The method described pursuant to any one of Clauses 3.1 to 3.4 further comprises:

[0463] - Create a DICOM node configuration based on the first digital certificate CERT-1 and / or the second digital certificate CERT-2.

[0464] Clause 4.1: A computer-implemented method for providing DNS responses, comprising:

[0465] - Receive the DNS request REC-DNS-REQ from the requester REQ to resolve the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2'.

[0466] The fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2' include the encoded domain name E-DN used as a tag.

[0467] - Determine the DET-D-DN decoding domain name D-DN based on the encoded domain name E-DN.

[0468] - Provide the requester REQ with a PROV-DNS-RSP DNS response DNS-RSP, wherein the DNS response DNS-RSP includes the decoded domain name D-DN.

[0469] Clause 4.2: The method according to Clause 4.1, wherein the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', FQDN-2' can include an encoded IP address E-IP as an alternative to the encoded domain name E-DN, the method further comprising:

[0470] - Based on the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2', determine whether the DET-DNS-TYP DNS request is related to an A resource record, an AAAA resource record, or a CNAME resource record.

[0471] - In the case where the DNS request is related to a CNAME resource record.

[0472] --Determine the decoded domain name D-DN based on the encoded domain name E-DN.

[0473] --Provide the requester REQ with the PROV-DNS-RSP DNS response DNS-RSP, wherein the DNS response DNS-RSP includes the CNAME resource record, and wherein the DNS response DNS-RSP includes the decoded domain name D-DN.

[0474] - In cases where the DNS request is related to an A resource record or an AAAA resource record.

[0475] --Based on the encoded IP address E-IP, determine the DET-D-IP decoded IP address D-IP.

[0476] --Provide the requester REQ with the DNS response DNS-RSP, wherein the DNS response DNS-RSP includes the A resource record or the AAAA resource record, and wherein the DNS response DNS-RSP includes the decoded IP address D-IP.

[0477] Clause 4.3: The method according to Clause 4.2, wherein the step of determining whether the DNS request of DET-DNS-TYP is related to an A resource record, an AAAA resource record or a CNAME resource record based on the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', FQDN-2' is based on the presence and / or content of tags that are not the lowest-level tags of the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', FQDN-2'.

[0478] Clause 4.4: The method according to Clause 4.2, wherein the step of determining whether the DNS request of DET-DNS-TYP is related to an A resource record, an AAAA resource record, or a CNAME resource record based on the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', FQDN-2' is based on the content of the lowest tag of the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', FQDN-2'.

[0479] Clause 5.1: A server SRV for providing a first digital certificate CERT-1 to a device DEV, comprising an interface SRV.IF and a computing unit SRV.CU.

[0480] - Configured to receive REC-AD authentication data AD from the device DEV via the secure communication channel SCC.

[0481] - Configured to receive REC-IDF-CERT from the device DEV or to determine DET-IDF-CERT by the server SRV. The first certificate identifier IDF-CERT-1 is specifically a hash value or a random value.

[0482] - Configured for verifying the authentication data AD described in VRF-AD.

[0483] - Configured to receive REC-PBK-1, the first public key PBK-1 created by the device DEV, from the device DEV.

[0484] - Configured to send a first certificate signing request (CSR-1) based on the first public key PBK-1 and associated with the first domain name DN-1 to a Certificate Authority (CA) using SND-CSR-1.

[0485] Wherein, the first domain name DN-1 includes the first certificate identifier IDF-CERT-1,

[0486] Furthermore, the domain associated with the first domain name DN-1 is controlled by the server SRV.

[0487] - Configured to receive the first digital certificate CERT-1 (REC-CERT-1) from the Certificate Authority (CA).

[0488] Wherein, the first digital certificate CERT-1 is a wildcard certificate signed by the Certificate Authority (CA) based on the first domain name DN-1 and the first public key PBK-1.

[0489] - Configured to provide the first digital certificate CERT-1, PROV-CERT-1, to the device DEV.

[0490] Clause 5.2: The server SRV described in Clause 5.1 is also configured to perform the method described in any one of Clauses 1.2 to 1.17.

[0491] Clause 5.3: A device DEV, including an interface DEV.IF and a computing unit DEV.CU, is configured to:

[0492] - Determine the authentication data used by DET-AD to authenticate the device DEV at the server SRV.

[0493] Optionally, the server SRV is sent an SND-IDF-CERT first certificate identifier IDF-CERT-1, specifically, wherein the first certificate identifier IDF-CERT-1 is a hash value or a random value.

[0494] - Create a first asymmetric key pair, CRT-AKP-1, comprising a first public key PBK-1 and a first private key PRK-1.

[0495] - Send the first public key PBK-1, SND-PBK-1, to the server SRV.

[0496] - Receive the first digital certificate CERT-1 and install INST-CERT-1 on the device DEV.

[0497] Clause 5.4: The device DEV as described in Clause 5.3 is also configured to perform the steps of the method described in any one of Clauses 2.2 to 2.18.

[0498] Clause 5.5: A client CLT including an interface CLT.IF and a computing unit CLT.CU, said client CLT being a client of device DEV, said client CLT being configured to:

[0499] - Determine the DET-RD registration data RD,

[0500] - Send the registration data RD (SND-RD) to the device DEV.

[0501] - Create a second asymmetric key pair, CRT-AKP-2, which includes a second public key PBK-2 and a second private key PRK-2.

[0502] - Send the second public key PBK-2, SND-PBK-2, to the device DEV.

[0503] - Receive and install INST-CERT-2 second digital certificate CERT-2.

[0504] Clause 5.6: A system comprising:

[0505] - Server SRV as described in either Clause 5.1 or 5.2,

[0506] - The device DEV as described in either clause 5.3 or 5.4.

[0507] Clause 5.7: The system described in Clause 5.6 further includes:

[0508] - Client CLT as described in Clause 5.5.

[0509] Clause 5.8: The system described in Clause 5.7, wherein the client CLT and the device DEV are located in the intranet INTR.

[0510] Clause 5.9: A DNS server including an interface and a computing unit, configured to:

[0511] - Receive the DNS request REC-DNS-REQ from the requester REQ to resolve the fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2'.

[0512] The fully qualified domain names FQDN-1, FQDN-2, FQDN-1', and FQDN-2' include the encoded domain name E-DN used as a tag.

[0513] - Determine the DET-D-DN decoding domain name D-DN based on the encoded domain name E-DN.

[0514] - Provide the requester REQ with a PROV-DNS-RSP DNS response DNS-RSP, wherein the DNS response DNS-RSP includes the decoded domain name D-DN.

[0515] Clause 5.10: The DNS server described in Clause 5.9 is also configured to perform the method described in any one of Clauses 4.2 to 4.4.

[0516] Clause 6.1: A computer-implemented method for providing a digital certificate CERT-1 to a device DEV, comprising:

[0517] - Receive REC-DID device identifier dataset DID, whereby the device identifier dataset DID uniquely identifies the device DEV.

[0518] - Determine the key creation dataset KCD for DET-KCD, including the certificate identifier IDF-CERT-1, which is based on the device identifier dataset DID.

[0519] - Send the SND-KCD key to the device DEV to create a dataset KCD.

[0520] - Receive a certificate creation request (CCR) from the device DEV, which is a REC-CCR request for creating a dataset KCD based on the key and associated with the first domain name DN-1.

[0521] Wherein, the first domain name DN-1 includes the certificate identifier IDF-CERT-1,

[0522] - Send the certificate creation request CCR or a modified certificate creation request CCR' described in the SND-CCR to the Certificate Authority (CA).

[0523] - Provide the device DEV with the PROV-CERT-1 digital certificate CERT-1.

[0524] The digital certificate CERT-1 is a wildcard certificate based on the first domain name DN-1, signed by the Certificate Authority (CA).

[0525] Clause 6.2: The method according to Clause 6.1, wherein the device identifier dataset DID includes at least one of the following:

[0526] - The serial number of the device DEV, DEV-SNR,

[0527] -The material number of the device DEV is DEV-MNR.

[0528] - The supplier name of the equipment DEV, DEV-VEN, and / or

[0529] - The model name of the device DEV is DEV-MOD.

[0530] Clause 6.3: The method described pursuant to Clause 6.2 further includes:

[0531] - Query the QRY-DB database (DB) for information related to the device DEV.

[0532] - Receive from the database DB the REC-DEV serial number DEV-SNR, the material number DEV-MNR, the supplier name DEV-VEN, and / or the model name DEV-MOD of the device DEV.

[0533] Clause 6.4: The method according to any one of Clauses 6.1 to 6.3, wherein the device identifier dataset DID includes an organization identifier DEV-INST, wherein the organization identifier DEV-INST identifies the organization hosting the device DEV, and wherein the organization identifier DEV-INST is determined based on the credentials of an active user.

[0534] Clause 6.5: The method according to any one of Clauses 6.1 to 6.4, wherein the certificate identifier IDF-CERT-1 is a hash of the device identifier dataset DID.

[0535] Clause 6.6: The method according to any one of Clauses 6.1 to 6.5, wherein the key creation dataset KCD further includes a pre-shared secret KCD-OTP and / or a certificate request domain name.

[0536] Clause 6.7: The method according to any one of Clauses 6.1 to 6.6, wherein the pre-shared secret is based on at least one of the following:

[0537] -Pre-shared one-time password

[0538] -Pre-shared key

[0539] -Pre-shared hardware token.

[0540] Clause 6.8: The method according to any one of Clauses 6.1 to 6.7, wherein the Certificate Creation Request (CCR) is a Registered EST Request via Secure Transmission.

[0541] Clause 6.9: The method according to any one of Clauses 6.1 to 6.8, wherein the Key Creation Dataset (KCD) includes a pre-shared secret KCD-OTP, wherein the Certificate Creation Request (CCR) includes another pre-shared secret CCR-OTP, and wherein the method further comprises:

[0542] - In response to receiving the Certificate Creation Request (CCR), perform a CHK check to see if another pre-shared secret, CCR-OTP, of the Certificate Creation Request (CCR) matches the pre-shared secret, KCD-OTP, of the Key Creation Dataset (KCD).

[0543] Specifically, the step of sending the certificate creation request (CCR) described in the SND-CCR is only performed if a positive check is performed.

[0544] Clause 6.10: The method according to Clause 6.9, wherein the Certificate Creation Request (CCR) includes the Certificate Identifier (IDF-CERT-1), wherein performing the check further includes checking whether another pre-shared secret (CCR-OTP) of the Certificate Creation Request (CCR) is associated with the Certificate Identifier (IDF-CERT-1).

[0545] Clause 6.11: The method according to any one of Clauses 6.1 to 6.10, wherein sending the SND-KCD key to the device DEV to create the dataset KCD comprises:

[0546] - Automatically transmit the ATRM-KCD key to the device DEV via the secure communication channel SCC to create a dataset KCD, or

[0547] - Store the STR-KCD key creation dataset KCD on a portable storage medium, and transmit the MTRM-KCD key creation dataset KCD to the device DEV via the portable storage medium.

[0548] Clause 6.12: The method according to any one of Clauses 6.1 to 6.11, wherein the first domain name DN-1 includes the asterisk label AL.

[0549] Clause 6.13: The method described in Clause 6.12, wherein the asterisk label AL is the last label of the first domain name DN-1.

[0550] Clause 6.14: The method according to any one of Clauses 6.1 to 6.13, wherein the first certificate identifier IDF-CERT-1 is a tag of the first domain name DN-1 that is different from the last tag of the first domain name DN-1.

[0551] Clause 6.15: The method described in Clause 6.14, wherein the first certificate identifier IDF-CERT-1 is the penultimate tag of the first domain name DN-1.

[0552] Clause 6.16: The method described pursuant to any one of Clauses 6.1 to 6.15 further comprises:

[0553] -Prove ownership of the domain associated with the first domain name DN-1 (PRV-OWN).

[0554] Clause 6.17: The method described in Clause 6.16, wherein the step of proving ownership PRV-OWN includes at least one of the following sub-steps:

[0555] - Receive REC-CLG challenge from the Certificate Authority (CA).

[0556] - Determine the response of DET-RSP related to the challenge, wherein the response indicates control over the domain associated with the first domain name DN-1.

[0557] - Provide the PROV-RSP response to the Certificate Authority (CA).

[0558] - Notify INF-CA that the Certificate Authority (CA) has provided the response.

[0559] Clause 6.18: The method described pursuant to any one of Clauses 6.1 to 6.17 further comprises:

[0560] - Create a CRT-DNS DNS resource record for the first domain name DN-1.

[0561] Clause 6.19: The method described pursuant to any one of Clauses 6.1 to 6.18 further comprises:

[0562] - Create a DICOM node configuration based on the first digital certificate CERT-1 and / or the second digital certificate CERT-2.

[0563] Clause 6.20: The method described pursuant to any one of Clauses 6.1 to 6.19 further comprises:

[0564] - Determine the modified certificate creation request (CCR) DET-CCR' based on the certificate creation request.

[0565] Specifically, the modified Certificate Creation Request (CCR) is sent to the Certificate Authority (CA).

[0566] Clause 6.21: The method described in accordance with Clause 6.20, wherein the modified Certificate Creation Request (CCR) does not contain the pre-shared secret CCR-OTP.

[0567] Clause 7.1: A computer-implemented method for installing a digital certificate CERT-1 on a device DEV, comprising:

[0568] - Receive a REC-KCD from the server SRV, including a key containing a certificate identifier IDF-CERT-1, to create a dataset KCD. The certificate identifier IDF-CERT-1 is based on a device identifier dataset DID associated with the device DEV.

[0569] - Determine the certificate creation request (CCR) associated with the first domain name DN-1 for the DET-CCR to create dataset KCD based on the key.

[0570] Wherein, the first domain name DN-1 includes the certificate identifier IDF-CERT-1,

[0571] - The certificate creation request (CCR) is sent from the server SRV to the Certificate Authority (CA) via the SND-CCR.

[0572] - Receive the digital certificate CERT-1, which is REC-CERT-1, wherein the digital certificate CERT-1 is a wildcard certificate based on the first domain name DN-1, signed by the Certificate Authority (CA).

[0573] - Install the digital certificate described in INST-CERT-1.

[0574] Clause 7.2: The method according to Clause 7.1, wherein the device identifier dataset DID includes at least one of the following:

[0575] - The serial number of the device DEV, DEV-SNR,

[0576] -The material number of the device DEV is DEV-MNR.

[0577] - The supplier name of the equipment DEV, DEV-VEN, and / or

[0578] - The model name of the device DEV is DEV-MOD.

[0579] Clause 7.3: The method according to Clause 7.1 or 7.2, wherein the device identifier dataset DID includes an organization identifier DEV-INST, wherein the organization identifier DEV-INST identifies the organization hosting the device DEV, and wherein the organization identifier DEV-INST is determined based on the credentials of an active user.

[0580] Clause 7.4: The method according to any one of Clauses 7.1 to 7.3, wherein the certificate identifier IDF-CERT-1 is a hash of the device identifier dataset DID.

[0581] Clause 7.5: The method according to any one of Clauses 7.1 to 7.4, wherein the key creation dataset KCD further includes a pre-shared secret KCD-OTP and / or a certificate request domain name CRDN.

[0582] Clause 7.6: The method according to any one of Clauses 7.1 to 7.5, wherein the key creation dataset KCD further includes a pre-shared secret KCD-OTP, wherein the pre-shared secret KCD-OTP is based on at least one of the following:

[0583] -Pre-shared one-time password

[0584] -Pre-shared key

[0585] -Pre-shared hardware token.

[0586] Clause 7.7: The method according to any one of Clauses 7.1 to 7.6, wherein the Certificate Creation Request (CCR) is a Secure Transmission Registration EST Request.

[0587] Clause 7.8: The method according to any one of Clauses 7.1 to 7.7, wherein receiving the key from the server SRV to create the dataset KCD comprises:

[0588] - Automatically receive the key from the server SRV via the secure communication channel SCC to create the dataset KCD, or

[0589] - Store the key creation dataset KCD of STR-KCD on a portable storage medium, and receive the key creation dataset KCD from the server SRV through the portable storage medium.

[0590] Clause 7.9: The method described in any one of Clauses 7.1 to 7.8, wherein the first domain name DN-1 includes the asterisk label AL.

[0591] Clause 7.10: The method described in Clause 7.9, wherein the asterisk label AL is the last label of the first domain name DN-1.

[0592] Clause 7.11: The method according to any one of Clauses 7.1 to 7.10, wherein the first certificate identifier IDF-CERT-1 is a tag of the first domain name DN-1 that is different from the last tag of the first domain name DN-1.

[0593] Clause 7.12: The method described in Clause 7.11, wherein the first certificate identifier IDF-CERT-1 is the penultimate tag of the first domain name DN-1.

[0594] Clause 7.13: The method described pursuant to any one of Clauses 7.1 to 7.12 further includes:

[0595] - Create a DICOM node configuration based on the first digital certificate CERT-1.

[0596] Clause 8.1: A server SRV configured to provide a digital certificate CERT-1 to a device DEV is configured to:

[0597] - Receive the REC-DID device identifier dataset (DID), which uniquely identifies the device (DEV).

[0598] - Determine the key creation dataset KCD for DET-KCD, including the certificate identifier IDF-CERT-1, which is based on the device identifier dataset DID.

[0599] - Send the SND-KCD key to the device DEV to create a dataset KCD.

[0600] - Receive a certificate creation request (CCR) from the device DEV, which is a REC-CCR request for creating a dataset KCD based on the key and associated with the first domain name DN-1.

[0601] Wherein, the first domain name DN-1 includes the certificate identifier IDF-CERT-1,

[0602] - Send the certificate creation request (CCR) described in the SND-CCR to the Certificate Authority (CA).

[0603] - Provide the device DEV with the PROV-CERT-1 digital certificate CERT-1.

[0604] The digital certificate CERT-1 is a wildcard certificate based on the first domain name DN-1, signed by the Certificate Authority (CA).

[0605] Clause 8.2: The server SRV as described in Clause 8.1 is also configured to perform the method described in any one of Clauses 6.2 to 6.19.

[0606] Clause 9.1: A device DEV for installing the digital certificate CERT-1 is configured to:

[0607] - Receive a REC-KCD from the server SRV, including a key creation dataset KCD containing a certificate identifier IDF-CERT-1, where the certificate identifier IDF-CERT-1 is based on a device identifier dataset DID associated with the device DEV.

[0608] - Determine the certificate creation request (CCR) associated with the first domain name DN-1 for the DET-CCR to create dataset KCD based on the key.

[0609] Wherein, the first domain name DN-1 includes the certificate identifier IDF-CERT-1,

[0610] - The certificate creation request (CCR) is sent from the server SRV to the Certificate Authority (CA) via the SND-CCR.

[0611] - Receive the digital certificate CERT-1, which is REC-CERT-1, wherein the digital certificate CERT-1 is a wildcard certificate based on the first domain name DN-1, signed by the Certificate Authority (CA).

[0612] - Install the digital certificate described in INST-CERT-1.

[0613] Clause 9.2: The device DEV as described in Clause 9.1 is also configured to perform the method described in any one of Clauses 7.2 to 7.13.

[0614] Where not explicitly described, various embodiments or aspects and features thereof may be combined or interchanged with each other without limiting or broadening the scope of the described invention, provided that such combination or interchange is meaningful and in the sense of the invention. Advantages described with respect to one embodiment of the invention are also advantages of other embodiments of the invention where applicable.

Claims

1. A computer-implemented method for providing a digital certificate (CERT-1) to a device (DEV), comprising: - Receive (REC-DID) Device Identifier Dataset (DID), which uniquely identifies the device (DEV). - Determine (DET-KCD) a Key Creation Dataset (KCD) including a Certificate Identifier (IDF-CERT-1) and a Pre-Shared Secret (KCD-OTP), wherein the Certificate Identifier (IDF-CERT-1) is a hash of the Device Identifier Dataset (DID), the device is configured to initiate the creation of the digital certificate based on the Key Creation Dataset, and the Pre-Shared Secret is installed on the device during its manufacture. - Send the key to the device (DEV) to create a dataset (KCD) (SND-KCD). - Receive (REC-CCR) a certificate creation request (CCR) associated with the first domain name (DN-1) based on the key creation dataset (KCD) from the device (DEV). The first domain name (DN-1) includes the certificate identifier (IDF-CERT-1). - Send the Certificate Creation Request (CCR) or its modified version (CCR') to the Certificate Authority (CA). - Provide the digital certificate (CERT-1) to the device (DEV) (PROV-CERT-1). The digital certificate (CERT-1) is a wildcard certificate based on the first domain name (DN-1) signed by the Certificate Authority (CA).

2. The method according to claim 1, wherein, The Device Identifier Dataset (DID) includes at least one of the following: - The serial number (DEV-SNR) of the device (DEV). - The material number (DEV-MNR) of the device (DEV). - The name of the supplier of the device (DEV) (DEV-VEN), and / or - The model name of the device (DEV) (DEV-MOD).

3. The method according to claim 2, further comprising: - Query (QRY-DB) information related to the device (DEV) from the database (DB). - Receive (REC-DEV) the serial number (DEV-SNR), material number (DEV-MNR), supplier name (DEV-VEN), and / or model name (DEV-MOD) of the device (DEV) from the database (DB).

4. The method according to any one of claims 1-3, wherein, The Device Identifier dataset (DID) includes an Organization Identifier (DEV-INST), wherein the Organization Identifier (DEV-INST) identifies the organization hosting the device (DEV), and wherein the Organization Identifier (DEV-INST) is determined based on the credentials of an active user.

5. The method according to any one of claims 1-3, wherein, The Key Creation Dataset (KCD) also includes a Certificate Request Domain Name (CRDN).

6. The method according to any one of claims 1-3, wherein, The Certificate Creation Request (CCR) is a registration EST request transmitted securely.

7. The method according to any one of claims 1-3, wherein, The Certificate Creation Request (CCR) includes another pre-shared secret (CCR-OTP), wherein the method further includes: - In response to receiving the Certificate Creation Request (CCR), perform (CHK) to check whether another pre-shared secret (CCR-OTP) of the Certificate Creation Request (CCR) matches the pre-shared secret (KCD-OTP) of the Key Creation Dataset (KCD). Specifically, the step of sending the Certificate Creation Request (CCR) is performed only if a positive check is performed.

8. The method according to claim 7, wherein, The Certificate Creation Request (CCR) includes the Certificate Identifier (IDF-CERT-1), wherein performing the check further includes checking whether another pre-shared secret (CCR-OTP) of the Certificate Creation Request (CCR) is associated with the Certificate Identifier (IDF-CERT-1).

9. The method according to any one of claims 1-3, wherein, Sending the Key Creation Dataset (KCD) to the device (DEV) (SND-KCD) includes: - Automatically transmit the key to the device (DEV) via the Secure Communication Channel (SCC) to create a dataset (KCD), or - Store the Key Creation Dataset (KCD) on a portable storage medium (STR-KCD) and transmit the Key Creation Dataset (KCD) to the device (DEV) via the portable storage medium (MTRM-KCD).

10. A computer-implemented method for installing a digital certificate (CERT-1) on a device (DEV), comprising: - Received from server (SRV) (REC-KCD) is a Key Creation Dataset (KCD) containing a certificate identifier (IDF-CERT-1) and a pre-shared secret, wherein the certificate identifier (IDF-CERT-1) is a hash of a Device Identifier Dataset (DID) associated with the device (DEV), and the pre-shared secret is installed on the device during its manufacture. - Determine (DET-CCR) a Certificate Creation Request (CCR) associated with a first domain name (DN-1) based on the Key Creation Dataset (KCD), wherein the first domain name (DN-1) includes the Certificate Identifier (IDF-CERT-1), and the device is configured to initiate the creation of the digital certificate based on the Key Creation Dataset. - Send the certificate creation request (CCR) to the Certificate Authority (CA) via the server (SRV) (SND-CCR). - Receive (REC-CERT-1) the digital certificate (CERT-1), wherein the digital certificate (CERT-1) is a wildcard certificate based on the first domain name (DN-1) signed by the Certificate Authority (CA). - Install the digital certificate described in (INST-CERT-1).

11. A server (SRV) configured to provide a digital certificate (CERT-1) to a device (DEV), said server (SRV) being configured to: - Receive (REC-DID) Device Identifier Dataset (DID), which uniquely identifies the device (DEV). - The determination (DET-KCD) includes a certificate identifier (IDF-CERT-1) and a key creation dataset (KCD) with a pre-shared secret, wherein the certificate identifier (IDF-CERT-1) is a hash of the device identifier dataset (DID), the device is configured to initiate the creation of the digital certificate based on the key creation dataset, and the pre-shared secret is installed on the device during its manufacture. - Send the key to the device (DEV) to create a dataset (KCD) (SND-KCD). - Receive (REC-CCR) a certificate creation request (CCR) associated with the first domain name (DN-1) based on the key creation dataset (KCD) from the device (DEV). in, The first domain name (DN-1) includes the certificate identifier (IDF-CERT-1). - Send the Certificate Creation Request (CCR) (SND-CCR) to the Certificate Authority (CA). - Provide the digital certificate (CERT-1) to the device (DEV) (PROV-CERT-1). The digital certificate (CERT-1) is a wildcard certificate based on the first domain name (DN-1) signed by the Certificate Authority (CA).

12. A device (DEV) for installing digital certificates (CERT-1), configured to: - Received from server (SRV) (REC-KCD) is a Key Creation Dataset (KCD) containing a certificate identifier (IDF-CERT-1) and a pre-shared secret, wherein the certificate identifier (IDF-CERT-1) is a hash of a Device Identifier Dataset (DID) associated with the device (DEV), and the pre-shared secret is installed on the device during its manufacture. - Determine (DET-CCR) the certificate creation request (CCR) associated with the first domain name (DN-1) based on the key creation dataset (KCD), wherein, The first domain name (DN-1) includes the certificate identifier (IDF-CERT-1), and the device is configured to initiate the creation of the digital certificate based on the key creation dataset. - Send the certificate creation request (CCR) to the Certificate Authority (CA) via the server (SRV) (SND-CCR). - Receive (REC-CERT-1) the digital certificate (CERT-1), wherein the digital certificate (CERT-1) is a wildcard certificate based on the first domain name (DN-1) signed by the Certificate Authority (CA). - Install the digital certificate described in (INST-CERT-1).

13. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 10.

14. A computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 10.

Images