Efficient, high-volume certificate chain validation

Abstract

Techniques are disclosed for a certificate chain validation framework in which a validation service may validate a leaf certificate on behalf of an application service without traversing the rest of the certificate chain. The validation service maintains a database of validation information provided by a certificate authority. When the validation service receives a certificate chain validation request from an application service, the validation service may validate the leaf certificate by verifying signature and certificate data associated with other certificates in the certificate chain indicated by the leaf certificate using associated validation information from the database.

Description

EFFICIENT, HIGH-VOLUME CERTIFICATE CHAIN VALIDATIONBACKGROUND{00011 Digital certificates, or public key certificates, are electronic documents binding a public key to an individual, organization, or entity, typically established through the digital signature of a certificate authority (CA). Digital certificates include information such as the certificate subject’s name, public key, issuer’s name, serial numbers, and validity dates, and are used to verify the identity of the certificate holder and enable secure communication over the internet. Digital signatures authenticate digital messages by serving as digital fingerprints that uniquely identify the senders of the messages and ensure that the content of the messages has not been altered. CAs, trusted third-party organizations, issue signed digital certificates, verify identities, and maintain and revoke signature keys and certificates as needed. Certificate validation, which ensures a digital certificate's authenticity and checks its revocation status, involves verifying the digital signature and the certificate chain back to a trusted CA, However, the process of validating certificate chains, which includes checking each certificate's digital signature and revocation status, is computationally expensive and poses significant performance challenges, especially for applications handling large volumes of validation requests.SUMMARY(0002] In general, aspects of this disclosure are directed to techniques to enable an efficient, high-volume certificate chain validation framework that validates leaf certificates associated with certificate chains without traversing the entire chains. The framework includes an end-entity computing device and a certificate authority (CA) that communicates with a validation service maintaining a database of certi ficate validation information. When an end-entity device requests certificate issuance, the CA provides a signed root certificate, and possibly signed intermediate certificates, to the end-entity device. The end-entity device generates leaf certificates using a private cryptographic key, incorporating uniquely identifying information about other certificates in the chain, such as issuer names and serial numbers. The CA supplies the validation service with essential information about the issued certificates and the corresponding end-entity devices, such as issuer and sub ject names, public cryptographic keys of the CA and or end-entity device, the digital signatures of the signed certificates, and / or copies of the signed certificates issued tothe end-entity device.(0003] When a validation request for a leaf certificate is received, the validation service extracts, from the leaf certificate, a digital signature, device authentication information (e.g., a device public key), and certificate data that is associated with the remaining certificates and uses its database to validate the leaf certificate based on verifying that the end-entity device that generated the leaf certificate is associated with the remaining certificates of the chain indicated by the leaf certificate, verifying that the chain of digital signatures associated with the certificate chain is valid, and determining the validity and revocation status of each certificate in the chain. This approach enables the validation service to validate the leaf certificate based on information included in the leaf certificate and the database of the validation service, eliminating the need to traversing the entire certificate chain to ascertain the validity of the leaf certificate, thereby significantly reducing the computational burden and enhancing performance for high-volume certificate validation scenarios.(0004] In some aspects, the techniques described herein relate to a method comprising: receiving, from an application service associated with a user device, a certificate validation, request to validate a leaf certificate of a certificate chain witho ut traversing the certificate chain, wherein the certificate chain was generated by the user device and includes two or more linked certificates including at least the leaf certificate and a root certificate, and wherein the leaf certificate includes device authentication information of the user device: retrieving, from a data repository and using the device authentication information from the leaf certificate, validation information for the one or more other linked certificates in the certificate chain other than the leaf certificate, wherein the validation information for the one or more other linked certificates is stored in association with the device authentication information in the data, repository; determining, based on the validation information lor the one or more other linked certificates and without traversing the certificate chain, whether the leaf certificate is valid; and responsive to determining that the leaf certificate is valid: transmitting, to the application service, an indication that the leaf certificate is valid.

[0005] In some aspects, the techniques described herein relate to a system for validating certificate chains, the system comprising: a memory; and a hardware processor that is configured to: receive, from an application service associated with a user device, a certificate validation request to validate a leaf certificate of a certificate chain without traversing the certificate chain,7wherein the certificate chain was generated by the user device and includes two or more linked certificates including at least the leaf certificate and a root certificate, and wherein the leaf certificate includes device authentication information of the user device; retrieve, from a data repository and using the device authentication information from the leaf certificate, validation information for the one or more other linked certificates in the certificate chain other than the leaf certificate, wherein the validation information for the one or more other linked certificates is stored in association with the device authentication information in the data reposi tory; determine, based on the validation information for the one or more other linked certificates and without traversing the certificate chain, whether the leaf certificate is valid; and responsive to determining that the leaf certificate is valid: transmit to foe application, service, an indication that the leaf certificate is valid.|0006| In some aspects, the techniques described herein relate to a non-transitory computer- readable medium containing computer executable instructions and a processor that executes the instructions to: receive, from an application sen ice associated with a user device, a certificate validation request to validate a leaf certificate of a certificate chain without traversing foe certificate chain, wherein the certificate chain was generated by the user device and includes two or more linked certificates including at least foe leaf certificate and a root certificate, and wherein the leaf certificate includes device authentication information of the user device; retrieve, from a data repository and using the device authentication information from the leaf certificate, validation information for the one or more other linked certificates in the certificate chain other than the leaf certificate, wherein the val idation information for the one or more other linked certificates is stored in association with the device authentication information in the data repository; determine, based on the validation information lor the one or more other linked certificates and without traversing the certificate chain, whether the leaf certificate is valid; and responsive to determining that the leaf certificate is valid: transmit, to the application service, an indication that the leaf certificate is valid.|0007] The details of one or more examples are set forth in foe accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from foe description and drawings, and from the claims.BRI EF DESCRIPTION OF DRAWINGS|0008] FIG. I is a conceptual diagram illustrating an example leaf certificate validation framework, in accordance with one or more aspects of the present disclosure.|0009| FIG. 2 is a block diagram illustrating an example computing device that is configured to generate a certi ficate chain including a leaf certificate that indicates information about other certificates) in the associated certificate chain, in accordance with aspects of this disclosure. 10010] FIG. 3 is a block diagram illustrating an example computing system that is configured to authenticate a computing device and validate a leaf certificate of a certificate chain based on validating the leaf certificate without traversing the certificate chain, in accordance with aspects of this disclosure.|0011] FIG. 4 is a flowchart, illustrating an example of leaf certificate chain validation in accordance with techniques of this disclosure.DETAILED DESCRIPTION|0012] FIG. 1 is a conceptual diagram illustrating an example leaf certificate validation framework, in accordance with one or more aspects of the presen t disclosure. The framework of FIG. I includes computing device 100, certificate authority 110 (e.g., “certificate auth 110”), validation service 120, database 130, third-party service 140, and network 150. Computing device 100 refers to the device that requires certificate validation and stores the digital certificates to be validated. For example, computing device 100 may need to authenticate a device or user account identity to establish a secure connection with third-party service 140 by providing a certificate chain to third-party service 140. Certificate authority 110 is a trusted entity responsible for issuing digital certificates. Validation service 120 handles the certificate chain validation process. Validation service 120 performs multiple functions responsive to receiving certificate^') and certificate chain validation requests from third-party service 140. Validation service 120 validates the leaf certificate of a certificate chain without traversing the rest of the certificate chain by extracting certificate data identifying the remaining certificates of the chain from the leaf certificate in order io retrieve validation and revocation information associated with other certificates in the chain, and then using the retrieved validation arid revocation information associated wi th the rest of the certificate chain to val idate the leaf certificate, without traversing the rest of the certificate chain. Validation service 120 then provides third-party service 140 with information indicating the validity of the leaf certificate.thus enabling third-party service 140 to verify the identity of computing device 100 and establish a secure connection over network 150 without needing to check validity and perform revocation status checks for each certificate in the chain itself. Third-party service 140 may be any external service that requires proof of device authenticity. For example, third-party service 140 may include an application service associated with a user device (e.g., computing device 100). Third- party service 140 may request a leaf certificate and / or a certificate chain from computing device 100 and may provide at least a portion of the certificate chain that inc ludes a leaf certificate to validation service 120 for validation and revocation determinations, as described in more detail herein,|00I3] Network 150 represents any public or private communications network, for instance, cellular, Wi-Fi, and / or other types of networks, for transmitting data between computing systems, servers, and computing devices. Computing device 100, certificate authority 110, validation service 120, database 130, and / or third-party service 140 may exchange data, via network 150, with one another to provide secure access to third-party service 140 via certificate chain validation when computing device 100 is connected to network 150. Network 150 may include one or more network hubs, network switches, network routers, or any other network equipment, which are operatively inter-coupled thereby providing for the exchange of information between computing device 100, certificate authority 110, validation service 120, database 130, and / or third-party service 140. Computing device 100, certificate authority 110, validation service 120, database 130, and / or third-party service 140 may transmit and receive data across network 150 using any suitable communication techniques. Computing device 100, certificate authority 110, validation sendee 120, database 130, and / or third-party sendee 140 may each be operatively coupled to network 150 using respective network links. The links coupling computing device 100, certificate authority 110, validation service 120, database 130, and / or third-party-' service 140 to network 150 may be Ethernet or other types of network connections and such connections may be wireless and / or wired connections.|0014] C Certificate authority 1 10 is an entity responsible for issuing and managing digital certificates within a Public Key Infrastructure (PKI) framework. Digital certificates, also known as public key certificates, are electronic documents that bind a public key to an individual, organization, or other entity. The binding is typically established through the digital signature of a certificate authority (e.g., certificate authority 1 10). A digital certificate may contain variouskinds of information about the certificate subject, issuer (e.g., certificate authority 110), and the certificate itself For example, a digital certificate may indicate who the certificate subject is (e.g., a device type or other anonymous identifier associated with computing device 100) or other identifying information, the certificate subject's public key, the issuer’s name (e.g., the name of certificate authority 110) and / or other identifying information, certificate serial numbers, and validity information about the digital certificate such as dates before and after which the digital certificate is invalid. Digital certificates are used to verify the identity of the certificate holder and enable secure communication and transactions over the internet. A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. The digital signature may be created using one or more signature creation schemes known in the art (e.g., Rivest-Shainir-Adleman or “RSA”, Elliptic Curve Digital Signature Algorithm or “ECDSA”, etc.) by applying a cryptographic hash function to the message or document (e.g., the information included in a digital certificate), and then generating the di gital signature using the resulting hash value and the signer's private key. The validity of a digital signature may be verified using any corresponding signature verification, scheme known in. the art (e.g., RSA, ECDSA, etc.) by performing computations using the digital signature with the signer's public key and a computed hash value of the information included in the associated certificate. Digital signatures provide strong evidence that the message or document originated from the claimed sender and has not been altered in transit. Certificate authority I 10 is a trusted organizations that issues digi tal certificates. Certificate authority 1 10 is responsible for verifying the identity of the certificate subject, providing information about issued certificates and public keys to validation service 120, and revoking certificates when necessary. When a certificate is issued, certificate authority 1 10 digitally signs the certificate with its own private key, creating a. chain of trust.Such a chain of trust allows relying parties to verify the authenticity of a certificate by tracing the leaf certificate back to the trusted certificate authority 1 10.|0015| Certificate authority 110 validates the identity of entities (e.g., computing device 100 or a user account associated with computing device 100) requesting certificates to ensure only authentic identities are issued certificates. Certificate authority 1 10 may validate the identity of devices like computing device 100 using any authentication process known in the art. For example, certificate authority 110 may authenticate the identity of computing device 100 based on receiving a copy of the public key of computing device 100 and a message signed with thecorresponding private key of computing device 100. Computing device 100 may provide a message signed with a private key and a copy of a corresponding public key with the request for signed certrficate(s), or in response to a request receive from certificate authority 110 in response to the request for signed certificates). Certificate authority 110 considers a device (e.g., computing device 100) to be authenticated when certificate authority 110 determines that the same device provided the public key, signed the message with a corresponding private key, and issued the request for signed certificate(s). Additionally or alternatively, any authentication process kno wn in the art may be used by certificate authority 1 10 to authenticate computing device 100 so long as computing device 100 sends to certificate authority 110 a copy of its public key or another instance of device authentication information that validation service 120 will later be able to use to look up associated certificate data and validate a signature across the leaf certificate. In response to authenticating computing device 100, certificate authority 1 10 may then generate and issue signed digital certificates to computing device 100 responsive to the certificate signature request,10016] Certificate authority 1 10 includes communication components) (e.g., “comm, comp(s)”) 111 for communicating with computing devices and validation services, an authentication module (e.g,, “auth. module”) 1 IS for authenticating devices requesting certificates, and cryptography module (e.g., “crypt, module”) 119 for generating encryption / decryption keys and generating / si going certificates. Although various modules and / or components of certificate authority 1 10 may perform operations described herein using software, hardware, firmware, or a mixture of hardware, software, and firmware residing in and / or executing at certificate authority 110, Certificate authority 110 may further include multiple processors or multiple devices, as virtual machines executing on underlying hardware, as one or more services of a computing platform, and / or as one or more executable programs at an application layer of a computing platform of certificate authority 110.|0017] Communication component(s) 111 may include any combination of input and / or output components included in certificate authority 110 and / or included in any other devices that are communicatively coupled to certificate authority 110. Communication component(s) 111 allow certificate authority 110 to communicate with external devices via one or more wired / wireless / mobile networks, such as network 150. Communication components) 111 may include a network interface, such as an Ethernet card, an optical transceiver, a radio frequencytransceiver, or any other type of device that may send and receive information. Examples of communication components) 111 may include a network interface card(e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that may send and / or receive information. Other examples of communication component^) 111 may include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers. Certificate authority 1 10 may control communication components) 111 to communicate with one or more of the other devices or services described herein based on instructions associated with authentication module 1 18, cryptography module 119, and / or any other software elements of certificate authority 110. For example, certificate authority 110 may control communication components) I 1 I to receive certificate requests from computing device 100, to provide public-private key paifis) and / or signed certificates to computing device 100, and / or to send data that identifies computing device 100 and its associated certificates generated by certificate authority HO to validation service 120.Before issuing a certificate, authentication module 118 of certificate authority 110 authenticates the identity computing device 100 and / or the user account associated with computing device 100. The authentication process may be performed using any methods known in the art, for example, facial recognition, voice authentication, password or passphrase authentication, biometric authentication, two-factor authentication, location-based authentication, digital signature authentication, etc. In some examples, a user may not have a user account to be used for authentication. In such examples, the authentication process may be included in the process for enabling the user to create a new user account 10019] To issue a certificate, cryptography module 1 19 of certificate authority 110 generates a certificate containing the requesting entity’s authenticated identity details (e.g., the certificate subject). Certificate authority 110 digitally signs each certificate that certificate authority 110 issues with its own private key(s) to confirm the certificate's authenticity and integrity. After generating the signed certificates, certificate authority 1 10 may provide the signed certificates to computing device 100. Certificates generated by certificate authority 1 10 may include data indicating associated issuers, certificate subjects, certificate serial numbers, issuer signatures, validity dates / periods, issuer public keys aad / or subject public keys.J0020] In the certificate validation framework of FIG. 1, certificate authority 110 provides validation service 120 with information to assist validation service 120 in later validating leafcertificates that are generated by computing device 100 based on the issued certificates received from certificate authority 1 10. Certificate authority 110 may provide validation service 120 with any sort of information that may be used by validation service 120 to determine validity and revocation status of certificates later received from computing device 100 (or other devices that received certificates from certificate authority). For example, after generating the signed certificates requested by computing device 100, certificate authority 110 may provide validation service 120 with a device authentication information of computing device 100 (e.g., the device public key or another anonymous identifier computing device 100) and certificate information associated with issued certificates (e.g., certificate serial numbers, certificate subjects, validity periods, issuer names, CA public keys, etc.). The data provided by certificate authority 1 10 may be a minimal amount of information required to enable validation service 120 to validate leaf certificates without needing to traverse the certificate chain. In some implementations, the data provided by certificate authority to validation service 120 may include copies of the issued signed certificates. Certificate authority 1 10 may further provide validation service 120 with updates to the certificate and / or cryptographic key data. For example, certificate authority 1 10 may provide lists that indicate revoked certificates by serial number, public key, and / or another identifier of the certificate, device, or user account. As another example, certificate authority 110 may provide indications of revoked public keys associated with already issued certificates. Validation service 120 may store and maintain data provided by certificate authority 110 within database 130, which may include any local or remote data storage structure known in the art that is accessible to validation service 120.|002ii Validation service 120 may be a remote computing system (cloud-based and / or server- based) that assists third-party service 140 in a uthenticating leaf certificates and checking for revocation of associated certificates. Cloud based computing generally refers to networked computer architectures where application execution, service provision, and data storage may be divided, to some extent, between clients and cloud computing devices. The “cloud” may refer to a service or a group of services accessible over a network (e.g., network 150) by clients, server devices, and cloud computing systems, for example. Thus, one or more of the described functions of va l id ation service 120 may be divided into additional functional or physical components, or combined into fewer functional or physical components. In some further examples, additional functional and / or physical components may be added io the examplesshown in FIG. 1. Delivery of cloud computing based services may invol ve multiple cloud components communicating with each other over application programming interfaces, such as web services and multi-tier architectures, for example.{0022] Certificate validation is the process of verifying that a digital certificate is genuine and has not been revoked. Certificate validation typically involves checking the certificate's digital signature, verifying the chain of digital signatures associated with the certificate chain back to a trusted CA (e.g., certificate authority 110), and checking certificates’ revocation statuses. Certificate revocation may occur for various reasons, such as the certificate subject's private key being compromised, or the subject no longer being authorized to use the certificate.{0023] Digital cert ificates are typically issued as part of a hierarchical trust structure known as a certificate chain or certification path. At the top of the trust hierarchy is the root certificate authority (e.g,, certificate authority 1 10), which is a trusted organization responsible for issuing and managing digital certificates. The certificate chains themselves are also organized into a hierarchical structure. At the top of the chain is the root, certificate, which is signed by certificate authority 110 (e.g,, the root CA). Certificate authority 110 (e.g,, the root CA.) may also issue subsequent certificates in the chain that are signed with one or more corresponding private keys (e.g., intermediate certificates). Computing device 100 may use a private-public key pair and certificate information extracted from the other certificates to be included in the certificate chain to generate end-entity certificates, which are known as leaf certificates. Each certificate in a certificate chain typically contains the public key of the certificate subject as well as the digital signature of the issuer (e.g,, certificate authority 110). Thus the chain of digital signatures associated with a certificate chain links the identity' and public key of the certificate subject (e.g., computing device 100) to the issuer (e.g., certificate authority 110), creating a chain of trust. |0024] Validation services typically validate a leaf certificate by tracing the leaf certificate back to a trusted root CA (e.g., certificate authority 110), thus validating the entire certificate chain. However, such a form of certificate chain validation may be computationally expensi ve, and may also introduce significant perfbnnance and scalability challenges, particularly for applications and services that need to handle large volumes of certificate chain validation requests. Parsing and validating digital certificates requires the system to decode each certificate’s fields, extract the relevant information (such as the issuer, subject, public key, and signature), and then perform ctyptographic operations to verify the digital signature. The process must be repeated for eachcertificate in the cha in, from the leaf certificate up to the root certificate. The signature validation process itself is also computationally intensive. For each certificate in the chain, validation systems typically use the public key of the issuer (e.g., certificate authority 1 10) to verify the digital signature on the certificate. Thus, the validation process invol ves performing resource- intensive cryptographic operations, such as hashing the certificate data and performing signature validation computations using the digital signature and the public key of the issuer (e.g., certificate authority 110). As the chain gets longer, the number of these signature validation operations increases, further taxing the system's processing capabilities. Additionally, the need to fetch and process certificate revocation information, either through Certificate revocation list (CRL) downloads or online certificate status protocol (OCSP) queries, may add even more latency and processing overhead to the validation process. These revocation checks require additional network requests and processing, which may further compound the performance challenges.{0025] Implementations described herein are directed toward an efficient, high-volume leaf certificate validation framework that enables validation, service 120 to provide efficient valida tion of a leaf certificate without the need to traverse the rest of the certificate chain. When computing device 100 requests that certificate authority 1 10 issues certificate(s), certificate authority 1 10 may send computing device 100 a signed root certificate (and in some cases, signed intermediate certificate's)). Thereafter, computing device 100 may generate and sign leaf certificates using a private key whose corresponding public key has been provided to certificate authority 110. Computing device 100 may generate these leaf certificates based on the other certificate^) to be included in the certificate chain to be generated. For example, computing device 100 may generate a leaf certificate to include certificate data about the other certifjcate(s) that will be included in the chain, such as the issuer name and certificate serial numbers.{0026] Certificate authority 110 may provide validation service 120 with identifying information about the certificates issued (e.g., serial numbers, issuer names, validity dates, revocation status, public keys, etc.) along with information that may be used to anonymously identify the end- entity computing device (e.g., the public key of computing device 100) to which the certificates were issued. Validation service 120 stores the minimal amount of data needed to authenticate the end-entity computing devices (e.s., computing device 100) and check the expiration and revocation status of their associated issued certificates, such as certificate serial numbers, end-entity public keys, issuer public keys, certificate or public key validity dates, and / or certificate or public key revocation information. Thereafter, when validation service 120 receives a request to validate a leaf certificate without traversing the other certificate(s) of the certificate chain, validation service 120 may use the information stored in its database to validate that the end- entity computing device (e.g., computing device 100) that generated the leaf certificate is the same end-entity computing device to which the other certificate(s) in the certificate chain were issued, to determine whether the chain of cryptographic signatures associated with the certi ficate chain is valid, and to determine whether each of the certificates of the certificate chain are expired and / or revoked. Thus, validation service 120 need only process the leaf certificate and access the certificate information stored in database 130, without the need to traverse the rest of the certificate chain, in order to determine whether the leaf certificate is valid.|0027| Validation service 120 may determine that a leaf certificate is valid based on: (a) determining that the certificates indicated by the certificate data extracted from the leaf certificate are associated with corresponding device authentication information (e.g., public key) of computing device 100 extracted from the leaf certificate in database 130, and (b) verifying that a chain of cryptographic signatures corresponding to the digital signatures of the certificate chain are valid. In some implementations, validation service 120 may also require that all certificates indicated by the certificate data extracted from the leaf certificate be unexpired and unrevoked in order to determine that the leaf certific ate is vali d. In other implemen tations, validation service 120 may determine a leaf certificate is valid despite one or more other certificates of the certificate chain being expired and / or revoked, but may still provide third-party service MO with an indication of which certificates are expired and / or revoked with the indication of validity for the leaf certificate.|0028j As depicted in FIG. 1, validation service 120 may include at least communication component(s) (“COM. compfs)”) 121, authentication module (“aiith. module”) 128, and database manager module 125 (e.g., “data man mod”) 125. Although various modules and / or components of validation service 120 may perform operations described herein using software, hardware, firmware, or a mixture of hardware, software, and firmware residing in and / or executing at validation service 120. Validation service 120 may further include multiple processors or multiple devices, as virtual machines executing on underlying hardware, as one or more services of a computing platform, and / or as one or more executable programs at anapplication layer of a computing platform of validation service 120.10029 ] Communication components) 121 may include any combination of input and / or output components included in validation service 120 and / or included in any other devices that are communicatively coupled to validation service 120. Communication component(s) 121 allow validation service 120 to communicate with external devices via one or more wiredAvireless / mobile networks, such as network 150. Communication components) 121 may include a network interlace, such as an Ethernet card, an optical transceiver, a radio frequency transcei ver, or any other type of device that may send and receive information. Examples of communication components) 121 may include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that may send and / or receive information. Other examples of communication components) 121 may include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers. Validation service 120 may control communication components) 121 to communicate with one or more of the other devices described herein based on instructions associated with authentication module 128, database manager module 125, and / or any other software elements of validation service 120. For example, validation sendee 120 may control communication component(s) 121 to receive uniquely identifying information associated with issued certificates or device identities from certificate authority' 110, to receive updated revocation information associated with issued certificates, to receive requests to validate leaf certificates and / or entire certificate chains from third-party service 140, to store and retrieve data in database 130, and to provide third-party service 140 with information relevant to validation of certificate chains.

[0030] Database manager module 125 of validation service 120 is responsible for updating and retrieving information from database 130. Database manager module 325 may update database 130 based on information concerning devices and certificates received from certificate authority 110 and may retrieve information based on determining query terms or filter values corresponding to lookup requests issued to database manager module 125 by authentication module 128. Database 130 may include any kind of database known in the art which database manager module 125 is capable of updating, managing, and retrieving information from. Moreover, although database 130 is depicted as being remote from validation service 120, it should be appreciated that database 130 could additionally or alternatively include one or moredata repositories internal to validation service 120.(0031] Database manager module 125 may receive, from certificate authority 110 (e.g., via one or more communication component^) 111 ), device authentication information that anonymously identifies computing device 100 (e.g., a public key of computing device 100 ) and certificate information associated with one or more certificates issued to computing device 100 by certificate authority 110. For example, database manager module 125 may receive indications of certificate serial numbers, certificate subjects, issuer names, validity periods, revocation statuses, and / or copies of digital signatures, along with public keys of certificate authority 1 10 and computing device 100. Database manager module 125 may store the information about the issued certificates in association with the device authentication information of computing devi ce 100 (and / or the user account of computing device 100) in database 130.(0032] Database manager module 125 may also receive and store in database 130 other information provided by certificate authority 110 used in traditional validation of certificate chains. For example, database manager module 125 may receive copies of the public keys that certificate authority 110 used to sign issued certificates (e.g., root and intermediate certificates), store the public keys of certificate authority 110 in database 130, and then retrieve one or more of the stored public keys of certificate authority 1 10 based on requests received from authentication module 128. In examples where validation service 120 receives the entire certificate chain with the validation request, and where information needed to verify the chain of digital signatures across the certi ficate chain is not extractable from a leaf certificate, is corrupted, or is otherwise invalid, validation service 120 may use traditional methods of validating leaf certificates that involve traversing the whole certificate chain to check each certificate’s si gnature .(0033] After database manager module 125 stores issued certificate and associated device information in database 130, authentication module 128 of validation service 120 may receive a request to validate a. leaf certificate of a certificate chain without traversing the rest of the certificate chain from third-party service 140 (e.g., via one or more communication component! s) 121 ). Third-party service 140 may request that validation service 120 validate a leaf certificate of a certificate chain that third-party service 140 received from computing device 100. In some implementations, authentication module 128 of validation service 120 may receive the entire certificate chain with the leaf certificate validation request. In some implementations,authentication module 128 may receive the leaf certificate but not the rest of the certificates in the certificate chain with the leaf certificate validation request.

[0034] Regardless of if the entire certificate chain or just the leaf certificate of the chain is received with the leaf certificate validation request, authentication module 128 of validation service 120 only needs to process the leaf certificate of the certificate chain in order to validate the leaf certificate and check for expiration or revocation for the other certificates in the certificate chain. Since computing device 100 generates its own leaf certificate on-device, the leaf certificate received by authentication module 128 will be signed by a private key of computing device 100. To validate the signature on the leaf certificate, authentication module 128 may extract the certificate data and the digi tal signature from the leaf certificate, compute a hash value of the certificate data included in the leaf certificate, and then perform verification computations using the hash value to verify whether the signature on the leaf certificate is valid. In some implementations, depending on which digital signature scheme is used, additional hash values and / or the public key of computing de vice 100 (extracted from the leaf certificate or retrieved from database 130) may be used to verify' whether the signature on the leaf certificate is valid. Based on the results of the verification computations, authentication module 128 may determine that the leaf certificate was generated by computing device 100 (e.g_, the same computing device to which the corresponding certificates were issued),

[0035] Authentication module 128 may further use the certificate data extracted from the leaf certificate to request information from database 130 from database manager module 125 in order to verify the validity of a chain of cryptographic signatures that corresponds to the certificate chain associated with the leaf certificate, wherein each certificate of the certifi cate chain has a corresponding digital signature in the chain of cryptographic signatures. As described elsewhere herein, computing device 100 will generate a certificate chain to include two or more linked certificates including at least a root certificate and a leaf certificate, and the leaf certificate will include certificate information that enables authentication module 128 to request that database manager module 125 retrieve from database 130 signature validation information about the one or more other linked certificates of the certificate chain other than the leaf certificate. Authentication module 128 may extract the certificate data from the leaf certificate, use the certificate data to request signature validation information about the other certificates of the certificate chain from database 130 from database manager module 125, Authentication module128 provides requests for information from database manager module 125 with the device authentication information (e.g., device public key) indicated by the leaf certificate that enables database manager module 125 to retrieve the signature validation information stored in association with the device authentication information in database 130.|0036) Authentication module 128 may consider all certificates issued by certificate authority 1 10 for which certificate information is stored in database 130 to include authentic information and verified signatures, unless other certificate data in database 130 conflicts with such a determination (e.g., based on revocation or expiration of a validity period for a particular certificate or issuer public key). Authentication module 128 may also determine the validity of the signature on the leaf certificate as described above. When authentication module 128 has determined that the digital signatures associated with the leaf certificate and with the other certificates of the certificate chain are all valid, then authentication module 128 may determine that the chain of cryptographic signatures associated with the certificate chain, which corresponds to the validated signatures of the leaf and other certificates, is valid. In some implementations, database manager module 125 may update database 130 to include expirations and re vocations of public keys corresponding to digital signatures of issued certificates. In such implementations, the public key expiration and revocation data may be included in the signature validation requested and received by authentication module 128, and authentication module 128 may further only consider a chain of cryptographic signatures to be val id when none of the digital signatures associated with the other certificates of the chain, other than the leaf certificate, are expired or revoked.{0037) Authentication module 128 may further request that database manager module 125 retrieve the certificate expiration and revocation information necessary for determining whether any of the one or more other linked certificates of the certificate chain other than the leaf certificate have expired or been revoked. For example, authentication module 128 may request that database manager module 125 retrieve certificate expiration and revocation information from database 130 such as validity periods and revocation statuses associated with the certificate serial numbers, issuer names, or any other extracted certificate data associated with the other certificate(s). As another example, authentication module 128 may request that database manager module 125 retrieve validity period and revocation information from database 130 that is stored in association with a particular certificate serial number and instance of device authenticationinformation, for example to determine whether the a particular certificate is expired or has been revoked.|0038| Authentication module 128 of validation service 120 may determine, based on the information extracted from the leaf certificate and the information associated with the certificates of the certificate chain retrieved from database 130, whether the leaf certi ficate is val id without traversing the certificate chain. For example, authentication module 128 may determine that a leaf certificate is valid based on determining: (a) the chain of cryptographic signatures across the certificate chain is valid, and (b) the device that generated the leaf certificate (e.g., computing device 100) is the same device associated with the corresponding issued certificates according to the information received from certificate authority 110 and stored in database 130. In some implementations, in order to validate the leaf certificate, authentication module 128 may further require that none of the one or more other linked certificates of the certificate chain other than the leaf certificate have expired or been revoked. In other implementations, however, authentication module 128 may still validate the leaf certificate even if one or more of the other certificates of the chain have expired or been revoked based on determining that the public key used to sign that expired or revoked certificate has not expired or been revoked, Authentication module 128 may then direct communication components) 121 to transmit data to third-party service 140 indicating the results of foe determinations. For example, authentication module 128 may generate indications of the leaf certificate being valid or invalid, and in some implementations indications of which cert ificates are expired or revoked, to send to third-party service 140,10039] Once validation service 120 transmits the results of the certificate chain validation request back to the third-party service 140 that provided the request, third-party service 140 may determine whether or not to allow computing device 100 to access certain secure resources. For example, in response to receiving an indication that a leaf certificate submitted by computing device 100 is invalid, third-party service 140 may deny computing device 100 access to a secure portion of a webpage associated with third-party service 140. In some implementations, in response to failing a validation check, computing device 100 may request updated certificates from certificate authority 110 and then use them to automatically generate a new leaf certificate and / or certificate chain associated with third-party service 140.|004O] C Computing device 100 represents an individual mobile or non-mobile computing devicethat is configured to perform several actions related to issuing certificate requests, generating certificate chains, and accessing serviced' s) provided by third-party service 140. Examples of computing device 100 include a mobile phone, a tablet computer, a laptop computer, a desktop computer, a server, a mainframe, a set-top box, a television, a wearable device (e.g., a computerized watch, computerized eyewear, computerized gloves, etc.), a home automation device or system (e.g., an intelligent thermostat or security system), a voice-interfece or countertop home assistant device, a personal digital assistants (PDA), a gaming system, a media player, an e-book reader, a mobile television platform, an automobile navigation or infotainment system, or any other type of mobile, now-mobile, wearable, and non-wearable computing device configured to access an electronic messaging sendee.|0041] C Computing device 100 may include communication component(s) 101 (“comm. comp(s)”), data repository 112, operating system (“OS”) 102, user interface component (“UIC”) 104, and one or more applications Capps’ ’) 106. OS 102 may include one or more modules such as authentication module 108 and cryptography module 109. Various modules and / or components of computing device 100 may perform operations described herein using software, hardware, firmware, or a mixture of hardware, software, and firmware residing in and / or executing at computing device 100. Computing device 100 may include multiple processors or multiple devices, as virtual machines executing on underlying hardware, as one or more services of a computing platform, and / or as one or more executable programs at an application layer of a computing platform of computing device 100.

[0042] Computi ng device 100 may use OS 102 , one or more of modules 108-109, and / or one or more applications 106 of computing device 100 to communicate with at. least certificate authority 110 and third-party service 140 using communication component(s) 101 to exchange data over network 150, which may include one or more wireless and or wired networks and protocols, including, but not limited to, GSM (Global System for Mobile communications), CDMA (Code Division Multiple Access), IEEE 802.11, Bluetooth, or via a docking station connected to a personal computer or server, to name a few examples. For example, authentication module 108 of OS 102 of computing device 100 may be configured to request signed certificates from certificate authority 110 over network 150 upon initial setup or after a factory reset to manufacturer default settings. As another example, computing device 100 may include a web browser that may be used to connect to a secure server associated with third-party service 140I Sonce third-party service 140 authenticates computing device 100 and confinns its permission to access the server has not been revoked.|0043| ( tommunication component(s) 101 may include any combination of input and / or output components included in computing device 100 and / or included in any other devices that are communicatively coupled to computing device 100. Communication components) 101 allow computing device 100 to communicate with external devices via one or more wired / wireless / mobile networks, such as network 150. Communication components) 101 may include a network interface, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that may send and receive information. Examples of communication components) 101 may include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that may send anchor receive information. Other examples of communication components) 101 may include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers. Computing device 100 may control communication component(s) 101 to communicate with one or more of the other devices or services described herein based on instructions associated with OS 102 and / or any other software elements of computing device 100. For example, computing device 100 may control communication components) 101 to receive certificates and public-private key pairs requests from certificate authority 110, to request connections to third-party' service 140 and receive requests for certificate chains from third-party service, to provide leaf certificates and / or certificate chains to requesting third-party service 140, and / or to establish connections with third- party service 140 in response to being authenticated.|0044] C tomputing device 100 may include data repository 112 in local memory on computing device 100 and / or data repository 112 may be a remote repository accessible by computing device 100 over one or more networks, such as network 150. OS 102 may manage data repository 112 by storing data in, removing data from, and modifying data stored in data repository 112. Data repository 112 may include any data stored temporarily or permanently in association with computing device 100. OS 102 may include data in data repository 112 necessary to enable computing device 100 andtor another device mentioned herein to perform certain actions. For example, when computing device 100 receives key(s) and / or certificate(s) from certificate authority 1 10, OS 102 may store the key(s) and / or certificate(s) in datarepository 1 12 for later retrieval.(0045] I JIC 104 of computing device 100 functions as an input and / or output device for computing device 100. UIC 104 may be implemented using various technologies. For instance, UIC 104 may function as an input device using presence-sensitive input screens, microphone technologies, infrared sensor technologies, or other input device technology for use in receiving user input. UIC 104 may function as output device configured to present output to a user using any one or more display devices, speaker technologies, haptic feedback technologies, or other output device technology for use in outputting information to a user. As an input device, (JIC 104 detects input (e.g., touch and non-touch input) from a user of computing device 100. Examples of user input gestures performed by a user (e.g., the user touching, pointing, and / or swiping at or near one or more locations of UIC 104 with a finger or a stylus pen). As an output device, UIC 104 presents information (e.g., audible, visual, anchor haptic information) to a user in the form of a user interface.(0046] An example of an application(s) 106 is a web browser application or a smartphone application (or “app”). Application^) 106 provide computing device 100 with various functionalities. Examples include social media functionality, web browsing capabilities, calendars, contact information, games, document processing, photo editing, document sharing, among others. Application(s) 106 may employ UIC 104 to display information at a graphical user interface (GUI), One or more application^) 106 of computing device 100 may assist computing device 100 in establishing secure connections with various services, such as third- party service 140, For example, applicationts) 106 may include a rideshare app that is associated with a user account for which payment information is stored. When computing device 100 executes the rideshare app, the rideshare app may connect to its associated server (i.e., third- party service 140) via conimunication component(s) 101 and network 150 to authenticate the user and / or computing device .100 for log-in.|0047| OS 102 of computing device 100 may provide an execution environment for one or more modules and. or applications of computing device 100, such as authentication module 108 and cryptography module 109. OS 102 may represent a multi-threaded operating system or a single- threaded operating system with which various software elements of computing device 100 may interface to access hardware components of computing device 100. OS 102 may include a kernel that facilitates access to the underlying hardware of computing device 100, where that kernelmay present a number of different interfaces (e.g., application programmer interfaces (APIs)) that modules 108-109 and / or various other software elements of computing device 100 may invoke to access the underlying hardware of compu ting device 100.{0048] Authentication module 108 of OS 102 may initiate certificate signature requests to certificate authority 110 on behalf of computing device 100 (e.g., via one or more communication component(s) 101). For example, authentication module 108 may be pre- configured to connect to certificate authority 110 and request one or more signed certificates upon initial setup of computing device 100 by a consumer, upon initial log-in to a particular user account on computing device 100, upon memory reset of computing device 100 (e.g., after a factory reset of all setings), and / or upon initial connection to a new service associated with certificate authority 110 for the first time. For example, certificate authority 110 may be associated with a developer of OS 102 of computing device 100, and authentication module 108 of OS 102 may be configured by the developer to connect to certificate authority 110 upon initial setup of computing device in order to obtain at least a signed root certificate, authenticate a public key (or other anonymous identifier of computing device 100) with certificate authority' 110, and in some examples also obtain one or more intermediate signed certificates from certificate authority 110.

[0049] Cryptography module 109 of OS 102 may generate one or more private-public key pairs, digi tal signatures, leaf certificates, and certificate chains based on certifi cate(s) recei ved from certificate authorities, such as certificate authority I 10, and based on the generated one or more private-public key pairs. In one illustrative example, computing device 100 may generate one or more cryptographic keys (e.g., public-private key pair(s)) and receive one or more certificates signed by certificate authority 110 from certificate authority 110 (e.g., via one or more communication components) 101). la such an example, OS 102 of computing device 100 may cause the keys and certificate(s) to be stored in a secure area within data repository 112 and cryptography module 109 of OS 102 may use one or more of the stored keys and certificate(s) to generate leaf certificates and certificate chains. For instance, cryptography module 109 may generate a leaf certificate that contains a unique public key generated by computing device 100 (or another instance of device authentication information for computing device 100 and / or a user account ). The leaf certificate generated may further be generated based on the received root and / or intermediate certificates to include certificate data associated with the root and / orintermediate certificates to be included in the chain (or requested by third-party service 140), as will be described in more detail herein. Cryptography module 109 may further generate a digital signature to include in the leaf certificate using the private key generated by cryptography module 109 and retrieved from data repository 112 by OS 102.|0050j In some implementations, cryptography module 109 of OS 102 may generate a leaf certificate and / or a whole certificate chain in response to a request from an application 106 associated with third-party service 140, wherein the certificate chain includes the root certificate and intermediate certificate(s) received from certificate authority 110 and the leaf certificate generated by computing device 100. Cryptography module 109 may generate the leaf certificates and their corresponding digital signatures based on data received from application^) 106 and / or third-party service 140 (e.g., a request provided by third-party service 140 for computing device 100 to generate a certificate chain including particular certificates or certificates from particular issuers).{00511 FIG. 2 is a block diagram illustrating an example computing device that is configured to generate a leaf certificate that indicates information about other certificate(s) in the associated certificate chain, in accordance with aspects of this disclosure. Computing device 200 of FIG. 2 is described below as an example of computing device 100 of FIG. I. FIG. 2 illustrates only one example of computing device 200, and many other examples of computing device 200 may be used in other instances. Computing device 200 may include a subset of the components included in FIG. 2 or may include additional components not shown in FIG. 2.|0052j As shown in the example of FIG. 2, computing device 200 includes user interface device 240 (e.g., “UID 240”), one or more processors 238, one or more communication units 246, one or more input components 222, one or more output components 244, and one or more storage components 250. Storage components 250 of computing device 200 include an operating system (“OS”) 202 and applications) 206. OS 202 includes UI module 220. authentication module 208, and cryptography module 209.|0053| Communication channels 252 may interconnect each of the components 240, 238, .246, 222, 244, and 250 for inter-component communications (physically, communicatively, and / or operatively). In some examples, communication channels 252 may include a system bus, a network connection, an inter-process conimunication data structure, or any other method for comm unicating data.(0054] One or more communication units 246 of computing device 200 may communicate with external devices via one or more wired and / or wireless networks by transmiting and / or receiving network signals on the one or more networks. Examples of communication units 246 include a network interlace card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS recei ver, or any other type of de vice that may send and / or receive information. Other examples of communication units 246 may include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers.(0055] One or more input components 222 of computing device 200 may recei ve input.Examples of input are tactile, audio, and video input. Input components 222 of computing device 200, in one example, includes a presence-sensitive input device (e.g., a touch sensitive screen, a UID), mouse, keyboard, voice responsive system, video camera, microphone or any other type of device for detecting input from a human or machine. In some examples, input components 222 may include one or more sensor components one or more location sensors (GPS components, Wi-Fi components, cellular components), one or more temperature sensors, one or more movement sensors (e.g,, accelerometers, gyros), one or more pressure sensors (e.g., barometer), one or more ambient light sensors, and one or more other sensors (e.g., microphone, camera, infrared proximity sensor, hygrometer, and the like). Other sensors may include a heart rate sensor, magnetometer, glucose sensor, hygrometer sensor, olfactory sensor, compass sensor, step counter sensor, to name a few other non-limiting examples.(0056| One or more output components 244 of computing device 100 may generate output.Examples of output are tactile, audio, and video output Output components 244 of computing device 200, in one example, includes a U1.D, sound card, video graphics adapter card, speaker, cathode ray tube (CRT) monitor, liquid crystal display (LCD), or any other type of device for generating output to a human or machine.(0057] In some examples, UID 240 of computing device 200 may include a presence-sensitive display configured to detect input (e.g., touch and non-touch input) from a user of respective computing device 200. U ID 240 may output infbnnation to a user in the form of a Ul, which may be associated with functionality provided by computing device 200. Computing device 200 may output such UIs that may be associated with computing platforms, operating systems, applications, and / or services executing at or accessible from computing device 200 (e.g., electronic message applications, chat applications, Internet browser applications, mobile ordesktop operating systems, social media applications, electronic games, menus, and other types of applications).|0058| While illustrated as an internal component of computing device 200, HID 240 may also represent an external component that shares a data path with computing device 200 for transmitting and / or receiving input and output. For instance, in one example, UID 240 represents a built-in component of computing device 200 located within and physically connected to the external packaging of computing device 200 (e.g., a screen on a mobile phone). In another example, UID 240 represents an external component of computing device 200 located outside and physically separated from the packaging or housing of computing device 200 (e.g,, a monitor, a projector, etc. that shares a wired and / or wireless data path with computing device 200).|0059| One or more processors 238 may implement functionality and / or execute instructions associated with computing device 200. Examples of processors 238 include application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configure to function as a processor, a processing unit, or a processing device.|0060| As shown in the example of FIG. 2, computing device 200 includes OS 202. OS 202 may control the operations of components of computing device 200 as well as provide an execution environment for one or more modules, such as U1 module 220, authentication module 208, and / or cryptography module 209, and one or more applications, such as applications 206. OS 202 may represent a multi-threaded operating system or a single-threaded operating system with which Ul module 220, authentication module 208, and / or cryptography module 209, and applications 206 may interface to access hardware of computing device 200. OS 202 may include a kernel that facilitates access to the underlying hardware of computing device 200, where kernel may present a number of different interfaces (e.g., application programmer interfaces (APIs) that UI module 220. authentication module 208, cryptography module 209, and applications 206 may invoke to access the underlying hardware of computing device 200.Modules 220, 208, and / or 209 may each include program instructions and / or data that are executable by computing device 200 (e.g., by one or more processors 238). For example, modules 220, 208, and / or 209 may include instructions that cause computing device 200 to perform one or more of the operations and actions described in the present disclosure.|006I| Modules 220, 208, and / or 209 may be operable by processors 238 to perform various actions, operations, or functions of computing device 200. For example, processors 238 of computing device 200 may retrieve and execute instructions stored by storage components 250 that cause processors 238 to perform the operations of modules 220, 208, and / or 209, The instructions, when executed by processors 238, may cause computing device 200 to store information within storage components 250.J0062J One or more storage components 250 within computing device 200 may store information for processing during operation of computing device 200 (e.g., computing device 200 may store data accessed by modules 220, 208, and / or 209 during execution at computing device 200). In some examples, storage component 250 is a temporary memory, meaning that a primary purpose of storage componen t 250 is not long-term storage. Storage components 250 on computing device 200 may be configured for short-term storage of information as volatile memory and therefore not retai n stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories ( SRAM), and other forms of volatile memories known in. the art, |0063| Storage components 250, in some examples, also include one or more computer-readable storage media. Storage components 250 in some examples include one or more non-transitory computer-readable storage mediums. Storage components 250 may be configured to store larger amounts of information than typically stored by volatile memory- Storage components 250 may further be configured for long-term storage of information as non-volatile memory space and retain information after power on / off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage components 250 may store program instructions and / or information (e.g., data) associated modules 220, 208, and / or 209. Storage components 250 may include a memory configured to store data or other information associated with modules 220, 208, and / or 209. |0064] OS 202 may use one or more of modules 220, 208, and / or 209 may perform operations described herein using software, hardware, firmware, or a mixture of both hardware, software, and firmware residing in and executing on computing device 200 or at one or more other remote computing devices. In some examples, modules 220, 208, and / or 209 maybe implemented as hardware, software, and / or a combination of hardware and software. Computing device 200 mayexecute modules 220, 208, and / or 209 with one or more processors. Computing device 200 may execute any of modules 220, 208, and / or 209 as or within a virtual machine executing on underlying hardware. Modules 220, 208, and / or 209 may be implemented in various ways. For example, any of modules 220, 208 , and / or 209 may be implemented as a downloadable or pre- installed application (e.g., as a part of applications 206). In another example, modules 220, 208, and / or 209 may be implemented as part of the operating system of computing device 200.

[0065] I .11 module 220 may interpret inputs detected at UID 240. Ul module 220 may relay information about the inputs detected at UID 240 to one or more associated platforms, operating systems, applications, and / or services executing at computing device 200 to cause computing device 200 to perform a function, Ul module 220 may also receive information and instructions from one or more associated platforms, operating systems, applications, and / or services executing at computing device 200 (e.g., applications 206) for generating a graphical user interface (“GUI”) for display at UID 240. Additionally, Ul module 220 may act as an intermediary between the one or more associated platforms, operating systems, applications, and / or services executing at computing device 200 and various output devices of computing device 100 (e.g., speakers, LED indicators, vibrators, etc.) to produce output (e.g., graphical, audible, tactile, etc.) with computing device 200.

[0066] In some examp les, Ul module 220 may receive an indicati on of one or more user inputs detected at UID 240 and may output information about the user inputs to modules 208 and / or 209 or any other application or component of computing device 200 for which the user inputs are intended. For example, UID 240 may detect a user input and send data about the user input to Ul module 220. Ul module 220 may perform one or more actions based on the detected input. In the example of FIG. 2, Ul module 220 may cause authentication module 208 to transmit (e.g., via one or more communication units 246) a connection request to a third-party service (e.g., third-party service 140) associated with an application 206 running on computing device 200 in response to detecting a user input at UID 240 that corresponds to a selection of an icon associated with a corresponding third-party application.

[0067] Authentication module 208 handles authentication processes of computing device 200. Upon initial setup of computing de vice 200, after a reset of device settings, or in response to a request received from a certificate authority (e.g., from certificate authority 110 via one or more communication units 246), authentication module 208 will initiate an authentication procedurewith the certificate authority by transmitting a request (e.g., via one or more conununication units 246) to be issued one or more signed certificates. Authentication module 208 may cause computing device 200 to transmit (e.g,, via one or more communication units 246) some sort of anonymously identifying device authentication information (e.g., digital signature and / or device public key), access token, and / or user account information that may be used by the certificate authority to authenticate computing device 200 (and / or a user account associated with computing device 200) to the certificate authority. Computing device 200 may provide the certificate authority with device authentication information necessary to authenticate computing device 200 (and / or the user account), and the certificate authority may use any authentication process known in the art to authenticate computing device 200 (and / or a user account). In response to being authenticated, computing device 200 will then receive (e.g., via one or more communication units 246) the issued signed certificates and will store the certificates securely in local storage within storage components 250.10068] Authentication module 208 may also participate in authentication processes with third- party services (e.g,, third-party service 140), Authentication, module 208 may cause one or more communication units 246 of computing de vice 200 to transmi t a request to establish a connection with a third-party service (e.g,, third-party service 140), For example, authentication module 208 may initiate a connection with a third-party service associated with a bank based on UI module 220 indicating that a user selected an application 206 icon associated with that bank’s third-party service. The third-party service may send a request back, to computing device 200, e.g., via communication units 246, for computing device 200 to provide a leaf certificate and / or certificate chain to authenticate its identity before allowing computing device 200 to connect to the third-party service.|0069j Authentication module 208 may interpret the request of the third-party service and then generate and transmit (e.g., via one or more communication units 246) the required authenticating materials tor authentication by the third-party service. Authentication module 208 may cause cryptography module 209 to generate the leaf certificate based on one or more of the certificates received from the certificate authority and stored locally on computing device 200, and to include a digital signature in die leaf certificate signed using a private key generated by cryptography module 209 and stored locally on computing device 200. In some implementations, authentication module 208 may further cause cryptography module 209 to generate the entirecertificate chain that includes the leaf certificate linked to the one or more other certificates indicated by the leaf certificate.

[0070] Cryptography module 209 may provide authentication module 208 with the leaf certificate and / or the entire certificate chain. Authentication module 208 will then transmit these authentication materials to the third-party service via one or more of the communication units 246. Upon authentication by the third-party service, authentication module 208 may cause one or more communication units 246 of computing device 200 to establish a network connection with the third-party service.

[0071] ( Cryptography module 209 handles processes related to cryptography on computing device 200. Cryptography module 209 may generate at least one private-public key pair for use by one or more components of computing device 200 in generating certificate and / or authentication data, as described herein. Cryptography module 209 may use the private and / or public key to generate authentication information to provide to authentication module 208 for authenticating computing device 200 with a certificate authority. Cryptography module 209 may receive certificates issued and signed by a certificate authority (e.g,, certificate authority 1 10) from authentication module 208 or another component of computing device 200 in response to a request for issued signed certificates from the certificate authority'. Cryptography module 209 may store these certificates and encryption keyfs) locally on computing device 200 in a secure area of storage components 250,

[0072] When authentication module 208 sends a request to generate a leaf certificate and / or certificate chain to cryptography module 209, the request may indicate which certificates the type of connection and / or the particular third-party service require to be validated. Cryptography module 209 will then generate the leaf certificate to include indications of the device authentication information associated with computing device 200 (e.g., corresponding to the device authentication information used by the certificate authority to authenticate computing device 200) and the certificates stored on computing device 200 that are indicated by the request received from authentication module 208. For example, cryptography module 209 may generate the leaf certificate to include the public key of computing device 200 and the certificate serial numbers and issuer names of every certificate that the request from authentication module 208 speci fies for this type of connection or particular th ird-party service. In some implementations, cryptography module 209 may additionally generate the certificate chain including the requestedcertificates linked to the leaf certificate in a certificate chain. Cryptography module 209 may also generate a digital signature with the private key of computing device 200 and include the digital signature in the leaf certificate. Cryptography module 209 may then provide the requested leaf certificate and / or entire certificate chain to authentication module 208 for authentication module 208 to assist the third-party service with validating the identity and permissions of computing device 200 (and / or an associated user account).

[0073] FIG. 3 is a block diagram illustrating an example computing system that is configured to authenticate a computing device and validate a leaf certificate of a certificate chain without traversing the certificate chain, in accordance with aspects of this disclosure. Validation service 320 of FIG. 3 is described below as an example of validation service 120 of FIG. I. FIG. 3 illustrates only one example of validation service 320, and many other examples of validation service 320 may be used in other instances. Validation sen-ice 320 may include a subset of the components included in FIG. 3 or may include additional components not shown in FIG. 3. Validation service 320 may be a remote computing system, such as a cloud-based or server- based system, or it may be a companion computing device communicatively coupled to one or more other computing devices or computing systems described herein (e.g., certificate authority HO).

[0074] As shown in the example of FIG . 3, validation service 320 includes one or more processors 338, one or more commun ication channels 352, one or more communication units 346, and one or more storage components 350. Storage components 350 of validation service 320 include authentication module 328, database manager module 325, and database 330. In some implementations, validation servicer 320 may be a server and / or a group of devices networked in a cloud computing system. Thus, in some implementations, one or more of the described components of validation service 320 may be di vided into additional functional or physical components, or combined into fewer functional or physical components. In some further examples, additional functional and / or physical components may be added to the examples shown in FIG. 3. Delivery of cloud computing based services may involve multiple cloud components communicating with each other over application programming interfaces, such as web services and multi-tier architectures, for example.

[0075] Communication channels 352 may interconnect each of the components 338, 346, and 350 for inier-component communications (physically, communicatively, and / or operatively). Insome examples, contmutiication channels 352 may include a system bus, a network connection, an inter-process communi cation data structure, or any other method for communicating data. [0076 j One or more communication units 346 of validation service 320 may communicate with external devices via one or more wired and / or wireless networks by transmiting and / or receiving network signals on the one or more networks. Examples of communication units 346 include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that may send and / or receive information. Other examples of communication units 346 may include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers.

[0077] One or more processors 338 may implement functionality and / or execute instructions associated with validation service 320. Examples of processors 338 include application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configure to function as a processor, a processing unit, or a processing device.

[0078] Modules 328 and / or 325 may be operable by processors 338 to perform various actions, operations, or functions of validation service 320, For example, processors 338 of validation service 320 may retrieve and execute instructions stored by storage components 350 that cause processors 338 to perform the operations modules 328 and / or 325. The instructions, when executed by processors 338, may cause validation service 320 to store information within storage components 350,

[0079] One or more storage components 350 within validation service 320 may store information for processing during operation of validation service 320 (e.g., validation service 320 may store data accessed by modules 328 and / or 325 during execution at validation service 320). In some examples, storage component 350 is a temporary memory, meaning that a primary purpose of storage component 350 is not long-term storage. Storage components 350 on validation service 320 may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.

[0080] Storage components 350, in some examples, also include one or more computer-readable storage media. Storage components 350 in some examples include one or more aon-iransitory computer-readable storage mediums, Storage components 350 may be configured to store largeramounts of information than typically stored by volatile memory. Storage components 350 may further be configured for long-term storage of information as non-volatile memory space and retain information after power on / off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage components 350 may store program instructions and / or information (e.g., data) associated modules 323 and / or 325. Storage components 350 may include a memory configured to store data or other information associated with modules 328 and / or 325.|'0081 | One or more of modules 328 and / or 325 may perform operations described herein using software, hardware, firmware, or a mixture of both hardware, software, and firmware res iding in and executing on val idation service 320 or at one or more other remote computing devices. In some examples, modules 328 and / or 325 may be implemented as hardware, software, and / or a combination of hardware and software. Validation service 320 may execute modules 328 and / or 325 with one or more processors. Validation service 320 may execute any of modules 328 and / or 325 as or within a virtual machine executing on underlying hardware. Modules 328 and / or 325 may be implemented in various ways. For example, any of modules 328 and / or 325 may be implemented as part of the operating system of validation service 320.|0082] Database manager module 325 manages database 330 by storing, deleting, modifying, searching, extracting, and updating certificate validation information associated with certificates issued by a certificate authority (e.g., certificate authority 110) to one or more computing devices (e.g., computing devices 100 and / or 200), Database 330 may be any kind of data storage system that database manager module 325 of validation service 320 may use to manage the database operations described herein. Although database 330 is depicted as an internal component of validation service 320, database 330 may also represent an external component accessible to database manager module 325. For example, database 330 may exist as a remote file storage server that database manager module 325 is able to update and query. Database manager module 325 may receive instructions from one or more of modules 328 and / or 327 that indicate which database management operations database manager module 325 should perform. For example, authentication module 328 may provide information that should be stored in database 330 and / or requests for information previously stored in database 330. Database manager module 325 may then determine which database entries to generate or update, which query terms to use, etc. andperform the requested operations using the information included in the database 330. Database manager module 325 may store and retrieve various uniquely identifying information about certificates and the computing devices to which they were issued using database 330, as described herein. For example, database manager module 325 may receive, store, and retrieve information associating particular certificates with particular computing devices and particular validation information (e.g., validity periods, revocation statuses, etc.) from at least one certificate authority (e.g., certificate authority 110).|0O83| Authentication module 328 handles authentication processes of validation service 3:20, Authentication module 328 provides authentication services for third-party services (e.g., third- party service 140) and a certificate authority (e.g,, certificate authority 1 10), as described herein. For example, upon initial setup of a computing device (e.g., computing device 100), after a reset of device settings, or in response to a request issued by a certificate authority (e.g,, certificate authority 110), the certificate authority may authenticate the identity of the computing device (or a user account of the computing device) using any authentication process known in the art, and upon authentication the certificate authority may issue the computing device one or more certificates as well as encryption keys (e.g., public-private key pair).|0084] Authentication module 328 of the val idation service 320 may receive, from the certificate authority (e.g., via one or more communication units 346) and / or from database manager module 325, device authentication information and certificate data that identifies to which computing devices particular certificates have been issued. The certificate information received from the certificate authority and / or database manager module 325 may include identifying certificate data, such as certificate subject names, issuer names, certificate serial numbers, digital signatures, and / or issuer public keys, as well as certificate and signature expiration and revocation information including validity periods (e.g., periods outside of which the corresponding certificate, signature, and / or issuer public key is expired) and revocation statuses of certificates, signatures, and / or issuer public keys. The de vice authentication information received from the certificate authority may include device identifiers like public keys, indications of device types, anonymous user account identifiers, and / or any other instance of information which may be used by database manager module 325 to anonymously identify, in database 330, which computing device is associated with each certificate. Authentication module 328 may further receive updates to this information later from the certificate authority, for example thecertificate authority may provide an updated revocation status if a certificate us revoked or updated validity period data if a certificate has been renewed. Authentication module 328 forwards the received information including the device authentication data and the identifying certificate data, as well as the validation and revocation data — to the database manager module 325. Database manager module 325 subsequently updates the database 330 with the new information, ensuring that the database accurately reflects the current status of all certificates and associated devices.Authentication module 325 may receive requests from third-party services (e.g., third- party service 140) to authenticate a computing device and validate a leaf certificate that a computing device generated (e.g., via one or more of the communication. units 346), as described elsewhere herein. A uthentication module 328 will recei ve at least the leaf certificate generated by the computing device being authenticated (e.g., computing device 100), and in some implementations may receive the entire certificate chain, from the requesting third-party services along with the leaf certificate validation requests. In response to recei ving a leaf certificate validation request from a third-party service, authentication module 328 may extract device authentication information, such as a public key, and certificate data, such as issuer names and / or serial numbers, from the leaf certificate. A uthentication module 328 may then send a request for validation information from database 330 to database manager module 325 based on the device authentication information and identifying certificate data extracted from the leaf certificate. Based on the validation information received from database manager module 325 responsive to the request, authentication module 328 may determine whether the leaf certificate is valid without traversing the certificate chain by determining whether (a) a chain of cryptographic signatures corresponding to the chain of digital signatures of the certificate chain is valid, and (b ) the other certificate(s) of the chain indicated by the ex tracted certificate data have been issued and are associated with the same computing device that generated the leaf certificate. |0086| Authentication module 328 may determine that a chain of cryptographic signatures corresponding to the chain of digital signatures of the certificate chain is valid based on validating the signature across the leaf and determining that none of the signatures and / or public keys associated with the other certificates of the chain have expired or been revoked. Authentication module 328 may extract a digital signature and a public key from a received leaf certificate. The digital signature may have been signed by the computing device that generatedthe leaf certificate using the pri vate key generated by the computing device and provided to the certificate authority with the request for signed certificates and / or during the authentication process. Authentication module 328 may validate the signature across the leaf by performing one or more signature validation techniques known in the art based on the digital signature, the public key, and a hash of the certificate data extracted from foe leaf certificate. Authentication module 328 may determine foe validity of the remaining signatures of the chain of cryptographic signatures associated with the certificate chain based on the validation information retrieved from database 330 by database manager module 325. For example, authentication module 328 may determine that the chain of cryptographic signatures is valid if the signature across the leaf certificate is determined to be valid and if the validation information does not indicate any expirations or revocations associated with corresponding signatures or public keys. As another example, authentication module 328 may determine that the chain of cryptographic signatures is invalid if the signature across the leaf certificate is determined to be invalid and / or if the validation information indicates any expirations or revocations associated with corresponding signatures or public keys.|0087| Authentica tion module 328 may determine that the other certificate / s) of the chain indicated by the extracted certificate data have been issued and are associated with the same computin g device that generated the leaf certificate based on determining that the certificate data extracted from the leaf certificate corresponds to certificate data included in the validation information received from database manager module 325 that was stored in database 330 in association with a public key that is associated, within database 330, with device authentication information corresponding to the device authentication information extracted from the leaf certificate. Thus, for example, if authentication module 328 determines, based on processing the leaf certificate and foe validation mfonnation received from database manage module 325, that the leaf certificate indicates certificate subjects and issuer names that are associated, within database 330, with the same public key included in the leaf certificate, then authentication module 328 may determine that the certificates indicated by the certificate data extracted from the leaf certifica te were issued to the same computing de vice that generated the leaf certi fica te to include the corresponding certificate data.|0088j Authentication module 328 may further receive expiration and revocation information associated with certificates, signatures, and / or public keys associated with the other certificatesof the certificate chain other than the leaf certificate from database manager module 325 in response to sending validation information requests. Authentication module 328 may use the expiration and revocation information associated with the other certificates of the chain and retrieved from database 330 by database manager module 325 for validating the leaf certificate without traversing the chain. For example, authentication module 328 may determine whether a leaf certificate is valid based on comparing a time at which the leaf certificate was received or generated outside to the validity periods indicated for the other certificates in the chain, and may determine that a leaf certificate is invalid if recei ved / generated outside of at least one of the validity periods. As another example, authentication module 328 may determine that a leaf certificate is valid based on determining that none of the other certificates of the certificate chain (and / or their corresponding signatures and / or public keys) have expired or been revoked, and authentication module 328 may determine that a leaf certificate is invalid based on determining that at least one of the other certificates of the certificate chain (and / or their corresponding signatures and / or public keys) has expired or been revoked. In some implementations, authentication module 328 may determine that a certificate of the chain has expired or been revoked, but may nonethe less determine that the leaf certificate is valid based on determining that the cryptographic signature and / or public key associated with the certificate is unexpired and / or unrevoked. In such implementations, authentication module 328 may determine certificate expirations and / or revocations, and provide indications of any certificate expirations and / or revocations to the third-party sendee requesting validation, but may not take certificate expirations and / or revocations into account when validating the leaf certificate,

[0089] Upon determining the validity-' of the leaf certificate, authentication module 328 may cause one or more of the communication compoiient(s) 321 of validation service 320 to transmit the validation decision back to die diird-party service requesting die certificate chain validation. Once validation service 320 transmits the results of the certificate chain validation request back to the third-party service that provided the request, the requesting third-party service may determine whether to allow the corresponding computing device that provided that certificate chain to access certain secure resources. For example, in response to receiving an indication that a leaf certificate submitted by a particular computing device is valid, a third-party service may allow that computing device access to a secure portion of a webpage associated with that third- party service.|0090| FIG. 4 is a flowchart illustrating an example of leaf certificate validation in accordance with techniques of this disclosure. Although primarily described with respect to computing device 100, certificate authority 110, validation service 120, database 130, third-party service 140, and network 150 of FIG. 1 , it should be understood that the techniques illustrated by FIG. 4 may be applied by any of the corresponding computing devices disclosed herein, including computing device 200 and validation service 320.I'OOSHJ Validation service 120 recei ves a leaf certificate validation request from an application service (e.g., third-party service 140) associated with an application of computing device 100 to validate a leaf certificate of a certificate chain generated by computing device 100 (402). Third- party service 140 may be an application sendee associated with an application 106 installed on computing device 100 that requires secure authentication before allowing computing device 100 access to certain resources of third-party service 140. In order to authenticate the user, third-party service 140 may provide a request to computing device 100 for a certificate chain from computing device 100. As described elsewhere herein, computing device 100 may generate a leaf certificate based on one or more other certificates previously received from certificate authority 110 that are to be linked in the certificate chain. The leaf certificate generated by computing device 100 based on the other certificate(s) to be included in the certificate chain will include indications of identifying certificate data (e.g., issuer and subject names, serial numbers, etc.) associated with the certificates and device authentication information (e.g., a digital signature and / or public key) of computing device 100 (or an associated account). For example, the leaf certificate may indica te certificate serial numbers of other certificate(s) to be included in the chain and the public key of computing device 100. Computing device 100 may generate just the leaf certificate or the entire certificate chain, which includes two or more linked certificates including all of the certificates linked in the chain (e.g., at least the leaf certificate and the root certificate, but also including any intermediate certificates that may be included in the certificate chain). As described elsewhere herein, computing device 100 may generate and transmit the leaf certificate and / or the entire certificate chain to third-party service 140 in response to the request, for a certificate chain provided by third-party service 140. Third-party service 140 will issue a request to validation service 120 to validate the leaf certificate and provide the leaf certificate or the entire certificate chain recei ved from computing device 100.|0092j Validation service 120 retrieves, from database 130 and using the device authentication information, validation information for the other certificates of the certificate chain other than the leaf certificate (404), Validation service 120 may extract certificate data from the leaf certificate that indicates information associated with the other certificates (hat may be used to retrieve validation information from database 130. Validation service 120 may then retrieve the validation information corresponding to the device authentication information and the certificate data extracted from the leaf certificate lor the other certificates of the chain from database 130. 10093] Validation service 120 determines, based on the retrieved validation information and without traversing the certificate chain, whether the leaf certificate is valid (406). For example, validation service 120 may determine, based on processing the leaf certificate and retrieving the validation information, and without traversing the chain, whether the leaf certificate is valid based on determining whether : (a) the chain of cryptographic signatures corresponding to the signatures of the certificate chain is valid, and (b) the computing device that generated the leaf certificate (e.g„ computing device 100) is the same computing device associated with the corresponding issued certificates in the information received from certificate authority 110 and stored in database 130, As described herein, determining whether the chain of cryptographic signatures is valid includes determining whether the signature across the leaf certificate is valid and determining whether the validation information indicates expirations or revocations of any of the other signatures and / or public keys of the certificate chain corresponding to the remaining certificates of the certificate chain have expired or been revoked. If validation service 120 determines that the signature associated with the leaf certificate is valid, and tha t none of the other signatures and / or public keys associated with the remaining certificates of the chain have expired and / or been revoked, then validation service 120 may determine that the chain of cryptographic signatures corresponding to the certificate chain is valid. As described herein, determining whether the same computing device that generated the leaf certificate was issued the remaining certificates in the certificate chain includes determining whether the certificate data and device authentication information extracted from the certificate is associated with corresponding certificate data and device authentication information in database 130. In some implementations, in order to validate the leaf certificate, valida tion service 120 may further require that the validation informa tion indicates that none of the one or more other linked certificates of the certificate chain other than the leaf certificate have expired or been revoked. Inother implementations, however, validation service 120 may still validate the leaf certificate even if one or more of the other certificates of the chain have expired or been revoked. Because validation service 120 has access to the certificate data and device authentication information provided by certificate authority 110 and stored in database 130, and to the extracted certificate data included in the leaf certificate, validation service 120 does not need to traverse the chain and can lookup validation information for the remaining certificates in the chain even though validation service 120 has only recei ved and / or processed the leaf certificate without receiving and / or processing the remaining certificates in the chain.1'00941 Responsive to determining that the leaf certificate is valid, validation service 120 transmits an indication that the leaf certificate is valid to third-party service 140 that requested the certificate chain validation request (408). In implementations in which a leaf certificate is determined to be valid whi le one or more other certificates of the certificate chain are determined to be expired or revoked, validation service 120 may additionally provide third-party service 140 with indications of which certificates of the chain are expired or revoked.|0095] By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage mediums and media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media.. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable medium.{0096 j Instructions may be executed by one or more processors, such as one or more digitalsigns! processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor,” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules. Also, the techniques could be fully implemented in one or more circuits or logic elements.|0997] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize ftmctional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and / or firmware,

[0098] Various embodiments have been described. These and other embodiments are within the scope of the following claims.

[0099] This disclosure includes the following examples;

[0100] Example 1: A method comprising: recei ving, from an application sen-ice associated with a user device, a certificate validation request to validate a leaf certificate of a certificate chain without traversing the certificate chain, wherein the certificate chain was generated by the user device and includes two or more linked certificates including at least the leaf certificate and a root certi fica te, and wherein the leaf certificate includes device authentication information of the user device; retrieving, from a data repository and using the device authentication information from the leaf certificate, validation information for the one or more other linked certificates in the certificate chain other than the leaf certificate, wherein the validation information for the one or more other linked certificates is stored in association with the device authentication information in the data repository; determining, based on the validation information for the one or more other linked certificates and without traversing the certificate chain, whether the leaf certificate is valid; and responsi ve to determining that the leaf certificate is valid: transmitting, to the application service, an indication that the leaf certificate is valid.|010!| Example 2: The method of example 1 „ further comprising: determining that the validation information indicates a validity expiration date of a cryptographic key associated with at least one of the one or more other linked certificates in the certificate chain; and determining whether the leaf certificate is valid based at least in part on the validity expiration date.|0102| Example 3: The method of any of examples 1 through 2, further comprising: extracting, from the leaf certificate, certi ficate data assoc iated with the one or more other l inked certificates included in the certificate chain, wherein retrieving the validation information from the data repository is performed using the extracted certificate data associated with the one or more other linked certificates in the certificate chain.|0103| Example 4c The method of any of examples 1 through 3, further comprising: in response to determining that the leaf certi ficate is in valid, causing the user device to generate a new signed certificate associated with the application service.|0104| Example 5: The method of any of examples 1 through 4, further comprising: causing the user device to provide the leaf certificate to the application service without any other linked certificates from the two or more linked certificates in the certificate chain; and in response to causing the user device to provide the leaf certificate to the application sen- ice, receiving the leaf certificate from the application sendee without any other linked certificates from the two or more linked certificates in the certificate chain, wherein determining whether die leaf certificate is valid is performed without receiving any of the other linked certificates included in the certificate chain.|0105] Example 6: The method of any of examples I through 5, wherein determining, based on the validation information for the one or more other linked certificates in the certificate chain and without traversing the certificate chain, whether the leaf certificate is valid includes: determining, based on the validation information retrieved from the data repository and without traversing the certificate chain, whether one or more digital signatures corresponding to the one or more other linked certificates are valid; determining, based on the device authentication information from the leaf certificate and without traversing the certificate chain, whether a leaf certificate digital signature included in the leaf certificate is valid; and determining, based on determining whether the one or more digital signatures corresponding to the one or more other linked certificates are valid, further based on determining whether the leaf certificate digital signa ture is valid, and without traversing the chain, whether the leaf certificate is valid.

[0106] Example 7: The method of any of examples 1 through 6, further comprising: determining., without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more other linked certificates has been revoked; and transmitting, to the application service, an indication that the leaf certificate is invalid.[0107| Example 8: The method of example 7, wherein determining, without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more ot her linked certificates has been revoked includes: identifying at least one revocation indication associated with the cryptographic key in the validation information retrieved from data repository; and determining that the leaf certificate is invalid based on identifying the at least one revocation indication associated with the cryptographic key corresponding to the at least one of the one or more other linked certificates.|0108| Example 9: A computer program product comprising at least one non -transitory computer-readable storage media including instructions that, when executed by one or more processors, cause the one or more processors to perform the method of any of ex amp les 1 through 8.|0109] Example 10: A system comprising one or more memories including computer-executable instructions and one or more hardware processors configured to execute the computer-executable instructions to perform the method of any of examples 1 through 8.

[0110] Example 11: A system for validating certificate chains, the system comprising: a memory; and a hardware processor that is configured to: receive, from an application service associated with a user device, a certificate validation request to validate a leaf certificate of a certificate chain without traversing the certificate chain, wherein the certificate chain was generated by the user device and includes two or more linked certificates including at least the leaf certificate and a root certificate, and wherein the leaf certificate includes device authentication information of the user device; retrieve, from a data repository' and using the device authentication information from the leaf certificate, validation information for the one or more other linked certificates in the certificate chain other than the leaf certificate, wherein the validation information for the one or more other linked certificates is stored in association with the device authentication information in the data repository; determine, based on the validation information for the one or more other linked certificates and without traversing the certificatechain, whether the leaf certificate is valid; and responsive to determining that the leaf certificate is valid: transmit, to the application service, an indication that the leaf certificate is valid.[0111| Example 12: The system of example 11, wherein the hardware processor is further configured to: determine that the validation information indicates a validity expiration date of a cryptographic key associated with at least one of the one or more other linked certificates in the certificate chain; and determine whether the leaf certificate is valid based at least in part on the validity expiration date.

[0112] Example 14: The system of any of examples 11 through 12, wherein the hardware processor is further configured to: extract, from the leaf certi ficate, certificate data associated with the one or more other linked certificates included in the certificate chain, wherein retrieving the validation information from the data repository is performed using the extracted certificate data associated with the one or more other linked certificates in the certificate chain.[0113| Example 15: The system of any of examples 11 through 14, wherein the hardware processor is further configured, to: in response to determining that the leaf certificate is invalid, cause the user device to generate a new signed certificate associated with the application service.

[0114] Exampl e 16: The system of any of examples 11 through 15, wherein the hardware processor is further configured to: cause the user device to provide the leaf certificate to the application service without any other linked certificates from the two or more linked certificates in the certificate chain; and in response to causing the user device to provide the leaf certificate to the application service, receive the leaf certificate from the application service without any other linked certificates from the two or more linked certificates in the certificate chain, wherein determining whether the leaf certificate is valid is performed without receiving any of the other linked certificates included in the certificate chain.[0115| Example 17: The system of any of examples 11 through 16, wherein detennining, based on the validation information for the one or more other linked certificates in the certificate chain and without traversing the certificate chain, whether the leaf certificate is valid includes: determining, based on the validation information retrieved from the data repository and without traversing the certificate chain, whether one or more digital signatures corresponding to the one or more other linked certificates are valid; detennining, based on the device authentication information from the leaf certificate and without traversing the certificate chain, whether a leaf certificate digital signature included in the leaf certificate is valid; and determining, based on42determining whether the one or .more digital signa tores corresponding to the one or more other linked certificates are valid, farther based on determining whether the leaf certificate digital signature is valid, and without traversing the chain, whether the leaf certificate is valid.|0116| Example 18: The system of any of examples 11 through 17, wherein the hard ware processor is further configured to: determine, without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more other linked certificates has been revoked; and transmit;, to the application service, an indication that the leaf certificate is invalid,

[0117] Example 19: The system of example 18, wherein determining, without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more other linked certificates has been revoked includes: identifying at least one revocation indication associated with the cryptographic key in the validation information retrieved from data repository; and determining that the leaf certificate is invalid based on identifying the at least one revocation indication associated with the cryptographic key corresponding to the at least, one of the one or more other linked certificates,

[0118] Example 20: A non-transitoiy computer-readable medium containing computer executable instructions and a processor that executes the instructions to: receive, from an application service associated with a user device, a certificate validation request to validate a leaf certifi cate of a certificate chain without traversi n g the certificate chain, wherein the certifi cate chain was generated by the user device and includes two or more linked certificates including at least the leaf certificate and a root certificate, and wherein the leaf certificate includes device authentication information of the user device; retrieve, from a data repository and using the de vice authentication information from the leaf certificate, validation information for the one or more other linked certificates in the certificate chain other than the leaf certificate, wherein the validation information for the one or more other linked certificates is stored in association with the device authentication information in the data repository; determine, based on the validation inlbimation for the one or more other linked certificates and without traversing the certificate chain, whether the leaf certificate is valid; and responsive to determining that the leaf certificate is valid: transmit, to the application service, an indication that the leaf certificate is valid.|0119] Example 21 : The non-rtansitory computer-readable medium of example 20, wherein the processor further executes the instructions to: determine that the validation information indicatesa validity expiration date of a cryptographic key associated with at least one of the one or more other linked certificates in the certificate chain ; and determine whether the leaf certificate is valid based at least in part on the validity expiration date.{0120] Example 22: The non-transitory computer-readable medium of any of examples 20 through 21 , wherein the processor further executes the instructions to: extract, from the leaf certificate, certi ficate data associated with the one or more other l inked certificates included in the certificate chain, wherein retrieving the validation information from the data repository is performed using the extracted certificate data associated with the one or mote other linked certificates in the certificate chain.{0121] Example 23: The non-transitory computer-readable medium of any of examples 20 through 22, wherein the processor further executes the instructions to; in response to determining that the leaf certificate is invalid, cause the user device to generate a new signed certificate associated with the application service.{0122] Example 24: The non-transitory computer-readable medium of any of examples 20 through 23, wherein the processor further executes the instructions to: cause the user device to provide the leaf certificate to the application service without any other linked certificates from the two or more linked certificates in the certificate chain; and in response to causing the user device to provide the leaf certificate to the application service, receive the leaf certificate from the application service without any other Jinked certificates from the two or more linked certificates in the certificate chain, wherein determining whether the leaf certificate is valid is performed without, receiving any of the other linked certificates included in the certificate chain. {0123] Example 25: The non-transitory computer-readable medium of any of examples 20 through 24, wherein determining, based on the validation information for the one or more other Jinked certificates in the certificate chain and without traversing the certificate chain, whether the leaf certificate is valid includes: determining, based on the validation information retrieved from the data repository and without traversing the certificate chain, whether one or more digital signatures corresponding to the one or more other linked certificates are valid; determining, based on the device authentication information from the leaf certificate and without traversing the certificate chain, whether a leaf certificate digital signature included in die leaf certificate is valid; and determining, based on determining whether the one or more digital signatures corresponding to the one or more other linked certificates are valid, further based on determiningwhether the leaf certificate digital signature is valid, and without traversing the chain, whether the leaf certificate is valid.|0124| Example 26: The non-transitory computer-readable medium of any of examples 20 through 25, wherein the processor further executes the instructions to: determine, without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more other linked certificates has been revoked; and transmit; to the application service, an indication that the leaf certificate is inval id.|0125 j Example 27: The non-transitory computer-readable medium of example 26, wherein determining, without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more other linked certificates has been revoked includes.' identifyi ng at least one revocation indication associated with the cryptographic key in the validation information retrieved from data repository; and determining that the leaf certificate is invalid based on identifying the at least one revocation indication associated with the cryptographic key corresponding to the at. least one of the one or more other linked certificates.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: receiving, from an application service associated with a user device, a certificate validation request to validate a leaf certificate of a certificate chain without tra versing the certificate chain, wherein the certificate chain was generated by the user device and includes two or more linked certificates inc hiding at least the leaf certificate and a root certificate, and wherein the leaf certificate includes device authentication information of the user device; retrieving, from a data repository and using the device authentication information from the leaf certificate, validation information for the one or more other linked certificates i n. the certificate chain other than the leaf certificate, wherein the validation infonnation for the one or more other linked certificates is stored in association with the device authentication information in the data repository; determining, based on the validation information for the one or more other linked certificates and without traversing the certificate chain, whether the leaf certificate is valid; and responsive to determining that the leaf certificate is valid: transmitting, to the application sendee, an indication that the leaf certificate is valid,2. The method of claim L further comprising: determining that the validation information i ndicates a validity expiration date of a cryptographic key associated with at least one of the one or more other li nked certificates in the certificate chain; and determining whether the leaf certificate is valid based at least in part on the validity expiration date.

3. The method of any of claims 1 through 2, further comprising: extracting, from the leaf certificate, certificate data associated with the one or more other linked certificates included in the certificate chain, wherein retrieving the validation infonnation from the data repository is performed using the extracted certificate data associated with the one or more other linked certificates in the certificate chain.

4. The method of any of claims 1 through 3, further comprising: in response to determining that the leaf certificate is invalid, causing the user device to generate anew signed certificate associated with the application service.

5. The method of any of claims 1 through 4, further comprising: causing the user device to provide the leaf certificate to the application service without any other linked certificates from the two or more linked certificates in the certificate chain; and in response to causing the user device io provide the leaf certificate to the application service, receiving the leaf certificate from the application service without any other linked certificates from the two or more linked certificates in the certificate chain, wherein determining whether the leaf certificate is valid is performed without receiving any of the other linked certificates included in the certificate chain.

6. The method of any of claims 1 through 5, wherein determining, based on the validation information for the one or more other linked certificates in the certificate chain and without traversing the certificate chain, whether the leaf certi ficate is valid includes: determining, based on the validation information retrieved from the data repository and without traversing the certificate chain, whether one or more digital signatures corresponding to the one or more other linked certificates are valid: determining, based on the device authentication information from the leaf certificate and without traversing the certificate chain, whether a leaf certificate digital signature included in the leaf certificate is valid; and determining, based on determining whether the one or more digital signatures corresponding to the one or more other linked certificates are valid, further based on determining whether the leaf certificate digital signature is valid, and without traversing the chain, whether the leaf certificate is valid7. The method of any of chums 1 through 6, further coinprising; determining, without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more other linked certificates has been revoked; and transmitting, to the application service, an indication that the leaf certificate is in valid.

8. The method of claim 7, wherein determining, without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more other linked certificates has been revoked includes: identifying at least one revocation indication associated with the cryptographic key in the validation information retrieved from data repository; and determining that the leaf certificate is invalid based on identifying the at least one revocation indication associated with the cryptographic key corresponding to the at least one of the one or more other linked certificates.

9. A computer program product comprising at least one non-transitory computer-readable storage media including instructions that, when executed by one or more processors, cause the one or more processors to perform any combination of the method of claims 1 through 8.

10. A system, comprising means for performing any combination of the method of claims I through 8.1 1 . A system for validating certificate chains, the system comprising: a memory; and a hardware processor that is configured to; receive, from an application service associated with a user device, a certificate validation request to validate a leaf certificate of a certificate chain without traversing the certificate chain, wherein the certificate chain was generated by the user device and includes two or more linked certificates including at least the leaf certificate and a root certificate, and wherein the leaf certificate includes device authentication information of the user device;retrieve, from a data repository and using the device authentication infbnnation from the leaf certificate, validation information for the one or more other linked certificates in the certificate chain other than the leaf certificate, wherein the validation information for the one or more other linked certificates is stored in association with the device authentication information in the data repository; determine, based on the validation information for the one or more other linked certificates and without traversing the certificate chain, whether the leaf certificate is valid; and responsive to determining that the leaf certificate is valid: transmit, to the application service, an indication that the leaf certificate is valid,12. The system of claim 1 1 , wherein the hardware processor is further configured to: cause the user device to provide the leaf certificate to the application service without any other linked certificates from the two or more linked certificates in the certificate chain.; and in response to causing the user device to provide the leaf certificate to the application service, recei ve the leaf certificate from the application service without any other l inked certificates from the two or more linked certificates in the certificate chain, wherein determining whether the leaf certificate is valid is performed without receiving any of the other linked certificates included in the certificate chain,13. The system of any of claims 1 1 through 12, wherein determining, based on the validation information for the one or more other linked certificates in the certificate chain and without traversing the certificate chain, whether the leaf certificate is valid includes: determining, based on the validation information retrieved from the data repository and without traversing the certificate chain, whether one or more digital signatures corresponding to the one or more other linked certificates are valid; determining, based on the device authentica tion information from the leaf certificate and without traversing the certificate chain, whether a leaf certificate digital signature included in the leaf certificate is valid; anddetermining, based on determining whether the one or more digital signatures corresponding to the one or more other linked certificates are valid, further based on determining whether the leaf certificate digital signature is valid, and without traversing the chain, whether the leaf certificate is valid14. The system of any of claims 11 through 13, wherein the hardware processor is further configured to: determine, without traversing the certificate chain, that a cryptographic key associated with at least one of the one or more other linked certificates has been revoked: and transmit, to the application service, an indication that the leaf certificate is invalid.

15. A non-transitory computer-readable medium containing computer executable instructions and a processor that executes the instructions to perform any combination of the method of claims 1 through 8.

Images