Dynamic generation of digital certificate requests

An environment such as a package-handling facility, manufacturing facility, or the like, may contain a number of client devices such as printers (e.g., label printers, or the like). While certain configuration data may be applied to the client devices from a central managing server, other configuration data is specific to each client device, and may therefore involve time-consuming manipulation of each client device.

Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

Examples disclosed herein are directed to a method in a server, the method comprising: storing, in a memory of the server, a certificate signing request (CSR) input template comprising: (i) a dynamic first field definition including an attribute name, and (ii) a second field definition including a second field value; transmitting respective CSR instructions to a plurality of client devices, each instruction based on the CSR input template; in response to transmitting the instructions, receiving, from each client device, a CSR comprising: (i) a first field value including an attribute value inserted in place of the attribute name, and (ii) the second field value; installing respective digital certificates at each of the client devices in response to receiving the CSRs.

Additional examples disclosed herein are directed to a server, comprising: a memory storing a certificate signing request (CSR) input template comprising: (i) a dynamic first field definition including an attribute name, and (ii) a second field definition including a second field value; and a processor configured to: transmit respective CSR instructions to a plurality of client devices, each instruction based on the CSR input template; in response to transmitting the instructions, receive, from each client device, a certificate signing request (CSRs) comprising: (i) a first field value including an attribute value inserted in place of the attribute name, and (ii) the second field value; install respective digital certificates at each of the client devices in response to receiving the CSRs.

Further examples disclosed herein are directed to a method in a client computing device, the method comprising: receiving, from a server, an instruction to generate a certificate signing request (CSR), the instruction containing: (i) a dynamic first field definition including an attribute name, and (ii) a second field definition including a second field value; retrieving, from a local memory of the client computing device, an attribute value corresponding to the attribute name; replacing the attribute name in the dynamic first field definition with the retrieved attribute value, to generate a first field value; generating and sending the CSR containing the first field value and the second field value; and responsive to generating and sending the CSR, receiving and storing a digital certificate in the local memory.

Still further examples disclosed herein are directed to a client computing device, comprising: a communications interface; a memory; and a processor configured to: receive, from a server, an instruction to generate a certificate signing request (CSR), the instruction containing: (i) a dynamic first field definition including an attribute name, and (ii) a second field definition including a second field value; retrieve, from the memory, an attribute value corresponding to the attribute name; replace the attribute name in the dynamic first field definition with the retrieved attribute value, to generate a first field value; generate and send the CSR containing the first field value and the second field value; and responsive to generating and sending the CSR, receive and store a digital certificate in the memory.

illustrates a systemfor installing and/or updating digital certificates in client computing devices, such as printers or other media processing devices. The systemincludes a plurality of client devices, including in the illustrated example a first printer-and a second printer-(collectively referred to as printers, and generically referred to as a printer; similar nomenclature is also used for other components herein). In the present example, the printersare label printers, configured to apply indicia (e.g. via a thermal print head, although any of a variety of other impression technologies may be employed by the printers) to labels from a supply of labels housed within the respective bodies of the printers. Processed labels may be dispensed from outlets-and-of the printers. The systemcan include a wide variety of other client devices aside from, or in addition to, the printers, and can also include a greater number of client devices than the two example printersshown. Further, the fleet of client devices in the systemcan include devices of different types, and/or having different operating attributes. For example, the printerscan handle different media widths, use different impression technologies, or the like.

Control of the printers, e.g., to provide print commands to the printers, can be effected by providing local commands via operating interfaces (e.g., buttons, touch screens, or the like) of the printers. In other examples, control of the printerscan be effected by sending commands to the printersvia a network(e.g., a suitable combination of local and wide-area networks, e.g., including a Wi-Fi network deployed within the facility housing the printers).

In addition to print command data (e.g., defining a print job for execution by a printer), configuration data may periodically be provided to, or collected from, one or more of the printers. Configuration data can include network settings, print settings (e.g., indicia intensity, and the like), and/or printer status (e.g., error codes, battery level, and the like). To deploy configuration data to the printers, and to collect configuration data from the printers, the systemincludes a fleet management serverconnected with the network. The servercan be configured to establish communication links with each printervia the networkto facilitate the exchange of configuration data. In some examples, communication links between printersand the servercan be initiated by each printer, e.g., by use of a uniform resource locator (URL) or other suitable network identifier stored at each printerthat corresponds to the server.

To secure the above-mentioned communication links with the printers, the servercan be configured to deploy digital certificates to the printers, and/or coordinate deployment of digital certificates to the printers. As will be apparent to those skilled in the art, a digital certificate installed at a printerenables the printerto establish encrypted connections with other computing devices, such as the server.

While some configuration data, such as print settings, network settings, or the like, can be deployed to a plurality of the printersfrom the server, the installation of digital certificates at the printersmay involve the use of data uniquely identifying each printer. As a result, the deployment of digital certificates at the printersmay involve separate commands to each printerfrom the server, and/or manual interaction with each printer. To mitigate the need for separate commands and manual interactions to deploy digital certificates to the printers, the serverand the printersperform functionality to implement dynamic device identification for certificate signing requests (CSRs) in the system. As discussed below, the dynamic device identification functionality implemented in the systemenables the serverto send a common instruction to generate a CSR to multiple printers, and enables those printersto generate unique CSRs based on dynamic manipulations of the common instruction.

also illustrates certain internal components of the server. The serverincludes a processor(e.g. a central processing unit (CPU), graphics processing unit (GPU), or combination thereof), interconnected with a non-transitory computer readable storage medium, such as a memory. The memoryincludes a suitable combination of volatile memory (e.g. Random Access Memory or RAM) and non-volatile memory (e.g. read only memory or ROM, Electrically Erasable Programmable Read Only Memory or EEPROM, flash memory). The processorand the memoryeach comprise one or more integrated circuits. The memorystores computer readable instructions executable by the processorto perform various functionality to exchange configuration data with the printers. In particular, the memorystores a certificate management applicationexecutable by the processorto perform various actions discussed herein. The applicationcan be integrated, in some examples, with other fleet management functions performed by the server, such as updating print settings, collecting status data, and the like. The applicationcan therefore also be referred to as a printer profile manager application.

The serveralso includes a communications interfaceinterconnected with the processor. The communications interfaceincludes suitable hardware (e.g. transmitters, receivers, network interface controllers and the like) allowing the serverto communicate with other computing devices—particularly the printers.

The systemcan also include a certificate authority (CA), which may be implemented as a distinct computing device from the server. The certificate authorityis configured to generate digital certificates for use by other devices, such as the printers. Such digital certificates authenticate the identities of the printers, facilitating the establishment of secure communications links, e.g., between the printersand the server.

Turning to, certain internal components of an example printerare shown. Each printerin the systemincludes those components, although the printerscan have distinct form factors, versions of each component, and the like.

The printeras shown inincludes a processorsuch as a central processing unit (CPU) and/or graphics processing unit (GPU), application-specific integrated circuit (ASIC), or the like, communicatively coupled with a non-transitory computer-readable storage medium such as a memory, e.g., a combination of volatile and non-volatile memory elements. The memorystores a plurality of computer-readable instructions in the form of applications, including in the illustrated example a firmware applicationwhose execution by the processorconfigures the printerto perform various operations to execute print jobs, exchange configuration data with the server, and the like.

The printeralso includes a communications interface, enabling the printerto establish connections with WLANs, such as the networkshown in. The communications interfacecan therefore include any suitable combination of transceivers, antenna elements, and corresponding control hardware enabling communications with the networks.

The printeralso includes, in this example, a print headcontrollable to apply indicia to media, e.g., from a supply housed within the printer. The print headcan include a thermal print head, e.g. with an array of independently controllable thermal elements to activate pigment in the media, and/or to transfer pigment from a ribbon within the housingto the media. In other examples, the print headcan employ impression technologies other than thermal printing.

Turning to, a methodof dynamically deploying digital certificates to client devices such as the printersis illustrated. The methodis described below in conjunction with its example performance in the system. As indicated in, certain blocks of the methodare performed by the printers, while other blocks of the methodare performed by the server. In general, performance of the methodallows the serverto centrally coordinate the deployment of digital certificates unique to each of the printers.

At block, the serveris configured to store a digital certificate input template (also referred to herein simply as a template), e.g., in the memory. The template includes a set of field definitions employed by the printersto generate CSRs in order to obtain digital certificates. Each field definition includes, for example a field name and information indicating how a corresponding field value is to be obtained. As will be apparent to those skilled in the art, a CSR can contain a number of field names and corresponding values to identify the entity seeking a digital certificate.

In the present example, at least one field definition of the template stored by the serveris dynamic, in that the template does not necessarily specify a static field value corresponding to the dynamic field name. The definition for the dynamic field contains an attribute name corresponding to an attribute of the printers. Each printercan have a different attribute value corresponding to the attribute name, and to generate a CSR, each printer replaces any attribute names in the template with the corresponding attribute value. The same template can therefore be used to instruct multiple printersto generate CSRs, and the resulting CSRs generated by the printerscontain different values as a result of the dynamic replacement of the above-mentioned attribute names.

Prior to storage of the template at the server, the template can be created, e.g., by an operator of the server. The servercan be configured, for example, to present an interface (e.g., on a display connected with the server) containing a plurality of field names-,-,-, and-.illustrates an example interface, including respective field names “Client ID” (e.g., a Subject Alternative Name (SAN) field), “Organization Name”, “Address”, and “Email”. As will be apparent to those skilled in the art, the field names shown in the interfacecorrespond to values that may be included in a CSR.

The interfacealso includes an input prompt-,-,-, and-for each field name. The input prompt-, in particular, can accept static characters, and can also accept attribute names for dynamic replacement at the printers. In the present example, the input prompts-,-, and-accept static input, but in other examples, more than one field can be dynamic.

To populate the input prompts, an operator of the servercan select (e.g., place focus on) a prompt, and provide input data via any suitable input device (e.g., a keyboard or the like). The servercan be configured, for dynamic field definitions such as the field name-and prompt-, to monitor input data entered into the prompt-substantially in real-time, and to compare the input to a listof printer attributes, e.g., stored in the memory. As seen in, the listcontains four attributes, including a media access control (MAC) address, a model number, a serial number, and an operating system (OS) version. Certain attributes (e.g., MAC address and serial number) may be unique to each printer, while other attributes (e.g., model number and OS version) may be shared between printers.

When the serverdetermines that a portion of the input data in the prompt-matches one or more attribute names from the list, the servercan render an overlaycontaining the matching attribute name(s). The operator may then select one of the attribute names in the overlay to populate the attribute name in the prompt. Alternatively, the operator may continue entering input data. As will be apparent from, the prompt-can accommodate both static values (e.g., the string“Site-A”, which may be a name of the facility in which the printersare deployed) and dynamic attribute names. In the illustrated example, the string“M” matches the first character of two attribute names from the list(MAC Address and Model Number). The two matching attribute names are therefore rendered in an overlay, and may be selected to auto-complete an attribute name in the prompt-.

Turning to, the completed template is shown in the interface, with the above-mentioned static text as well as an attribute namecontained in the prompt-. Operators can be employed to distinguish attribute names from static text, such as greater-than and less-than operators as shown in. In addition, separation operators (e.g., the ampersand shown in) can be used to separate components of a field value definition, as in the prompt-. The remaining input promptsare populated with static content in the example of.

Returning to, at blockthe serveris configured to send a CSR instruction to at least a subset of the printers. For example, the servercan be configured to send the CSR instruction in response to a command received from the previously mentioned operator. The CSR instruction is an instruction to the printersto generate and send a CSR, and contains the digital certificate input template. That is, the instruction includes the field names, and the field values defined in the input prompts, as set out in connection with.

The subset of printersto which a CSR instruction is sent at blockcan be selected in various ways. For example, the servercan be configured to receive specific selections of individual printers, e.g., from an operator. In other examples, the servercan send the CSR instruction to every printerin a physical facility, department, or the like. In further examples, the servercan send the CSR instruction to each printerwith a certain feature (e.g., an OS version supporting a particular certificate implementation).

illustrates an example performance of block. In particular, the serversends a CSR instruction to both printers. Although the CSR instructions are addressed to distinct printers, the contentof each CSR instruction is identical. The use of dynamic field definitions enables each printerto generate a distinct CSR (i.e., having different content that the CSRs generated by other printers).

At block, each printeris configured to receive the CSR instruction, e.g., via the network. At block, each printerthat received the CSR instruction is configured to identify any attribute names in the CSR instruction. When an attribute name is identified, such as the attribute name <MAC> shown in, the printeris configured to retrieve, from the memory, the corresponding attribute value. Identifying attribute names in the CSR instruction can include inspecting the CSR instruction for the above-mentioned operators, such as greater-than or less-than operators. The CSR instruction can include a plurality of attribute names, which can be retrieved and concatenated to form a field value.

At block, having identified attribute names and retrieved corresponding attribute values from local memoryat block, the printeris configured to replace the attribute name in the relevant field name definition of the CSR instruction with the corresponding attribute value retrieved at block.

At block, the printeris then configured to generate and send a CSR containing a field value in place of the dynamic field value definition from the CSR instruction. The CSR also contains field values explicitly defined in the CSR instruction (e.g., the static values in the prompts-,-, and-. Turning to, for example, the printers-and-are shown transmitting respective CSRs-and-to the server. The CSRsboth contain the same values for the fields “organization name”, “address”, and “email”, as well as the same static value “Site-A” in the client identifier field. However, the client identifier fields in the CSRsuniquely identify the respective printers, as the attribute name <MAC> has been replaced with a corresponding MAC address of each printer. In other words, by sending a common set of CSR instruction contentto more than one printer, the servercauses the printersto generate distinct CSRs, which in turn enable the generation of distinct digital certificates for each printer.

As will be apparent, some or all of the contents of the CSRscan be encrypted, e.g., with respective private encryption keys stored at the printers. Upon receipt of the CSRsat block, the servercan be configured to obtain and install digital certificates at the printers, at block. Obtaining digital certificates can include forwarding the CSRsto the CA, and receiving a distinct certificate for each printerfrom the CAin response. The certificates can then be transmitted to the printersfor storage in the memory, at block. In other examples, the printerscan transmit the CSRsdirectly to the CA, in which case blocksandcan be omitted. In such examples, the printersproceed directly from blockto block, receiving the corresponding certificates from the CAand storing in the memory.

In other examples, rather than transmitting a CSR instruction to each printercontaining the input template, the servercan be configured to obtain attribute values for each printer, and generate distinct CSR instructions for each printer. That is, the replacement of attribute names with attribute values in the CSR template can be performed by the server, rather than by the printers.

illustrates a methodof dynamically deploying digital certificates to client devices such as the printers, according to such examples. In the illustrated example, the serveris configured to store the CSR input template at block, as discussed above in connection with block. At block, the serveris configured to request the attribute values indicated in the CSR input template from the printers. That is, instead of sending the CSR input template to the printers, the serveris configured to identify any dynamic field definitions in the CSR input template, and to request the corresponding attribute values from each printer.

At block, the printer(e.g., any printerreceiving a request generated by the server at block) receives the request and retrieves the relevant attribute values, as described above in connection with block. At block, the printerreturns the retrieved attribute values to the server.

At block, the serveris configured to generate client device-specific (e.g., printer-specific, in this example) CSR instructions in which the attribute names in dynamic field definitions with the retrieved attribute values received from printers. The replacement of attribute names with attribute values is otherwise as discussed above in connection with block.

At block, the serveris configured to send the above-mentioned client device-specific CSR instruction to the printer(e.g., multiple distinct client device-specific CSR instructions to respective printers). The CSR instruction(s) sent at blockinclude static attribute values in place of the dynamic attribute names of the CSR input template.

At block, the printeris configured to receive the CSR instruction. At blockthe printeris configured to generate and send a CSR based on the instruction received at block. As will be apparent, the printerneed not retrieve attribute values and insert those values into the CSR instruction in this example, as such insertion was already performed by the server.

At block, the serveris configured to receive the CSR, as described above in connection with block. At block, the serveris configured to obtain and install a digital certificate using the CSR, as described above in connection with block. At block, the printeris configured to receive and store the digital certificate, as discussed above in connection with block.

In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings.

The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.

Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

Certain expressions may be employed herein to list combinations of elements. Examples of such expressions include: “at least one of A, B, and C”; “one or more of A, B, and C”; “at least one of A, B, or C”; “one or more of A, B, or C”. Unless expressly indicated otherwise, the above expressions encompass any combination of A and/or B and/or C.

It will be appreciated that some embodiments may be comprised of one or more specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.

Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.