Short-duration digital certificate issuance method and system based on long-duration digital certificate verification

Abstract

A method, system and computer storage medium for issuing short-duration digital certificates based on long-duration digital certificate verification are disclosed. The method includes: a certificate authority service receives a request from an entity to issue a long-duration digital certificate for verification purposes between the entity and the service. After issuing the long-duration digital certificate, the entity submits a request to the service to issue a short-duration digital certificate, the short-duration digital certificate including a validity period shorter than the validity period of the long-duration digital certificate. The service may use the long-duration digital certificate to verify the entity, and after verifying the entity, issue the short-duration digital certificate to the entity. The entity may then use the short-duration digital certificate to enable a user client to authenticate the entity and communicate securely with the entity.

Description

[0001] This application is a divisional application of invention patent application No. 201580066378.4 entitled “Issuance of short-duration digital certificates based on long-duration digital certificate verification” after PCT international application No. PCT / US2015 / 065634, filed on December 14, 2015, entered the Chinese national phase on June 6, 2017.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to co-pending U.S. Patent Application No. 14 / 570,867, filed on December 15, 2014, entitled “SHORT-DURATION DIGITAL CERTIFICATE ISSUANCE BASED ON LONG-DURATION DIGITAL CERTIFICATE VALIDATION,” the entire contents of which are incorporated herein by reference in their entirety. Background Art

[0004] Certificate authorities typically issue digital certificates to clients to enable these clients to establish secure communications with other entities and to allow these other entities to authenticate these clients. In order to issue digital certificates to clients, certificate authorities may need to verify information about the client by checking government databases, third-party databases and services, and other client technologies. If the information about the client can be verified by the certificate authority, the certificate authority can generate and issue a digital certificate to the client. However, such verification techniques may be time and resource intensive activities. Therefore, since the cost and time required to obtain these digital certificates may be large, requests for multiple digital certificates may be undesirable. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0006] Figure 1 Illustrative examples of environments in which various embodiments may be implemented are shown;

[0007] Figure 2 An illustrative example of an environment in which various components of a certificate authority service are collectively configured to issue long duration digital certificates and short duration digital certificates to clients according to at least one embodiment is shown;

[0008] Figure 3An illustrative example of an environment according to at least one embodiment is shown in which a certificate authority service issues a short duration digital certificate to a client upon receiving a valid long duration digital certificate;

[0009] Figure 4 An illustrative example of an environment according to at least one embodiment is shown in which a user client rejects a long duration digital certificate received from a client server;

[0010] Figure 5 An illustrative example of an environment according to at least one embodiment is shown in which a user client is able to authenticate a client server using a short duration digital certificate received from the client server;

[0011] Figure 6 shows an illustrative example of a process for receiving long duration digital certificates and short duration digital certificates from a certificate authority service in accordance with at least one embodiment;

[0012] Figure 7 shows an illustrative example of a process for generating and issuing a long duration digital certificate in response to a client requesting issuance of a long duration digital certificate in accordance with at least one embodiment;

[0013] Figure 8 An illustrative example of a process for authenticating a client utilizing a long duration digital certificate and issuing one or more short duration digital certificates in response to a client request is shown in accordance with at least one embodiment;

[0014] Fig. 9 shows an illustrative example of a process for authenticating a client server using a digital certificate according to at least one embodiment; and

[0015] Fig.10 Illustrative examples of environments in which various embodiments may be implemented are shown. DETAILED DESCRIPTION

[0016] In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details are set forth to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that the embodiments may be practiced without the specific details. In addition, well-known features may be omitted or simplified so as not to obscure the described embodiments.

[0017] The technology described and proposed herein relates to issuing a long duration certificate that can be used for requesting and obtaining a short duration digital certificate for server authentication. In an embodiment, an entity (e.g., the computing device of an organization) communicates with a certificate authority service such as by calling one or more application program interfaces (APIs) of a service to request the issuance of a long duration digital certificate. An entity can be associated with a client of a certificate authority service, and it can be configured to issue digital certificates to various clients, so that these various clients can establish a secure communication channel with other entities, and allow these other entities to authenticate these various clients by using issued digital certificates. Long duration digital certificates may be issued a longer verification period (e.g., one year or longer), and may include extensions that may be marked as critical. This critical extension may prevent a user client (e.g., a browser application installed on a user computing device) from accepting this long duration digital certificate, because these user clients may not be configured to identify critical extensions or may be configured to reject this critical extension.

[0018] Once the certificate authority service has verified the entity, to ensure that a long duration digital certificate can be issued to this entity, the certificate authority service can issue this long duration certificate to the entity or the server of the entity. When receiving the long duration digital certificate, the entity can request a short duration digital certificate, which can be used to establish a secure communication channel with a user client. For example, in an embodiment, the certificate authority service receives a long duration digital certificate and a request to issue a short duration digital certificate from the entity. The certificate authority service can verify the information specified in the long duration digital certificate to authenticate the entity, and issue a short duration digital certificate to this entity after verification. Relative to the long duration digital certificate (for example, a few days, a few months, etc.), the short duration digital certificate can have a shorter verification period. In addition, the certificate authority service can determine this verification period based on the remaining verification period of the long duration digital certificate. For example, if the remaining verification period of the long duration digital certificate is three months, the certificate authority service can issue a short duration digital certificate with a verification period of no more than three months.

[0019] In an embodiment, once an entity has obtained a short duration digital certificate from a certificate authority service, the entity may provide this short duration digital certificate to a user client to establish a secure communication channel. Upon receiving the short duration digital certificate, the user client may verify the identity of the entity by evaluating the short duration digital certificate, and verify the digital signature included in the short duration digital certificate by using the public key obtained from the certificate authority service. This may enable the user client to verify that the short duration digital certificate is issued by the certificate authority service and is therefore valid. By utilizing this short duration digital certificate, the user client may obtain the public key of the entity, and utilize this public key to encrypt data and send it to the entity via a secure communication channel.

[0020] In this way, an entity may be able to obtain multiple short duration digital certificates from a certificate authority service based on a previously issued long duration digital certificate, without the need to perform a large number of verification processes before issuing each short duration digital certificate. In addition, the technology described and proposed herein is conducive to other technical advantages. For example, because in some embodiments, a long duration digital certificate includes an extension that is unrecognizable and / or causes a user client to reject a long duration digital certificate, it is no longer necessary for an entity to revoke and request the issuance of a new long duration digital certificate when a long duration digital certificate is damaged. In addition, if a short duration digital certificate is damaged, the entity can revoke this short duration digital certificate and utilize the issued long duration digital certificate to obtain a new short duration digital certificate from a certificate authority service, without the need to undergo the entire verification process again.

[0021] Figure 1 An illustrative example of an environment 100 in which various embodiments may be implemented is shown. In environment 100, a certificate authority service 102 may provide a certificate authority system that enables a client of the certificate authority service 102 to request the issuance of one or more digital certificates that may prove the client's (e.g., a named object as identified within a digital certificate) ownership of a public key. These one or more digital certificates may allow other entities such as a user client 106 (e.g., a browser application) to verify the client's identity and establish a secure communication channel with the client, thereby enabling the transmission of encrypted and unencrypted data. In an embodiment, the certificate authority service 102 receives a request from a client for a long duration digital certificate that may be used to issue a short duration digital certificate at a later time, as long as the long duration digital certificate remains valid.

[0022] The certificate authority service 102 may perform one or more verification processes when receiving a request for issuing a long duration certificate from a client to ensure that the client can be trusted and authorized to obtain a digital certificate from the certificate authority service 102. For example, the certificate authority service 102 may access one or more government agencies, third-party databases, or any other trusted information repository to evaluate the client, ensure that the client is the client it claims to be, and ensure that the client has been properly reviewed for digital certificates. If the client has been properly reviewed by the certificate authority service 102, the certificate authority service 102 may issue a long duration digital certificate to the client for obtaining a shorter duration digital certificate. In some embodiments, the long duration digital certificate is an X.509 certificate, which may specify the issuer of the digital certificate, the validity period of the certificate, the object (e.g., the client), the public key of the object, and the digital signature of the certificate authority service 102. However, this long duration digital certificate may further specify a key extension that may indicate that the long duration digital certificate is only used for verification purposes. This key extension may not be recognized by some user clients 106, and therefore may be automatically rejected by these user clients 106. Alternatively, the user client 106 may be configured to reject any digital certificates that include this critical extension.

[0023] Once the client has received this long duration digital certificate from the certificate authority service 102, the client can submit a request to the certificate authority service 102 through one or more client servers 104 to obtain one or more short duration digital certificates, which can be used to establish a secure communication channel with the user client 106, and enable the user client 106 to authenticate the client server 104. The request to the certificate authority service 102 may include the aforementioned long duration digital certificate. Once the request from one or more client servers 104 is received, the certificate authority service 102 can evaluate the long duration digital certificate to verify the identity of the client, and ensure that the long duration digital certificate is still valid. In an embodiment, the request can be digitally signed using the client private key corresponding to the public key specified in the long duration digital certificate to ensure that it is issuing one or more short duration digital certificates to the same entity to which the certificate authority service 102 originally issued the long duration digital certificate. The certificate authority service 102 can verify the digital signature using the public key of the long duration digital certificate.

[0024] The certificate authority service 102, after verifying the identity of the client that has provided the request, may evaluate the long duration digital certificate to determine the remaining validation period of the digital certificate. The certificate authority service 102 may use this information to establish a validity period that may be specified in one or more short duration digital certificates. For example, if the remaining validation period of the long duration digital certificate is three months, the certificate authority service 102 may issue a short duration digital certificate whose validation period does not exceed the remaining three-month period defined in the long duration digital certificate. Alternatively, the client may specify the desired validation period of the short duration digital certificate through the request, as long as the desired validation period does not exceed the remaining validation period of the provided long duration digital certificate.

[0025] The certificate authority service 102 may also generate a short duration digital certificate to include the same public key specified in the long duration digital certificate. This may enable the short duration digital certificate to be used as a proxy for the long duration digital certificate and enable access to the user client 106 or other entity. For example, the long duration digital certificate may be issued to a client via a physical implementation such as a smart card, badge, or other device in which the long duration digital certificate may be stored. The client may present the smart card, badge, or other device to the certificate authority service 102 via a computing device at a remote location. Based at least in part on the analysis of the long duration digital certificate in the smart card or other device, a short duration digital certificate may be issued to the client that may be valid for a shorter period of time. This may enable the client to access the remote location using this newly issued short duration digital certificate, which may only be valid during his / her time at this remote location. In an alternative embodiment, the short duration digital certificate may also specify a client key different from the key specified in the long duration digital certificate. This may enable the client to revoke the short duration digital certificate (if compromised) without exposing the client key specified in the long duration digital certificate.

[0026] Once the client has received one or more short duration digital certificates from the certificate authority service 102 through one or more client servers 104, the client server 104 can now send data to one or more user clients 106 along with the received one or more short duration digital certificates. The user client 106 can obtain from the certificate authority service 102 a public key of a key pair that can be used to verify the digital signature of the certificate authority service 102 specified in the one or more short duration digital certificates. If the digital signature of the certificate authority service 102 is verified to be authentic, then the user client 106 can determine that the one or more short duration digital certificates are valid, and therefore use them to verify the identity of the one or more client servers 104, and if verified, use the client's public key specified in the short duration digital certificate. For example, if the client server 104 is used to send digitally signed (e.g., using the client's private key) data to the user client 106, then the user client 106 can use the client's public key as specified in the short duration digital certificate to verify the client's digital signature and determine whether the data sent is valid. Therefore, the user client 106 can be used to securely send information to the client server 104.

[0027] As described above, a client may communicate with a certificate authority service to request the issuance of a long duration digital certificate, which may be used for verification purposes in obtaining a short duration digital certificate. In addition, a client may request these short duration digital certificates from a certificate authority service through one or more client servers, which may then be used to enable a user client to authenticate one or more client servers. The request for these short duration digital certificates may include the long duration digital certificate, which the certificate authority service may utilize to authenticate the client. Thus, Figure 2 An illustrative example of an environment 200 is shown in which various components of a certificate authority service 202 are collectively configured to issue long duration digital certificates and short duration digital certificates to clients 212 in accordance with at least one embodiment.

[0028] The certificate authority service 202 may provide an interface 204 to clients 212 that enables these clients 212 to access the certificate authority service 202. The clients 212 may utilize the interface 204 over one or more communication networks, such as the Internet. The interface 204 may include certain security protections to ensure that the clients 212 are authorized to access the certificate authority service 202. For example, in order to access the certificate authority service 202, the client may need to provide a username and a corresponding password or key when using the interface 204. In addition, requests (e.g., API calls) submitted to the interface 204 may require an electronic signature generated using a key so that the electronic signature can be verified by the certificate authority service 202, such as by an authorization system (not shown).

[0029] Through interface 204, client 212 may be able to submit a request to one or more client 212 servers for issuance of a long duration digital certificate. As described above, the long duration digital certificate may be utilized at a later time to cause certificate authority service 202 to authenticate client 212 and issue a short duration digital certificate to the client 212 server. The request for issuance of a long duration digital certificate may include information about client 212, such as client 212's name, address, income information, etc. In addition, through interface 204, client 212 may be allowed to specify a validation period for the long duration digital certificate, which may then be specified within the long duration digital certificate.

[0030] Once the certificate authority service 202 has received a request from a client 212 to issue a long-duration digital certificate, the interface 204 may send the request to a management subsystem 206, which may be configured to process the request and determine whether the client 212 may be issued a long-duration digital certificate. For example, the management subsystem 206 may be configured to access a government agency database and other third-party databases to determine whether the client 212 may be issued a long-duration digital certificate based at least in part on the client 212 information provided with the request. For example, if the management subsystem 206 determines that the client 212 cannot be trusted based at least in part on the information specified in the third-party database, the management subsystem 206 may deny the client 212's request for a long-duration digital certificate. If the management subsystem 206 determines that the client 212 may be issued a long-duration digital certificate, the management subsystem 206 may store the client 212 information in the client profile repository 210. In addition, the management subsystem 206 may access the certificate data storage area 208 to obtain a certificate template that can be used to generate a long-duration digital certificate. For example, the management subsystem 206 can obtain an X.509 digital certificate template from the certificate data storage area 208 and use the template to generate a long-duration X.509 digital certificate for the client 212. The management subsystem 206 can provide the client 212 with the newly generated long-duration digital certificate through the interface 204.

[0031] In an embodiment, management subsystem 206 specifies critical extensions within the long-duration digital certificate that may not be recognized by a user client or that may be rejected by a user client. For example, a critical extension may be a "verification-only" extension that may signal to a user client that the digital certificate may not be used to authenticate client 212. Such a critical extension may include information about one or more verifications performed to authenticate client 212, such as the date the verification was performed, the standard or requirement for client 212 verification, and / or an identifier of client 212 for which certificate authority service 202 performed the verification.

[0032] At a later time, client 212 may access interface 204 again through one or more client 212 servers to request the creation of one or more short duration digital certificates, which can be used to establish a secure communication channel with a user client and enable the user client to authenticate client 212. The request may include a long duration digital certificate previously issued to client 212. In addition, in some embodiments, the request may be digitally signed by client 212 using a private key of client 212, which may correspond to a public key specified in the original long duration digital certificate. Upon receiving the request, management subsystem 206 may evaluate the long duration digital certificate to determine the remaining verification period of the long duration digital certificate. For example, a long duration digital certificate may include a validity period field specifying the start date and expiration date of the long duration digital certificate. Management subsystem 206 may be able to calculate the remaining verification period of the long duration digital certificate based at least in part on the specified expiration date.

[0033] In addition, if the request has been digitally signed by the client 212, the management subsystem 206 can access the client profile repository 210 to obtain a key corresponding to this particular client 212, which can be used to verify the digital signature included with the request and ensure that the received request is valid. If the management subsystem 206 determines that the client 212 is what it claims to be based at least in part on the information specified in the long-duration digital certificate, the management subsystem 206 can access the certificate data storage area 208 to obtain a digital certificate template that can be used to generate one or more short-duration digital certificates requested. One or more short-duration digital certificates can be similar to long-duration digital certificates, except for certain specified information. For example, a short-duration digital certificate can specify a validity period that is less than or equal to the remaining verification period of the long-duration digital certificate. For example, if the remaining verification period of the long-duration digital certificate is three months, the management subsystem 206 can specify in the short-duration digital certificate that the validity period of the short-duration digital certificate is any value less than or equal to three months. The expiration date of the short-duration digital certificate can therefore coincide with the expiration date of the long-duration digital certificate, or be earlier than the expiration date of the long-duration digital certificate.

[0034] In addition, the short duration digital certificate may not include the critical extensions specified in the long duration digital certificate. This may enable the user client to utilize the short duration digital certificate to authenticate the client 212 and enable the user client to communicate securely with the client 212. In some embodiments, the management subsystem 206 may generate a short duration digital certificate that specifies a replacement client 212 key for the key specified in the original long duration digital certificate. This may help reduce the likelihood that the long duration digital certificate, and therefore the original client 212 key, is compromised due to a short duration digital certificate breach.

[0035] Once the management subsystem 206 has generated one or more short duration digital certificates in response to a client 212 request, the management subsystem 206 may access the profile of the client 212 within the client profile repository 210 to specify the number of short duration digital certificates issued, the corresponding client 212 keys, and any other information that may be used to generate digital certificates on behalf of the client 212 at a later time. The management subsystem 206, through the interface 204, may issue these short duration digital certificates to the client 212, who may provide these short duration digital certificates to user clients to enable these user clients to authenticate the client 212 and securely send data to the client 212 over a secure communication channel. In addition, these short duration digital certificates may enable the client 212 to digitally sign his / her data and encrypt data to be sent to the user clients.

[0036] As described above, a client may send a request including a previously issued long-duration digital certificate to a certificate authority service to obtain one or more short-duration digital certificates that may be sent to user clients so that these user clients may utilize the short-duration digital certificates to authenticate the client. Figure 3 An illustrative example of an environment 300 is shown in which a certificate authority service 304 issues a short-duration digital certificate 308 to a client 302 upon receiving a valid long-duration digital certificate 306, according to at least one embodiment. In environment 300, as part of a request to the certificate authority service 304 to issue one or more short-duration digital certificates 308, the client 302 may provide the long-duration digital certificate 306 previously issued by the certificate authority service 304 to the client 302. As described above, the long-duration digital certificate 306 may specify a validity period, which may include a start date (e.g., a date such as the start date of the certificate). Figure 3 field as shown) and an expiration date (e.g. Figure 3The validity period may define the duration for which the long duration digital certificate 306 is valid. In addition, the validity period may enable the certificate authority service 304 to determine the remaining validation period of the long duration digital certificate 306. For example, the certificate authority service 304 may calculate the remaining validation period of the long duration digital certificate 306 using the expiration date and the current date and time.

[0037] The long-duration digital certificate 306 may also include a critical extension that may be used to prevent a user client from using the long-duration digital certificate 306 to authenticate the client 302. For example, Figure 3 As shown, the long duration digital certificate 306 may specify an extension with an identifier "Verify Type Only-1.01". This particular extension may be marked as critical, which means that if the user client does not recognize the critical extension, the user client must reject the long duration digital certificate 306. In addition, when the user client is updated to recognize this critical extension, the user client may be configured to not accept any long duration digital certificate 306 that includes this critical extension. Therefore, the client 302 may not be able to assert its identity to the user client using only this long duration digital certificate 306.

[0038] As described above, when a client 302 submits a request to a certificate authority service 304 to obtain one or more short duration digital certificates 308, the client 302 may provide a previously issued long duration digital certificate 306 to the certificate authority service 304. The certificate authority service 304 may evaluate the long duration digital certificate 306 to ensure that the long duration digital certificate 306 is still valid. In addition, the certificate authority service 304 may evaluate one or more subject fields (not shown) to verify that the client 302 is what it claims to be. For example, one or more subject fields may specify a given name and surname of the client 302, the organization name and / or unit of the client 302, the state, province and country where the organization may be located, the public name (e.g., URL) of the client 302 or other entity, etc. In an embodiment, the client 302 digitally signs the request to the certificate authority service 304 using the key included in the long duration digital certificate 306, so as to ensure to the certificate authority service 304 that the short duration digital certificate 308 will be issued to the same client 302 to which the long duration digital certificate 306 is issued.

[0039] Once the certificate authority service 304 has authenticated the client 302 using the long duration digital certificate 306, the certificate authority service 304 may generate and issue one or more short duration digital certificates 308 to the client 302. These one or more short duration digital certificates 308 may be similar to the long duration digital certificate 306, except for a few alternative entries. For example, Figure 3 As shown, the validity period of the short duration digital certificate 308 is shorter than the validity period specified in the long duration digital certificate 306. For example, the certificate authority service 304 may specify a start date equal to the date on which the short duration digital certificate 308 is generated. Alternatively, the start date of the short duration digital certificate 308 may be defined as a later date from the date on which the short duration digital certificate 308 is issued to the client 302 and before the expiration date specified in the long duration digital certificate 306.

[0040] In an embodiment, the short duration digital certificate 308 is generated to include at least one subject field that is specific to the client 302 or other entity specified within the same subject field of the long duration digital certificate 306. For example, the short duration digital certificate 308 may specify the same organization name, organization location (e.g., state, province, country), and public name (e.g., URL) as specified within the long duration digital certificate 306. In some embodiments, the short duration digital certificate 308 may also include additional subject fields that are not specified within the long duration digital certificate 306. For example, the short duration digital certificate 308 may specify, through one or more of these additional subject fields, the identity of a trusted entity associated with the user 302 for which the short duration digital certificate 308 has been generated. In addition, one or more additional subject fields included within the short duration digital certificate 308 may specify a second location (e.g., state, province, country) in which the short duration digital certificate 308 may be utilized.

[0041] The expiration date of the short duration digital certificate 308 may be defined by the certificate authority service 304 based at least in part on the expiration date specified in the long duration digital certificate 306 and / or the client 302 request. Figure 3 As shown, the expiration date specified in the short duration digital certificate 308 is earlier than the expiration date specified in the long duration digital certificate 306. The validity period of the short duration digital certificate 308 can be defined by the certificate authority service 304 or by the client 302 through request, as long as the validity period of the short duration digital certificate 308 does not exceed the remaining validation period of the long duration digital certificate 306.

[0042] The short-duration digital certificate 308 may not include a critical extension included in the long-duration digital certificate 306 that prevents the user client from using the digital certificate. Figure 3 As shown, the short-duration digital certificate 308 does not include the extension "Validation Type Only-1.01". Instead, the extension specified in the short-duration digital certificate 308 can enable the user client to utilize the short-duration digital certificate 308 to authenticate the client 302 and for other purposes (e.g., data verification, data decryption, etc.). When the short-duration digital certificate 308 expires, the client 302 can submit a request to the certificate authority service 304 again together with the long-duration digital certificate 306 to obtain a new short-duration digital certificate 306.

[0043] As described above, a long-duration digital certificate issued to a client by a certificate authority service may not be used to verify the authenticity of the client's assertion of his / her identity. For example, a long-duration digital certificate may include critical extensions that may not be recognized by one or more user clients, or may indicate to these one or more user clients that the long-duration digital certificate may not be accepted for client authentication. Figure 4 An illustrative example of an environment 400 is shown in which a user client 404 rejects a long duration digital certificate 406 received from a client server 402 in accordance with at least one embodiment.

[0044] The long-duration digital certificate 406 may include many similar fields included in a conventional digital certificate. For example, the long-duration digital certificate 406 may specify the validity period of the certificate, the client to whom the long-duration digital certificate 406 is issued, the client key, and a certificate authority service digital signature that can be used to verify that the long-duration digital certificate 406 is valid. However, the long-duration digital certificate 406 may include one or more critical extensions that can be used to specify that the long-duration digital certificate 406 is only used for authentication. For example, if Figure 4 As shown, the long-duration digital certificate 406 may specify an extension with an identifier "Validation Type Only-1.01". This particular extension may be marked as critical, which means that if the user client 404 does not recognize the critical extension, the user client 404 must reject the long-duration digital certificate 406. In addition, when the user client 404 is updated to recognize this critical extension, the user client 404 may be configured to not accept any long-duration digital certificates 406 that include this critical extension.

[0045] If the user client 404 receives this long-duration digital certificate 406 from the client server 402, the user client 404 may discard the data received from the client server 402 and terminate the communication channel with the client server 402. Thus, the client may only be allowed to utilize the long-duration digital certificate 406 for verification purposes in conjunction with the services of a certificate authority. Furthermore, this may limit the exposure of the long-duration digital certificate 406 to a wide audience, thereby reducing the risk that the long-duration digital certificate 406, and therefore the client's public key, may be compromised.

[0046] As described above, a client may request one or more short-duration digital certificates from a certificate authority service through one or more client servers. The request may include a long-duration digital certificate, which may enable the certificate authority service to authenticate the client and utilize information specified in the long-duration digital certificate to limit the validity period of one or more short-duration digital certificates to be issued to the client. These one or more short-duration digital certificates may be used by the client to assert his / her identity to a user client and enable the user client to authenticate the client. Thus, Figure 5 An illustrative example of an environment 500 is shown in accordance with at least one embodiment, wherein a user client 504 is able to authenticate a client server 502 using a short duration digital certificate 506 received from a client server 502. The user client 504 and the client server 502 may be similar to Figure 4 User client and client server shown.

[0047] In environment 500, client server 502 may send data and short duration digital certificate 506 to user client 504. User client 504 may be a browser application with which a user may interact to access client server 502. When user client 504 initiates communication with client server 502, client server 502 may respond by providing certain data and short duration digital certificate 506 to user client 504. Short duration digital certificate 506 may specify the identity of the client, the validity period of short duration digital certificate 506, the client public key, and the digital signature of the certificate authority service that issued the short duration digital certificate to client server 502. In addition to this information, short duration digital certificate 506 may specify one or more extensions that may be used to specify that short duration digital certificate 506 may be used for a particular purpose. For example, Figure 5 As shown, the short duration digital certificate 506 may include a "basic constraints" extension that can be used to limit the path length of the certificate chain. Although the "basic constraints" extension is widely used throughout this disclosure for illustrative purposes, additional and / or alternative extensions may be specified within the short duration digital certificate 506.

[0048] However, with Figure 4 Compared to the long-duration digital certificate shown, the short-duration digital certificate 506 may not specify critical "verify-only" extensions, such as Figure 4 The short duration digital certificate 506 is a "Verify Type Only-1.01" extension specified within the long duration digital certificate shown. Thus, the short duration digital certificate 506 can be recognized by the user client 504 and enables the user client 504 to utilize the short duration digital certificate 506 to authenticate the client server 502 and verify the certificate authority service digital signature specified within the short duration digital certificate 506 by using the certificate authority service's public key. Thus, if the user client 504 is able to authenticate the client server 502 and verify that the short duration digital certificate 506 is valid, then the user client 504 can engage in further communications with the client server 502 over the secure communication channel.

[0049] As described above, a client may submit a request to a certificate authority service to request the issuance of a long-duration digital certificate, which may be used solely for verification purposes between the client and the certificate authority service. In addition, once a long-duration digital certificate has been issued to a client, the client may submit a new request to the certificate authority service for the issuance of one or more short-duration digital certificates, which may be used by user clients to authenticate the client and enable secure communications between the client and these user clients. The new request for the issuance of one or more short-duration digital certificates may include the above-mentioned long-duration digital certificate, which the certificate authority service may utilize to authenticate the client and obtain the information required to define the parameters of the short-duration digital certificate. Thus, Figure 6 An illustrative example of a process 600 for receiving a long duration digital certificate and a short duration digital certificate from a certificate authority service according to at least one embodiment is shown. Process 600 may be performed by a client via one or more client servers that may be configured to facilitate communication between the client and the certificate authority service.

[0050] In order for a client to obtain a long-duration digital certificate, the client may be required to provide certain information to the certificate authority service, which the certificate authority service may use to properly vet the client as a trusted entity to which a long-duration digital certificate may be entrusted. For example, the certificate authority service may access one or more databases maintained by government agencies, trusted third-party databases, and other trusted information repositories to determine whether the client is trustworthy. Thus, the client may be required to satisfy 602 one or more certificate authority service validation requirements in order to obtain a long-duration certificate.

[0051] If the client can meet the certificate authority service verification requirements, the certificate authority service can generate a long duration digital certificate. This long duration digital certificate can specify a long validity period (e.g., one year or longer) and a specific key extension, which can specify that the long duration digital certificate can only be used for verification purposes through the certificate authority service. Therefore, the long duration digital certificate may not be accepted by the user client that is configured to identify this specific key extension. Alternatively, the key extension may not be recognized by the user client, which may cause the user client to reject the long duration digital certificate. The validity period of the long duration digital certificate may be limited by the certificate authority service or the client through his / her request to the service. In the case of generating a long duration digital certificate, the certificate authority service can issue a long duration digital certificate to the client for use. Therefore, the client can receive 604 a long duration digital certificate from the certificate authority service.

[0052] At any time after having received the long duration digital certificate from the certificate authority service, the client can submit 606 requests to the certificate authority service to issue one or more short duration digital certificates, which can be used for authentication purposes when communicating with one or more user clients. The request may include the above-mentioned long duration digital certificate, which the certificate authority service can use to verify the identity of the client, and ensure that the client is authorized to obtain the requested one or more short duration digital certificates. In an embodiment, the request submitted to the certificate authority service is digitally signed by the client by utilizing the private key of the client corresponding to the public key specified in the long duration digital certificate. The certificate authority service can verify the digital signature using the public key of the long duration certificate. This enables the certificate authority service to ensure that the short duration digital certificate will be issued to the same entity that was previously issued the long duration digital certificate.

[0053] Once the certificate authority service has authenticated the client using the long duration digital certificate, the certificate authority service may generate one or more short duration digital certificates that may be issued to the client. The duration or validity period of these short duration digital certificates may be shorter than the long duration digital certificate. For example, the certificate authority service may define the validity period of the short duration digital certificate based at least in part on the remaining verification period of the long duration digital certificate. Alternatively, the client may request a specific validity period for these short duration digital certificates as long as the validity period is less than or equal to the remaining verification period of the long duration digital certificate. This may prevent the certificate authority service from issuing a short duration digital certificate, the expiration date of which is later than the expiration date of the long duration digital certificate. The short duration digital certificate may also omit the key extensions specified in the long duration digital certificate. This may enable these short duration digital certificates to be used by the user client to authenticate the client. Once the short duration digital certificates have been generated, the client may receive 608 these short duration digital certificates from the certificate authority service.

[0054] Once the client has received one or more short duration digital certificates from the certificate authority service, the client may utilize 610 these one or more short duration digital certificates for authentication purposes. For example, the client's client server may provide a copy of the short duration digital certificate to the user client so that, for example, the user client can determine that they are communicating with a server that is authorized to operate on behalf of the domain name specified in the short duration digital certificate. The short duration digital certificate may include a certificate authority service digital signature, which may be verified by the user client using a public key obtained from the certificate authority service and maintained by, for example, the user client in a data storage location for trusted certificates. If the digital signature is verified, then the user client may determine that the short duration digital certificate is credible and can be used to ensure that the client is who it claims to be.

[0055] As described above, a certificate authority service may receive a request from a client to issue a long-duration digital certificate. Such a long-duration digital certificate may be used for authentication purposes between the client and the certificate authority service. For example, a long-duration digital certificate may specify critical extensions that may cause a user client to reject the digital certificate if provided to the user client by the client or any other entity. However, the certificate authority service may utilize this long-duration digital certificate to authenticate the client and issue a short-duration digital certificate that may be used for authentication upon request. Thus, Figure 7An illustrative example of a process 700 for generating and issuing a long-duration digital certificate in response to a client requesting the issuance of a long-duration digital certificate according to at least one embodiment is shown. Process 700 may be performed by the aforementioned certificate authority service, which may be configured to receive requests from clients and communicate with other entities to determine whether the client can be entrusted with a long-duration digital certificate. In addition, the certificate authority service may be configured to generate these long-term digital certificates based at least in part on the client's request and known digital certificate formats and standards.

[0056] The client may communicate with the certificate authority service to request the issuance of a long duration digital certificate, which may be used for verification purposes between the client and the certificate authority service. The client may operate one or more servers, which may be used to communicate with various user clients in the course of business. In order for these one or more servers to be authenticated by these user clients and to achieve secure communication between these one or more servers and the user clients, the client may need to obtain one or more digital certificates to ensure these user clients that the client is who it claims to be. As described above, the long duration digital certificate will be used for verification purposes. In addition, this long duration digital certificate may be required in order to obtain a short duration digital certificate that can be used by the user client for server authentication. Therefore, the certificate authority service may receive 702 a request from the client to issue a long duration digital certificate.

[0057] The request from the client may include information about the client's business operations. For example, the client may provide the certificate authority service with its name, address, email address, uniform resource locator (URL), financial records, etc. for review. This information may be necessary to determine whether the client can be entrusted with one or more long duration digital certificates. Therefore, the certificate authority service may determine 704 whether it has received the necessary information from the client to perform a thorough verification process for reviewing the client. If the client does not provide this necessary information as required by the certificate authority service, the certificate authority service may deny 706 the client's request to issue a long duration digital certificate.

[0058] If the client has provided the certificate authority service with the necessary information needed to authenticate the client, the certificate authority service may perform 708 one or more entity and domain verification processes to verify and authenticate the requester (e.g., the client). For example, in some embodiments, the certificate authority service may send one or more electronic mail (e-mail) messages to an address known to be responsible for the client's domain management. For example, the certificate authority service may utilize a "WHOIS" query to identify the client domain and send an authentication link to a designated contact address included in the client's "WHOIS" entry. Additionally or alternatively, the certificate authority service may access various government agency databases and other third-party databases to determine whether the client can be entrusted with a long-duration digital certificate based at least in part on the information provided.

[0059] Once the certificate authority service has performed the entity and domain validation processes, the certificate authority service may determine 710 whether these processes have been satisfied. For example, if the certificate authority service determines that the client may not be trusted with long duration digital certificates based on an analysis of the client's information specified within government agency databases and other third-party databases, the certificate authority service may deny 706 the client's request. However, if the validation processes have been satisfied, the certificate authority service may generate 712 a long duration digital certificate that may be used for authentication purposes between the certificate authority service and the client.

[0060] The long duration digital certificate may specify the issuer of the digital certificate, the validity period of the certificate, the subject (e.g., the client), the subject's public key, and the digital signature of the certificate authority service. The long duration digital certificate may further specify a critical extension that may indicate that the long duration digital certificate is only used for verification purposes. This critical extension may not be recognized by some user clients, and therefore may be automatically rejected by these user clients. Alternatively, the user client may be configured to reject any digital certificate that includes this critical extension. Once the certificate authority service has generated this long duration digital certificate, the certificate authority service may issue 714 this certificate to the client. Therefore, the client may now utilize this long duration digital certificate for verification purposes, and as part of a request to obtain a short duration digital certificate for communicating with one or more user clients.

[0061] As described above, a certificate authority service may receive a request from a client to issue one or more short-duration digital certificates. These one or more short-duration digital certificates may be used by user clients to authenticate the client and enable secure communications between the client and these user clients, as opposed to previously issued long-duration digital certificates. The request from the client may include a previously issued long-duration digital certificate, which may be used by the certificate authority service to verify the client and obtain information needed to generate the requested short-duration digital certificate. Thus, Figure 8 An illustrative example of a process 800 for authenticating a client utilizing a long duration digital certificate and issuing one or more short duration digital certificates in response to a client request is shown in accordance with at least one embodiment.

[0062] Similar to the above process 700, the client can communicate with the certificate authority service to request the issuance of a short duration digital certificate, which can be provided by the client to the user client so that these user clients can authenticate the client and send secure communications to the client. The request may include a long duration digital certificate previously issued to the client by the certificate authority service and can only be used for the verification purpose between the client and the certificate authority service. In some embodiments, the request for issuing a short duration digital certificate can be digitally signed using the client's private key included in the long duration digital certificate to ensure that the short duration digital certificate will be issued to the client. The certificate authority service can verify the digital signature using the public key of the long duration digital certificate. Therefore, the certificate authority service can receive 802 requests for issuing one or more short duration digital certificates.

[0063] Once the certificate authority service has received a request from a client to issue one or more short-duration digital certificates, the certificate authority service may examine 804 the information included within the long-duration digital certificate to determine 806 whether the certificate is valid. For example, the certificate authority service may evaluate the subject field within the long-duration digital certificate to determine whether the entity submitting the request matches the subject specified within the long-duration digital certificate. In addition, the certificate authority service may determine whether the long-duration digital certificate has been tampered with by utilizing the included certificate authority service digital signature to determine the validity of the certificate. If the certificate authority service determines that the long-duration digital certificate is invalid, then the certificate authority service may deny 808 the client's request to issue a short-duration digital certificate.

[0064] In an embodiment, a long duration digital certificate may be issued by a certificate authority service different from a certificate authority service configured to issue a short duration digital certificate to a client. The long duration digital certificate may include a certificate authority service digital signature corresponding to this different certificate authority service. Thus, the certificate authority service may first determine whether it has a public key from this different certificate authority service, and if so, utilize this public key to verify the digital signature specified in the long duration digital certificate and validate the long duration digital certificate. If the long duration digital certificate is valid, the certificate authority service may proceed to check the long duration digital certificate to determine whether it can issue the requested short duration digital certificate to the client.

[0065] If the certificate authority service determines that the long duration digital certificate is indeed valid, the certificate authority service can determine 810 whether the long duration digital certificate still has enough remaining verification period for issuing a short duration digital certificate. For example, the certificate authority service may require that the long duration digital certificate must have a remaining verification period greater than three months so that the certificate authority service issues any short duration digital certificate based on the long duration digital certificate. Similarly, the certificate authority service can be configured to only issue short duration digital certificates with a specific validity period. If this specific validity period exceeds the remaining verification period of the long duration digital certificate, the certificate authority service may not be allowed to generate the requested one or more short duration digital certificates. Therefore, if the certificate authority service determines that the long duration digital certificate does not have enough remaining verification period, the certificate authority service can reject 808 the client's request.

[0066] Once the certificate authority service has determined that the long duration digital certificate has sufficient remaining validation period to be used to issue the requested one or more short duration digital certificates, the certificate authority service can determine 812 the validity period of the short duration digital certificates to be issued. As described above, the certificate authority service can be configured to generate short duration digital certificates with a set validity period. Therefore, these short duration digital certificates can specify this specific validity period. In other embodiments, the client can specify the expected validity period of the short duration digital certificate by request. If the expected validity period does not exceed the remaining validation period of the long duration digital certificate, the certificate authority service can use this expected validity period to calculate the start date and expiration date of the requested one or more short duration digital certificates.

[0067] The certificate authority service may generate one or more short duration digital certificates using the determined validity period of the short duration digital certificate and the information obtained from the long duration digital certificate. Subsequently, the certificate authority service may issue 814 the one or more short duration digital certificates to the client in response to his / her request. This may enable the client to provide these one or more short duration digital certificates to various user clients to enable these user clients to authenticate the client and communicate securely with the client.

[0068] As described above, a long duration digital certificate may include a critical extension that may not be recognized by the user client, or may cause the user client to not accept the long duration digital certificate when detecting and recognizing such extension. Therefore, if a client presents a long duration digital certificate to the user client, the user client may not be able to authenticate the client, and therefore no further communications with the client will occur. Therefore, Fig. 9 An illustrative example of a process 900 for authenticating a client server using a digital certificate is shown in accordance with at least one embodiment. The process 900 may be performed by any user client, such as a browser application installed on a user's computing device.

[0069] When the user client sets up a communication channel with the client server, the client server can send one or more digital certificates to the user client to establish the identity of the client server. These digital certificates can include various fields, which can be used to determine whether the client server is what it claims. For example, the digital certificate can include a subject field, which can specify the name, address and domain of the client and the associated client server. In addition, the digital certificate can include a certificate authority service digital signature, which the user client can use to verify that the digital certificate is issued by a trusted certificate authority service, and that the digital certificate is valid. In addition, the digital certificate can include various extensions, which can specify how the digital certificate should be processed by the user client. Therefore, when setting up communication with the client server, the user client can receive 902 digital certificates from this client server, and can further identify any extensions specified in 904 digital certificates.

[0070] As mentioned above, long duration digital certificate can comprise the key extension that can specify that long duration digital certificate can only be used for the verification purpose between client-server and issuing certificate authority service.This key extension may not be identified by some user clients, and therefore may cause these user clients to reject long duration digital certificate.Alternately, in some embodiments, user client can be configured to identify this key extension, and therefore do not accept the long duration digital certificate from client-server.Therefore, user client can determine whether the digital certificate received by 906 comprises this "only verification" key extension.If digital certificate comprises this key extension, user client can terminate the communication channel between 908 user clients and the client so, because user client may not authenticate the client.Yet, if the key extension does not exist, user client can continue 910 to process digital certificate with authentication client-server so.

[0071] Fig.10 Various aspects of an exemplary environment 1000 for implementing various aspects according to various embodiments are shown. It should be understood that, although a web-based environment is used for the purpose of explanation, various embodiments can be implemented using different environments appropriately. The environment includes an electronic client device 1002, which may include any appropriate device operable to send and / or receive requests, messages or information through an appropriate network 1004, and in some embodiments, the information is transmitted back to the user of the device. Examples of such client devices include personal computers, cell phones, handheld messaging devices, laptop computers, tablet computers, set-top boxes, personal data assistants, embedded computer systems, e-book readers, etc. The network may include any suitable network, including intranets, the Internet, cellular networks, local area networks, satellite networks or any other such networks and / or combinations thereof. The components used for such a system may depend at least in part on the type of the selected network and / or environment. The protocols and components used to communicate through such a network are well known, and will not be discussed in detail herein. Communication through a network may be implemented through wired or wireless connections and combinations thereof. In this example, the network includes the Internet, as the environment includes a web server 1006 for receiving requests and providing content in response to the requests, but for other networks, alternative devices serving similar purposes may be used, as will be apparent to one of ordinary skill in the art.

[0072] The illustrative environment includes at least one application server 1008 and a data storage area 1010. It should be understood that there may be several application servers, layers or other elements, processes or components that can be linked or otherwise configured, which can interact to perform tasks, such as obtaining data from an appropriate data storage area. As used herein, a server can be implemented in various ways, such as a hardware device or a virtual computer system. In some contexts, a server may refer to a programming module being executed on a computer system. As used herein, unless otherwise noted or clearly known from the context, the term "data storage area" refers to any device or device combination capable of storing, accessing and retrieving data, which may include any combination and any number of data servers, databases, data storage devices and data storage media in any standard, distributed, virtual or clustered environments. The application server may include any appropriate hardware, software and firmware, which may be integrated with the data storage area and process some or all data access and business logic of the application depending on the needs of various aspects of one or more applications of the execution client device. The application server can provide access control services that cooperate with the data storage area, and can generate content that can be provided to the user, including but not limited to text, pictures, audio, video and / or other content, which can be provided to the user by the web server in the form of hypertext markup language ("HTML"), extensible markup language ("XML"), JavaScript, cascading style sheets ("CSS"), or another suitable client-side structured language. The content transmitted to the client device can be processed by the client device to provide content in one or more forms, including but not limited to forms that can be perceived by the user through hearing, vision and / or through other senses (including touch, taste and / or smell). The processing of all requests and responses and the delivery of content between the client device 1002 and the application server 1008 can be handled by the web server using PHP: in this example, a hypertext preprocessor ("PHP"), Python, Ruby, Perl, Java, HTML, XML, or another suitable server-side structured language. It should be understood that the web server and application server are not necessary and are merely exemplary components, because the structured code discussed herein can be executed on any suitable device or host as discussed elsewhere herein. Furthermore, unless the context clearly dictates otherwise, operations described herein as being performed by a single device may be collectively performed by multiple devices, which may form a distributed and / or virtual system.

[0073] The data storage area 1010 may include several separate data tables, databases, data files, dynamic data storage schemes, and / or other data storage mechanisms and media for storing data related to specific aspects of the present disclosure. For example, the data storage area shown may include mechanisms for storing production data 1012 and user information 1016, which can be used to provide content for the production side. The data storage area is also shown as including a mechanism for storing log data 1014, which can be used for reporting, analysis, or other such purposes. It should be understood that there may be many other aspects that may need to be stored in the data storage area, such as page image information and access rights information, which may be stored in any of the mechanisms listed above or in additional mechanisms stored in the data storage area 1010 as appropriate. The data storage area 1010 can be operated by logic associated therewith so as to receive instructions from the application server 1008 and obtain, update, or otherwise process data in response to the instructions. The application server 1008 can provide static data, dynamic data, or a combination of static data and dynamic data in response to the received instructions. Dynamic data (such as data used in web logs (blogs), shopping applications, news services, and other such applications) can be generated by a server-side structured language as described herein, or can be provided by a content management system ("CMS") operating on an application server or under its control. In one example, a user can submit a search request for a certain type of item through a device operated by the user. In this case, the data storage area may access user information to verify the identity of the user, and can access directory details to obtain information about the type of item. Subsequently, the information can be returned to the user, such as in the form of a list of results on a web page, which the user can view through a browser on the user device 1002. Information about a specific item of interest can be viewed in a dedicated page or window of the browser. However, it should be noted that the embodiments of the present disclosure are not necessarily limited to the content of a web page, but can be more generally applicable to processing basic requests, where the request is not necessarily a request for content.

[0074] Each server will typically include an operating system that provides executable program instructions for basic management and operation of the server, and will typically include a computer-readable storage medium (e.g., hard disk, random access memory, read-only memory, etc.) that stores instructions that, when executed by the server's processor, allow the server to perform its intended functions. Suitable implementations of the server's operating system and basic functionality are known or commercially available and are readily implemented by one of ordinary skill in the art, particularly in light of the disclosure herein.

[0075] In one embodiment, the environment is a distributed and / or virtual computing environment utilizing multiple computer systems and components interconnected by communication links, using one or more computer networks or direct connections. However, it should be appreciated by those of ordinary skill in the art that such a system may be used in a variety of environments having more than Fig.10 The system may operate equally well with fewer or more components than shown. Fig.10 The depiction of system 1000 in FIG. 1 should be regarded as illustrative in nature and not limiting the scope of the present disclosure.

[0076] Various embodiments may also be implemented in a variety of operating environments, which may include one or more user computers, computing devices, or processing devices that can be used to operate any one of a plurality of applications in some cases. A user or client device may include any one of many general-purpose personal computers, such as a desktop, laptop, or tablet computer running a standard operating system, and cellular, wireless, and handheld devices running mobile software and capable of supporting a plurality of networks and messaging protocols. Such a system may also include many workstations running any one of a plurality of commercially available operating systems and other known applications, for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating over a network. These devices may also include virtual devices, such as virtual machines, hypervisors, and other virtual devices capable of communicating over a network.

[0077] Various embodiments of the present disclosure utilize at least one network that may be familiar to those skilled in the art to support communications using any of a variety of commercially available protocols, such as Transmission Control Protocol / Internet Protocol ("TCP / IP"), User Datagram Protocol ("UDP"), protocols operating in various layers of the Open Systems Interconnection ("OSI") model, File Transfer Protocol ("FTP"), Universal Plug and Play ("UPnP"), Network File System ("NFS"), Common Internet File System ("CIFS"), and AppleTalk. The network can be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, a satellite network, and any combination of the above networks.

[0078] In embodiments utilizing a web server, the web server may run any of a variety of server or middle-tier applications, including a Hypertext Transfer Protocol ("HTTP") server, an FTP server, a Common Gateway Interface ("CGI") server, a data server, a Java server, an Apache server, and a business application server. The server may also be capable of executing programs or scripts in response to requests from user devices, such as by executing a program that may be implemented in any programming language (such as C, C# or C++) or any scripting language (such as Ruby, PHP, Perl, Python or TCL) and their combinations. The server may also include a database server, including but not limited to, and Commercially available database servers, as well as open source servers such as MySQL, Postgres, SQLite, MongoDB, and any other server capable of storing, retrieving, and accessing structured or unstructured data. The database server may include a table-based server, a file-based server, an unstructured server, a relational server, a non-relational server, or a combination of these and / or other database servers.

[0079] The environment may include various data storage areas and other memories and storage media as discussed above. These may reside in various locations, such as on a storage medium that is local to (and / or resides in) one or more computers, or away from any or all computers in the network. In a specific set of embodiments, information may reside in a storage area network ("SAN") familiar to those skilled in the art. Similarly, any necessary files for performing functions attributed to a computer, server, or other network device may be stored locally and / or remotely, where appropriate. In the case where the system includes a computerized device, each such device may include hardware elements that may be electrically coupled via a bus, including, for example, at least one central processing unit ("CPU" or "processor"), at least one input device (e.g., a mouse, keyboard, controller, touch screen, or keypad), and at least one output device (e.g., a display device, printer, or speaker). Such a system may also include one or more storage devices such as disk drives, optical storage devices, and solid-state storage devices such as random access memory ("RAM") or read-only memory ("ROM"), as well as removable media devices, memory cards, flash memory cards, etc.

[0080] Such devices may also include a computer-readable storage medium reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and a working memory, as described above. The computer-readable storage medium reader may be connected to or configured to receive a computer-readable storage medium representing a remote, local, fixed and / or removable storage device and a storage medium for temporarily and / or more permanently containing, storing, sending and retrieving computer-readable information. The system and various devices will also typically include a number of software applications, modules, services, or other elements located within at least one working memory device, including operating systems and applications such as client applications or web browsers. It should be understood that alternative embodiments may have many variations different from those described above. For example, custom hardware may also be used and / or specific elements may be implemented in hardware, software (including portable software, such as applets), or both. In addition, connections to other computing devices (such as network input / output devices) may be employed.

[0081] Storage media and computer-readable media for containing code or code portions may include any suitable media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information, such as computer-readable instructions, data structures, program modules or other data, including RAM, ROM, electrically erasable programmable read-only memory ("EEPROM"), flash memory or other memory technology, compact disk read-only memory ("CD-ROM"), digital versatile disk (DVD) or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other medium that can be used to store the desired information and can be accessed by the system device. Based on the disclosure and teachings provided herein, those of ordinary skill in the art will understand other ways and / or methods to implement various embodiments.

[0082] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the claims.

[0083] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that it is not intended to limit the invention to the specific form or forms disclosed, but rather, the invention is intended to cover all modifications, alternative constructions, and equivalents that fall within the spirit and scope of the invention, as defined in the appended claims.

[0084] The use of the terms "a" and "an" and "the" and similar indicators in the context of describing the disclosed embodiments (particularly in the context of the appended claims) should be interpreted as covering the singular and the plural, unless otherwise specified herein or clearly contradicted by the context. The terms "include", "have", "include" and "contain" are all interpreted as open terms (i.e., meaning "including but not limited to") unless otherwise specified. The term "connected" should be interpreted as partially or entirely included, attached to or joined together when unmodified and referring to a physical connection, even if there are some objects in between. Unless otherwise specified herein, the description of the range of values ​​is used herein only as a shorthand method of individually referring to each individual value falling within the range, and each individual numerical value is incorporated into this specification as if each individual numerical value was listed separately herein. The use of the term "group" (e.g., "a group of items") or "subset" should be interpreted as a non-empty set including one or more members unless otherwise specified or contradicted by the context. Furthermore, unless otherwise noted or contradicted by context, the term "subset" of a corresponding set does not necessarily mean a proper subset of the corresponding set, but a subset and a corresponding set may be equivalent.

[0085] Unless specifically stated otherwise or otherwise contradicted by context, connective language, such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C," together with the context of use, is understood to be generally used to present that an item, term, etc. can be A or B or C, or any non-empty subset of the set of A and B and C. For example, in the illustrative example of a set with three members, the connective phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such connective language is generally not intended to imply that certain embodiments require that at least one of A, at least one of B, and at least one of C each be present.

[0086] The operations of the processes described herein may be performed in any suitable order, unless otherwise specified herein or otherwise clearly contradictory in context. The processes described herein (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executed together on one or more processors, implemented by hardware or a combination thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

[0087] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate embodiments of the present invention and does not limit the scope of the present invention unless otherwise specified. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of the present invention.

[0088] Embodiments of the present disclosure are described herein, including the best mode known to the inventor for carrying out the present invention. After reading the foregoing description, variations of these embodiments may become apparent to those of ordinary skill in the art. The inventor expects those skilled in the art to use such variations where appropriate, and the inventor wishes that the embodiments of the present disclosure be practiced in a manner different from that specifically described herein. Therefore, the scope of the present disclosure includes all modifications and equivalents of the subject matter described in the appended claims as permitted by applicable law. In addition, unless otherwise specified herein or otherwise the context is clearly contradictory, any combination of the above-mentioned elements of all possible variations is included within the scope of the present disclosure.

[0089] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0090] Embodiments of the present disclosure may be described in terms of the following:

[0091] 1. A computer-implemented method comprising:

[0092] Under the control of one or more computer systems configured with executable instructions,

[0093] Issuing a first digital certificate to an entity, the first digital certificate specifying a critical extension, the critical extension enabling authentication of the entity to a certificate authority service, the first digital certificate:

[0094] specifying at least one subject field specific to the entity;

[0095] specifying a first public key;

[0096] corresponds to a first private key; and

[0097] specifying a first validity period of the first digital certificate;

[0098] receiving a request for issuing a second digital certificate from the entity, the request comprising the first digital certificate and a digital signature, the second digital certificate being usable for authenticating a server of the entity;

[0099] determining whether to issue the second digital certificate based at least in part on a validity period specified in the first digital certificate and the first public key; and

[0100] The second digital certificate is issued to have the at least one subject field and a second validity period that is shorter than the first validity period.

[0101] 2. The computer-implemented method of clause 1, wherein the critical extension capable of verifying the entity to a certificate authority service further prevents the first digital certificate from being used to authenticate the server of the entity.

[0102] 3. A computer-implemented method as described in clause 1 or 2, wherein the critical extension specifies a date of verification of the entity by the certificate authority service before issuing the first digital certificate, one or more criteria used by the certificate authority service to verify the entity, and an identifier corresponding to the entity.

[0103] 4. The computer-implemented method of any of clauses 1-3, wherein the second digital certificate further comprises a second public key different from the first public key specified in the first digital certificate.

[0104] 5. A system comprising at least one computing device configured to implement one or more services, wherein the one or more services are configured to:

[0105] A first digital certificate is issued to an entity, wherein the first digital certificate:

[0106] enabling authentication of the entity to the one or more services; and

[0107] specifying at least one subject field specific to the entity;

[0108] receiving a request from the entity to issue a second digital certificate, the request including the first digital certificate, and the second digital certificate can be used to authenticate the entity;

[0109] determining whether to issue the second digital certificate based at least in part on information specified within the first digital certificate; and

[0110] The second digital certificate is issued to have information based at least in part on the information specified within the first digital certificate and to have the at least one subject field specific to the entity.

[0111] 6. A system as described in clause 5, wherein:

[0112] The request to issue the second digital certificate includes a digital signature; and

[0113] The one or more services are also configured to verify the digital signature using a public key specified in the first digital certificate.

[0114] 7. A system as described in clause 5 or 6, wherein:

[0115] The information specified in the first digital certificate includes a validity period of the first digital certificate; and

[0116] The one or more services are also configured to utilize the validity period of the first digital certificate to verify that the first digital certificate has not expired and can be used to issue the second digital certificate.

[0117] 8. The system of clause 7, wherein the information of the second digital certificate specifies a validity period that is shorter than the validity period of the first digital certificate.

[0118] 9. The system of any of clauses 5-8, wherein the information included in the second digital certificate is also based at least in part on a validity period specified by the entity in the request to issue the second digital certificate.

[0119] 10. The system of any of clauses 5-9, wherein the second digital certificate is further issued to have one or more additional subject fields not included in the first digital certificate.

[0120] 11. The system of any of clauses 5-10, wherein the first digital certificate specifies a critical extension that indicates that the first digital certificate should not be used for authentication.

[0121] 12. A system as described in clause 11, wherein the critical extension includes a date of verification of the entity by the one or more services before issuing the first digital certificate, one or more criteria used by the one or more services to verify the entity, and an identifier corresponding to the entity.

[0122] 13. A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by one or more processors of a computer system, cause the computer system to at least:

[0123] receiving, from an entity, a request for issuance of a digital certificate that can be used to authenticate the entity, the request including a previously issued digital certificate that can be used to verify the entity to a certificate authority service and specifying at least one subject field that is specific to the entity;

[0124] determining whether to issue the digital certificate based at least in part on information specified within the previously issued digital certificate; and

[0125] The digital certificate is issued to have information based at least in part on the information specified within the previously issued digital certificate and to have the at least one subject field specific to the entity.

[0126] 14. A non-transitory computer-readable storage medium as described in clause 13, wherein the instructions further include instructions that, when executed by the one or more processors of the computer system, cause the computer system to obtain an expected validity period defined by the entity within the request to determine whether to issue the second digital certificate.

[0127] 15. The non-transitory computer-readable storage medium of clause 13 or 14, wherein the previously issued digital certificate is issued by the computer system in response to a request from the entity to issue the previously issued digital certificate.

[0128] 16. The non-transitory computer-readable storage medium of any of clauses 13-15, wherein:

[0129] The previously issued digital certificate also specifies a public key corresponding to the private key;

[0130] The information specified in the previously issued digital certificate includes a validity period of the previously issued digital certificate; and

[0131] The instructions also include instructions that, when executed by the one or more processors, cause the computer system to utilize the validity period to verify that the previously issued digital certificate has not expired and can be used to issue the digital certificate.

[0132] 17. The non-transitory computer-readable storage medium of clause 16, wherein the information included within the issued digital certificate specifies a validity period that is shorter than the validity period of the previously issued digital certificate.

[0133] 18. The non-transitory computer-readable storage medium of clause 16 or 17, wherein the request to issue the digital certificate is digitally signed by the entity using the private key corresponding to the public key.

[0134] 19. The non-transitory computer-readable storage medium of any of clauses 13-18, wherein the previously issued digital certificate specifies a critical extension that includes one or more criteria for authenticating the entity.

[0135] 20. The non-transitory computer-readable storage medium of clause 19, wherein the critical extension further indicates that the previously issued digital certificate should not be used for authentication.

Claims

1. A computer-implemented method for issuing a digital certificate, comprising: receiving, from an entity, a request for issuance of a short-lived second digital certificate that can be used to authenticate a server of the entity, the request including a long-lived first digital certificate that cannot be used to authenticate a server of the entity; determining whether to issue the second digital certificate based at least in part on a first validity period specified in the first digital certificate; as well as The second digital certificate is issued, and the second digital certificate has a second validity period specified in the second digital certificate, wherein the second validity period is shorter than the first validity period, and the expiration date of the second validity period coincides with the expiration date of the first validity period or is earlier than the expiration date of the first validity period.

2. The computer-implemented method of claim 1, wherein: The request includes a digital signature; as well as The method also includes verifying the digital signature using a first public key specified by the first digital certificate.

3. The computer-implemented method of claim 1 or 2, further comprising: The first validity period is utilized to verify that the first digital certificate has not expired and can be used to issue the second digital certificate.

4. A computer-implemented method as described in claim 1 or 2, wherein the second digital certificate is issued with one or more subject fields not included in the first digital certificate.

5. A system for issuing a digital certificate, comprising: one or more processors, and a memory storing computer executable instructions that, when executed, cause the one or more processors to: receiving, from an entity, a request for issuance of a short-lived second digital certificate that can be used to authenticate a server of the entity, the request including a long-lived first digital certificate that cannot be used to authenticate a server of the entity; determining whether to issue the second digital certificate based at least in part on a first validity period specified in the first digital certificate; as well as The second digital certificate is issued to have a second validity period specified in the second digital certificate, the second validity period is shorter than the first validity period, and the expiration date of the second validity period coincides with the expiration date of the first validity period or is earlier than the expiration date of the first validity period.

6. The system of claim 5, wherein: The first digital certificate also specifies a critical extension that specifies: a date of verification of an entity prior to issuance of the first digital certificate, one or more criteria that can be used to verify the entity, and an identifier corresponding to the entity.

7. The system of claim 5 or 6, wherein: The second digital certificate includes one or more subject fields not specified in the first digital certificate.

8. The system of claim 5 or 6, wherein: The first digital certificate specifies a first public key corresponding to a first private key.

9. The system of claim 8, wherein: The request is digitally signed using the first private key corresponding to the first public key.

10. The system of claim 8, wherein: The second digital certificate includes a second public key that is different from the first public key specified in the first digital certificate.

11. The system of claim 5 or 6, wherein: The first digital certificate is an X.509 digital certificate.

12. A non-transitory computer-readable storage medium having computer-executable instructions stored thereon, the computer-executable instructions, as a result of being executed by one or more processors of a computer system, causing the computer system to at least perform the following operations: In response to a request to issue a short-term second digital certificate that can be used to authenticate a server of an entity, determining whether to issue the second digital certificate based at least in part on a first validity period specified in a long-term first digital certificate included in the request, wherein the first digital certificate is not usable to authenticate the server of the entity; and The second digital certificate is issued to have a second validity period specified in the second digital certificate, the second validity period is shorter than the first validity period, and the expiration date of the second validity period coincides with the expiration date of the first validity period or is earlier than the expiration date of the first validity period.

13. A non-transitory computer-readable storage medium as described in claim 12, wherein the first digital certificate also specifies a critical extension, which specifies: a date of verification of the entity before issuing the first digital certificate, one or more criteria that can be used to verify the entity, and an identifier corresponding to the entity.

14. The non-transitory computer-readable storage medium of claim 12 or 13, wherein: The second digital certificate includes one or more subject fields not specified in the first digital certificate.

15. The non-transitory computer-readable storage medium of claim 12 or 13, wherein: The computer-executable instructions further cause the computer system to obtain an expected second validity period defined by the entity within the request to determine whether to issue the second digital certificate.

Images