CUSTOM RULES FOR GLOBAL CERTIFICATE ISSUANCE

Abstract

Computer-implemented method, including: Receiving an initial request (124) to generate a certificate issuance policy by a certificate management service (106) of a cloud provider, wherein the initial request (124) indicates: one or more user accounts or roles to which the certificate issuance policy should be applied, and a certificate issuance rule, including an action to be performed in respect of requirements that comply with the certificate issuance rule; Storing a certificate issuance policy resource that contains a representation of the certificate issuance rule specified in the first request (124); Receiving a second request to generate a certificate, wherein the second request is associated with a user account or role, and wherein the second request includes a variety of parameters relating to the generation of the requested certificate; Determine, by means of a rule engine (120) of the certificate management service (106), that the certificate issuance policy applies to the user account or user account role associated with the second request, wherein the rule engine (120) within the certificate management service (106) is separated from a variety of certificate authority services (CA services) into which the rule engine (120) is integrated via an application programming interface (API); based on the certificate issuance rule specified in the first requirement (124), modifying at least one of the multiple parameters of the second requirement to obtain a modified second requirement; Generating the certificate based on the amended second requirement; and Returning the generated certificate (114) in response to the second request.

Description

BACKGROUND

[0001] Asymmetric cryptographic systems use key pairs, including public and private keys, to encrypt and decrypt data. For example, a public key infrastructure (PKI) uses pairs of public and private keys to enable secure electronic communication. Public keys can be associated with digital certificates, which certify the owner of a particular public key. The digital certificates are created and signed by a public or private certificate authority, which acts as a trusted third party. Various digital certificates can be used, for example, to establish secure connections over a network such as the internet. HTTPS (Hypertext Transfer Protocol Secure) uses digital certificates to establish secure connections using TLS (Transport Layer Security).US 6,108,788 A describes a certificate management system and procedure that allows an applicant to customize certificates by selecting variable specification data for certificate content. US 2011 / 0 154,024 A1 describes a certificate authority selection unit that implements a procedure for selecting one of several certificate authorities serving multiple management domains in a communications system. US 2011 / 0 213,960 A2 describes a public key infrastructure that includes a client side for requesting and using certificates when communicating over a network and a server side for managing the issuance and maintenance of those certificates. WO 2018 / 045,001 A1 describes systems, devices, services, platforms, and methods that provide digital security services and improve the issuance of digital security certificates for communications systems.It is an object of the invention to propose computer-implemented methods and a system for issuing user-defined certificates. This object is achieved by a method according to claim 1, a method according to claim 4, and a system according to claim 14. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various embodiments according to the present disclosure are described with reference to the drawings, in which the following applies: Fig. Figure 1 is a diagram illustrating an environment that allows users to configure and use certificate issuance policies according to some implementations. Fig. Figure 2 is a diagram illustrating the application of certificate issuance policies in response to certificate requests from various users or resources according to some implementations. Fig. Figure 3 is a diagram illustrating the dynamic configuration of a certificate issuance policy according to some embodiments. Fig. Figure 4 is a diagram illustrating the use of a custom pre-approval process for certificate issuance and the validation of a custom pre-approval process by a certificate management service according to a certificate issuance policy according to some embodiments. Fig. Figure 5 is a diagram illustrating the use of a hook in a custom approval process for certificate issuance by a certificate management service in response to certificate issuance requests according to some embodiments. Fig. Figure 6 is a flowchart illustrating the operations of a method for configuring a certificate issuance policy using a certificate management service and for using a configured certificate issuance policy to control certificate issuance requests according to some embodiments. Fig. Figure 7 shows an example provider network environment according to some implementations. Fig. Figure 8 is a block diagram of an example provider network that provides customers with a storage service and a hardware virtualization service according to some embodiments. Fig. Figure 9 is a block diagram showing an example computer system that can be used in some embodiments. DETAILED DESCRIPTION

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

[0004] Today, users typically control certificate issuance within an organization using certificate templates or CA-specific rules. A template defines, for example, the attributes and their order to be included in a digital certificate, such as a domain name, issue date, expiration date, public key, and the digital signature to be provided by the certificate authority. With CA-specific rules, users apply rules to a particular issuing certificate authority, and users cannot deviate from these rules. However, many CA administrators and other users want to manage certificate issuance from different CAs and be able to control the details of the issued certificates based on the context of a request, such as whether a user or role is requesting a certificate, what type of certificate is being requested, and so on.

[0005] To address these and other challenges, techniques for providing a certificate issuance rule engine are described here, enabling users to configure certificate issuance policies and associated rules that can be applied to both public and private certificate authorities and to specific users or user groups.Examples of rule types that can be configured as part of a certificate issuance policy include rules defining which domains certificates can be issued for, whether domain wildcards can be used, certificate validity periods, cryptographic key types and sizes, certificate labeling conventions, one or more fields to be populated by the certificate issuance rule, a rate at which the user account or role requests certificates, a quantity of certificates to be requested by the user account or role, a time, and the like. Among other advantages, the described certificate issuance rule engine enables efficient management of certificate issuance across all user organizations, thereby improving the security of the services protected by the issued certificates.

[0006] Fig. Figure 1 is a diagram illustrating an environment that allows users to configure certificate issuance policy resources according to some implementations. A provider network (or "cloud" provider network) provides users with the ability to use one or more types of compute-related resources, such as compute resources (e.g., running instances and / or containers of virtual machines (VMs), running batch jobs, executing code without provisioning servers), data / storage resources (e.g., object storage, block storage, data archive storage, databases and database tables, etc.), network-related resources (e.g., configuring virtual networks including groups of compute resources, content delivery networks (CDNs), domain name services (DNS)), and 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 can be provided as services, e.g., as a hardware virtualization service that can run compute instances, as a storage service that can store data objects, etc. Users (or "customers") of provider networks 100 can use one or more user accounts linked to a customer account, although these terms can be used somewhat interchangeably, depending on the context of use. Users can (e.g., using an electronic device 102) travel across one or more intermediate networks 104 (e.g.,(The Internet) interact with a provider network 100 via one or more interfaces, for example, by using API (Application Programming Interface) calls, via a console implemented as a website or application, etc. An API refers to an interface and / or communication protocol between a client and a server, so that when the client makes a request in a predefined format, it should receive a response in a specific format or initiate a defined action. In the context of the cloud provider's network, APIs provide customers with a gateway to access the cloud infrastructure by allowing them to retrieve data from the cloud provider's network or trigger actions there. This enables the development of applications that interact with the resources and services hosted on the cloud provider's network.APIs can also enable different services within the cloud provider network to exchange data. The interface(s) can be part of a control plane of the provider network or serve as a front end to a control plane that includes "backend" service support and allows services to be offered to customers more directly.

[0007] A cloud provider network (or simply "cloud") typically refers to a large pool of accessible virtualized computing resources (such as compute, storage, and network 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 adapt to varying loads. Cloud computing thus encompasses both the applications delivered as services over a publicly accessible network (such as the internet or a mobile network) and the hardware and software in the cloud providers' data centers that deliver these services.

[0008] A cloud provider's network can consist of multiple regions, where a region is a geographic area in which the cloud provider clusters (groups together) data centers. Each region comprises multiple (e.g., two or more) Availability Zones (AZs) connected via a private, high-speed network, such as a fiber optic communication link. An AZ (also referred to as a "zone") provides an isolated failover domain, comprising one or more data center facilities with separate power, network, and cooling from those in another AZ. A data center is a physical building or area that houses, powers, and cools the servers of the cloud provider's network.Preferably, the AZs within a region are positioned far enough apart from each other so that a natural disaster (or other failure-causing event) does not affect or take offline more than one AZ at a time.

[0009] Users can connect to an Access Point (AZ) of the cloud provider's network via a publicly accessible network (e.g., the internet, a mobile network), for example, through a Transit Center (TC). TCs are the primary backbone locations that connect users to the cloud provider's network. They can be located in the facilities of other network providers (e.g., internet service providers (ISPs), telecommunications providers) and securely connected to the AZs (e.g., via a VPN or a direct connection). Each region can operate two or more TCs for redundancy. Regions are connected to a global network that includes a private network infrastructure (e.g., fiber optic links controlled by the cloud provider) that connects each region to at least one other region.The cloud provider's network can deliver content from points of presence (POPs) outside these regions, but these points are connected to them via edge locations and regional edge cache servers. This isolation and geographic distribution of computing hardware enables the cloud provider's network to provide users globally with low-latency resource access and a high degree of fault tolerance and stability.

[0010] In general, the traffic and operations of a provider network can be broadly divided into two categories: control plane operations, which are executed via a logical control plane, and data plane operations, which are executed via a logical data plane. While the data plane represents the movement of user data through the distributed computing system, the control plane represents the movement of control signals through the distributed computing system. The control plane generally comprises one or more control plane components, which are distributed across and implemented by one or more control servers. Control plane traffic generally includes administrative operations such as system configuration and management (e.g., resource allocation, hardware capacity management, diagnostic monitoring, and system status information).The data plane comprises user resources deployed on the provider's network (e.g., compute instances, containers, block storage volumes, databases, file storage). Data plane traffic generally includes non-administrative operations, such as the transfer of user data to and from user resources. Control plane components are typically deployed on a different server group than data plane servers, and control plane and data plane traffic may be sent over separate networks.

[0011] To provide these and other computing resource services, provider networks often rely on virtualization techniques. For example, virtualization technologies can enable users to control or utilize computing resources (such as a "computing instance," like a virtual machine with a guest operating system (OS) running with a hypervisor that may be on top of an underlying host operating system; a container that may be running inside a virtual machine; or a computing instance that can run on "bare-metal" hardware without an underlying hypervisor), where one or more computing resources can be implemented using a single electronic device. Thus, a user can directly use a computing resource hosted by the provider network (provided, for example, by a hardware virtualization service) to perform a variety of computing tasks.Additionally or alternatively, a user can indirectly utilize a computing resource 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—usually without the user having control over or knowledge of the underlying computing instance(s).

[0012] For example, a "serverless" function, in various implementations, can contain code provided by a user or another entity—such as the provider network itself—that can be executed on demand. Serverless functions can be managed within a provider network by an on-demand code execution service and can be associated with a specific user or account, or be generally accessible to multiple users / accounts. A serverless function can be associated with a URL (Uniform Resource Locator), a URI (Uniform Resource Identifier), or another reference that can be used to invoke the serverless function. A serverless function can be executed by a compute resource, such as a virtual machine, a container, etc., when it is triggered or invoked.In some implementations, a serverless function can be invoked through an API (Application Programming Interface) call or a specially formatted HTTP (Hypertext Transport Protocol) request message. Accordingly, users can define serverless functions that can be executed on demand without the user having to maintain dedicated infrastructure to run the serverless function. Instead, the serverless functions can be executed on demand using resources managed by the provider network. In some implementations, these resources can be kept in a "ready" state (for example, by having a pre-initialized runtime environment configured to execute the serverless functions), enabling the serverless functions to run in near real time.

[0013] As mentioned earlier, implementations include a Certificate Management Service 106 (or more generally, any type of PKI service or services) that allows users to create and manage certificate-related resources. The Certificate Management Service 106 provides numerous functions related to creating, storing, and renewing public and private certificates (e.g., SSL / TLS X.509 certificates) and keys used to protect users' websites and applications. Certificates created by the Certificate Management Service 106 can secure single domain names, multiple specific domain names, wildcard domains, or combinations thereof. For example, wildcard certificates can protect an unlimited number of subdomains. Users can also obtain certificates from a private Certificate Authority (e.g.,Export certificates signed by private CAs (108) that are managed by the Certificate Management Service (106) for use anywhere in a user's internal PKI.

[0014] As stated above, an SSL / TLS certificate enables web browsers and other applications to identify and establish encrypted network connections to websites that use the SSL / TLS protocol. Certificates are used within a cryptographic system known as a Public Key Infrastructure (PKI). PKI provides a way for one party to verify the identity of another using certificates, provided both parties trust a third party (the Certificate Authority).

[0015] In some implementations, a certificate management service (CMS) provides at least two different options for users who want to deploy managed certificate-related resources. For example, the CMS can provide public certificate management services (CMS) for users who require a secure web presence using TLS. In some implementations, certificate-related resources created by the CMS can be delivered to user resources or otherwise returned to a requesting user through other services provided by the cloud provider (such as a load balancing service, a content delivery network (CDN) service, an API gateway service, or another service where users may have deployed endpoint resources).The Certificate Management Service 106 can also provide functions that enable the automatic renewal of expiring certificates.

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

[0017] In some implementations, the certificate-related resources managed by a Certificate Management Service (CMS) are associated with a number of attributes. For example, in some implementations, certificates issued by the CMS (such as a Certificate 114) are domain-validated. The Subject field of a certificate issued by the CMS identifies a domain name. Thus, when a user requests a certificate, they confirm ownership or control of all domains specified in the request. Ownership or control of the specified domain names can be validated using email, DNS, or other methods supported by the CMS.

[0018] In some implementations, certificates issued by Certificate Management Service 106 may be associated with a defined validity period (e.g., 13 months or another time period). Certificate Management Service 106 may also manage the certificate renewal process and the provisioning of certificates after renewal. In some implementations, certificates issued by Certificate Management Service 106 are trusted by major browsers (Google Chrome, Microsoft Internet Explorer and Microsoft Edge, Mozilla Firefox, etc.) and operating systems.

[0019] In some implementations, each Certificate Management Service 106 certificate includes at least one fully qualified domain name (FQDN), and users 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 users can access the site using either of these names. Certificate Management Service 106 also allows users to create a wildcard certificate by using an asterisk (*) in the domain name, which can protect multiple sites within the same domain. For example, *.example.com protects both www.example.com and images.example.com. In some implementations, a certificate also specifies an algorithm and key size.The Certificate Management Service 106, for example, can support several public key algorithms, including but not limited to: 2048-bit RSA, 4096-bit RSA, Elliptic Prime Curve 256-bit, Elliptic Prime Curve 384-bit, etc. Certificates can be associated with other parameters, as described herein.

[0020] As mentioned earlier, users can typically control some aspects of certificate issuance using certificate templates (e.g., Template 116) or CA-specific rules. A template defines, for example, the attributes and the order of attributes to be included in a digital certificate, such as a domain name, issue date, expiration date, public key, the digital signature to be provided by the certificate authority, and so on. With CA-specific rules, users apply rules to a particular issuing certificate authority, and users cannot deviate from these rules. However, many CA administrators and other users want to issue certificates from different CAs and be able to control the details of the certificate extension values ​​created at the user level. The numbered circles in Fig. Figure 1 illustrates an example process in which a user generates a request 124 to create a certificate issuance policy; a certificate management service 106 processes the request and creates a certificate issuance policy resource (e.g., one or more certificate issuance policy resources 118A, 118B, ..., 118N) to be applied by a certificate issuance rule engine 120 as part of the global registration authority services 122 provided by the certificate management service 106; a user or resource generates a certificate issuance request 126; the certificate issuance rule engine 120 (which is separate from a variety of CA services into which the rule engine is integrated) applies one or more certificate issuance rules applicable to the request, possibly including modifying the request (e.g.,to specify certain extension values ​​or to modify other parts of the request); and a CA (e.g., the public CA services 110) that generates and returns a requested certificate 114.

[0021] In circuit "1", a customer uses electronic device 102 to send a request to the certificate management service 106 to create a certificate issuance policy. The user may be responsible for configuring, or otherwise want to configure, a set of certificate issuance rules to be applied to a set of users and / or roles (for example, users or roles defined as part of an organization). As mentioned earlier, a user has the ability to define certificate issuance policies that can be applied globally to a group of users, across different certificate authorities, and for different certificate types. This significantly reduces the overhead of managing certificate issuance within organizations.In some implementations, a user can create and configure a certificate issuance policy using an API, web-based console, CLI, or other interface provided by the Certificate Management Service 106. For example, a user who wants to configure a certificate issuance policy can log on to a web-based console provided by the Certificate Management Service 106 and provide input indicating that the user wants to configure a new rule set. The web-based console can then provide a guided set of interfaces and interface elements that request input used to define the policy.As shown, a certificate issuance request 126 can alternatively originate from a customer service 128, a control plane of another service of the provider network 100, or any other service or resource requesting the issuance of a certificate.

[0022] In some implementations, the definition of a certificate issuance policy may include, among other information, a user or group of users and / or roles to which the policy is to be applied (or to which individual rules comprising a policy are to be applied). In some implementations, the selected users or roles to which a policy or rule is to be applied may be chosen based on a selection of user accounts, roles, user groups, organizations, or other groupings of users or roles. Such user accounts, roles, user groups, and organizations may be defined using an identity and access management service provided by the Cloud Provider Network 100 or using an identity and access management system controlled by the organization configuring the policy.

[0023] In some implementations, the definition of a certificate issuance rule can include a rule statement. For example, a rule statement can specify one or more domains and further specify whether users or roles to which the rule applies are permitted or prohibited from issuing certificates for the specified domains. Another example: A rule statement can specify whether users are allowed to use wildcards as part of a domain specified in a request. As yet another example, a rule statement can specify whether it applies to public certificates, private certificates, or both. Rule statements can also specify requirements for other parameters of certain certificate issuance requests, such as a key type, key size, validity period, validation type (e.g., DNS or email validation), and so on.Other example rules include limiting the number of certificates a user can issue or a rate at which certificates are requested. The rule statements configured as part of a certificate issuance policy can be configured incrementally and updated over time, as described in more detail here.

[0024] As a concrete example, a CA administrator could configure a rule that applies to requests associated with User A when requesting public or private certificates. In this example, the rule might specify that User A can only issue certificates for the subject name "*.usera.example.com" and that the certificates must have a validity period of no more than 30 days. Another example: A rule could be applied to an entire development team of users, requiring that every certificate issued by a user on the development team contain a specific tag. As yet another example, a rule could be configured to apply to all users in an organization, requiring that a specific domain validation method be used for all requests to issue a public certificate.A rule can be configured to apply only to one or more specified certification authorities. Additionally, a template for requirements that match the rule can be specified (among many other options).

[0025] In circuit "2", the certificate management service 106 processes the request. In some implementations, the certificate management service 106 creates a certificate issuance policy resource or adds the rule to an existing certificate issuance policy resource (for example, one of the certificate issuance policy resources 118A, 118B, ..., 118N). The certificate issuance policy resources can be stored, for example, as text documents or other data structures that contain a structured representation (for example, in JSON format) of the rules contained in the policy.For example, each policy and / or rule can 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 that specifies the types of requests to which the policy or rule applies, and action information that specifies a type of action that the Certificate Issuance Rule Engine 120 should perform in response to identifying a request that matches a policy or rule.

[0026] In circuit “3”, a certificate issuance request 126 is generated and sent to the certificate management service 106. In some implementations, the request is associated with a request context that includes at least one identifier of a user account or role associated with the request, as well as several parameters relating to the requested certificate (e.g., a subject name, certificate type, validity period, key type, etc.). The request context may also contain a wide range of other information, including, but not limited to, an IP address associated with the request, a time at which the request is generated, a number of requests from the same user account or role in a previous period, a requestor type associated with the request (e.g., a user or role), and the like.

[0027] In circle "4", the Certificate Issuance Rule Engine 120 receives the request and determines whether one or more certificate issuance policies apply to the request. For example, the Certificate Issuance Rule Engine 120 can determine whether any policy applies to the user account or role associated with the request and further determine whether any certificate issuance rules contained in a policy match any request context (for example, if a certificate issuance rule applies to a request for public certificates associated with a specified domain name, the Certificate Issuance Rule Engine 120 can determine whether the request is for a public certificate for the specified domain name). As shown, the Certificate Issuance Rule Engine 120 is used by a variety of CA services (e.g.,the public CA services 110 and private CA services 112 et al.) are separated, into which the rule engine is integrated.

[0028] In the example from Fig. In step 1, the certificate issuance rule engine 120 determines that at least one policy and its associated rule apply to the certificate issuance request 126. Therefore, in circle 5, the certificate issuance rule engine 120 modifies at least one of the many parameters relating to the requested certificate in this example to obtain a modified certificate generation request. For instance, if request 126 is for a public certificate with a validity period of six months, and a rule applicable to the request limits the public certificates requested by the specific user to a maximum of three months, the certificate issuance request can be modified to change the requested validity period (e.g., possibly by modifying a certificate signing request (CSR) associated with the request).As another example, the Rule Engine 120 for certificate issuance could modify a key type or other parameter associated with the request based on one or more applicable rules. The example is shown in [reference to relevant document]. Fig. Figure 1 illustrates how a certificate issuance request is modified by the certificate issuance rule engine 120. In other examples described herein, requests may also be rejected or processed differently based on one or more applicable rules.

[0029] In circle “6”, the public CA service 110 generates the certificate 114 based on the modified request and returns it. In some embodiments, the certificate is returned to the requesting device 102, or in other examples, it can be automatically installed in one or more integrated services of the provider network 100, depending on the user request. Although this in Fig. As the example shown illustrates the interposition of a rule engine 120 for certificate issuance between requesting devices and different types of CAs within a provider network 100, a rule engine for certificate issuance can also be used in other examples to control certificate issuance requests directed to external CAs or other certificate-related services.

[0030] The in Fig. One example illustrates the use of a Rule Engine 120 for certificate issuance and configured certificate issuance policies to control the issuance of certificates across public CA services, private CA services, and the like. Other examples demonstrate the broader use of Rule Engine 120 for certificate issuance to manage and restrict the creation and use of private certificate authorities (CAs) within a user's organization, document signing solutions, and any other type of certificate services that might exist in an organization's PKI.

[0031] Fig. Figure 2 is a diagram illustrating the application of certificate issuance policy resources to multiple users within an organization and, optionally, the use of a hierarchical application of multiple certificate issuance policy resources to users, according to some implementations. As shown in Fig. As shown in Figure 2, for example, a group of users 200A, 200B, ... 200N, who are part of an organization 216, can be grouped into one or more user groups 202. Furthermore, a CA administrator or another user has configured an organization policy 204 (e.g., including rules to be applied to all users in organization 216), one or more user group policies 206A, ..., 206N, and one or more user policies 208A, ..., 208N.

[0032] In this example, a user 200A in loop "1A" generates a certificate issuance request 210 using an electronic device and requests the issuance of a public certificate 212 using public CA services 110. The certificate issuance rule engine 120A in loop "2A" determines whether one or more policies and / or rules apply to the request, at least partially based on the request context (e.g., the identity of user 200A, a role used for the request, parameters related to the requested certificate, etc.). In this example, in addition to a user policy 208A that applies specifically to user 200A, an organization policy 204 may also apply to the request, with one rule specifying that the request is allowed and a second rule specifying that a particular domain validation method should be used.The rule engine 120 for certificate issuance can thus generate a modified request to the public CA services 110, which leads to the issuance of a certificate 212 in the "3A" cycle.

[0033] Similarly, another user, 200N, in circle "1B" generates a second certificate issuance request, 210, possibly with different request parameters. For example, the second certificate issuance request, 210, could request a certificate from a private certificate authority, 108. In the example of Fig. 2. The Certificate Issuance Rule Engine 120 determines that at least one policy and / or rule applies to the second request and determines that the request is not permitted. The Certificate Issuance Rule Engine 120 therefore sends a Certificate Issuance Rejection Response 214 to the requesting user device to inform the user that the certificate issuance request was not permitted. As shown, the application of certificate issuance policies and rules can thus be hierarchical, depending on the division of an organization into user groups, etc. In some embodiments, responses can be returned to requesting devices when the Certificate Issuance Rule Engine 120 modifies a requested certificate issuance based on the application of one or more certificate issuance rules, for example.to inform the user that the request has been fulfilled, but that certain parameters may have changed.

[0034] Fig. Figure 3 is a diagram illustrating the dynamic configuration of resources for certificate issuance policies and associated certificate issuance policy rules according to some implementations. For example, a user in circle "1" in Fig. 3. A computing device 102 is used to configure a resource 300 for the certificate issuance policy, which will be applied to requests associated with any of several accounts or roles. The sample resource 300 for the certificate issuance policy is initially configured with a rule that allows users, for example, to request the issuance of certificates that can secure any subject name "*.example.com". For example, in circle "2", a certificate issuance request 302 is generated, requesting the generation of a certificate that matches the wildcard subject name. According to the current rule, the request is processed successfully, and in circle "3", a certificate 304 is returned by the certificate management service 106.

[0035] In this example, the user who originally configured the certificate issuance policy resource 300 decides at a certain point to restrict certificate issuance to a specific subject name without wildcards (e.g., "dev.example.com"). Therefore, in loop 4, the user uses a web-based console, API, CLI, or other interface to generate a policy update request 306 and modify the applicable policy / rule as desired. Later, in loop 5, a second certificate issuance request 302 is made, which matches the certificate issuance policy resource 300. In loop 6, the certificate issuance rule engine 120 rejects the request, and the requested certificate is neither created nor returned.As shown, the Rule Engine 120 for certificate issuance thus enables the creation of dynamic rules for certificate issuance, which can be changed by an organization over time as needed.

[0036] Fig. Figure 4 is a diagram illustrating the ability for users to provide custom request context in conjunction with certificate issuance requests, according to some implementations. For example, an organization might have its own 400 approval system to authorize user requests for specific certificate types. In this example, the organization's 400 approval system can receive and parse certificate issuance requests (such as a 402 certificate issuance request) and, if a request is permitted by its internal policies or procedures, generate a 404 token that verifies the requester's authorization to receive the certificate.In other examples, users can retrieve data from a Lightweight Directory Access Protocol (LDAP) system or another internal authentication system and provide the data as part of certificate issuance requests for use in conjunction with one or more configured certificate issuance policies. As in... Fig. As shown in Figure 4, such a 404 token can be provided as part of the request context of a certificate issuance request (e.g., a certificate issuance request 406) and validated in circle “3” by the certificate management service 106 before the requested certificate is generated and returned by an appropriate certificate authority.

[0037] For example, in district “1” in Fig. 4. A device 408 submits a request for a certificate to an organization's certificate issuance and approval system 400 (where the request may, for example, identify a subject name, certificate type, etc.). The certificate issuance and approval system 400 receives the request and determines, based on its own internal rules and procedures, whether the request is valid. For example, the certificate issuance and approval system 400 may determine whether the certificate issuance request is valid based on a user's identity, a subject name identified by the request, or other parameters or combinations thereof. If the certificate issuance and approval system 400 determines that the request is valid, the system returns a token 404 to the requesting device 408.

[0038] In loop "2", device 408 sends a certificate issuance request to the certificate management service 106, with the request containing the token. In loop "3", rule engine 120 or another component determines that the request matches a resource for the certificate issuance policy and processes the request accordingly. In this example, processing the request includes validating the token (e.g., by directly parsing the token, calling a serverless function to validate the token, etc.). In loop "4", rule engine 120, in response to determining that the token is valid, sends the request to a certificate authority to generate the certificate.In other examples, rule engine 120 rejects the request if it detects that a provided token is invalid or expired, and returns a response indicating that the request was rejected.

[0039] Fig. Figure 5 shows a diagram illustrating the ability for users to configure a certificate issuance policy to invoke an external approval workflow for certificate issuance, according to some implementations. Fig. 4. An organization used an external certificate issuance approval system to validate certificate issuance requests and provide data that could be used as a custom request context in a certificate issuance request sent to the Certificate Management Service 106. In the example of Fig. Instead, 5 is a certificate issuance policy resource configured to call a "hook" to an external certificate issuance approval system 500 as part of the processing of requests by a rule engine 120 for certificate issuance.

[0040] For example, imagine an organization that wants to allow its users to export a public certificate only if the certificate issuance has been approved by a specific person within the organization. In this example, the certificate issuance rule engine 120 can "hook on" the external approval system 500 whenever a user submits a public certificate issuance request. The external approval system 500 can then generate an email or a web console alert, trigger a ticketing system, or otherwise prompt the user to either approve or deny the request. A response is then sent back to the certificate issuance rule engine 120 for further processing.

[0041] For example, a computing device sends 502, as in Fig. In circle 1, a certificate issuance request (504) is sent to the certificate management service (106). In circle 2, the rule engine (120) receives the request and identifies a certificate issuance policy resource that matches the request (for example, based on the request context, including a user account or role associated with the request). In this example, the specified certificate issuance policy contains a rule indicating that requests matching the rule will cause the rule engine (120) to call an external approval system (500) for certificate issuance.

[0042] In some embodiments, the certificate issuance rule engine 120 can then send an approval request 506 for certificate issuance to the external approval system 500 and, depending on whether the internal approval processes determine that the request is permissible or not, return a corresponding approval response 508 for certificate issuance (or a rejection response in other examples). Once the certificate issuance rule engine 120 has received approval from the external approval system 500, the rule engine can instruct the appropriate certification authority to generate and issue the requested certificate (e.g., certificate 510 in circle "3").

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

[0044] Operation 600, in block 602, includes receiving a request to generate a certificate by a certificate management service, where the request is associated with a request context that includes: an identifier of a user account or role associated with the request and several parameters relating to the requested certificate.

[0045] Operations 600 in block 604 also include identifying a certificate issuance rule to be applied to the request, at least partially based on the request context.

[0046] Operations 600 in block 606 also include changing at least one of the many parameters relating to the requested certificate in order to obtain a modified request to generate the certificate.

[0047] Operations 600 also include, in block 608, the return of the certificate based on the changed request for certificate generation.

[0048] In some embodiments, the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy, which further contains a second certificate issuance rule, wherein the certificate management service provides both public certificate authority (CA) services and private certificate authority services, the second request being a request to generate a public certificate, and wherein the operations further include: receiving a third request to a private certificate authority to generate a private certificate; determining that the certificate issuance policy contains the second certificate issuance rule, which denies the generation of the private certificate based on a request context associated with the third request; and sending a response indicating that the third request was denied.

[0049] In some embodiments, the action to be performed includes at least one of the following elements: allowing a request, rejecting a request, using a specified template, or changing at least one parameter of a request;and the application of the certificate issuance rule is based on at least one of the following elements: the 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 a domain name wildcard is used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key size or certificate tag, one or more fields to be filled in by the certificate issuance rule, a rate at which the user account or role requests certificates, a volume of certificates requested by the user account or role, or a time of day.

[0050] In some embodiments, the certificate issuance rule is configured to apply to certificate issuance requests from a user group that includes a variety of user accounts or roles, including the user account or role.

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

[0052] In some embodiments, the request to generate a certificate is a first request to generate a certificate, and the operations also include: receiving a request to modify the certificate issuance rule by the certificate management service; storing a 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.

[0053] 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 operations further include: receiving a second request to generate a certificate from the 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 on at least part of the second request context; rejecting the second request based on the second certificate issuance rule; and sending a response indicating that the second request was rejected.

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

[0055] In some embodiments, the operations also include sending a request to approve the certificate generation request to an external certificate issuance approval system, wherein the approval request includes at least part of the request context, and receiving a response approving the certificate generation request.

[0056] Fig. Figure 7 illustrates an example environment of a provider network (or “service provider system”) according to some embodiments. A provider network 700 can provide customers with resource virtualization through one or more virtualization services 710, which enable customers to purchase, rent, or otherwise obtain instances 712 of virtualized resources, including, but not limited to, compute and storage resources implemented on devices within the provider network or in networks in one or more data centers. The resource instances 712 can be assigned local Internet Protocol (IP) addresses 716; the local IP addresses are the internal network addresses of the resource instances 712 on the provider network 700. In some embodiments, the provider network 700 can also use public IP addresses 714 and / or public IP address ranges (e.g.,Provide Internet Protocol Version 4 (IPv4) or Internet Protocol Version 6 (IPv6) addresses that customers can obtain from provider 700.

[0057] Traditionally, the provider network 700, through the virtualization services 710, can allow a customer of the service provider (for example, a customer operating one or more customer networks 750A-750C (or "client networks") including one or more customer devices 752) to dynamically associate at least some of the customer's assigned or allocated public IP addresses 714 with certain customer-assigned resource instances 712. The provider network 700 can also allow the customer to reassign a public IP address 714, previously assigned to one customer-assigned virtualized computing resource instance 712, to another customer-assigned virtualized computing resource instance 712.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 the operator of the customer network(s) 750A-750C, can implement customer-specific applications and present the customer's applications on an intermediate network 740, such as the Internet. Other network units 720 in the intermediate network 740 can then generate traffic to a public destination IP address 714, which is published by the customer networks 750A-750C. The traffic is forwarded to the service provider's data center and, in the data center, via a network substrate, to the local IP address 716 of the virtualized computing resource instance 712 that is currently assigned to the public destination IP address 714.Similarly, response traffic from the virtualized computing resource instance 712 can be routed via the network substrate back to the intermediate network 740 to the source unit 720.

[0058] Local IP addresses, as used here, are the internal or "private" network addresses of, for example, resource instances within a provider network. Local IP addresses may be located in address blocks reserved by Internet Engineering Task Force (IETF) Request for Comments (RFC) 1918 and / or have an address format specified by IETF RFC 4193, and may be modifiable within the provider network. Network traffic originating outside the provider network is not directly routed to local IP addresses but uses public IP addresses mapped to the local IP addresses of the resource instances. The provider network may include network devices or appliances that provide network address translation (NAT) or similar functionality to map public IP addresses to local IP addresses and vice versa.

[0059] Public IP addresses are changeable internet network addresses assigned to resource instances either by the service provider or the customer. Traffic directed to a public IP address is translated, for example, via 1:1 NAT and forwarded to the corresponding local IP address of a resource instance.

[0060] Some public IP addresses can be assigned by the provider's network infrastructure to specific resource instances. These public IP addresses can be referred to as default public IP addresses or simply default IP addresses. In some implementations, mapping a default IP address to a local IP address of a resource instance is the default startup configuration for all resource instance types.

[0061] At least some public IP addresses can be assigned to or obtained from customers of the provider's 700 network; a customer can then map their assigned public IP addresses to specific resource instances associated with that customer. These public IP addresses can be referred to as the customer's public IP addresses or simply as customer IP addresses. Unlike standard IP addresses, which are assigned to resource instances by the provider's 700 network, customer IP addresses can also be mapped to resource instances by the customers themselves, for example, via an API provided by the service provider. Furthermore, unlike standard IP addresses, customer IP addresses are assigned to customer accounts and can be mapped to different resource instances by the respective customers as needed or desired.A customer IP address is associated with a customer's account, not with a specific resource instance, and the customer controls this IP address until they choose to release it. Unlike traditional static IP addresses, customer IP addresses allow the customer to mask resource instance or availability zone outages by reassigning the customer's public IP addresses to any resource instance associated with the customer's account. For example, using customer IP addresses, a customer can work around issues with their resource instances or software by reassigning the customer IP addresses to the backup resource instances.

[0062] Fig. Figure 8 is a block diagram of an exemplary provider network environment that provides customers with a storage service and a hardware virtualization service, according to some embodiments. A hardware virtualization service 820 provides customers with multiple compute resources 824 (e.g., compute instances 825, such as VMs). The compute resources 824 can be provided, for example, as a service to customers of a provider network 800 (e.g., to a customer implementing a customer network 850). Each compute resource 824 can be equipped with one or more local IP addresses. The provider network 800 can be configured to forward packets from the local IP addresses of the compute resources 824 to public Internet destinations and from public Internet sources to the local IP addresses of the compute resources 824.

[0063] The provider network 800 can provide the customer network 850, which is coupled to an intermediate network 840, for example, via a local area network 856, with the ability to implement virtual computer systems 892 through the hardware virtualization service 820, which is coupled to the intermediate network 840 and the provider network 800. In some embodiments, the hardware virtualization service 820 can provide one or more APIs 802, such as a web service interface, through which the customer network 850 can access functions provided by the hardware virtualization service 820, for example, through a console 894 (e.g., a web-based application, stand-alone application, mobile application, etc.) of a customer device 890.In some embodiments, each virtual computer system 892 in the provider network 800 can correspond to a computing resource 824 in the customer network 850 that is leased, rented or otherwise made available to the customer network 850.

[0064] From an instance of the virtual computer system(s) 892 and / or another customer device 890 (e.g., via the console 894), the customer can access the functionality of a storage service 810, e.g., via one or more APIs 802, to store data to and from storage resources 818A-818N of a virtual datastore 816 (e.g., a folder or "bucket," a virtualized volume, a database, etc.) provided by the provider network 800. In some embodiments, a virtualized datastore gateway (not shown) can be provided in the customer network 850. This gateway can cache at least some data locally, such as frequently accessed or critical data, and can communicate with the storage service 810 via one or more communication channels to upload new or modified data from a local cache, thus preserving the primary datastore (the virtualized datastore 816).In some embodiments, a user can provide and access virtual storage devices 816 via the virtual computer system 892 and / or another customer device 890 through the storage service 810, which acts as a storage virtualization service, and these storage devices can be presented to the user as local (virtualized) storage 898.

[0065] Although in Fig. Although not shown in Figure 8, the virtualization services can also be accessed from resource instances within the provider network 800 via API(s) 802. For example, a customer, appliance service provider, or other entity can access a virtualization service via API(s) 802 from within a corresponding virtual network in the provider network 800 to request an allocation of one or more resource instances within that virtual network or within another virtual network.

[0066] In some embodiments, a system implementing some or all of the techniques described herein may include a general-purpose computer system, such as the one described in Fig. Figure 9 shows a computer system 900, which 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 connected 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. While Fig. 9 where the computer system 900 is shown as a single computing unit, the computer system 900 can, in various embodiments, comprise a computing unit or any number of computing units configured to work together as a single computer system 900.

[0067] In various embodiments, the Computer System 900 can be a single-processor system with one processor 910 or a multi-processor system with several processors 910 (e.g., two, four, eight, or any other suitable number). The processor(s) 910 can be any suitable processor capable of executing instructions. For example, the processor(s) 910 can be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, ARM, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multi-processor systems, each of the processors 910 can typically, but not necessarily, implement the same ISA.

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

[0069] In some embodiments, the I / O interface 930 can be configured to coordinate I / O traffic between the processor 910, the system memory 920, and all 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 can perform any necessary protocol, time, 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, the I / O interface 930 can include support for devices connected via various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard.In some embodiments, the function of the I / O interface 930 can be divided into two or more separate components, such as a north bridge and a south bridge. Furthermore, in some embodiments, some or all functions of the I / O interface 930, for example, an interface to the system memory 920, can be integrated directly into the processor 910.

[0070] The network interface 940 can be configured to enable data exchange between the computer system 900 and other devices 960 connected to one or more networks 950, such as other computer systems or devices, as described in Fig.Figure 1 illustrates this. In various embodiments, the Network Interface 940 can support communication over any suitable wired or wireless general-purpose data network, such as types of Ethernet networks. Furthermore, the Network Interface 940 can support communication over telecommunications / telephony networks, such as analog voice networks or digital fiber optic communication networks, over storage area networks (SANs), such as Fibre Channel SANs, and / or over any other suitable network type and / or protocol.

[0071] In some embodiments, the Computer System 900 comprises one or more offload cards 970A or 970B (including one or more processors 975 and possibly including one or more network interfaces 940) connected using the I / O interface 930 (e.g., a bus implementing a version of the PCI-E (Peripheral Component Interconnect - Express) standard, or another connection such as a QuickPath (QPI) or UltraPath (UPI) connection). For example, in some embodiments, the Computer System 900 can function as an electronic host device (e.g., operated as part of a hardware virtualization service) that hosts computing resources such as compute instances, and one or more offload cards 970A or 970B execute a virtualization manager capable of managing compute instances running on the electronic host device.For example, in some embodiments, the 970A or 970B offload cards can perform compute instance management operations, such as pausing and / or resuming compute instances, starting and / or stopping compute instances, performing memory transfer / copy operations, and so on. In some embodiments, these management operations can be performed by the 970A or 970B offload cards in coordination with a hypervisor (e.g., at the request of a hypervisor) run by the other 910A-910N processors of the 900 computer system. However, in some embodiments, the virtualization manager implemented by the 970A or 970B offload card(s) can handle requests from other entities (e.g., the compute instances themselves) and cannot coordinate with (or service) a separate hypervisor.

[0072] In some embodiments, the system memory 920 can be an embodiment of a computer-accessible medium configured to store program instructions and data as described above. In other embodiments, however, program instructions and / or data can be received, sent, or stored on other types of computer-accessible media. Generally speaking, a computer-accessible medium can include any non-volatile storage medium or storage medium such as magnetic or optical media, e.g., a floppy disk or DVD / CD, connected to the computer system 900 via the I / O interface 930. A non-volatile, computer-accessible storage medium can also include any volatile or non-volatile medium such as RAM (e.g., SDRAM, Double Data Rate (DDR) SDRAM, SRAM, etc.), read-only memory (ROM), etc., which in some embodiments of the computer system 900 may be included as system memory 920 or as another type of memory.Furthermore, a computer-accessible medium may include transmission media or signals such as electrical, electromagnetic, or digital signals that are transmitted via a communication medium such as a network and / or a wireless connection, as may be implemented via the Network Interface 940.

[0073] The various embodiments can furthermore be implemented in a wide variety of operating environments, which in some cases may include one or more user computers, computing devices, or processing devices that can be used to run any one of a number of applications. User or client devices can include any number of general-purpose computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless, and portable devices running mobile software and capable of supporting a range of networking and messaging protocols.Such a system may also include a number of workstations running any of a variety of commercially available operating systems and other well-known applications for purposes such as development and database management. These devices may also include other electronic equipment, such as dummy terminals, thin clients, gaming systems, and / or other devices capable of communicating over a network.

[0074] Most embodiments use at least one network known to those skilled in the art to support communications using a variety of widely used 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 networks 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.

[0075] In implementations that use a web server, the web server can run a variety of server or mid-tier applications, including HTTP servers, File Transfer Protocol (FTP) servers, Common Gateway Interface (CGI) servers, data servers, Java servers, business application servers, and so on. The server(s) can also be capable of executing programs or scripts in response to requests from user devices, such as by running one or more web applications, which can be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C#, or C++, or any scripting language, such as Perl, Python, PHP, or TCL, and combinations thereof. The servers can also include database servers, including, in particular, those commercially available from Oracle®, Microsoft®, Sybase®, IBM®, and so on. The database servers can be relational or non-relational (e.g.,"NoSQL"), distributed or not distributed, etc.

[0076] The environments disclosed herein may include a variety of data storage devices and other storage media, as discussed above. These may be located in a variety of places, such as on a storage medium that is local to (and / or located within) one or more of the computers, or remote from any or all of the computers across the network. In a certain set of embodiments, the information may be stored in a Storage Area Network (SAN) known to those skilled in the art. Likewise, all files required to perform the functions assigned to the computers, servers, or other network devices may be stored locally and / or remotely, as needed.If a system includes computerized devices, 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., a mouse, keyboard, controller, touchscreen, or keypad), and / or at least one output device (e.g., a display, printer, or loudspeaker). 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 cards, etc.

[0077] Such devices may also include a computer-readable storage media reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and working memory, as described above. The computer-readable storage media reader may be connected to, or designed to accommodate, a computer-readable storage medium, which may be remote, local, fixed, and / or removable storage devices and media for the temporary and / or permanent containment, storage, transmission, and retrieval of computer-readable information.The system and its various devices also typically include a number of software applications, modules, services, or other elements located within at least one memory device, including an operating system and application programs, such as a client application or a web browser. It is understood that alternative embodiments may exhibit numerous variations from the one described above. For example, customized hardware may be used, and / or specific elements may be implemented in hardware, software (including portable software such as applets), or both. Furthermore, a connection to other computing devices, such as network input / output devices, may be implemented.

[0078] Storage media and computer-readable media containing code or parts of code may include any suitable media known or used in the field, including storage and communication media such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing and / or transmitting information, such as computer-readable instructions, data structures, program modules, or other data, including RAM, ROM, electrically erasable programmable read-only memory (“EEPROM”), flash memory, or any other storage technology, compact disc read-only memory (“CD-ROM”), digital versatile disc (DVD), or any other optical storage medium, magnetic cartridges, magnetic tape, magnetic disk storage, or any other magnetic storage device, or any other medium that can be used for this purpose.to store the desired information, and which can be accessed by a system device.

[0079] Text in brackets and blocks with dashed borders (e.g., capitals, dashes, semicolons, and dots) are used here to illustrate optional operations that add extra functionality to some embodiments. However, such notation should not be interpreted as meaning that these are the only options or optional operations, and / or that blocks with solid borders are not optional in certain embodiments.

[0080] Reference numbers with appended letters (e.g., 918A-918N) can be used to indicate that there may be one or more instances of the referenced entity in different embodiments. If multiple instances exist, they need not all be identical but may instead share some general characteristics or act in a common manner. Furthermore, the suffixes used do not imply that a specific quantity of the entity exists unless explicitly stated otherwise. Therefore, two entities using the same or different suffix letters may or may not have the same number of instances in different embodiments.

[0081] Unless explicitly stated otherwise, articles such as "a" or "an" should generally be interpreted as including one or more of the described elements. Accordingly, expressions such as "a device configured for this purpose" or "a computing device" are intended to include one or more of the named devices. These single or multiple devices can be configured together to perform the specified operations. For example, "a processor configured to perform operations A, B, and C" may include a first processor configured to perform operation A, working in conjunction with a second processor configured to perform operations B and C.

[0082] At least some embodiments of the disclosed technologies can be described with regard to the following sections: 1. Computer-implemented method, including: Receiving an initial request to create a certificate issuance policy by a certificate management service of a cloud provider, where the initial request specifies the following: one or more user accounts or roles to which the certificate issuance policy should be applied, and a rule for issuing certificates, including an action to be carried out in respect of requirements that comply with the rule for issuing certificates; Storing a resource for the certificate issuance policy, including a representation of the certificate issuance rule; Receiving a second request to generate a certificate, wherein the second request is associated with a user account or role and wherein the second request includes a variety of parameters relating to the generation of the requested certificate; Determine, through a rule engine of the certificate management service, that the certificate issuance policy applies to the user account or user account role, wherein the rule engine is separate from a variety of certificate authority services (CA services) into which the rule engine is integrated; Change at least one of the several parameters of the second requirement based on the certificate issuance rule to obtain a modified second requirement; and Return the certificate based on the amended second request. 2. The computer-implemented method of Section 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 requirement is a requirement to generate a public certificate, and wherein the method further comprises: Receiving a third request to a private certification authority to generate a private certificate; Specify that the certificate issuance policy includes a second certificate issuance rule that denies the generation of the private certificate based on a requirement context linked to the third requirement; and Sending a response indicating that the third request was rejected. 3. The computer-implemented method according to one of Sections 1 or 2, wherein the action to be performed includes at least one of the following: allowing a request, rejecting a request, using a specified template, or modifying at least one parameter of a request; and The application of the certificate issuance rule is based on at least one of the following elements: the 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 a domain name wildcard is used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key size or certificate tag, one or more fields to be filled in by the certificate issuance rule, a rate at which the user account or role requests certificates, a volume of certificates requested by the user account or role, or a time of day. 4. Computer-implemented method, including: Receiving a request to generate a certificate by a public key infrastructure (PKI) service, where the request is associated with a request context that includes: an identifier of a user account or role associated with the request and several parameters relating to the requested certificate; Identifying a certificate issuance rule by a rule engine of the PKI service that is to be applied to the request at least partially based on the request context, wherein the rule engine is separate from a variety of certificate authority services (CA services) into which the rule engine is integrated; Changing at least one of the many parameters relating to the requested certificate in order to obtain a modified request to generate the certificate; and Returning the certificate based on the changed request to generate the certificate. 5. The computer-implemented method of Section 4, wherein the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy which contains 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 the certificate is a request to generate a public certificate, and wherein the method further comprises: Receiving a second request to a private certification authority to generate a private certificate; Specify that the certificate issuance policy includes a second certificate issuance rule that denies the generation of the private certificate based on a requirement context associated with the second requirement; and Sending a response indicating that the second request was rejected. 6. The computer-implemented method according to one of Sections 4 or 5, wherein the action to be performed based on the certificate issuance rule includes at least one of the following: allowing a request, rejecting a request, using a specified template, or modifying at least one parameter of a request; and The application of the certificate issuance rule is based on at least one of the following elements: the 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 request, whether a domain name wildcard is used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key size or certificate tag, one or more fields to be filled in by the certificate issuance rule, a rate at which the user account or role requests certificates, a volume of certificates requested by the user account or role, or a time of day. 7. The computer-implemented method according to any of Sections 4 to 6, wherein the certificate issuance rule is configured to be applied to certificate issuance requests of a user group that includes a multitude of user accounts or roles, including the user account or role. 8. The computer-implemented method according to any of Sections 4 to 7, wherein a certificate issuance policy comprising the certificate issuance rule is a first certificate issuance policy, wherein the first certificate issuance policy applies to a user group comprising the user account or user account role, wherein a second certificate issuance policy further applies to the request, and wherein the second certificate issuance policy applies to the user account. 9. The computer-implemented method according to any of Sections 4 to 8, wherein the requirement to generate a certificate is a first requirement to generate a certificate, and wherein the method further comprises: Receiving a request to change the certificate issuance rule by the PKI service; Saving a modified certificate issuance rule based on the request; Receiving a second request to generate a certificate; and Applying the amended certificate issuance rule to the second requirement. 10. The computer-implemented method according to any of Sections 4 to 9, wherein the request to generate a certificate is a first request to generate a certificate, the request context is the first request context, the certificate issuance rule is a first certificate issuance rule, and wherein the method further comprises: Receiving a second request to generate a certificate by the PKI service, where the second request is associated with a second request context; Identify a second certificate issuance rule to be applied to the second requirement based on at least part of the second requirement context; Rejection of the second requirement based on the second certificate issuance rule; and Sending a response indicating that the second request was rejected. 11. The computer-implemented procedure according to any of Sections 4-10, wherein the request context further includes a token generated by an external system for authorizing certificate issuance, and wherein the procedure further includes validating the token. 12. The computer-implemented method according to any of Sections 4-11, further comprising: Sending a request for approval of the certificate generation request to an external certificate issuance approval system, wherein the approval request includes at least part of the request context; and Received a response approving the request to generate the certificate. 13. The computer-implemented method according to any of Sections 4-12, further comprising: Receiving an initial request to create a private Certificate Authority (CA); Receiving a second request to create at least one certificate issuance rule to be applied to certificate issuance requests directed to the private CA; and Create the private CA with at least one certificate issuance rule. 14. System, comprehensive: a first electronic device or multiple electronic devices for implementing a certificate management service in a multi-tenant provider network, wherein the certificate management service includes instructions which, when executed, cause the certificate management service to: Receiving a request to generate a certificate, wherein the request is associated with a request context that includes: an identifier of a user account or role associated with the request and several parameters relating to the requested certificate; Identifying a certificate issuance rule by a certificate management service to be applied to the request, at least partially, based on the request context, wherein the rule engine is separate from a variety of certificate authority (CA) services into which the rule engine is integrated; Changing at least one of the many parameters relating to the requested certificate in order to obtain a modified request to generate the certificate; and Returning the certificate based on the modified request to generate the certificate; and a second or more electronic devices for implementing a computing service in a multi-tenant provider network, wherein the computing service includes instructions which, when executed, cause the computing service to: obtain the certificate and install the certificate for use by a computing instance. 15. The system according to section 14, wherein the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy which contains 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, upon execution, cause the following for the certificate management service: Receiving a second request to a private certification authority to generate a private certificate; Specify that the certificate issuance policy includes a second certificate issuance rule that denies the generation of the private certificate based on a requirement context associated with the second requirement; and Sending a response indicating that the second request was rejected. 16. The system according to one of sections 14 or 15, wherein the action to be performed based on the certificate issuance rule includes at least one of the following: allowing a request, rejecting a request, using a specified template, or changing at least one parameter of a request; and The application of the certificate issuance rule is based on at least one of the following elements: the 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 request, whether a domain name wildcard is used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key size or certificate tag, one or more fields to be filled in by the certificate issuance rule, a rate at which the user account or role requests certificates, a volume of certificates requested by the user account or role, or a time of day. 17. The system according to any of sections 14 to 16, wherein the certificate issuance rule is configured to be applied to certificate issuance requests from a user group that includes a variety of user accounts or roles, including the user account or role. 18. The system according to any of Sections 14 to 17, wherein a certificate issuance policy comprising the certificate issuance rule is a first certificate issuance policy, wherein the first certificate issuance policy applies to a user group comprising the user account or user account role, wherein a second certificate issuance policy further applies to the request, and wherein the second certificate issuance policy applies to the user account. 19. The system according to any of Sections 14 to 18, wherein the request to generate a certificate is a first request to generate a certificate and wherein, when executed, the instructions also cause the certificate management service to perform the following: Receipt of a request to change the certificate issuance rule by the certificate management service; Saving a modified certificate issuance rule based on the request; Receiving a second request to generate a certificate; and Applying the amended certificate issuance rule to the second requirement. 20. The system according to any of Sections 14 to 19, wherein the request to generate a certificate is a first request to generate a certificate, the request context is the first request context, the certificate issuance rule is a first certificate issuance rule, and wherein, upon execution, the instructions also cause the certificate management service to perform the following: Receiving a second request to generate a certificate by the certificate management service, where the second request is associated with a second request context; Identify a second certificate issuance rule to be applied to the second requirement based on at least part of the second requirement context; Rejection of the second requirement based on the second certificate issuance rule; and

[0083] Sending a response indicating that the second request was rejected.

Claims

[1] Computer-implemented method, comprising: Receiving an initial request (124) to generate a certificate issuance policy by a certificate management service (106) of a cloud provider, wherein the initial request (124) indicates: one or more user accounts or roles to which the certificate issuance policy should be applied, and a certificate issuance rule, including an action to be performed in respect of requirements that comply with the certificate issuance rule; Storing a certificate issuance policy resource that contains a representation of the certificate issuance rule specified in the first request (124); Receiving a second request to generate a certificate, wherein the second request is associated with a user account or role, and wherein the second request includes a variety of parameters relating to the generation of the requested certificate; Determine, by means of a rule engine (120) of the certificate management service (106), that the certificate issuance policy applies to the user account or user account role associated with the second request, wherein the rule engine (120) within the certificate management service (106) is separated from a variety of certificate authority services (CA services) into which the rule engine (120) is integrated via an application programming interface (API); based on the certificate issuance rule specified in the first requirement (124), modifying at least one of the multiple parameters of the second requirement to obtain a modified second requirement; Generating the certificate based on the amended second requirement; and Returning the generated certificate (114) in response to the second request. [2] Computer-implemented method according to claim 1, wherein the certificate issuance rule is a first certificate issuance rule, wherein the certificate management service (106) provides both public certificate authority services (CA services) and private CA services, wherein the second requirement is a requirement to generate a public certificate (212), and wherein the method further comprises: Receiving a third request to a private CA to generate a private certificate; Specify that the certificate issuance policy includes a second certificate issuance rule that denies the generation of the private certificate based on a requirement context linked to the third requirement; and Sending a response indicating that the third request was rejected. [3] Computer-implemented method according to claim 1, wherein the action to be performed comprises at least one of the following: allowing a request, rejecting a request, using a specified template (116) or changing at least one parameter of a request;and the application of the certificate issuance rule is based on at least one of the following elements: the user account or role associated with the second request, a user group (200, 202) of which the user account or role is a member, a domain name specified in the second request, whether a domain name wildcard is used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key size or certificate tag, one or more fields to be completed by the certificate issuance rule, a rate at which the user account or role requests certificates, a volume of certificates requested by the user account or role, or a time of day. [4] Computer-implemented method, comprising: Receiving an initial request specifying a certificate issuance rule, wherein the certificate issuance rule includes an action to be performed in respect of requests that comply with the certificate issuance rule; Receiving a second request to generate a certificate by a public key infrastructure (PKI) service, wherein the second request is associated with a request context that includes: an identifier of a user account or role associated with the second request and several parameters relating to the requested certificate (114); Identifying by a rule engine (120) of the PKI service that the certificate issuance rule should be applied to the second request at least partially based on the request context, wherein the rule engine (120) is separated within the PKI service from a variety of certificate authority services (CA services) into which the rule engine (120) is integrated via an application programming interface (API); based on the certificate issuance rule specified in the first request, modifying at least one of the multitude of parameters relating to the requested certificate (114) to obtain a modified request to generate the certificate; Generating the certificate based on the modified certificate generation request; and Returning the generated certificate (114) in response to the second request. [5] Computer-implemented method according to claim 4, wherein the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy which contains a second certificate issuance rule, wherein a certificate management service (106) provides both public certificate authority services (CA services) and private CA services, wherein the second requirement to generate the certificate is a requirement to generate a public certificate (212), and wherein the method further comprises: Receiving a third request to a private certification authority to generate a private certificate; Determine that the certificate issuance policy includes the second certificate issuance rule, which denies the generation of the private certificate based on a requirement context linked to the third requirement; and Sending a response indicating that the third request was rejected. [6] Computer-implemented method according to claim 4, wherein the action to be performed based on the certificate issuance rule comprises at least one of the following: allowing a request, rejecting a request, using a specified template (116) or changing at least one parameter of a request;and the application of the certificate issuance rule is based on at least one of the following elements: the user account or role associated with the second request, a user group (200, 202) of which the user account or role is a member, a domain name specified in the second request, whether a domain name wildcard is used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key size or certificate tag, one or more fields to be filled in by the certificate issuance rule, a rate at which the user account or role requests certificates, a volume of certificates requested by the user account or role, or a time of day. [7] Computer-implemented method according to claim 4, wherein the certificate issuance rule is configured to be applied to certificate issuance requests (126) of a user group (200, 202) comprising a plurality of user accounts or roles, including the user account or role. [8] Computer-implemented method according to claim 4, wherein a certificate issuance policy comprising the certificate issuance rule is a first certificate issuance policy, wherein the first certificate issuance policy applies to a user group (200, 202) comprising the user account or user account role, wherein a second certificate issuance policy further applies to the second request and wherein the second certificate issuance policy applies to the user account. [9] Computer-implemented method according to claim 4, wherein the second requirement is to generate a first certificate, and wherein the method further comprises: Receiving a request to change the certificate issuance rule by the PKI service; Saving a modified certificate issuance rule based on the request to change the certificate issuance rule; Receiving a third request to generate a second certificate; and Applying the amended certificate issuance rule to the third requirement. [10] Computer-implemented method according to claim 4, wherein the second requirement is to generate a first certificate, the requirement context is the first requirement context, the certificate issuance rule is a first certificate issuance rule, and wherein the method further comprises: Receiving a third request to generate a second certificate by the PKI service, where the third request is associated with a second request context; Identify a second certificate issuance rule to be applied to the third requirement based on at least part of the second requirement context; Rejection of the third requirement based on the second certificate issuance rule; and Sending a response indicating that the third request was rejected. [11] Computer-implemented method according to claim 4, wherein the request context further comprises a token generated by an external system for authorizing the issuance of certificates, and wherein the method further comprises validating the token. [12] Computer-implemented method according to claim 4, further comprising: Sending a request to an external certificate issuance approval system to approve the second requirement for generating the certificate, wherein the approval request includes at least part of the request context; and Received a response approving the second requirement to generate the certificate. [13] Computer-implemented method according to claim 4, wherein the second requirement is directed to the creation of a private certification authority, CA (108). [14] System, encompassing: one or more first electronic devices (104) to implement a certificate management service (106) in a multi-tenant provider network (100), wherein the certificate management service (106) comprises instructions which, when executed, cause the certificate management service (106): receives an initial request specifying a certificate issuance rule, wherein the certificate issuance rule includes an action to be performed with respect to requests that conform to the certificate issuance rule; a second request to generate a certificate, the second request being associated with a request context that includes: an identifier of a user account or role associated with the request and several parameters relating to the requested certificate (114); Identifies, at least partially based on the request context, using a rule engine (120) of the certificate management service (106), that the certificate issuance rule should be applied to the second request, wherein the rule engine (120) within the certificate management service (106) is separated from a variety of certificate authority services (CA services) into which the rule engine (120) is integrated via an application programming interface (API); based on the certificate issuance rule specified in the first request, at least one of the multiple parameters relating to the requested certificate (114) is modified to obtain a modified request to generate the certificate; the certificate is generated based on the modified certificate generation request; and the generated certificate (114) returns in response to the second request; and one or more second electronic devices (104) for implementing a computing service in a multi-tenant provider network (100), the computing service comprising instructions which, when executed, cause the computing service to: the certificate returned by the Certificate Management Service (106), and The certificate received from the Certificate Management Service (106) is installed for use by a compute instance. [15] System according to claim 14, wherein the certificate issuance rule is a first certificate issuance rule of a certificate issuance policy which contains a second certificate issuance rule, wherein the certificate management service (106) provides both public certificate authority services (CA services) and private CA services, wherein the second requirement is a requirement to generate a public certificate (212), and wherein the instructions, upon execution, cause the following for the certificate management service (106): Receiving a third request to a private CA to generate a private certificate; Specify that the certificate issuance policy includes a second certificate issuance rule that denies the generation of the private certificate based on a requirement context linked to the third requirement; and Sending a response indicating that the third request was rejected. [16] System according to claim 14, wherein the action to be performed based on the certificate issuance rule comprises at least one of the following: allowing a request, rejecting a request, using a specified template (116) or changing at least one parameter of a request;and the application of the certificate issuance rule is based on at least one of the following elements: the user account or role associated with the second request, a user group (200, 202) of which the user account or role is a member, a domain name specified in the second request, whether a domain name wildcard is used, a requested certificate validity period, a requested cryptographic key type, a requested cryptographic key size or certificate tag, one or more fields to be filled in by the certificate issuance rule, a rate at which the user account or role requests certificates, a volume of certificates requested by the user account or role, or a time of day. [17] System according to claim 14, wherein the certificate issuance rule is configured to be applied to certificate issuance requests (126) of a user group (200, 202) which includes a plurality of user accounts or roles, including the user account or role. [18] System according to claim 14, wherein a certificate issuance policy comprising the certificate issuance rule is a first certificate issuance policy, wherein the first certificate issuance policy applies to a user group (200, 202) comprising the user account or user account role, wherein a second certificate issuance policy further applies to the request and wherein the second certificate issuance policy applies to the user account. [19] System according to claim 14, wherein the second requirement is a requirement to generate a first certificate, and wherein, upon execution, the instructions also cause the certificate management service (106) to perform the following: Receiving a request to change the certificate issuance rule by the Certificate Management Service (106); Saving a modified certificate issuance rule based on the certificate issuance rule change request; Receiving a third request to generate a second certificate; and Applying the amended certificate issuance rule to the third requirement. [20] System according to claim 14, wherein the second requirement is a requirement to generate a first certificate, the requirement context is the first requirement context, the certificate issuance rule is a first rule for issuing a certificate, and wherein, upon execution, the instructions also cause the certificate management service (106) to perform the following: Receiving a third request to generate a second certificate by the certificate management service (106), wherein the third request is associated with a second request context; Identify a second certificate issuance rule to be applied to the third requirement based on at least part of the second requirement context; Rejection of the third requirement based on the second certificate issuance rule; and Sending a response indicating that the third request was rejected.

Images