Custom rules for global certificate issuance

Abstract

Techniques are described for enabling users of a certificate management service to create certificate issuance policies that can be applied to certificate issuance requests and other certificate-related services on both public and private certificate authorities (CAs). According to the embodiments described herein, a certificate issuance policy includes one or more certificate issuance rules that will be applied to requests for certificate-related resources (e.g., public certificates, private certificates, etc.) associated with one or more specified user accounts or roles. The application of certificate issuance rules can be adjusted according to a specific request context (e.g., based on a user account or role associated with the request, the type of certificate requested, a subject name identified in the request, etc.), and a wide range of actions can be specified that will be performed on requests that match the rules (e.g., allowing or denying the request, modifying one or more parameters of the request, etc.).

Description

Technical Background

[0001] Asymmetric cryptographic systems use key pairs (including public and private keys) to encrypt and decrypt data. For example, public key infrastructure (PKI) uses public and private key pairs to facilitate secure electronic communications. A public key can be associated with a digital certificate that verifies the owner of a given public key. A digital certificate is created and signed by a public or private certificate authority that acts as a trusted third party. Various digital certificates can be used, for example, to create a secure connection over a network such as the Internet. For example, the secure hypertext transfer protocol (HTTPS) uses digital certificates to establish a secure connection using transport layer security (TLS). BRIEF DESCRIPTION OF THE DRAWINGS

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

[0003] Figure 1 is a diagram illustrating an environment for enabling a user to configure and use certificate issuance policies according to some embodiments.

[0004] Figure 2 is a diagram illustrating application of certificate issuance policies in response to requests for certificates from various users or resources according to some embodiments.

[0005] Figure 3 is a diagram illustrating dynamic configuration of certificate issuance policies according to some embodiments.

[0006] Figure 4 is a diagram illustrating the use of a custom certificate issuance pre-approval process according to some embodiments and the validation of the custom pre-approval process by a certificate management service according to a certificate issuance policy.

[0007] Figure 5 is a diagram illustrating the use of hooks into a custom certificate issuance approval process by a certificate management service in response to a certificate issuance request according to some embodiments.

[0008] Figure 6 is a flow chart illustrating the operation of a method for configuring a certificate issuance policy using a certificate management service and controlling certificate issuance requests using the configured certificate issuance policy according to some embodiments.

[0009] Figure 7 An example provider network environment is shown according to some embodiments.

[0010] Figure 8 is a block diagram of an example provider network that provides storage services and hardware virtualization services to customers according to some embodiments.

[0011] Fig. 9is a block diagram illustrating an example computer system that may be used in some embodiments. DETAILED DESCRIPTION

[0012] The present disclosure relates to methods, devices, systems, and non-transitory computer-readable storage media for enabling users of certificate management services to create certificate issuance policies that can be applied to certificate issuance requests and other certificate-related services on both public and private certificate authorities (CAs). According to the embodiments described herein, a certificate issuance policy includes one or more certificate issuance rules that will be applied to requests for certificate-related resources (e.g., public certificates, private certificates, etc.) associated with one or more specified user accounts or roles. The application of certificate issuance rules can be adjusted according to a specific request context (e.g., based on a user account or role associated with the request, the type of certificate requested, the subject name identified in the request, etc.), and a wide range of actions that will be performed on requests that match the rules can be specified (e.g., allowing or denying the request, modifying one or more parameters of the request, etc.).

[0013] Today, users typically use certificate templates or CA-specific rules to control the issuance of certificates within an organization. For example, a template defines the attributes and ordering of attributes to be included in a digital certificate, such as a domain name, an issue date, an expiration date, a public key, a digital signature to be provided by the CA, etc. Under CA-specific rules, users apply the rules to a specific issuing CA, but users cannot deviate from these rules. However, many CA administrators and other users expect to be able to manage the issuance of certificates from a range of CAs and control the details of issuing certificates based on the context of the request (such as, for example, the user or role requesting the certificate, the type of certificate requested, etc.).

[0014] To address these challenges, this document describes, among other things, technologies for providing a certificate issuance rules engine that enables users to configure certificate issuance policies and associated rules that can be applied to both public and private CAs and to specific users or user groups. Examples of various types of rules that can be configured as part of a certificate issuance policy include, but are not limited to: rules that define what domains certificates can be issued for, whether domain wildcards can be used, certificate validity periods, cryptographic key types and lengths, certificate marking conventions, one or more fields that a certificate issuance rule will complete, the rate at which user accounts or roles request certificates, the amount of certificates requested by user accounts or roles, or the time of day, etc. Among other benefits, the described certificate issuance rules engine can effectively manage certificate issuance on a user organization, thereby providing better security for services protected by the ultimately issued certificates.

[0015] Figure 11 is a diagram illustrating an environment for enabling users to configure certificate issuance policy resources according to some embodiments. A provider network 100 (or "cloud" provider network) provides users with the ability to use one or more of various types of computing-related resources, such as computing resources (e.g., executing virtual machine (VM) instances and / or containers, executing batch jobs, executing code without pre-configuring servers), data / storage resources (e.g., object storage, block-level storage, data archive storage, databases and database tables, etc.), network-related resources (e.g., configuring virtual networks (including multiple groups of computing resources), content delivery networks (CDNs), domain name services (DNS)), application resources (e.g., databases, application build / deployment services), access policies or roles, identity policies or roles, machine images, routers, and other data processing resources, etc. These and other computing resources may be provided as services, such as hardware virtualization services that can execute computing instances, storage services that can store data objects, etc. Users (or "customers") of the provider network 100 may use one or more user accounts associated with a customer account, but these items may be used somewhat interchangeably depending on the usage scenario. A user (e.g., using an electronic device 102) may interact with the provider network 100 across one or more intermediate networks 104 (e.g., the Internet) via one or more interfaces (such as by using an application programming interface (API) call), via a console implemented as a website or application, and the like. An API refers to an interface and / or communication protocol between a client and a server such that if a client issues a request in a predefined format, the client should receive a response in a specific format or initiate a defined action. In a cloud provider network scenario, an API provides a gateway for clients to access cloud infrastructure by allowing clients to obtain data from the cloud provider network or cause actions within the cloud provider network, thereby enabling the development of applications that interact with resources and services hosted in the cloud provider network. The API may also enable different services of the cloud provider network to exchange data with each other. The interface may be part of or act as a front end to a control plane of the provider network 100, which includes "backend" services that support and implement services that can be provided more directly to clients.

[0016] For example, a cloud provider network (or just "the cloud") generally refers to a large pool of accessible virtualized computing resources (such as computing, storage and networking resources, applications, and services). A cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adjust to variable loads. Thus, cloud computing can be considered to be both applications delivered as services via publicly accessible networks (e.g., the Internet, cellular communication networks) and the hardware and software in the cloud provider's data centers that provide these services.

[0017] A cloud provider network may be formed into multiple regions, where a region is a geographic area in which a cloud provider clusters data centers. Each region includes multiple (e.g., two or more) availability zones (AZs) connected to each other via a private high-speed network (e.g., a fiber optic communication connection). An AZ (also referred to as a "region") provides an isolated fault domain that includes one or more data center facilities that have separate power, separate networking, and separate cooling relative to a data center facility in another AZ. A data center refers to a physical building or enclosure that houses and provides power and cooling for the servers of a cloud provider network. Preferably, AZs within a region are located far enough apart from each other so that a natural disaster (or other event that causes a failure) does not affect more than one AZ at the same time or take more than one AZ offline.

[0018] Users can connect to AZs of a cloud provider network via publicly accessible networks (e.g., the Internet, cellular communication networks), such as through a transit center (TC). TCs are the main backbone locations that link users to the cloud provider network and can be co-located with other network provider facilities (e.g., Internet service providers (ISPs), telecommunications providers) and securely connected to AZs (e.g., via VPNs or direct connections). Two or more TCs can be operated per region for redundancy. Regions are connected to a global network that includes a private networking infrastructure (e.g., a fiber connection controlled by a cloud provider) that connects each region to at least one other region. The cloud provider network can deliver content from points of presence (or "POPs") located outside of these regions but networked to these regions through edge locations and regional edge cache servers. This partitioning and geographic distribution of computing hardware enables the cloud provider network to provide users with low-latency resource access with a high degree of fault tolerance and stability on a global scale.

[0019] In general, the services and operations of the provider network can be broadly divided into two categories: control plane operations carried on the logical control plane and data plane operations carried on the logical data plane. The data plane represents the movement of user data through the distributed computing system, while the control plane represents the movement of control signals through the distributed computing system. The control plane typically includes one or more control plane components distributed across one or more control servers and implemented by them. Control plane services typically include management operations, such as system configuration and management (e.g., resource placement, hardware capacity management, diagnostic monitoring, system status information). The data plane includes user resources (e.g., computing instances, containers, block storage volumes, databases, file storage) implemented on the provider network. Data plane services typically include non-management operations, such as transmitting user data to user resources and transmitting user data from user resources. Control plane components are typically implemented on a set of servers separate from data plane servers, and control plane services and data plane services can be sent over separate / different networks.

[0020] To provide these and other computing resource services, the provider network 100 typically relies on virtualization technology. For example, virtualization technology can enable users to control or use computing resources (e.g., "computing instances," such as VMs using a guest operating system (O / S) that operates using a hypervisor that may or may not further operate on top of an underlying host O / S; containers that may or may not operate in a VM; computing instances that can execute on "bare metal" hardware without an underlying hypervisor), where a single electronic device can be used to implement one or more computing resources. Thus, users can directly use computing resources hosted by the provider network (e.g., provided by a hardware virtualization service) to perform various computing tasks. Additionally or alternatively, users can indirectly use computing resources by submitting code to be executed by the provider network (e.g., via an on-demand code execution service), which in turn uses one or more computing resources to execute the code, typically without the user having any control or knowledge of the underlying computing instances involved.

[0021] For example, in various embodiments, a "serverless" function may include code that can be executed on demand provided by a user or other entity (such as the provider network itself). Serverless functions may be maintained within the provider network through an on-demand code execution service and may be associated with a specific user or account or may be generally accessible to multiple users / accounts. Serverless functions may be associated with a uniform resource locator (URL), uniform resource identifier (URI), or other reference that can be used to call serverless functions. Serverless functions may be executed by computing resources such as virtual machines, containers, etc. when triggered or called. In some embodiments, serverless functions may be called by application programming interface (API) calls or specially formatted hypertext transfer protocol (HTTP) request messages. Therefore, users may define serverless functions that can be executed on demand without requiring users to maintain dedicated infrastructure to execute serverless functions. Alternatively, resources maintained by the provider network 100 may be used to execute serverless functions on demand. In some embodiments, these resources may be maintained in a "ready" state (e.g., with a pre-initialized runtime environment configured to execute serverless functions), thereby allowing serverless functions to be executed almost in real time.

[0022] As discussed, the embodiment includes a certificate management service 106 (or more generally one or more PKI services of any type), which a user can use to create and manage certificate-related resources. The certificate management service 106 provides many features related to creating, storing and updating public and private certificates (e.g., SSL / TLS X.509 certificates) and keys for protecting the user's websites and applications. The certificates created by the certificate management service 106 can protect a single domain name, multiple specific domain names, wildcard domains, or a combination of these. For example, a wildcard certificate can protect an unlimited number of subdomains. Users can also export certificates signed by a private certificate authority (e.g., private CA 108) managed by the certificate management service 106 to use anywhere in the user's internal PKI.

[0023] As indicated above, SSL / TLS certificates allow web browsers and other applications to identify websites and establish encrypted network connections with them using the SSL / TLS protocol. Certificates are used in a cryptographic system known as a public key infrastructure (PKI). PKI provides a way for one party to confirm the identity of another party using a certificate (if both parties trust a third party), known as a certificate authority.

[0024] In some embodiments, the certificate management service 106 provides at least two different options for users who wish to deploy managed certificate-related resources. For example, the certificate management service 106 may provide a public certificate management service 110 for users who need a secure web presence using TLS. In some embodiments, the certificate-related resources created by the certificate management service 106 may be deployed to user resources via other services provided by the cloud provider (e.g., via a load balancing service, a content delivery network (CDN) service, an API gateway service, or other services where the user may have deployed endpoint resources), or otherwise returned to the requesting user. The certificate management service 106 may also provide features that enable automatic renewal of expired certificates.

[0025] In some embodiments, the certificate management service 106 also provides a private certificate authority service 112. For example, the private certificate authority service can be used for private use within an organization. When establishing a secure encrypted communication channel, each endpoint uses certificates and cryptographic techniques to prove its identity to another endpoint. Internal API endpoints, web servers, VPN users, IoT devices, and many other applications use private certificates to establish the encrypted communication channels required for their secure operation. Users can create their own certificate authority (CA) hierarchy and use it to issue certificates to authenticate users, computers, applications, services, and other devices.

[0026] In some embodiments, the certificate-related resources managed by the certificate management service 106 are associated with a number of characteristics. For example, in some embodiments, the certificates (e.g., certificate 114) issued by the certificate management service 106 are domain-validated. The subject field of the certificate issued by the certificate management service 106 identifies the domain name, so when a user requests a certificate, the user verifies ownership or control of all domains specified in the request. Ownership or control of a specified domain name can be verified using email, DNS, or other methods supported by the certificate management service 106.

[0027] In some embodiments, certificates issued by the certificate management service 106 may be associated with a defined validity period (e.g., 13 months or any other period of time). The certificate management service 106 may also manage the process of renewing certificates and pre-configuring certificates after the certificates are renewed. In some embodiments, certificates issued by the certificate management service 106 are trusted by mainstream browsers (Google Chrome, Microsoft Internet Explorer and Microsoft Edge, Mozilla Firefox, etc.) and operating systems.

[0028] In some embodiments, each certificate management service 106 certificate includes at least one fully qualified domain name (FQDN), and the user can add additional names as needed. For example, a user creating a certificate for www.example.com can also add the name www.example.net (if the user enters the site using either name). The certificate management service 106 also allows users to use an asterisk (*) in the domain name to create a certificate containing a wildcard name, which can protect several sites in the same domain. For example, *.example.com protects www.example.com and images.example.com. In some embodiments, the certificate also specifies an algorithm and a key length. The certificate management service 106 can, for example, support several public key algorithms, including but not limited to: 2048-bit RSA, 4096-bit RSA, 256-bit Elliptic Prime Curve, 384-bit Elliptic Prime Curve, etc. The certificate can be associated with other parameters as described herein.

[0029] As indicated, users can typically use certificate templates (e.g., template 116) or CA-specific rules to control some aspects of certificate issuance. For example, a template defines the attributes and attribute ordering that will be included in a digital certificate, such as a domain name, an issue date, an expiration date, a public key, a digital signature to be provided by the CA, etc. Under CA-specific rules, users apply the rules to a specific issuing CA, but users cannot deviate from these rules. However, many CA administrators and other users expect to be able to issue certificates from a range of CAs and control the details of certificate extension values ​​created at the user level. Figure 1 The numbered circles in illustrate an example process, which includes: a user generates a request 124 to create a certificate issuance policy; the certificate management service 106 processes the request and creates a certificate issuance policy resource (e.g., one or more of the certificate issuance policy resources 118A, 118B, ..., 118N) to be applied by the certificate issuance rules engine 120 as part of the global registry service 122 provided by the certificate management service 106; the user or resource generates a certificate issuance request 126; the certificate issuance rules engine 120 (which is separate from the multiple CA services with which the rules engine is integrated) applies one or more certificate issuance rules applicable to the request, which may include modifying the request (e.g., setting certain extension values ​​or modifying other parts of the request); and the CA (e.g., the public CA service 110) generates and returns the requested certificate 114.

[0030] At circle "1", the customer uses an electronic device 102 to send a request to the certificate management service 106 to create a certificate issuance policy. For example, the user may be responsible for or otherwise expect to configure a set of certificate issuance rules to apply to a set of users and / or roles (e.g., users or roles defined as part of an organization). As indicated, the user is able to define a certificate issuance policy that can be applied globally to a series of users, on different CAs, and on different certificate types, thereby significantly reducing the burden of managing certificate issuance within the organization. In some embodiments, the user can use the API provided by the certificate management service 106, a web-based console, a CLI, or other interfaces to create and configure a certificate issuance policy. For example, a user who expects to configure a certificate issuance policy can log in to a web-based console provided by the certificate management service 106, and provide input indicating that the user expects to configure a set of new rules. Then, the web-based console can provide a set of instructive interfaces and interface elements for requesting input for defining a policy. As shown, the certificate issuance request 126 can alternatively originate from a customer service 128, a control plane of another provider network 100 service, or any other service or resource requesting the issuance of a certificate.

[0031] In some embodiments, the definition of a certificate issuance policy may include the user or set of users and / or roles to which the policy (or individual rules comprising the policy) will be applied, as well as other information. In some embodiments, the selected users or roles to which the policy or rules will be applied may be selected based on a selection of a user account, role, user group, organization, or other user or role grouping, where such user accounts, roles, user groups, and organizations may be defined using identity and access management services provided by cloud provider network 100 or using an identity and access management system controlled by the organization configuring the policy.

[0032] In some embodiments, the definition of a certificate issuance rule may include a rule statement. As an example, a rule statement may specify one or more domains, and further specify whether to grant or deny the issuance of certificates for the specified domains to one or more users or roles to which the rule applies. As another example, a rule statement may specify whether a user is allowed to use wildcards as part of a domain specified in a request. As yet another example, a rule statement may specify whether it applies to public certificates, private certificates, or both. A rule statement may also specify requirements for other parameters of certain certificate issuance requests, such as key type, key length, validity period, verification type (e.g., DNS or email verification), etc. Other example rules include restrictions on the number of certificates that a user can issue, or the rate at which certificates are requested. Rule statements configured as part of a certificate issuance policy may be configured incrementally and updated over time, as described in more detail herein.

[0033] As an illustrative example, a CA administrator might configure rules that will apply to requests associated with User A when requesting a public or private certificate. In this example, the rules might specify that User A can only issue certificates for the subject name "*.usera.example.com" and that the certificate must be valid for no more than 30 days. As another example, a rule might be applied to a user's entire development team, requiring that any certificates issued by users on the development team include a specific tag. As yet another example, a rule might be configured to apply to all users within an organization, requiring that any public certificate issuance request must use a specific domain validation method. Rules can be configured to apply only to one or more specified CAs, can specify templates to be used for requests that match the rule, and many other possibilities.

[0034] At circle "2", the certificate management service 106 processes the request. In some embodiments, the certificate management service 106 creates a certificate issuance policy resource or adds a rule to an existing certificate issuance policy resource (e.g., one of the certificate issuance policy resources 118A, 118B, ..., 118N). The certificate issuance policy resource may be stored, for example, as a text document or other data structure containing a structured representation (e.g., in JSON format) of the rules contained in the policy. For example, each policy and / or rule may be specified and stored in a structured representation that identifies one or more users or roles to which the policy or rule applies, request context information indicating the type of request to which the policy or rule applies, and action information indicating the type of action that the certificate issuance rules engine 120 will perform in response to identifying a request that matches the policy or rule.

[0035] At circle "3", a certificate issuance request 126 is generated and sent to the certificate management service 106. In some embodiments, the request is associated with a request context, which includes at least an identifier of a user account or role associated with the request, and a plurality of parameters related to the requested certificate (e.g., subject name, certificate type, validity period, key type, etc.). The request context may also include a variety of other information, including, but not limited to: an IP address associated with the request, a time when the request was generated, a number of requests from the same user account or role in the previous time period, a principal type associated with the request (e.g., user or role), etc.

[0036] At circle "4", the certificate issuance rules engine 120 receives the request and determines whether one or more certificate issuance policies apply to the request. For example, the certificate issuance rules engine 120 may determine whether any policies apply to the user account or role associated with the request, and further determine whether the certificate issuance rules contained in the policies match any request context (e.g., if the rules apply to a certificate issuance request for a public certificate associated with a specified domain name, the rules engine 120 may determine whether the request is for a public certificate for the specified domain name). As shown, the certificate issuance rules engine 120 is separate from the multiple CA services with which the rules engine is integrated (e.g., the public CA service 110 and the private CA service 112, as well as possible other services).

[0037] exist Figure 1 In the example of , the certificate issuance rules engine 120 determines that at least one policy and associated rule apply to the certificate issuance request 126. Thus, in this example, at circle "5", the certificate issuance rules engine 120 modifies at least one of a plurality of parameters associated with the requested certificate to obtain a modified request to generate a certificate. For example, if the request 126 is for a public certificate with a validity period of six months, and the rules applicable to the request limit public certificates requested by a particular user to a maximum of three months, the certificate issuance request may be modified to change the requested validity period (e.g., perhaps by modifying a certificate signing request (CSR) associated with the request). As another example, the certificate issuance rules engine 120 may modify the key type or any other parameter associated with the request based on one or more applicable rules. Figure 1 The example illustrates modification of a certificate issuance request by the certificate issuance rules engine 120; in other examples described herein, a request may also be denied or otherwise processed differently based on one or more applicable rules.

[0038] At circle "6", public CA service 110 generates and returns certificate 114 based on the modified request. In some embodiments, the certificate is returned to requesting device 102, or in other examples, it can be automatically installed in one or more integrated services of provider network 100 based on user request. Figure 1 The illustrated example illustrates the intervention of the certificate issuance rules engine 120 within the provider network 100 between requesting devices and various types of CAs, but in other examples, the certificate issuance rules engine may also be used to control certificate issuance requests or other certificate-related services involving external CAs.

[0039] Figure 1The illustrated examples involve using the certificate issuance rules engine 120 and configured certificate issuance policies to control the issuance of certificates on, for example, public CA services, private CA services, etc. In other examples, the certificate issuance rules engine 120 may be used more broadly to manage the creation and restrict the use of private CAs within a user organization, document signing solutions, and any other type of certificate-related services that may exist within an organization's PKI.

[0040] Figure 2 is a diagram illustrating the application of a certificate issuance policy resource to multiple users within an organization and optionally the hierarchical application of multiple certificate issuance policy resources to the users according to some embodiments. Figure 2 As shown, for example, a set of users 200A, 200B, ... 200N that are part of an organization 216 may be grouped into one or more user groups 202. In addition, a CA administrator or other user has configured an organization policy 204 (e.g., including rules that will apply to all users in the organization 216), one or more user group policies 206A, ..., 206N, and one or more user policies 208A, ..., 208N.

[0041] In this example, at circle "1A", user 200A uses an electronic device to generate a certificate issuance request 210, which requests the issuance of a public certificate 212 using the public CA service 110. At circle "2A", the certificate issuance rules engine 120A determines whether one or more policies and / or rules apply to the request based at least in part on the request context (e.g., the identity of user 200A, the role used for the request, parameters related to the requested certificate, etc.). In this example, in addition to the user policy 208A specific to user 200A, the organizational policy 204 may also apply to the request, with one rule indicating that the request is granted and a second rule indicating that a specific domain verification method will be used. Therefore, the certificate issuance rules engine 120 can generate a modified request to the public CA service 110, thereby achieving the issuance of the certificate 212 at circle "3A".

[0042] Similarly, at circle "1B", a different user 200N generates a second certificate issuance request 210, which may include different request parameters. For example, the second certificate issuance request 210 may request a certificate from the private CA 108. Figure 2In the example of , the certificate issuance rules engine 120 determines that at least one policy and / or rule applies to the second request and determines that the request is not permitted. Therefore, the certificate issuance rules engine 120 sends a certificate issuance rejection response 214 to the requesting user device to alert the user that the certificate issuance request is not permitted. As shown in the figure, the application of certificate issuance policies and rules can therefore be applied in a hierarchical manner based on the division of the organization into user groups, etc. In some embodiments, where the certificate issuance rules engine 120 modifies the requested certificate issuance based on the application of one or more certificate issuance rules, a response can be returned to the requesting device, for example to notify the user that the request is being satisfied but certain parameters may have changed.

[0043] Figure 3 is a diagram illustrating dynamic configuration of certificate issuance policy resources and associated certificate issuance policy rules according to some embodiments. Figure 3 , a user uses computing device 102 to configure certificate issuance policy resource 300 to apply to requests associated with any of a plurality of accounts or roles. Example certificate issuance policy resource 300 is initially configured with rules that, for example, permit a user to request issuance of a certificate that will be used to protect any subject name "*.example.com". For example, at circle "2", a certificate issuance request 302 is generated requesting generation of a certificate matching a wildcard subject name, and according to the current rules, the request is successfully processed, and at circle "3", a certificate 304 is returned by certificate management service 106.

[0044] In this example, at some point in time, the user who initially configured the certificate issuance policy resource 300 decided to limit certificate issuance to only specific subject names without wildcards (e.g., "dev.example.com"). Therefore, at circle "4", the user generates a policy update request 306 using a web-based console, API, CLI, or other interface to modify the applicable policy / rules as needed. At a later point in time, at circle "5", the certificate issuance policy resource 300 applies a second certificate issuance request 302, and at circle "6", the certificate issuance rules engine 120 denies the request and does not generate or return the requested certificate. As shown, the certificate issuance rules engine 120 is therefore able to create dynamic certificate issuance rules that can change over time based on the needs of the organization.

[0045] Figure 4is a diagram illustrating that a user can provide a custom request context in conjunction with a certificate issuance request according to some embodiments. As an example, an organization may have its own approval system 400 for approving user requests for certain types of certificates. In this example, the organization's own approval system 400 may receive and analyze a certificate issuance request (e.g., certificate issuance request 402), and if its own internal policies or procedures permit the request, generate a token 404 that proves the requester's permission to obtain the certificate. In other examples, a user may obtain data from a Lightweight Directory Access Protocol (LDAP) system or other internal authentication system and provide the data as part of a certificate issuance request for use in conjunction with one or more configured certificate issuance policies. As shown in FIG. Figure 4 As shown, such a token 404 may be provided as part of the request context of a certificate issuance request (e.g., certificate issuance request 406) and verified by the certificate management service 106 at circle "3" before the applicable CA generates and returns the requested certificate.

[0046] For example, in Figure 4 At circle "1" in FIG. 4 , device 408 sends a request for a certificate to the organization's certificate issuance approval system 400 (e.g., where the request may identify a subject name, a certificate type, etc.). The certificate issuance approval system 400 receives the request and determines whether to grant the request based on its own internal rules and procedures. For example, the certificate issuance approval system 400 may determine whether to grant the certificate issuance request based on the identity of the user, the subject name identified by the request, or based on other parameters or a combination thereof. In response to the certificate issuance approval system 400 determining to grant the request, the system returns a token 404 to the requesting device 408.

[0047] At circle "2", the device 408 then sends a certificate issuance request to the certificate management service 106, wherein the request includes a token. At circle "3", the rule engine 120 or other component determines that the certificate issuance policy resource applies to the request and processes the request accordingly. In this example, processing the request includes verifying the token (e.g., by directly analyzing the token, calling a serverless function to verify the token, etc.). At circle "4", in response to the rule engine 120 determining that the token is valid, the rule engine 120 sends the request to the CA to generate a certificate. In other examples, in response to the rule engine 120 determining that the provided token is invalid or expired, the rule engine 120 rejects the request and returns a response indicating that the request is rejected.

[0048] Figure 5 is a diagram showing that according to some embodiments a user can configure a certificate issuance policy to invoke an external certificate issuance approval workflow. Figure 4In , the organization uses an external certificate issuance approval system to validate the certificate issuance request and provide data that can be used as a custom request context in the certificate issuance request sent to the certificate management service 106. Figure 5 In the example of , the certificate issuance policy resource is instead configured to call a “hook” into the external certificate issuance approval system 500 as part of the certificate issuance rules engine 120 processing the request.

[0049] For example, consider an organization that desires that its users be able to export public certificates only if a specific person in the organization approves the issuance of the certificate. In this example, whenever an applicable user issues a public certificate issuance request, the certificate issuance rules engine 120 can "hook" into the external approval system 500. The external approval system 500 can then generate an email, an alert in a web console, trigger a ticket system, or otherwise cause a specific person to approve or deny the request, which then sends a response back to the certificate issuance rules engine 120 for further processing.

[0050] For example, Figure 5 As shown, at circle "1", a computing device 502 sends a certificate issuance request 504 to the certificate management service 106. At circle "2", the rule engine 120 receives the request and identifies a certificate issuance policy resource applicable to the request (e.g., based on the request context including a user account or role associated with the request). In this example, the identified certificate issuance policy includes a rule indicating that requests to which the rule applies will cause the rule engine 120 to call the external certificate issuance approval system 500.

[0051] In some embodiments, the certificate issuance rule engine 120 may then send a certificate issuance approval request 506 to the external approval system 500, and determine whether the request can be granted according to the internal approval process, returning a corresponding certificate issuance approval response 508 (or a rejection response in other examples). Once the certificate issuance rule engine 120 receives approval from the external approval system 500, the rule engine may cause the appropriate CA to generate and issue the requested certificate (e.g., certificate 510 at circle "3").

[0052] Figure 6600 is a flowchart illustrating the operation of a method for enabling a user to configure and use a certificate issuance policy according to some embodiments. Some or all of the operations 600 (or other processes described herein, or variations and / or combinations thereof) are performed under the control of one or more computer systems configured with executable instructions and implemented as codes (e.g., executable instructions, one or more computer programs, or one or more applications) that are executed together on one or more processors. The code is stored on a computer-readable storage medium, for example, in the form of a computer program including instructions that can be executed by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of the operations 600 are performed by the certificate management service 106 of other figures, etc.

[0053] Operations 600 include receiving, by a credential management service, a request to generate a credential at block 602 , wherein the request is associated with a request context including an identifier of a user account or role associated with the request and a plurality of parameters related to the requested credential.

[0054] Operations 600 also include identifying, at block 604, certificate issuance rules to be applied to the request based at least in part on the request context.

[0055] Operations 600 also include, at block 606, modifying at least one of a plurality of parameters associated with the requested credential to obtain a modified request to generate a credential.

[0056] Operations 600 also include returning the credential based on the request to generate a modification of the credential at block 608 .

[0057] In some embodiments, the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy that also includes a second certificate issuance rule, wherein the certificate management service provides both public certificate authority (CA) services and private CA services, wherein the second request is a request to generate a public certificate, and wherein the operation also includes: receiving a third request to generate a private certificate for the private CA; determining that the certificate issuance policy includes the second certificate issuance rule, and the second certificate issuance rule denies generation of the private certificate based on a request context associated with the third request; and sending a response indicating that the third request is denied.

[0058] In some embodiments, the action to be performed includes at least one of: granting the request, denying the request, using a specified template, or modifying at least one parameter of the request; and application of the certificate issuance rule is based on at least one of: a user account or role associated with the request, a user group of which the user account or role is a member, a domain name specified in the second request, whether domain name wildcards are used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key length or certificate label, one or more fields to be completed by the certificate issuance rule, a rate at which certificates are requested by a user account or role, a volume of certificates requested by a user account or role, or a time of day.

[0059] In some embodiments, the certificate issuance rule is configured to apply to certificate issuance requests from a user group including multiple user accounts or roles, including the user account or role.

[0060] In some embodiments, the certificate issuance policy is a first certificate issuance policy, the first certificate issuance policy is applicable to a user group including the user account or role, a second certificate issuance policy resource is additionally applicable to the request, and the second certificate issuance policy is applicable to the user account.

[0061] In some embodiments, the request to generate a certificate is a first request to generate a certificate, and the operation also includes: receiving a request to modify a certificate issuance rule by a certificate management service; storing the modified certificate issuance rule based on the request; receiving a second request to generate a certificate; and applying the modified certificate issuance rule to the second request.

[0062] In some embodiments, the request to generate a certificate is a first request to generate a certificate, the request context is a first request context, the certificate issuance rule is a first certificate issuance rule, and the operation also includes: receiving a second request to generate a certificate by a certificate management service, wherein the second request is associated with a second request context; identifying a second certificate issuance rule to be applied to the second request based at least in part on the second request context; rejecting the second request based on the second certificate issuance rule; and sending a response indicating that the second request is rejected.

[0063] In some embodiments, the request context also includes a token generated by an external certificate issuing approval system, and wherein the method also includes validating the token.

[0064] In some embodiments, the operations further include: sending a request to an external certificate issuance approval system to approve the request to generate a certificate, wherein the approval request includes at least a portion of the request context; and receiving a response to the request to approve the request to generate a certificate.

[0065] Figure 7An example provider network (or "service provider system") environment is shown according to some embodiments. The provider network 700 may provide resource virtualization to customers via one or more virtualization services 710, which allow customers to purchase, lease, or otherwise obtain instances 712 of virtualized resources (including, but not limited to, computing resources and storage resources) implemented on devices within one or more provider networks in one or more data centers. A local Internet Protocol (IP) address 716 may be associated with the resource instance 712; the local IP address is the internal network address of the resource instance 712 on the provider network 700. In some embodiments, the provider network 700 may also provide a public IP address 714 and / or a public IP address range (e.g., an Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) address) that customers can obtain from the provider 700.

[0066] Conventionally, the provider network 700 may allow a customer of the service provider (e.g., a customer operating one or more customer networks 750A-750C (or "client networks") including one or more customer devices 752) via the virtualization service 710 to dynamically associate at least some of the public IP addresses 714 assigned or allocated to the customer with a specific resource instance 712 assigned to the customer. The provider network 700 may also allow a customer to remap a public IP address 714 previously mapped to one virtualized computing resource instance 712 assigned to the customer to another virtualized computing resource instance 712 also assigned to the customer. Using the virtualized computing resource instances 712 and public IP addresses 714 provided by the service provider, a customer of the service provider (such as an operator of the customer networks 750A-750C) may, for example, implement customer-specific applications and present the customer's applications on an intermediate network 740 such as the Internet. Other network entities 720 on the intermediate network 740 may then generate traffic destined for the destination public IP address 714 published by the customer networks 750A-750C; the traffic is routed to the service provider data center, and there, via the network underlay, to the local IP address 716 of the virtualized computing resource instance 712 that is currently mapped to the destination public IP address 714. Similarly, response traffic from the virtualized computing resource instance 712 may be routed back to the source entity 720 on the intermediate network 740 via the network underlay.

[0067] As used herein, a local IP address refers to an internal or "private" network address of a resource instance, for example, in a provider network. A local IP address may be within an address block reserved by Request for Comments (RFC) 1918 of the Internet Engineering Task Force (IETF) and / or have an address format specified by IETF RFC 4193, and may be variable within a provider network. Network traffic originating outside the provider network is not routed directly to a local IP address; instead, traffic uses a public IP address that is mapped to the local IP address of the resource instance. The provider network may include a networking device or appliance that provides network address translation (NAT) or similar functionality to perform mappings from public IP addresses to local IP addresses and from local IP addresses to public IP addresses.

[0068] A public IP address is an Internet-mutable network address assigned to a resource instance by a service provider or customer. Traffic routed to a public IP address is translated, for example, via 1:1 NAT, and forwarded to the corresponding local IP address of the resource instance.

[0069] Some public IP addresses may be assigned to specific resource instances by the provider network infrastructure; these public IP addresses may be referred to as standard public IP addresses, or simply standard IP addresses. In some embodiments, the mapping of standard IP addresses to the local IP addresses of resource instances is the default startup configuration for all resource instance types.

[0070] At least some public IP addresses may be assigned to or obtained by customers of the provider network 700; then, the customer may assign the public IP address assigned to it to a specific resource instance assigned to the customer. These public IP addresses may be referred to as customer public IP addresses, or simply customer IP addresses. Rather than being assigned to a resource instance by the provider network 700 as in the case of a standard IP address, a customer IP address may be assigned to a resource instance by the customer, for example, via an API provided by a service provider. Unlike a standard IP address, a customer IP address is assigned to a customer account and may be remapped to other resource instances by the corresponding customer as needed or desired. A customer IP address is associated with a customer account, rather than a specific resource instance, and the customer controls the IP address until the customer chooses to release the IP address. Unlike conventional static IP addresses, a customer IP address allows a customer to mask a resource instance or availability zone failure by remapping the customer's public IP address to any resource instance associated with the customer account. For example, a customer IP address enables a customer to solve a problem with a customer's resource instance or software by remapping the customer IP address to an alternative resource instance.

[0071] Figure 8820 provides a plurality of computing resources 824 (e.g., computing instances 825, such as VMs) to customers. Computing resources 824 may be provided as a service to customers of provider network 800 (e.g., customers implementing customer network 850), for example. Each computing resource 824 may be provided with one or more local IP addresses. Provider network 800 may be configured to route packets from the local IP addresses of computing resources 824 to public Internet destinations and to route packets from public Internet sources to the local IP addresses of computing resources 824.

[0072] The provider network 800 may enable a customer network 850 coupled to the intermediate network 840, for example, via a local network 856, to implement a virtual computing system 892 via a hardware virtualization service 820 coupled to the intermediate network 840 and the provider network 800. In some embodiments, the hardware virtualization service 820 may provide one or more APIs 802, such as web service interfaces, via which the customer network 850 may access functionality provided by the hardware virtualization service 820, for example, via a console 894 (e.g., a web-based application, a standalone application, a mobile application, etc.) of a customer device 890. In some embodiments, at the provider network 800, each virtual computing system 892 at the customer network 850 may correspond to a computing resource 824 that is rented, leased, or otherwise provided to the customer network 850.

[0073] From an instance of a virtual computing system 892 and / or another client device 890 (e.g., via a console 894), a client may access the functionality of a storage service 810, for example, via one or more APIs 802, to access and store data from storage resources 818A-818N (e.g., folders or "buckets," virtualized volumes, databases, etc.) of a virtual data store 816 provided by a provider network 800. In some embodiments, a virtualized data storage gateway (not shown) may be provided at the client network 850, which may cache at least some data locally (e.g., frequently accessed data or critical data) and may communicate with the storage service 810 via one or more communication channels to upload new or modified data from the local cache, so that a primary storage area for data (the virtualized data store 816) is maintained. In some embodiments, a user via the virtual computing system 892 and / or another client device 890 may mount and access virtual data store 816 volumes via the storage service 810 acting as a storage virtualization service, and these volumes may appear to the user as local (virtualized) storage devices 898.

[0074] Although Figure 8Although not shown, the virtualized service may also be accessed from a resource instance within the provider network 800 via API 802. For example, a customer, device service provider, or other entity may access the virtualized service via API 802 from within a corresponding virtual network on the provider network 800 to request allocation of one or more resource instances within the virtual network or within another virtual network.

[0075] In some embodiments, a system implementing part or all of the techniques described herein may include a general-purpose computer system (such as Fig. 9 The computer system 900 shown in the figure includes or is configured to access one or more computer-accessible media. In the illustrated embodiment, the computer system 900 includes one or more processors 910 coupled to a system memory 920 via an input / output (I / O) interface 930. The computer system 900 also includes a network interface 940 coupled to the I / O interface 930. Although Fig. 9 Computer system 900 is shown as a single computing device, but in various embodiments, computer system 900 may include one computing device or any number of computing devices configured to work together as a single computer system 900 .

[0076] In various embodiments, computer system 900 may be a uniprocessor system including one processor 910, or a multiprocessor system including several processors 910 (e.g., two, four, eight, or another suitable number). Processor 910 may be any suitable processor capable of executing instructions. For example, in various embodiments, processor 910 may be a general-purpose processor or an embedded processor that implements any of a variety of instruction set architectures (ISAs), such as x86, ARM, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISAs. In a multiprocessor system, each of processors 910 may typically, but not necessarily, implement the same ISA.

[0077] The system memory 920 may store instructions and data that may be accessed by the processor 910. In various embodiments, the system memory 920 may be implemented using any suitable memory technology, such as random access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data that implement one or more desired functions (such as those methods, techniques, and data described above) are shown as being stored within the system memory 920 as specialized certificate authority service code 925 (e.g., executable to fully or partially implement the certificate management service 106) and data 926.

[0078] In some embodiments, the I / O interface 930 may be configured to coordinate I / O traffic between the processor 910, the system memory 920, and any peripheral devices in the device, including the network interface 940 and / or other peripheral interfaces (not shown). In some embodiments, the I / O interface 930 may perform any necessary protocol, timing, or other data transformations to convert data signals from one component (e.g., the system memory 920) into a format suitable for use by another component (e.g., the processor 910). In some embodiments, for example, the I / O interface 930 may include support for devices attached through various types of peripheral buses (such as a variation of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard). In some embodiments, for example, the functionality of the I / O interface 930 may be split into two or more separate components, such as a north bridge and a south bridge. In addition, in some embodiments, some or all of the functionality of the I / O interface 930 (such as an interface to the system memory 920) may be directly incorporated into the processor 910.

[0079] For example, the network interface 940 may be configured to allow the computer system 900 to communicate with other devices 960 attached to one or more networks 950 (such as Figure 1 In various embodiments, the network interface 940 may support communication via any suitable wired or wireless general-purpose data network, such as various types of Ethernet networks, for example. In addition, the network interface 940 may support communication via a telecommunications / telephone network, such as an analog voice network or a digital fiber-optic communications network, via a storage area network (SAN), such as a Fibre Channel SAN, and / or via any other suitable type of network and / or protocol.

[0080] In some embodiments, the computer system 900 includes one or more offload cards 970A or 970B (including one or more processors 975, and possibly one or more network interfaces 940) connected using an I / O interface 930 (e.g., a bus implementing a version of the Peripheral Component Interconnect Express (PCI-E) standard, or another interconnect such as the QuickPath Interconnect (QPI) or the UltraPath Interconnect (UPI)). For example, in some embodiments, the computer system 900 may act as a host electronic device that hosts computing resources such as computing instances (e.g., operating as part of a hardware virtualization service), and one or more offload cards 970A or 970B execute a virtualization manager that can manage computing instances executed on the host electronic device. As an example, in some embodiments, the offload card 970A or 970B may perform computing instance management operations, such as pausing and / or unpausing computing instances, starting and / or terminating computing instances, performing memory transfer / copy operations, etc. In some embodiments, these management operations may be performed by offload card 970A or 970B in cooperation with hypervisors (e.g., based on requests from the hypervisors) executed by other processors 910A-910N of computer system 900. However, in some embodiments, the virtualization manager implemented by offload card 970A or 970B may adapt to requests from other entities (e.g., from the computing instances themselves) and may not cooperate with (or serve) any individual hypervisor.

[0081] In some embodiments, the system memory 920 may be an embodiment of a computer-accessible medium configured to store program instructions and data as described above. However, in other embodiments, program instructions and / or data may be received, sent, or stored on different types of computer-accessible media. In general, the computer-accessible medium may include any non-transitory storage medium or memory medium, such as magnetic or optical media, such as a disk or DVD / CD coupled to the computer system 900 via an I / O interface 930. The non-transitory computer-accessible storage medium may also include any volatile or non-volatile medium that may be included in some embodiments of the computer system 900 as the system memory 920 or another type of memory, such as RAM (e.g., SDRAM, double data rate (DDR) SDRAM, SRAM, etc.), read-only memory (ROM), etc. In addition, the computer-accessible medium may include a transmission medium or a signal transmitted via a communication medium (such as a network and / or a wireless link), such as an electrical signal, an electromagnetic signal, or a digital signal, and the communication medium may be implemented via a network interface 940.

[0082] Various embodiments discussed or proposed herein can be implemented in a variety of operating environments, in some cases, the operating environment may include one or more user computers, computing devices or processing devices that can be used to operate any of many applications. User devices or client devices may include any of many general personal computers, such as desktop computers or laptop computers running standard operating systems, and cellular devices, wireless devices and handheld devices that run mobile software and can support many networking and messaging protocols. Such a system may also include many workstations, which run various commercially available operating systems and any of 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, game systems and / or other devices that can communicate via a network.

[0083] Most embodiments use at least one network familiar to those skilled in the art to support communications using any of a variety of widely available protocols, such as Transmission Control Protocol / Internet Protocol (TCP / IP), File Transfer Protocol (FTP), Universal Plug and Play (UPnP), Network File System (NFS), Common Internet File System (CIFS), Extensible Messaging and Presence Protocol (XMPP), AppleTalk, etc. The network may include, for example, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), the Internet, an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network, and any combination thereof.

[0084] In embodiments using a web server, the web server may run any of a variety of server or middle-tier applications, including HTTP servers, file transfer protocol (FTP) servers, common gateway interface (CGI) servers, data servers, Java servers, business application servers, etc. 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 The server may include one or more web applications written in one or more scripts or programs in C, C#, or C++, or any scripting language such as Perl, Python, PHP, or TCL, and combinations thereof. The server may also include a database server, including but not limited to commercially available database servers from Oracle (R), Microsoft (R), Sybase (R), IBM (R), etc. The database server may be relational or non-relational (e.g., "NoSQL"), distributed or non-distributed, etc.

[0085] The environment disclosed herein may include various data storage areas and other memories and storage media as discussed above. These may reside in various locations, such as on storage media residing locally (and / or residing therein) on one or more computers, or on storage media residing away from any or all computers on 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 belonging to computers, servers or other network devices may be stored locally and / or remotely as 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, the elements including, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touch screen or keypad) and / or at least one output device (e.g., 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.

[0086] 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. A computer-readable storage medium reader may be connected to or configured to receive a computer-readable storage medium, which represents a remote, local, fixed and / or removable storage device and a storage medium for temporarily and / or longer accommodating, storing, transmitting 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 an operating system and applications, such as a client application or a web browser. 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 with other computing devices (such as network input / output devices) may be employed.

[0087] 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 media, removable and non-removable media implemented in any method or technology to store and / or transmit 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 present disclosure and the teachings provided herein, ordinary technicians in the art will understand other ways and / or methods of implementing various embodiments.

[0088] In the foregoing description, various embodiments are described. For explanatory purposes, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to those skilled in the art that the embodiments may be practiced without these specific details. In addition, in order not to obscure the described embodiments, well-known features may be omitted or simplified.

[0089] Bracketed text and boxes with dashed borders (e.g., large dashes, small dashes, dot dashes, and dots) are used herein to illustrate optional operations that add additional features to some embodiments. However, this notation should not be taken to mean that these are the only options or optional operations, and / or that in some embodiments, boxes with solid borders are not optional.

[0090] In various embodiments, reference numerals with suffix letters (e.g., 918A-918N) may be used to indicate that there may be one or more instances of the referenced entity, and when there are multiple instances, each instance need not be identical, but may instead share some general features or function in a common manner. Furthermore, unless expressly indicated to the contrary, the particular suffix used is not meant to imply that there is a particular amount of the entity. Thus, in various embodiments, two entities using the same or different suffix letters may or may not have the same number of instances.

[0091] References to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it should be understood that it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0092] Furthermore, in the various embodiments described above, unless specifically indicated otherwise, disjunctive language such as the phrase "at least one of A, B, or C" is intended to be understood to mean A, B, or C, or any combination thereof (e.g., A, B, and / or C). Similarly, language such as "at least one or more of A, B, and C" (or "one or more of A, B, and C") is intended to be understood to mean A, B, or C, or any combination thereof (e.g., A, B, and / or C). Thus, disjunctive language is neither intended nor should be understood to imply that a given embodiment requires that at least one of A, at least one of B, and at least one of C each be present.

[0093] Unless expressly stated otherwise, articles such as "a" or "an" should generally be interpreted as including one or more of the described items. Thus, phrases such as "a device configured to" or "computing device" are intended to include one or more of the recited devices. The one or more recited devices may be collectively configured to perform the recited operations. For example, "a processor configured to perform operations A, B, and C" may include a first processor configured to perform operation A working together with a second processor configured to perform operations B and C.

[0094] At least some embodiments of the disclosed technology may be described in terms of the following:

[0095] 1. A computer-implemented method, the method comprising:

[0096] A first request to create a certificate issuance policy is received by a certificate management service of a cloud provider, wherein the first request indicates:

[0097] One or more user accounts or roles to which the certificate issuance policy will apply, and

[0098] a certificate issuance rule, the certificate issuance rule comprising an action to be performed with respect to a request matching the certificate issuance rule;

[0099] storing a certificate issuance policy resource including a representation of said certificate issuance rules;

[0100] receiving a second request to generate credentials, wherein the second request is associated with a user account or role, and wherein the second request includes a plurality of parameters related to generation of the requested credentials;

[0101] determining, by a rules engine of the certificate management service, that the certificate issuance policy is applicable to the user account or role, wherein the rules engine is separate from a plurality of certificate authority (CA) services with which the rules engine is integrated;

[0102] Based on the certificate issuance rule, modify at least one of the plurality of parameters of the second request to obtain a modified second request; and

[0103] The credential is returned based on the modified second request.

[0104] 2. The computer-implemented method of clause 1, wherein the certificate issuance rule is a first certificate issuance rule, wherein the certificate management service provides both public certificate authority (CA) services and private CA services, wherein the second request is a request to generate a public certificate, and wherein the method further comprises:

[0105] receiving a third request for the private CA to generate a private certificate;

[0106] determining that the certificate issuance policy includes a second certificate issuance rule that denies generation of the private certificate based on a request context associated with the third request; and

[0107] A response is sent indicating that the third request is denied.

[0108] 3. A computer-implemented method as described in any of clauses 1 or 2, wherein the action to be performed includes at least one of the following: granting the request, denying the request, using a specified template, or modifying at least one parameter of the request; and

[0109] Wherein application of the certificate issuance rule is based on at least one of: the user account or role associated with the request, the user group of which the user account or role is a member, the domain name specified in the second request, whether domain name wildcards are used, the requested certificate validity period, the requested cryptographic key type, the requested cryptographic key length or certificate label, one or more fields to be completed by the certificate issuance rule, the rate at which certificates are requested by the user account or role, the volume of certificates requested by the user account or role, or the time of day.

[0110] 4. A computer-implemented method, the method comprising:

[0111] Receiving, by a public key infrastructure (PKI) service, a request to generate a certificate, wherein the request is associated with a request context, the request context comprising: an identifier of a user account or role associated with the request, and a plurality of parameters related to the requested certificate;

[0112] identifying, by a rules engine of the PKI service, a certificate issuance rule to be applied to the request based at least in part on the request context, wherein the rules engine is separate from a plurality of certificate authority (CA) services with which the rules engine is integrated;

[0113] modifying at least one of the plurality of parameters associated with the requested credential to obtain a modified request to generate the credential; and

[0114] The certificate is returned based on the request to generate the modification of the certificate.

[0115] 5. The computer-implemented method of clause 4, wherein the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy that also includes a second certificate issuance rule, wherein a certificate management service provides both public certificate authority (CA) services and private CA services, wherein the request to generate the certificate is a request to generate a public certificate, and wherein the method further comprises:

[0116] receiving a second request for the private CA to generate a private certificate;

[0117] determining that the certificate issuance policy includes the second certificate issuance rule, the second certificate issuance rule denying generation of the private certificate based on a request context associated with the second request; and

[0118] A response is sent indicating that the second request is denied.

[0119] 6. A computer-implemented method as described in any of clauses 4 or 5, wherein the action to be performed based on the certificate issuance rule includes at least one of the following: granting the request, denying the request, using a specified template, or modifying at least one parameter of the request; and

[0120] Wherein application of the certificate issuance rule is based on at least one of: the user account or role associated with the request, the user group of which the user account or role is a member, the domain name specified in the request, whether domain name wildcards are used, the requested certificate validity period, the requested cryptographic key type, the requested cryptographic key length or certificate label, one or more fields to be completed by the certificate issuance rule, the rate at which certificates are requested by the user account or role, the volume of certificates requested by the user account or role, or the time of day.

[0121] 7. A computer-implemented method as described in any of clauses 4-6, wherein the certificate issuance rule is configured to apply to certificate issuance requests from a user group including multiple user accounts or roles, the multiple user accounts or roles including the user account or role.

[0122] 8. A computer-implemented method as described in any of clauses 4-7, wherein the certificate issuance policy that includes the certificate issuance rule is a first certificate issuance policy, wherein the first certificate issuance policy is applicable to a user group including the user account or role, wherein a second certificate issuance policy is further applicable to the request, and wherein the second certificate issuance policy is applicable to the user account.

[0123] 9. The computer-implemented method of any of clauses 4-8, wherein the request to generate a credential is a first request to generate a credential, and wherein the method further comprises:

[0124] Receiving, by the PKI service, a request to modify the certificate issuance rule;

[0125] storing a modified certificate issuance rule based on the request;

[0126] receiving a second request to generate a certificate; and

[0127] The modified certificate issuance rule is applied to the second request.

[0128] 10. A computer-implemented method as described in any of clauses 4-9, wherein the request to generate a certificate is a first request to generate a certificate, the request context is a first request context, the certificate issuance rule is a first certificate issuance rule, and wherein the method further comprises:

[0129] receiving, by the PKI service, a second request to generate a certificate, wherein the second request is associated with a second request context;

[0130] identifying a second certificate issuance rule to be applied to the second request based at least in part on the second request context;

[0131] denying the second request based on the second certificate issuance rule; and

[0132] A response is sent indicating that the second request is denied.

[0133] 11. The computer-implemented method of any of clauses 4-10, wherein the request context further comprises a token generated by an external certificate issuance approval system, and wherein the method further comprises validating the token.

[0134] 12. The computer-implemented method of any of clauses 4-11, further comprising:

[0135] sending a request to an external certificate issuing approval system to approve the request to generate the certificate, wherein the approval request includes at least a portion of the request context; and

[0136] A response is received approving the request to generate the certificate.

[0137] 13. The computer-implemented method of any of clauses 4-12, further comprising:

[0138] receiving a first request to create a private certificate authority (CA);

[0139] receiving a second request to create at least one certificate issuance rule to be applied to a certificate issuance request involving the private CA; and

[0140] The private CA is created using the at least one certificate issuance rule.

[0141] 14. A system, comprising:

[0142] A first one or more electronic devices for implementing a certificate management service in a multi-tenant provider network, wherein the certificate management service includes instructions that, when executed, cause the certificate management service to:

[0143] receiving a request to generate a credential, wherein the request is associated with a request context, the request context comprising: an identifier of a user account or role associated with the request, and a plurality of parameters related to the requested credential;

[0144] identifying, by a rules engine of the certificate management service, a certificate issuance rule to be applied to the request based on at least a portion of the request context, wherein the rules engine is separate from a plurality of certificate authority (CA) services with which the rules engine is integrated;

[0145] modifying at least one of the plurality of parameters associated with the requested credential to obtain a modified request to generate the credential; and

[0146] returning the certificate based on the request to generate the modification of the certificate; and

[0147] second one or more electronic devices, the second one or more electronic devices being configured to implement a computing service in the multi-tenant provider network, the computing service comprising instructions that, when executed, cause the computing service to:

[0148] receiving the certificate, and

[0149] Install the certificate for use by the compute instance.

[0150] 15. The system of clause 14, wherein the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy that also includes a second certificate issuance rule, wherein the certificate management service provides both public certificate authority (CA) services and private CA services, wherein the request to generate a certificate is a request to generate a public certificate, and wherein the instructions, when executed, further cause the certificate management service to:

[0151] receiving a second request for the private CA to generate a private certificate;

[0152] determining that the certificate issuance policy includes the second certificate issuance rule, the second certificate issuance rule denying generation of the private certificate based on a request context associated with the second request; and

[0153] A response is sent indicating that the second request is denied.

[0154] 16. The system of any of clauses 14 or 15, wherein the action to be performed based on the certificate issuance rule comprises at least one of: granting the request, denying the request, using a specified template, or modifying at least one parameter of the request; and

[0155] Wherein application of the certificate issuance rule is based on at least one of: the user account or role associated with the request, the user group of which the user account or role is a member, the domain name specified in the request, whether domain name wildcards are used, the requested certificate validity period, the requested cryptographic key type, the requested cryptographic key length or certificate label, one or more fields to be completed by the certificate issuance rule, the rate at which certificates are requested by the user account or role, the volume of certificates requested by the user account or role, or the time of day.

[0156] 17. The system of any of clauses 14-16, wherein the certificate issuance rule is configured to apply to certificate issuance requests from a user group comprising a plurality of user accounts or roles, the plurality of user accounts or roles including the user account or role.

[0157] 18. A system as described in any of clauses 14-17, wherein the certificate issuance policy including the certificate issuance rule is a first certificate issuance policy, wherein the first certificate issuance policy is applicable to a user group including the user account or role, wherein a second certificate issuance policy is further applicable to the request, and wherein the second certificate issuance policy is applicable to the user account.

[0158] 19. The system of any of clauses 14-18, wherein the request to generate a credential is a first request to generate a credential, and wherein the instructions, when executed, further cause the credential management service to:

[0159] Receiving, by the certificate management service, a request to modify the certificate issuance rule;

[0160] storing a modified certificate issuance rule based on the request;

[0161] receiving a second request to generate a certificate; and

[0162] The modified certificate issuance rule is applied to the second request.

[0163] 20. The system of any of clauses 14-19, wherein the request to generate a certificate is a first request to generate a certificate, the request context is a first request context, the certificate issuance rule is a first certificate issuance rule, and wherein the instructions when executed further cause the certificate management service to:

[0164] receiving, by the credential management service, a second request to generate a credential, wherein the second request is associated with a second request context;

[0165] identifying a second certificate issuance rule to be applied to the second request based at least in part on the second request context;

[0166] denying the second request based on the second certificate issuance rule; and

[0167] A response is sent indicating that the second request is denied.

[0168] The specification and drawings are accordingly 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 disclosure as set forth in the claims.

Claims

1. A computer-implemented method, the method include: A first request to create a certificate issuance policy is received by a certificate management service of a cloud provider, wherein the first request indicates: one or more user accounts or roles, the certificate issuance policy being adapted to be applied to the one or more user accounts or roles, and a certificate issuance rule, the certificate issuance rule comprising an action to be performed with respect to a request matching the certificate issuance rule; storing a certificate issuance policy resource, the certificate issuance policy resource comprising a representation of the certificate issuance rule indicated in the first request; receiving a second request to generate credentials, wherein the second request is associated with a user account or role, and wherein the second request includes a plurality of parameters related to generation of credentials requested in the second request; determining, by a rules engine of the certificate management service, that the certificate issuance policy is applicable to the user account or role associated with the second request, wherein the rules engine is separate from a plurality of certificate authority (CA) services within the certificate management service, the rules engine being integrated with the plurality of CA services via an application programming interface; modifying at least one of the plurality of parameters of the second request based on the certificate issuance rule indicated in the first request to obtain a modified second request; generating the certificate based on the modified second request; as well as The generated certificate is returned as a response to the second request.

2. The computer-implemented method of claim 1 , wherein the certificate issuance rule is a first certificate issuance rule, wherein the certificate management service provides both a public certificate authority (CA) service and a private CA service, wherein the second request is a request to generate a public certificate, and wherein the method further include: receiving a third request for the private CA to generate a private certificate; determining that the certificate issuance policy includes a second certificate issuance rule that denies generation of the private certificate based on a request context associated with the third request; as well as A response is sent indicating that the third request is denied.

3. The computer-implemented method of claim 1, wherein the action to be performed comprises at least one of: granting the request, denying the request, using a specified template, or modifying at least one parameter of the request; and Wherein application of the certificate issuance rule is based on at least one of: the user account or role associated with the second request, a user group of which the user account or role is a member, a domain name specified in the second request, whether domain name wildcards are used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key length or certificate label, one or more fields to be completed by the certificate issuance rule, a rate at which certificates are requested by the user account or role, a volume of certificates requested by the user account or role, or a time of day.

4. A computer-implemented method, the method comprising: include: receiving a first request, the first request indicating a certificate issuance rule, the certificate issuance rule comprising an action to be performed with respect to a request matching the certificate issuance rule; receiving, by a public key infrastructure (PKI) service, a second request to generate a certificate, wherein the second request is associated with a request context, the request context comprising: an identifier of a user account or role associated with the second request, and a plurality of parameters related to the requested certificate; identifying, by a rules engine of the PKI service, that the certificate issuance rule is to be applied to the second request based at least in part on the request context, wherein the rules engine is separate from a plurality of certificate authority (CA) services within the PKI service, the rules engine being integrated with the plurality of CA services via an application programming interface; modifying at least one of the plurality of parameters associated with the requested certificate based on the certificate issuance rule indicated in the first request to obtain a modified request to generate the certificate; generating the certificate based on the modified request to generate the certificate; and The generated certificate is returned as a response to the second request.

5. The computer-implemented method of claim 4, wherein the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy that also includes a second certificate issuance rule, wherein a certificate management service provides both public certificate authority (CA) services and private CA services, wherein the second request is for generating a public certificate, and wherein the method further include: receiving a third request for the private CA to generate a private certificate; determining that the certificate issuance policy includes the second certificate issuance rule, the second certificate issuance rule denying generation of the private certificate based on a request context associated with the third request; as well as A response is sent indicating that the third request is denied.

6. The computer-implemented method of claim 4, wherein the action to be performed based on the certificate issuance rule comprises at least one of: granting the request, denying the request, using a specified template, or modifying at least one parameter of the request; and Wherein application of the certificate issuance rule is based on at least one of: the user account or role associated with the second request, a user group of which the user account or role is a member, a domain name specified in the second request, whether domain name wildcards are used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key length or certificate label, one or more fields to be completed by the certificate issuance rule, a rate at which certificates are requested by the user account or role, a volume of certificates requested by the user account or role, or a time of day.

7. The computer-implemented method of claim 4, wherein the certificate issuance rule is configured to apply to certificate issuance requests from a user group including a plurality of user accounts or roles, the plurality of user accounts or roles including the user account or role.

8. A computer-implemented method as described in claim 4, wherein the certificate issuance policy including the certificate issuance rule is a first certificate issuance policy, wherein the first certificate issuance policy is applicable to a user group including the user account or role, wherein a second certificate issuance policy is further applicable to the second request, and wherein the second certificate issuance policy is applicable to the user account.

9. The computer-implemented method of claim 4, wherein the second request is used to generate a first certificate, and wherein the method further include: Receiving, by the PKI service, a request to modify the certificate issuance rule; storing a modified certificate issuance rule based on a request to modify the certificate issuance rule; receiving a third request to generate a second certificate; as well as The modified certificate issuance rule is applied to the third request.

10. The computer-implemented method of claim 4, wherein the second request is for generating a first certificate, the request context is a first request context, the certificate issuance rule is a first certificate issuance rule, and wherein the method further include: receiving, by the PKI service, a third request to generate a second certificate, wherein the third request is associated with the second request context; identifying a second certificate issuance rule to be applied to the third request based at least in part on the second request context; denying the third request based on the second certificate issuance rule; as well as A response is sent indicating that the third request is denied.

11. The computer-implemented method of claim 4, wherein the request context further comprises a token generated by an external certificate issuance approval system, and wherein the method further comprises validating the token.

12. The computer-implemented method of claim 4, further comprising: include: sending a request to an external certificate issuance approval system to approve the second request to generate the certificate, wherein the approval request includes at least a portion of the request context; as well as A response is received approving the second request to generate the certificate.

13. The computer-implemented method of claim 4, wherein the second request involves a private certificate authority (CA).

14. A system, wherein the system include: A first one or more electronic devices for implementing a certificate management service in a multi-tenant provider network, wherein the certificate management service includes instructions that, when executed, cause the certificate management service to: receiving a first request, the first request indicating a certificate issuance rule, the certificate issuance rule comprising an action to be performed with respect to a request matching the certificate issuance rule; receiving a second request to generate a credential, wherein the second request is associated with a request context, the request context comprising: an identifier of a user account or role associated with the request, and a plurality of parameters related to the requested credential; The rules engine of the certificate management service identifies that the certificate issuance rule is to be applied to the second request based on at least a part of the request context, wherein the rules engine is separate from multiple certificate authority (CA) services within the certificate management service, and the rules engine is integrated with the multiple CA services via an application programming interface; Modify at least one of the multiple parameters related to the requested certificate based on the certificate issuance rule indicated in the first request to obtain a modified request for generating the certificate; Generate the certificate based on the modified request for generating the certificate; and Return the generated certificate as a response to the second request; and A second one or more electronic devices for implementing a computing service in the multi-tenant provider network, the computing service including instructions that, when executed, cause the computing service to: Receive the certificate returned by the certificate management service, and Install the certificate received from the certificate management service for use by the computing instance.

15. The system according to claim 14, wherein the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy further including a second certificate issuance rule, wherein the certificate management service provides both a public certificate authority (CA) service and a private CA service, wherein the second request is for generating a public certificate, and wherein the instructions, when executed, further cause the certificate management service to: Receive a third request for generating a private certificate for the private CA; Determine that the certificate issuance policy includes the second certificate issuance rule that rejects the generation of the private certificate based on the request context associated with the third request; And Send a response indicating that the third request is rejected.

16. The system according to claim 14, wherein the actions to be performed based on the certificate issuance rule include at least one of the following: granting a request, rejecting a request, using a specified template, or modifying at least one parameter of the request; and wherein the application of the certificate issuance rule is based on at least one of the following: the user account or role associated with the second request, the user group of which the user account or role is a member, the domain name specified in the second request, whether a domain name wildcard is used, the requested certificate validity period, the requested password key type, the requested password key length or certificate label, one or more fields to be completed by the certificate issuance rule, the rate at which the user account or role requests a certificate, the quantity of certificates requested by the user account or role, or the time of day.

17. The system according to claim 14, wherein the certificate issuance rule is configured to apply to certificate issuance requests from a user group including multiple user accounts or roles, the multiple user accounts or roles including the user account or role.

18. A system as described in claim 14, wherein the certificate issuance policy including the certificate issuance rule is a first certificate issuance policy, wherein the first certificate issuance policy is applicable to a user group including the user account or role, wherein a second certificate issuance policy is further applicable to the second request, and wherein the second certificate issuance policy is applicable to the user account.

19. The system of claim 14, wherein the second request is for generating a first certificate, and wherein the instructions, when executed, further cause the certificate management service to: Receiving, by the certificate management service, a request to modify the certificate issuance rule; storing a modified certificate issuance rule based on a request to modify the certificate issuance rule; receiving a third request to generate a second certificate; as well as The modified certificate issuance rule is applied to the third request.

20. The system of claim 14, wherein the second request is for generating a first certificate, the request context is a first request context, the certificate issuance rule is a first certificate issuance rule, and wherein the instructions, when executed, further cause the certificate management service to: receiving, by the certificate management service, a third request to generate a second certificate, wherein the third request is associated with the second request context; identifying a second certificate issuance rule to be applied to the third request based at least in part on the second request context; denying the third request based on the second certificate issuance rule; as well as A response is sent indicating that the third request is denied.

Images