Verification of certificate packages with asymmetric keys

Abstract

Operations of a certificate package verification service may include receiving a first certificate package including a first set of one or more digital certificates, and a digital signature associated with the first certificate package; determining, using a public key of an asymmetric key pair associated with a second set of the one or more digital certificates, that the digital signature is generated using a private key of the asymmetric key pair; and in response to determining that the digital signature is generated using the private key, storing the first certificate packet as a trusted certificate packet in a certificate repository.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the distribution of certificate bundles including digital certificates. More specifically, the present disclosure relates to the digital signing and verification of certificate bundles including digital certificates using asymmetric keys. BACKGROUND

[0002] A virtual cloud network includes network entities that communicate with each other. Communication between network entities can be performed according to a security protocol whereby network entities authenticate each other by presenting digital certificates. When a network entity presents a valid digital certificate to another network entity, the other network entity can trust that it is communicating with the one network entity (and not some unknown entity) based on a trust relationship with the CA that issued the digital certificate.

[0003] Digital certificates can be issued to network entities by a CA. A digital certificate can include a digital signature generated using a private key of the CA that issued the digital certificate. The digital signature can be verified using a CA certificate of the CA that includes a public key corresponding to the private key. Various CA certificates that can be used to verify digital certificates issued to various network entities can be included in a certificate bundle. The certificate bundle can be distributed to network entities throughout a virtual cloud network. For example, the certificate bundle can be installed when the virtual cloud network is initialized and / or when various network entities on the virtual cloud network are initialized. Further, the certificate bundle can be updated or replaced from time to time, e.g., to make new CA certificates available to network entities and / or to remove old CA certificates.

[0004] The mere inclusion of the content of this Background section in this document should not be taken as an acknowledgment or admission that the content is prior art. BRIEF DESCRIPTION OF DRAWINGS

[0005] The embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:

[0006] Figures 1-4 is a block diagram illustrating a mode for implementing a cloud infrastructure as a service system according to one or more embodiments;

[0007] Figure 5 is a hardware system according to one or more embodiments;

[0008] Figure 6A and Figure 6B illustrates features of an example system according to one or more embodiments;

[0009] Figure 7is a flow diagram illustrating an example certificate bundle distribution process for distributing a set of CA certificates to network entities associated with a virtual cloud network, in accordance with one or more embodiments; and

[0010] Figure 8 is a flow diagram illustrating example operations related to verifying a certificate bundle, in accordance with one or more embodiments. DETAILED DESCRIPTION

[0011] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. One or more embodiments can be practiced without these specific details. Features described in one embodiment can be combined with features described in a different embodiment. In some examples, well-known structures and devices are described with reference to block diagrams in order to avoid obscuring the present description.

[0012] 1. OVERALL SUMMARY

[0013] 2. CLOUD COMPUTING TECHNOLOGY

[0014] 3. COMPUTER SYSTEM

[0015] 4. ARCHITECTURE OVERVIEW

[0016] 5. CERTIFYING NETWORK ENTITIES

[0017] 6. EXAMPLE CERTIFICATE BUNDLE DISTRIBUTION PROCESS

[0018] 7. VERIFYING A CERTIFICATE BUNDLE

[0019] 8. OTHER MATTERS; EXTENSIONS

[0020] 1. OVERALL SUMMARY

[0021] One or more embodiments use an asymmetric key pair associated with one or more digital certificates in a current certificate bundle to verify a new certificate bundle. A system can distribute the new certificate bundle along with a digital signature associated with the new certificate bundle. The new certificate bundle can include one or more new digital certificates associated with a new asymmetric key pair. The digital signature can be generated by applying a hash function to the new certificate bundle to obtain a first hash value and digitally signing the first hash value using a private key of the asymmetric key pair associated with the current certificate bundle.

[0022] A system can verify a new certificate package by applying a hash function to the new certificate package to obtain a second hash value, decrypting the digital signature using a public key of an asymmetric key pair to obtain a third hash value, and comparing the third hash value to the second hash value. A match between the third hash value and the second hash value indicates that the private key used to digitally sign the first hash value and the public key used to decrypt the digital signature represent an asymmetric key pair associated with one or more digital certificates in a currently trusted certificate package. Responsive to determining that the third hash value matches the second hash value, the new certificate package can be stored as a trusted certificate package in a certificate repository. The certificate repository can include a data structure identifying the new certificate package as a trusted certificate package. Thus, by digitally signing the new certificate package using the private key of the asymmetric key pair associated with the current certificate package, trust can be established for the new certificate package based on the current certificate package.

[0023] One or more embodiments described in this specification and / or claimed in the claims can not be included in this "SUMMARY" section.

[0024] 2. Cloud computing technology

[0025] Infrastructure as a Service (IaaS) is one application of cloud computing technology. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In an IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, the IaaS provider can also provision various services to accompany these infrastructure components (example services include billing software, monitoring software, logging software, load balancing software, clustering software, etc.). Thus, because these services can be policy driven, an IaaS user can be able to implement policies to drive load balancing to maintain availability and performance of applications.

[0026] In some cases, an IaaS customer can access resources and services over a wide area network (WAN), such as the Internet, and can use the cloud provider's services to install the remaining elements of an application stack. For example, a user can log into an IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software into that VM. The customer can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting applications, monitoring performance, managing disaster recovery, etc.

[0027] In some cases, the cloud computing model will involve the participation of a cloud provider. The cloud provider can, but does not necessarily, specialize in providing (e.g., provisioning, renting, selling) IaaS. An entity can also choose to deploy a private cloud, thereby becoming its own infrastructure service provider.

[0028] In some examples, an IaaS deployment is a process to implement a new application or a new version of an application on a prepared application server or other similar device. An IaaS deployment can also include a process to prepare a server (e.g., install libraries, daemons, etc.). The deployment process is typically managed by the cloud provider, below the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Thus, the customer can be responsible for the process (OS), middleware, and / or application deployment (e.g., on a self-service virtual machine (e.g., that can be launched on-demand), etc.).

[0029] In some examples, IaaS provisioning can refer to the acquisition of computers or virtual hosts for use, even the installation of required libraries or services on them. Most of the time, deployment does not include provisioning, and provisioning can need to be performed first.

[0030] In some cases, IaaS provisioning faces challenges. The initial challenge is in provisioning the initial set of infrastructure. After the initial provisioning is complete, the evolution of the existing infrastructure (e.g., adding new services, changing services, removing services, etc.) also faces additional challenges. In some cases, both challenges can be addressed by enabling the configuration of the infrastructure to be defined in a declarative manner. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., what resources depend on what resources, and how they work together) can be described in a declarative manner. In some cases, once the topology is defined, a workflow to create and / or manage the different components described in the configuration file can be generated.

[0031] In some examples, an infrastructure can have many interconnected elements. For example, there can be one or more virtual private clouds (VPCs) (e.g., a potential on-demand pool of configurable and / or shareable computing resources), also referred to as a core network. In some examples, there can also be one or more ingress / egress traffic group rules provisioned to define how inbound and / or outbound traffic will be set up, and one or more virtual machines (VMs). Other infrastructure elements can also be provisioned, such as load balancers, databases, etc. As more and more infrastructure elements are desired and / or added, the infrastructure can evolve step by step.

[0032] In some cases, continuous deployment techniques can be employed to enable deployment of infrastructure code across various virtual computing environments. Further, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is desired to be deployed to one or more, but typically many, different production environments (e.g., across various different geographic locations, sometimes spanning the entire world). In some embodiments, the infrastructure and resources can be provisioned (manually and / or using provisioning tools) prior to deployment of the code to be executed on the infrastructure. However, in some examples, the infrastructure on which the code is to be deployed must first be set up. In some cases, provisioning can be done manually, resources can be provisioned with provisioning tools, and / or code can be deployed with deployment tools once the infrastructure is provisioned.

[0033] Figure 1 is a block diagram illustrating an example schema 100 of an IaaS architecture, in accordance with at least one embodiment. A service operator 102 can be communicatively coupled to a secure host tenancy 104, which can include a virtual cloud network (VCN) 106 and a secure host subnet 108. In some examples, the service operator 102 can use one or more client computing devices, which can be portable handheld devices (e.g., iPhone®, cell phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head mounted display), running software such as Microsoft Windows Mobile® and / or various mobile operating systems (e.g., iOS, Windows Phone, Android, BlackBerry 8, PalmOS, etc.) and enabling Internet, e-mail, Short Message Service (SMS), Blackberry®, or other communications protocols. Alternatively, the client computing devices can be general purpose personal computers including, by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. The client computing devices can be workstation computers running any of a variety of commercially-available UNIX® or UNIX-like operating systems, including, without limitation, the variety of GNU / Linux operating systems, such as, for example, Google Chrome OS. Alternatively, or additionally, client computing devices can be any other electronic device capable of

[0034] VCN 106 can include a local peering gateway (LPG) 110, which can be communicatively coupled to a secure shell (SSH) VCN 112 via the LPG 110 contained in the SSH VCN 112. The SSH VCN 112 can include an SSH subnet 114, and the SSH VCN 112 can be communicatively coupled to a control plane VCN 116 via the LPG 110 contained in the control plane VCN 116. Also, the SSH VCN 112 can be communicatively coupled to a data plane VCN 118 via the LPG 110. The control plane VCN 116 and the data plane VCN 118 can be contained in a service tenancy 119, which can be owned and / or operated by an IaaS provider.

[0035] The control plane VCN 116 can include a control plane demilitarized zone (DMZ) tier 120 that acts as a perimeter network (e.g., a portion of a company network between a company intranet and an external network). DMZ-based servers can assume limited responsibility and help control vulnerabilities. In addition, the DMZ tier 120 can include one or more load balancer (LB) subnets 122, a control plane application tier 124 that can include application subnet(s) 126, a control plane data tier 128 that can include database (DB) subnet(s) 130 (e.g., front-end DB subnet(s) and / or back-end DB subnet(s)). The LB subnet(s) 122 contained in the control plane DMZ tier 120 can be communicatively coupled to the application subnet(s) 126 contained in the control plane application tier 124 and to an internet gateway 134 that can be contained in the control plane VCN 116, and the application subnet(s) 126 can be communicatively coupled to the DB subnet(s) 130 contained in the control plane data tier 128 and to a service gateway 136 and a network address translation (NAT) gateway 138. The control plane VCN 116 can include the service gateway 136 and the NAT gateway 138.

[0036] The control plane VCN 116 can include a data plane mirror application tier 140 that can include application subnet(s) 126. The application subnet(s) 126 contained in the data plane mirror application tier 140 can include a virtual network interface controller (VNIC) 142 that can execute a compute instance 144. The compute instance 144 can communicatively couple the application subnet(s) 126 of the data plane mirror application tier 140 to the application subnet(s) 126 that can be contained in a data plane application tier 146.

[0037] The data plane VCN 118 can include a data plane app tier 146, a data plane DMZ tier 148, and a data plane data tier 150. The data plane DMZ tier 148 can include LB subnet(s) 122, which can be communicatively coupled to app subnet(s) 126 of the data plane app tier 146 and an internet gateway 134 of the data plane VCN 118. The app subnet(s) 126 can be communicatively coupled to a service gateway 136 of the data plane VCN 118 and a NAT gateway 138 of the data plane VCN 118. The data plane data tier 150 can also include DB subnet(s) 130, which can be communicatively coupled to the app subnet(s) 126 of the data plane app tier 146.

[0038] The internet gateway 134 of the control plane VCN 116 and the data plane VCN 118 can be communicatively coupled to a metadata management service 152, which can be communicatively coupled to a public internet 154. The public internet 154 can be communicatively coupled to the NAT gateway 138 of the control plane VCN 116 and the data plane VCN 118. The service gateway 136 of the control plane VCN 116 and the data plane VCN 118 can be communicatively coupled to cloud services 156.

[0039] In some examples, the service gateway 136 of the control plane VCN 116 or the data plane VCN 118 can make application programming interface (API) calls to the cloud services 156 without going through the public internet 154. The API calls from the service gateway 136 to the cloud services 156 can be one-way: the service gateway 136 can make API calls to the cloud services 156, and the cloud services 156 can send requested data to the service gateway 136. However, the cloud services 156 can not initiate API calls to the service gateway 136.

[0040] In some examples, the secure host tenancy 104 can be directly connected to the service tenancy 119, which can otherwise be isolated. The secure host subnet 108 can communicate with the SSH subnet 114 through the LPG 110, which can enable bidirectional communication on otherwise isolated systems. Connecting the secure host subnet 108 to the SSH subnet 114 can enable the secure host subnet 108 to access other entities within the service tenancy 119.

[0041] The control plane VCN 116 can allow users of the service tenancy 119 to set up or otherwise provision desired resources. Desired resources provisioned in the control plane VCN 116 can be deployed or otherwise used in the data plane VCN 118. In some examples, the control plane VCN 116 can be isolated from the data plane VCN 118, and a data plane mirror application tier 140 of the control plane VCN 116 can communicate with a data plane application tier 146 of the data plane VCN 118 via a VNIC 142, which can be contained in the data plane mirror application tier 140 and the data plane application tier 146.

[0042] In some examples, a user or customer of the system can make a request, such as a create, read, update, or delete (CRUD) operation, through the public internet 154, which can communicate the request to the metadata management service 152. The metadata management service 152 can communicate the request to the control plane VCN 116 through the internet gateway 134. The request can be received by the LB subnet(s) 122 contained in the control plane DMZ tier 120. The LB subnet(s) 122 can determine that the request is valid, and in response to the determination, the LB subnet(s) 122 can transmit the request to the application subnet(s) 126 contained in the control plane application tier 124. If the request is validated and requires a call to the public internet 154, the call to the public internet 154 can be transmitted to the NAT gateway 138, which can make the call to the public internet 154. Metadata that can be desired to be stored can be stored in the DB subnet(s) 130.

[0043] In some examples, the data plane mirror application tier 140 can facilitate direct communication between the control plane VCN 116 and the data plane VCN 118. For example, it can be desired to apply changes, updates, or other appropriate modifications to configuration to resources contained in the data plane VCN 118. Via the VNIC 142, the control plane VCN 116 can directly communicate with the resources contained in the data plane VCN 118, and thereby can perform the changes, updates, or other appropriate modifications to configuration.

[0044] In some embodiments, the control plane VCN 116 and the data plane VCN 118 can be contained in a service tenancy 119. In this case, a user or customer of the system can not own or operate the control plane VCN 116 or the data plane VCN 118. Instead, the IaaS provider can own or operate the control plane VCN 116 and the data plane VCN 118, both of which can be contained in the service tenancy 119. This embodiment can enable isolation of networks that can prevent a user or customer from interacting with resources of other users or other customers. Also, this embodiment can allow a user or customer of the system to privately store databases without having to rely on the public Internet 154, which can not have a desired level of threat prevention.

[0045] In other embodiments, the LB subnet(s) 122 contained in the control plane VCN 116 can be configured to receive signals from the service gateway 136. In this embodiment, the control plane VCN 116 and the data plane VCN 118 can be configured to be invoked by a customer of the IaaS provider without invoking the public Internet 154. A customer of the IaaS provider can desire this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on the service tenancy 119, which can be isolated from the public Internet 154.

[0046] Figure 2 is a block diagram illustrating another example pattern 200 of an IaaS architecture, in accordance with at least one embodiment. A service operator 202 (e.g., the service operator 102 of Figure 1 ) can be communicatively coupled to a secure host tenancy 204 (e.g., the secure host tenancy 104 of Figure 1 ), which can include a virtual cloud network (VCN) 206 (e.g., the VCN 106 of Figure 1 ) and a secure host subnet 208 (e.g., the secure host subnet 108 of Figure 1 ). The VCN 206 can include a local peering gateway (LPG) 210 (e.g., the LPG 110 of Figure 1 ), which can be communicatively coupled to a secure shell (SSH) VCN 212 (e.g., the SSH VCN 112 of Figure 1 ) via the LPG 110 contained in the SSH VCN 212. The SSH VCN 212 can include an SSH subnet 214 (e.g., the SSH subnet 114 of Figure 1 ), and the SSH VCN 212 can be communicatively coupled to a control plane VCN 216 (e.g., the control plane VCN 116 of Figure 1control plane VCN 116). Control plane VCN 216 can be contained in a service tenancy 219 (e.g., Figure 1 of service tenancy 119), and data plane VCN 218 (e.g., Figure 1 of data plane VCN 118) can be contained in a customer tenancy 221 that can be owned or operated by a user or customer of the system.

[0047] Control plane VCN 216 can include a control plane DMZ tier 220 (e.g., Figure 1 of control plane DMZ tier 120) that can include LB subnet(s) 222 (e.g., Figure 1 of LB subnet(s) 122), can include application subnet(s) 226 (e.g., Figure 1 of application subnet(s) 126), a control plane app tier 224 (e.g., Figure 1 of control plane app tier 124), can include database (DB) subnet(s) 230 (e.g., similar to Figure 1 of DB subnet(s) 130), a control plane data tier 228 (e.g., Figure 1 of control plane data tier 128). LB subnet(s) 222 contained in control plane DMZ tier 220 can be communicatively coupled to application subnet(s) 226 contained in control plane app tier 224 and an internet gateway 234 (e.g., Figure 1 of internet gateway 134) that can be contained in control plane VCN 216, and application subnet(s) 226 can be communicatively coupled to DB subnet(s) 230 contained in control plane data tier 228 and a service gateway 236 (e.g., Figure 1 of service gateway 136) and a network address translation (NAT) gateway 238 (e.g., Figure 1 of NAT gateway 138). Control plane VCN 216 can include service gateway 236 and NAT gateway 238.

[0048] Control plane VCN 216 can include a data plane mirror app tier 240 (e.g., Figure 1 of data plane mirror app tier 140) that can include application subnet(s) 226. Application subnet(s) 226 contained in data plane mirror app tier 240 can include compute instances 244 (e.g., similar to Figure 1The virtual network interface controller (VNIC) 242 (e.g., the VNIC of 142) of the computing instance 144. The computing instance 244 may facilitate the mirroring of the application subnet(s) 226 of the application layer 240 in the data plane and may be included in the application layer 246 in the data plane (e.g., Figure 1 Communication between one or more application subnets 226 in the data plane application layer 146 via VNIC 242 contained in the data plane mirror application layer 240 and VNIC 242 contained in the data plane application layer 246.

[0049] The Internet gateway 234 included in the control plane VCN 216 can be communicatively coupled to the metadata management service 252 (e.g., Figure 1 Metadata management service 252), which can communicatively couple to the public Internet 254 (e.g., Figure 1 The public internet 254 can communicatively couple to a NAT gateway 238 included in the control plane VCN 216. The service gateway 236 included in the control plane VCN 216 can communicatively couple to a cloud service 256 (e.g., ...). Figure 1 Cloud services (156).

[0050] In some examples, data plane VCN 218 may be included in customer lease 221. In this case, the IaaS provider may provide control plane VCN 216 for each customer, and the IaaS provider may set up a unique compute instance 244 for each customer, included in service lease 219. Each compute instance 244 may allow communication between control plane VCN 216 included in service lease 219 and data plane VCN 218 included in customer lease 221. Compute instance 244 may allow resources provisioned in control plane VCN 216 included in service lease 219 to be deployed or otherwise used in data plane VCN 218 included in customer lease 221.

[0051] In other examples, a customer of the IaaS provider can have a database that exists in the customer tenancy 221. In this example, the control plane VCN 216 can include a data plane mirror application tier 240, which can include application subnet(s) 226. The data plane mirror application tier 240 can reside in the data plane VCN 218, but the data plane mirror application tier 240 can not be in the data plane VCN 218. That is, the data plane mirror application tier 240 can access the customer tenancy 221, but the data plane mirror application tier 240 can not exist in the data plane VCN 218 or be owned or operated by the customer of the IaaS provider. The data plane mirror application tier 240 can be configured to make calls to the data plane VCN 218, but can not be configured to make calls to any entities contained in the control plane VCN 216. The customer can desire to deploy or otherwise use resources provisioned in the control plane VCN 216 in the data plane VCN 218, and the data plane mirror application tier 240 can facilitate the customer’s desired deployment or other use of the resources.

[0052] In some embodiments, a customer of the IaaS provider can apply filters to the data plane VCN 218. In this embodiment, the customer can determine what the data plane VCN 218 can access, and the customer can limit access from the data plane VCN 218 to the public Internet 254. The IaaS provider can not be able to apply filters or otherwise control access of the data plane VCN 218 to any external networks or databases. The customer applying filters and controls to the data plane VCN 218 contained in the customer tenancy 221 can help isolate the data plane VCN 218 from other customers and the public Internet 254.

[0053] In some embodiments, cloud services 256 can be invoked by service gateways 236 to access services that can not be present on public internet 254, control plane VCN 216, or data plane VCN 218. Connections between cloud services 256 and control plane VCN 216 or data plane VCN 218 can not be real-time or continuous. Cloud services 256 can exist on a different network owned or operated by an IaaS provider. Cloud services 256 can be configured to receive invocations from service gateways 236 and can be configured to not receive invocations from public internet 254. Some cloud services 256 can be isolated from other cloud services 256, and control plane VCN 216 can be isolated from cloud services 256 that can not be in the same region as control plane VCN 216. For example, control plane VCN 216 can be located in “Region 1,” and cloud service “Deployment 1” can be located in Region 1 and “Region 2.” If a service gateway 236 contained in control plane VCN 216 located in Region 1 makes an invocation to Deployment 1, the invocation can be transmitted to Deployment 1 in Region 1. In this example, Deployment 1 in control plane VCN 216 or Region 1 can not be communicatively coupled or otherwise in communication with Deployment 1 in Region 2.

[0054] Figure 1 is a block diagram illustrating another example pattern 300 of an IaaS architecture, in accordance with at least one embodiment. A service operator 302 (e.g., service operator 102 of Figure 1 ) can be communicatively coupled to a secure host tenancy 304 (e.g., secure host tenancy 104 of Figure 1 ), which can include a virtual cloud network (VCN) 306 (e.g., VCN 106 of Figure 1 ) and a secure host subnet 308 (e.g., secure host subnet 108 of Figure 1 ). VCN 306 can include an LPG 310 (e.g., LPG 110 of Figure 1 ), which can be communicatively coupled to an SSH VCN 312 (e.g., SSH VCN 112 of Figure 1 ) via LPG 310 contained in SSH VCN 312. SSH VCN 312 can include an SSH subnet 314 (e.g., SSH subnet 114 of Figure 1 ), and SSH VCN 312 can be communicatively coupled to a control plane VCN 316 (e.g., control plane VCN 116 of Figure 1 ) via LPG 310 contained in control plane VCN 316 and to a data plane VCN 318 (e.g., data plane VCN 118 of Figure 1Data plane VCN 118). Control plane VCN 316 and data plane VCN 318 may be included in service lease 319 (e.g., Figure 1 In the service rental (119).

[0055] The control plane VCN 316 may include one or more load balancer (LB) subnets 322 (e.g., Figure 1 The control plane DMZ layer 320 of (one or more) LB subnets 122) (e.g., Figure 1 The control plane DMZ layer 120 may include one or more application subnets 326 (e.g., similar to...). Figure 1 The control plane application layer 324 of (one or more) application subnets 126 (e.g., Figure 1 The control plane application layer 124) may include a control plane data layer 328 (e.g., one or more) of DB subnets 330. Figure 1 The control plane data layer 128). One or more LB subnets 322 contained in the control plane DMZ layer 320 can be communicatively coupled to one or more application subnets 326 contained in the control plane application layer 324 and an Internet gateway 334 that can be contained in the control plane VCN 316 (e.g., Figure 1 Internet gateway 134), and application subnet(s) 326 can communicatively couple to DB subnet(s) 330 contained in control plane data layer 328 and service gateway 336 (e.g., Figure 1 The service gateway) and Network Address Translation (NAT) gateway 338 (e.g., Figure 1 (NAT gateway 138). The control plane VCN 316 may include the service gateway 336 and the NAT gateway 338.

[0056] Data plane VCN 318 may include data plane application layer 346 (e.g., Figure 1 Data plane application layer 146), data plane DMZ layer 348 (e.g., Figure 1 Data plane DMZ layer 148), and data plane data layer 350 (e.g., Figure 1data plane DMZ tier 348 can include one or more trusted application subnets 360 and one or more untrusted application subnets 362 that can be communicatively coupled to the data plane application tier 346 and one or more LB subnets 322 that include the internet gateway 334 in the data plane VCN 318. The one or more trusted application subnets 360 can be communicatively coupled to the service gateway 336 included in the data plane VCN 318, the NAT gateway 338 included in the data plane VCN 318, and one or more DB subnets 330 included in the data plane data tier 350. The one or more untrusted application subnets 362 can be communicatively coupled to the service gateway 336 included in the data plane VCN 318 and the one or more DB subnets 330 included in the data plane data tier 350. The data plane data tier 350 can include one or more DB subnets 330 that can be communicatively coupled to the service gateway 336 included in the data plane VCN 318.

[0057] The one or more untrusted application subnets 362 can include one or more primary VNICs 364(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 366(1)-(N). Each tenant VM 366(1)-(N) can be communicatively coupled to a respective application subnet 367(1)-(N) that can be included in a respective container egress VCN 368(1)-(N) that can be included in a respective customer tenancy 380(1)-(N). A respective secondary VNIC 372(1)-(N) can facilitate communication between the one or more untrusted application subnets 362 included in the data plane VCN 318 and the application subnets included in the container egress VCNs 368(1)-(N). Each container egress VCN 368(1)-(N) can include a NAT gateway 338 that can be communicatively coupled to the public internet 354 (e.g., Figure 1 the public internet 154).

[0058] The internet gateway 334 included in the control plane VCN 316 and included in the data plane VCN 318 can be communicatively coupled to a metadata management service 352 (e.g., Figure 1The metadata management service 352 can be communicatively coupled to a public Internet 354. The public Internet 354 can be communicatively coupled to a NAT gateway 338 contained in the control plane VCN 316 and contained in the data plane VCN 318. A service gateway 336 contained in the control plane VCN 316 and contained in the data plane VCN 318 can be communicatively coupled to cloud services 356.

[0059] In some embodiments, the data plane VCN 318 can be integrated with a customer tenancy 380. In some cases, such as in cases where support for executing code can be desired, such integration can be useful or desirable for customers of the IaaS provider. A customer can provide code that can be disruptive, can communicate with other customer resources, or can otherwise cause undesirable effects to run. In response to this, the IaaS provider can determine whether to run the code provided by the customer to the IaaS provider.

[0060] In some examples, a customer of the IaaS provider can grant temporary network access to the IaaS provider and request functionality to be attached to the data plane application tier 346. Code to run the functionality can be executed in VMs 366(1)-(N) and the code can not be configured to run anywhere else on the data plane VCN 318. Each VM 366(1)-(N) can be connected to one customer tenancy 380. A respective container 381(1)-(N) contained in the VM 366(1)-(N) can be configured to run the code. In this case, there can be double isolation (e.g., the containers 381(1)-(N) run the code, where the containers 381(1)-(N) can be contained in at least the VMs 366(1)-(N) contained in the untrusted application subnet(s) 362), which can help prevent incorrect or otherwise undesirable code from damaging the network of the IaaS provider or damaging the network of a different customer. The containers 381(1)-(N) can be communicatively coupled to the customer tenancy 380 and can be configured to transmit or receive data from the customer tenancy 380. The containers 381(1)-(N) can not be configured to transmit or receive data from any other entity in the data plane VCN 318. Upon completion of running the code, the IaaS provider can terminate or otherwise dispose of the containers 381(1)-(N).

[0061] In some embodiments, the trusted application subnet(s) 360 can run code that can be owned or operated by the IaaS provider. In this embodiment, the trusted application subnet(s) 360 can be communicatively coupled to the DB subnet(s) 330 and configured to perform CRUD operations in the DB subnet(s) 330. The untrusted application subnet(s) 362 can be communicatively coupled to the DB subnet(s) 330, but in this embodiment, the untrusted application subnet(s) can be configured to perform read operations in the DB subnet(s) 330. Containers 381(1)-(N) that can be contained in each customer's VM 366(1)-(N) and that can run code from a customer can not be communicatively coupled to the DB subnet(s) 330.

[0062] In other embodiments, the control plane VCN 316 and the data plane VCN 318 can not be directly communicatively coupled. In this embodiment, there can be no direct communication between the control plane VCN 316 and the data plane VCN 318. However, communication can occur indirectly by at least one method. The LPG 310 can be established by the IaaS provider, which can facilitate communication between the control plane VCN 316 and the data plane VCN 318. In another example, the control plane VCN 316 or the data plane VCN 318 can invoke a cloud service 356 via a service gateway 336. For example, an invocation of a cloud service 356 from the control plane VCN 316 can include a request for a service that can be in communication with the data plane VCN 318.

[0063] Figure 1 is a block diagram illustrating another example pattern 400 of an IaaS architecture, in accordance with at least one embodiment. A service operator 402 (e.g., the service operator 102 of Figure 1 ) can be communicatively coupled to a secure host tenancy 404 (e.g., the secure host tenancy 104 of Figure 1 ), which can include a virtual cloud network (VCN) 406 (e.g., the VCN 106 of Figure 1 ) and a secure host subnet 408 (e.g., the secure host subnet 108 of Figure 1 ). The VCN 406 can include an LPG 410 (e.g., the LPG 110 of Figure 1 ), which can be communicatively coupled to an SSH VCN 412 (e.g., the SSH VCN 112 of Figure 1 ) via the LPG 410 contained in the SSH VCN 412. The SSH VCN 412 can include an SSH subnet 414 (e.g., the SSH subnet 114 of Figure 1SSH subnet 114) and the SSH VCN 412 can be communicatively coupled to the control plane VCN 416 via an LPG 410 contained in the control plane VCN 416 (e.g., Figure 1 the control plane VCN 116) and coupled to the data plane VCN 418 via an LPG 410 contained in the data plane VCN 418 (e.g., Figure 1 the data plane VCN 118). The control plane VCN 416 and the data plane VCN 418 can be contained in a service tenancy 419 (e.g., Figure 1 the service tenancy 119).

[0064] The control plane VCN 416 can include a control plane DMZ tier 420 (e.g., Figure 1 the control plane DMZ tier 120) that can include LB subnet(s) 422 (e.g., Figure 1 the LB subnet(s) 122), a control plane app tier 424 (e.g., Figure 1 the control plane app tier 124) that can include app subnet(s) 426 (e.g., Figure 1 the app subnet(s) 126), a control plane data tier 428 (e.g., Figure 1 the control plane data tier 128) that can include DB subnet(s) 430 (e.g., Figure 1 the DB subnet(s) 330). The LB subnet(s) 422 contained in the control plane DMZ tier 420 can be communicatively coupled to the app subnet(s) 426 contained in the control plane app tier 424 and to an internet gateway 434 (e.g., Figure 1 the internet gateway 134) that can be contained in the control plane VCN 416, and the app subnet(s) 426 can be communicatively coupled to the DB subnet(s) 430 contained in the control plane data tier 428 and to a service gateway 436 (e.g., Figure 1 the service gateway) and a network address translation (NAT) gateway 438 (e.g., Figure 1 the NAT gateway 138). The control plane VCN 416 can include the service gateway 436 and the NAT gateway 438.

[0065] The data plane VCN 418 can include a data plane app tier 446 (e.g., Figure 1 the data plane app tier 146), a data plane DMZ tier 448 (e.g., Figure 1 the data plane DMZ tier 148), and a data plane data tier 450 (e.g., Figure 1application subnets 460 (e.g., trusted application subnet 460(1) and untrusted application subnet 460(2)) that can be communicatively coupled to data plane application tier 446. Data plane DMZ tier 448 can include one or more LB subnets 422 that can be communicatively coupled to data plane application tier 446. Figure 1 application subnets 460 (e.g., trusted application subnet 460(1) and untrusted application subnet 460(2)) that can be communicatively coupled to data plane application tier 446. Data plane DMZ tier 448 can include one or more LB subnets 422 that can be communicatively coupled to data plane application tier 446. Figure 1 application subnets 460 (e.g., trusted application subnet 460(1) and untrusted application subnet 460(2)) that can be communicatively coupled to data plane application tier 446. Data plane DMZ tier 448 can include one or more LB subnets 422 that can be communicatively coupled to data plane application tier 446.

[0066] application subnets 460 (e.g., trusted application subnet 460(1) and untrusted application subnet 460(2)) that can be communicatively coupled to data plane application tier 446. Data plane DMZ tier 448 can include one or more LB subnets 422 that can be communicatively coupled to data plane application tier 446. Figure 1 application subnets 460 (e.g., trusted application subnet 460(1) and untrusted application subnet 460(2)) that can be communicatively coupled to data plane application tier 446. Data plane DMZ tier 448 can include one or more LB subnets 422 that can be communicatively coupled to data plane application tier 446.

[0067] application subnets 460 (e.g., trusted application subnet 460(1) and untrusted application subnet 460(2)) that can be communicatively coupled to data plane application tier 446. Data plane DMZ tier 448 can include one or more LB subnets 422 that can be communicatively coupled to data plane application tier 446. Figure 1Metadata management service 452 can be communicatively coupled to the public internet 454. The public internet 454 can be communicatively coupled to a NAT gateway 438 contained in a control plane VCN 416 and a data plane VCN 418. A service gateway 436 contained in a control plane VCN 416 and a data plane VCN 418 can be communicatively coupled to a cloud service 456.

[0068] In some examples, Figure 1 The architecture shown in block diagram 400 can be considered as Figure 1 This is an exception to the pattern shown in the architecture of block diagram 300, and this pattern may be what the IaaS provider's customers would expect if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer can have real-time access to the corresponding container 467(1)-(N) contained in each customer's VM 466(1)-(N). Container 467(1)-(N) can be configured to make calls to the corresponding auxiliary VNIC 472(1)-(N) contained in one or more application subnets 426 of the data plane application layer 446, which may be contained in the container egress VCN 468. The auxiliary VNIC 472(1)-(N) can transmit the calls to a NAT gateway 438, which can transmit the calls to the public internet 454. In this example, the container 467(1)-(N) that can be accessed by the customer in real-time can be isolated from the control plane VCN 416 and from other entities contained in the data plane VCN 418. Container 467(1)-(N) can also be isolated from resources from other customers.

[0069] In other examples, a client may use containers 467(1)-(N) to invoke cloud service 456. In this example, the client may run code within containers 467(1)-(N) requesting services from cloud service 456. Container 467(1)-(N) may transmit the request to a secondary VNIC 472(1)-(N), which may then transmit the request to a NAT gateway, which may transmit the request to the public internet 454. The public internet 454 may then transmit the request via internet gateway 434 to one or more LB subnets 422 contained in control plane VCN 416. In response to determining that the request is valid, one or more LB subnets may transmit the request to one or more application subnets 426, which may then transmit the request to cloud service 456 via service gateway 436.

[0070] It should be appreciated that the IaaS architectures 100, 200, 300, 400 depicted in the figures can have other components than those depicted. Additionally, the embodiments shown in the figures are merely some examples of cloud infrastructure systems with which embodiments of the present disclosure can be implemented. In some other embodiments, an IaaS system can have more or fewer components than those shown in the figures, can combine two or more components, or can have a different configuration or arrangement of components.

[0071] In certain embodiments, the IaaS systems described herein can include an application suite, middleware, and database service products delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI) offered by the present assignee.

[0072] In one or more embodiments, a computer network provides connectivity between a set of nodes. The nodes can be local to and / or remote from each other. The nodes are connected by a set of links. Examples of links include coaxial cable, unshielded twisted cable, copper wire, optical fiber, and virtual link.

[0073] A subset of the nodes implements the computer network. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another subset of the nodes uses the computer network. Such nodes (also referred to as “hosts”) can execute client processes and / or server processes. Client processes make requests for computational services such as execution of a particular application and / or storage of a particular amount of data. Server processes respond by executing the requested services and / or returning the corresponding data.

[0074] The computer network can be a physical network that includes physical nodes connected by physical links. A physical node is any digital device. A physical node can be a function-specific hardware device such as a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Additionally or alternatively, a physical node can be a general-purpose machine configured to execute various virtual machines and / or applications that perform the respective functions. A physical link is a physical medium that connects two or more physical nodes. Examples of links include coaxial cable, unshielded twisted cable, copper wire, and optical fiber.

[0075] A computer network can be an overlay network. An overlay network is a logical network implemented on top of another network, such as a physical network. Each node in an overlay network corresponds to a respective node in the underlying network. Thus, each node in an overlay network is associated with both an overlay address (used to address to the overlay node) and an underlay address (used to address the underlay node that implements the overlay node). An overlay node can be a digital device and / or a software process, such as a virtual machine, an application instance, or a thread. A link connecting overlay nodes is implemented as a tunnel through the underlay network. Overlay nodes at either end of a tunnel treat the underlying multi-hop path between them as a single logical link. Tunneling is performed by encapsulation and decapsulation.

[0076] In embodiments, a client can be local to and / or remote from a computer network. A client can access a computer network through other computer networks, such as a private network or the Internet. A client can transmit requests to a computer network using a communications protocol, such as the hypertext transfer protocol (HTTP). A request is transmitted through an interface, such as a client interface (such as a web browser), a program interface, or an application programming interface (API).

[0077] In embodiments, a computer network provides connectivity between clients and network resources. Network resources include hardware and / or software configured to perform server processes. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. Network resources are shared among multiple clients. Clients independently of one another request computing services from a computer network. Network resources are dynamically allocated to requests and / or clients on demand. Network resources allocated to each request and / or client can scale up or down based on, for example, (a) the computing services requested by a particular client, (b) the aggregate computing services requested by a particular tenant, and / or (c) the requested aggregate computing services of the computer network. Such a computer network can be referred to as a “cloud network.”

[0078] In embodiments, a service provider provides a cloud network to one or more end users. A cloud network can implement various service models, including but not limited to software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). In SaaS, a service provider provides end users the ability to use an application executing on network resources of the service provider. In PaaS, a service provider provides end users the ability to deploy custom applications onto network resources. Custom applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, a service provider provides end users the ability to provision processing, storage, networks, and other basic computing resources provided by network resources. Any arbitrary application, including an operating system, can be deployed on network resources.

[0079] In embodiments, a computer network can implement various deployment models, including but not limited to private cloud, public cloud, and hybrid cloud. In a private cloud, network resources are provisioned for exclusive use by a particular group of one or more entities (as the term "entity" is used herein to refer to a company, organization, person, or other entity). The network resources can be local to the premises of the particular group of entities and / or remote from the premises of the particular group of entities. In a public cloud, cloud resources are provisioned for use by multiple entities independent of each other (also referred to as "tenants" or "customers"). The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network can be referred to as a "multi-tenant computer network." Several tenants can use the same particular network resource at different times and / or at the same time. The network resources can be local to the premises of the tenants and / or remote from the premises of the tenants. In a hybrid cloud, a computer network includes a private cloud and a public cloud. An interface between the private cloud and the public cloud allows portability of data and applications. Data stored at the private cloud and data stored at the public cloud can be exchanged through the interface. Applications implemented at the private cloud and applications implemented at the public cloud can have dependencies on each other. Calls from an application at the private cloud to an application at the public cloud (and vice versa) can be performed through the interface.

[0080] In embodiments, tenants of a multi-tenant computer network are independent of each other. For example, the business or operations of one tenant can be separate from the business or operations of another tenant. Different tenants can have different network requirements for the computer network. Examples of network requirements include processing speed, amount of data storage, security requirements, performance requirements, throughput requirements, latency requirements, resiliency requirements, quality of service (QoS) requirements, tenant isolation, and / or consistency. The same computer network can need to implement different network requirements needed by different tenants.

[0081] In one or more embodiments, in a multi-tenant computer network, tenant isolation is implemented to ensure that applications and / or data of different tenants are not shared with each other. Various tenant isolation methods can be used.

[0082] In embodiments, each tenant is associated with a tenant ID. Each network resource of the multi-tenant computer network is tagged with a tenant ID. A tenant is allowed to access a particular network resource only if the tenant and the particular network resource are associated with the same tenant ID.

[0083] In embodiments, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with a tenant ID. Additionally or alternatively, each data structure and / or data set stored by the computer network is tagged with a tenant ID. A tenant is allowed to access a particular application, data structure, and / or data set only if the tenant and the particular application, data structure, and / or data set are associated with the same tenant ID.

[0084] As an example, each database implemented by the multi-tenant computer network can be tagged with a tenant ID. Only tenants associated with the corresponding tenant ID can access the data of a particular database. As another example, each entry in a database implemented by the multi-tenant computer network can be tagged with a tenant ID. Only tenants associated with the corresponding tenant ID can access the data of a particular entry. However, the database can be shared by multiple tenants.

[0085] In embodiments, a subscription list indicates which tenants have authorization to access which applications. For each application, a list of tenant IDs of tenants authorized to access the application is stored. A tenant is only allowed to access a particular application if the tenant's tenant ID is included in the subscription list corresponding to the particular application.

[0086] In embodiments, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are isolated to tenant-specific overlay networks maintained by the multi-tenant computer network. As an example, a data packet from any source device in a tenant overlay network can only be transmitted to other devices within the same tenant overlay network. Encapsulation tunnels are used to prohibit any transmissions from a source device on a tenant overlay network to devices in other tenant overlay networks. Specifically, a data packet received from a source device is encapsulated within an outer data packet. The outer data packet is transmitted from a first encapsulation tunnel endpoint (in communication with the source device in the tenant overlay network) to a second encapsulation tunnel endpoint (in communication with a destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer data packet to obtain the original data packet transmitted by the source device. The original data packet is transmitted from the second encapsulation tunnel endpoint to the destination device in the same particular overlay network.

[0087] 3. Computer system

[0088] Figure 1 An example computer system 500 in which various embodiments can be implemented is illustrated. System 500 can be used to implement any of the computer systems described above. As shown, computer system 500 includes a processing unit 504 that communicates with a number of peripheral subsystems via a bus subsystem 502. These peripheral subsystems can include a processing acceleration unit 506, an I / O subsystem 508, a storage subsystem 518 and a communications subsystem 524. Storage subsystem 518 includes tangible computer-readable storage media 522 and a system memory 510.

[0089] Bus subsystem 502 provides an infrastructure for letting the various components and subsystems of computer system 500 communicate with each other as intended. Although bus subsystem 502 is shown schematically as a single bus, alternative embodiments of the bus subsystem can utilize multiple buses. Bus subsystem 502 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures can include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, which can be implemented as Mezzanine bus manufactured to the IEEE P1386.1 standard.

[0090] Processing unit 504, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of computer system 500. One or more processors can be included in processing unit 504. These processors can include single core or multicore processors. In certain embodiments, processing unit 504 can be implemented as one or more independent processing units 532 and / or 534, with single core or multicore processors included in each processing unit. In other embodiments, processing unit 504 can also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0091] In various embodiments, processing unit 504 can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in processing unit 504 and / or in storage subsystem 518. Through suitable programming, processing unit 504 can provide various functionalities described above. Computer system 500 can additionally include a processing acceleration unit 506, which can include a digital signal processor (DSP), a special-purpose processor, and / or the like.

[0092] I / O subsystem 508 can include user interface input devices and user interface output devices. User interface input devices can include, for example, a keyboard, pointing devices such as a mouse or trackball, touchpads, touch screens such as Apple® iPad® or Microsoft® Surface® touch screens, wheels, click wheels, dials, buttons, switches, key pads, keyboards, audio input devices with voice commands, microphones, and other types of input devices. User interface input devices can include, for example, motion sensing and / or gesture recognition devices such as the Microsoft Kinect® motion sensor that enables users to control and interact with an input device such as the Microsoft Xbox® 360 game controller using a natural user interface. User interface input devices can also include eye gesture recognition devices such as Google Glass® blink detector that detects eye activity (e.g., “blinking” of the eye) from users in a manner that mimics the way the operating system would detect user interface input instructions from a mouse or other pointing device. Further, user interface input devices can include voice recognition sensing devices that enable users to interact with the operating system through voice commands.

[0093] User interface input devices can also include, without limitation, three dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, and audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode reader 3D scanners, 3D printers, laser rangefinders, and eye gaze tracking devices. Additionally, user interface input devices can include, for example, medical imaging input devices such as computerized tomography, magnetic resonance imaging, positron emission tomography, medical ultrasonic devices. User interface input devices can also include, for example, audio input devices such as MIDI keyboards, digital musical instruments and the like.

[0094] User interface output devices can include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. The display subsystem can be a cathode ray tube (CRT), a flat-panel device such as that using a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, or any other display device suitable for use in a computing environment. In general, the term “output device” is intended to encompass all possible types of devices and mechanisms for outputting information from the computer system 500 to a user or other computer. For example, user interface output devices can include, without limitation, a variety of display devices that visually convey text, graphics, and audio / video information such as monitors, printers, speakers, headphones, automotive navigation systems, plotters, voice output devices, and modems.

[0095] Computer system 500 can include storage subsystem 518 that provides a tangible, non-transitory computer-readable storage medium for storing the software and data structures that provide the functionality described in this disclosure. The software can include programs, code modules, instructions, scripts, and / or the like that, when executed by one or more cores or processors of processing unit 504, provide the functionality described above. Storage subsystem 518 can also provide a repository for storing data used in accordance with this disclosure.

[0096] As Figure 1 Storage subsystem 518 can include various components, including system memory 510, computer-readable storage media 522, and computer-readable media reader 520, as depicted in the example in FIG. 5. System memory 510 can store program instructions that are loadable and executable by processing unit 504, such as an application 512. System memory 510 can also store data used in connection with the execution of the program instructions, such as program data 514, and / or data generated during the execution of the program instructions. Various different kinds of programs can be loaded into system memory 510, including but not limited to a client application, a Web browser, an intermediate layer application, a relational database management system (RDBMS), a virtual machine, a container, and the like.

[0097] System memory 510 can also store an operating system 516. Examples of operating systems 516 can include various versions of Microsoft Windows®, Apple Macintosh® and / or Linux operating systems, UNIX® variants including but not limited to the various GNU / Linux operating systems, Google Chrome® OS, and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS operating systems. In certain embodiments where computer system 500 executes one or more virtual machines, a virtual machine, along with its guest operating system (GOS), can be loaded into system memory 510 and executed by one or more processors or cores of processing unit 504.

[0098] The system memory 510 can take the form of different configurations depending on the type of computer system 500. For example, the system memory 510 can be a volatile memory such as a random access memory (RAM) and / or a non-volatile memory such as a read only memory (ROM), flash memory, etc. Different types of RAM configurations can be provided including static random access memory (SRAM), dynamic random access memory (DRAM), etc. In some embodiments, the system memory 510 can include a basic input / output system (BIOS) that contains the basic routines that help to transfer information between elements within the computer system 500, such as during startup.

[0099] The computer readable storage medium 522 can represent remote, local, fixed, and / or removable storage devices as well as storage media for temporarily and / or more permanently containing, storing, and / or providing computer-readable information to the computer system 500, including instructions that can be executed using the processing unit 504 of the computer system 500.

[0100] The computer readable storage medium 522 can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and / or transmission of information such as computer readable instructions, other data structures, program modules, or other data. This can include tangible computer readable storage media such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer readable media.

[0101] By way of example, computer-readable storage media 522 can include a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media; a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk; and an optical disk drive that reads from or writes to a removable, nonvolatile optical disk such as a CD ROM, DVD, and Blu-Ray® disk, or other optical media. Computer-readable storage media 522 can include, but is not limited to, Zip® drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD disks, digital video tape, and the like. Computer-readable storage media 522 can also include, but is not limited to, solid-state drives (SSD) based on nonvolatile memory such as flash memory-based SSDs, enterprise flash drives, solid state ROM, and the like, SSDs based on volatile memory such as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media can provide nonvolatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 500.

[0102] Machine-readable instructions that can be executed by one or more processors or cores of processing unit 504 can be stored on a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium can include a physical, tangible storage device that comprises volatile memory or non-volatile memory. Examples of non-transitory computer- readable storage media include magnetic media, such as a hard disk or tape; optical media, such as a DVD or Blu-ray® disc; various types of RAM; ROM; flash memory; hard drives; solid state drives; removable media, such as a flash drive or USB drive; or any other type of storage medium that can store machine-readable instructions for execution by a processor.

[0103] The communications subsystem 524 provides an interface to other computer systems and networks. The communications subsystem 524 serves as an interface for receiving data from and transmitting data to other systems from the computer system 500. For example, the communications subsystem 524 can enable the computer system 500 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 524 can include a radio frequency (RF) transceiver component (e.g., using cellular telephone technology, advanced data network technology, such as 3G, 4G or EDGE (enhanced data for global evolution) technology, WiFi (IEEE 802.11 family standards), or other mobile communication technologies, or any combination thereof), a Global Positioning System (GPS) receiver component, and / or other components, for accessing a wireless voice and / or data network. In some embodiments, the communications subsystem 524 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0104] In some embodiments, the communications subsystem 524 can also receive input, including structured and / or unstructured data feeds, event updates, and the like, on behalf of one or more users of the computer system 500.

[0105] For example, the communications subsystem 524 can be configured to receive data feeds 526 in real-time from users of social networks and / or other communication services, such as Twitter® feeds, Facebook® updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party information sources.

[0106] Further, the communications subsystem 524 can also be configured to receive data in the form of continuous data streams, which can include event streams 528 and / or event updates 530 of real-time events that can be continuous in nature or that otherwise do not have explicit terminations, such as sensor data applications, financial tickers, network performance measuring tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0107] The communications subsystem 524 can also be configured to output structured and / or unstructured data feeds 526, event streams 528, event updates 530, and the like to one or more databases that can be in communication with one or more stream computing devices coupled to computer system 500.

[0108] The computer system 500 can be one of various types, including a handheld portable device (e.g., an iPhone® cellular phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a work station, a mainframe, a kiosk, a server rack, or any other data processing system.

[0109] Due to the ever-changing nature of computers and networks, the description of computer system 500 depicted in the figure is intended only as a specific example. For example, hardware and / or software Figure 1 Many other configurations having more or fewer components than the system depicted in the figure are possible. For example, customized hardware might also be used and / or particular elements might be implemented in hardware, firmware, software (including applets), or a combination. Additionally, connection to other computing devices, such as network input / output devices, can be employed. Based on the disclosure and teachings provided herein, a person of ordinary skill in the related art will appreciate other ways and / or methods to implement the various embodiments.

[0110] 4. System Architecture Overview

[0111] Figure 1 and Figure 1 FIG. illustrates one example of a system 600, in accordance with one or more embodiments. Reference is made to FIG. 1 for purposes of providing context. Figure 1 and Figure 1 The system 600 described can perform operations associated with validating a certificate package as described herein. The system 600 can also perform operations associated with distributing a certificate package to a network entity as described herein.

[0112] As Figure 1As shown in FIG. 6, system 600 can include a virtual cloud network 602. Virtual cloud network 602 can include a certificate authority (CA) service 604 and a CA service repository 606. CA service 604 can perform operations including generating digital certificates and storing digital certificates in and / or in association with CA service repository 606. Digital certificates generated by CA service 604 and / or stored in CA service repository 606 can include CA certificates and / or entity certificates. Example CA certificates and example entity certificates are further described below in Section 6, “Authenticating Network Entities.” Additionally, or alternatively, CA service can perform operations including generating and / or in association with asymmetric key pairs including private keys and public keys. As used herein, the term “asymmetric key pair” refers to a public key and a private key that are associated with one another such that a digital signature or encryption generated using the private key can be verified or decrypted using the public key. The public key can be stored in CA service repository 606. In one example, a certificate repository 608 and / or a public key repository 610 can be included in CA service repository 606, can be included or associated with CA service repository 606. Digital certificates generated by CA service 604 can be stored in certificate repository 608 included in or associated with CA service repository 606. Public keys generated by CA service 604 can be stored in public key repository 610 included in or associated with CA service repository 606.

[0113] Virtual cloud network 602 can also include a distribution service 612, a distribution service repository 614, and a plurality of network entities 616. Distribution service 612 can perform operations including verifying digital certificates and storing verified digital certificates in and / or in association with distribution service repository 614. Distribution service 612 can also perform operations including verifying public keys and storing verified public keys in and / or in association with distribution service repository 614. In one example, a certificate repository 618 and / or a public key repository 620 can be included in or associated with distribution service repository 614. Digital certificates verified by distribution service 612 can be stored in certificate repository 618 included in or associated with distribution service repository 614. Public keys verified by distribution service 612 can be stored in public key repository 620 included in or associated with distribution service repository 614. Distribution service 612 can also perform operations including distributing digital certificates to and / or in association with the plurality of network entities 616. For example, distribution service 612 can distribute digital certificates that have been verified by distribution service 612 to the plurality of network entities 616.

[0114] As Figure 1As shown in FIG. 6, the CA service repository 606 and / or the certificate repository 608 associated with the CA service repository 606 can include a pending certificate repository 622 and a validated certificate repository 624. The pending certificate repository 622 can include one or more digital certificates that have not been validated by the distribution service 612. Additionally, or alternatively, the pending certificate repository 624 can include one or more certificate bundles that have not been validated by the distribution service 612. For example, the one or more certificate bundles in the pending certificate repository 622 can each include one or more digital certificates that have not been validated by the distribution service 612. The validated certificate repository 624 can include one or more digital certificates that have been validated by the distribution service 612. Additionally, or alternatively, the validated certificate repository 624 can include one or more certificate bundles that have been validated by the distribution service 612. For example, the one or more certificate bundles can each include one or more digital certificates that have been validated by the distribution service 612.

[0115] The public key repository 610 can include one or more public keys that correspond to one or more of the digital certificates in the certificate repository. In one example, the one or more public keys can be validated by the distribution service 612. Additionally, or alternatively, the one or more public keys in the public key repository 610 can correspond to one or more digital certificates that have been validated by the distribution service 612. Additionally, or alternatively, the public key repository 610 can include one or more public keys that have not been validated by the distribution service 612 and / or correspond to one or more digital certificates that have not been validated by the distribution service 612.

[0116] The CA service 604 can store digital certificates and / or certificate bundles including one or more digital certificates in the pending certificate repository 622. The digital certificates and / or certificate bundles stored in the pending certificate repository 622 can include digital certificates and / or certificate bundles generated by the CA service. Additionally, or alternatively, the digital certificates and / or certificate bundles stored in the pending certificate repository 622 can include digital certificates and / or certificate bundles generated by a third party and made available by the CA service. The CA service 604 can generate and / or update a certificate bundle configuration file that identifies a particular certificate bundle and / or a particular digital certificate stored in the certificate repository 608, such as in the pending certificate repository 622. The certificate bundle configuration file can include a file pointer that identifies a location in the pending certificate repository 622 where the particular certificate bundle and / or the particular digital certificate is stored. The certificate bundle configuration file can be stored in the CA service repository 606 or the certificate repository 608.

[0117] The distribution service 612 can obtain the certificate bundle and / or the digital certificate from the pending certificate repository 622 for validation. The distribution service 612 can identify a particular certificate bundle and / or a particular digital certificate in the pending certificate repository based on a file pointer in the certificate bundle configuration file. The distribution service 612 can validate the certificate bundle and / or the one or more digital certificates obtained from the pending certificate repository 622, and upon validating the certificate bundle and / or the one or more digital certificates, the distribution service 612 can store the certificate bundle and / or the one or more digital certificates in the validated certificate repository 624. Additionally, or alternatively, upon validating the certificate bundle and / or the one or more digital certificates, the distribution service 612 can store the certificate bundle and / or the one or more digital certificates in the distribution service repository 614, e.g., for distribution to one or more network entities 616 associated with the virtual cloud network 602. In one example, the distribution service 612 can store the certificate bundle and / or the one or more digital certificates to be distributed to the one or more network entities 616 in a certificate repository 618 included in or associated with the distribution service repository 614. The distribution service 612 can generate and / or update the certificate bundle configuration file identifying the particular certificate bundle and / or the particular digital certificate stored in the validated certificate repository 624 and / or the distribution service repository 614. The certificate bundle configuration file can include a file pointer identifying a location in the validated certificate repository 624 and / or in the distribution service repository 614 where the particular certificate bundle and / or the particular digital certificate is stored. The certificate bundle configuration file can be stored in the CA service repository 606 or in the distribution service repository 614.

[0118] With further reference to Figure 1 The CA service can generate one or more digital certificates and / or a certificate bundle including the one or more digital certificates. The one or more digital certificates can be generated using a private key of an asymmetric key pair. In one example, the CA service can generate the one or more digital certificates using the private key and then package the one or more digital certificates in a certificate bundle. In another example, the CA service 604 can package the one or more digital certificates as a data set, and the distribution service 612 can generate a certificate bundle including the one or more digital certificates, e.g., after validating the data set in a similar manner as validating a certificate bundle as described herein. Upon validating such a data set, the distribution service 612 can generate a certificate bundle including the one or more digital certificates and can distribute the certificate bundle to the one or more network entities 616.

[0119] In one example, the CA service 604 can generate an asymmetric key pair, and after generating the asymmetric key pair, the CA service 604 can generate one or more digital certificates corresponding to the asymmetric key pair. Additionally, or alternatively, the CA service can generate the digital certificates based on an asymmetric key pair provided to the CA service from another source, such as from an identity access management service. In one example, the CA service 604 can replace the asymmetric key pair from time to time, e.g., according to a security protocol. When the asymmetric key is replaced, the CA service 604 can also replace the digital certificates associated with the asymmetric key pair being replaced with new digital certificates corresponding to the new asymmetric key pair.

[0120] After generating the one or more digital certificates and packaging the one or more digital certificates in a certificate package, the CA service 604 can generate a digital signature associated with the certificate package using a private key of the asymmetric key pair. The distribution service 612 can verify the digital signature using a public key of the asymmetric key pair corresponding to the private key used to generate the digital signature. The public key can be stored in the public key repository 610. The distribution service 612 can retrieve the public key from the public key repository 610 and use the public key to verify the digital signature. The CA service 604 can generate and / or update a public key configuration file identifying a particular public key stored in the public key repository 610. The public key configuration file can include a file pointer identifying a location in the public key repository 610 where the particular public key is stored. The public key configuration file can be stored in the CA service repository 606 or the public key repository 610.

[0121] In one example, the public key used by the distribution service 612 to verify the digital signature can correspond to an asymmetric key pair associated with an additional set of one or more digital certificates generated using a private key of the asymmetric key pair. The additional set of one or more digital certificates can be currently or previously trusted by the distribution service. In one example, the additional set of one or more digital certificates can have been previously verified by the distribution service 612. In one example, the public key used to verify the digital signature can correspond to the private key used to generate the additional set of one or more digital certificates. Additionally, or alternatively, the public key used by the distribution service 612 to verify the digital signature can be currently or previously trusted by the distribution service 612, e.g., based on a security protocol that can be independent of and / or in addition to the verification of the digital signature associated with the certificate package.

[0122] In one example, the CA service 604 can generate the digital signature by applying a first hash function to the certificate package to obtain a hash value and then digitally signing the first hash value using a private key of an asymmetric key pair. In one example, the distribution service 612 can verify the digital signature by determining whether the digital signature was generated using the private key of the asymmetric key pair. The distribution service 612 can determine whether the digital signature was generated using the private key of the asymmetric key pair by applying a hash function to the first certificate package associated with the digital certificate to generate a second hash value, decrypting the digital signature to generate a third hash value, and comparing the third hash value to the second hash value. The third hash value matching the second hash value indicates that the private key used to digitally sign the first hash value corresponds to the public key used to decrypt the digital signature. The third hash value matching the second hash value indicates that the private key used to digitally sign the first hash value and the public key used to decrypt the digital signature represent the asymmetric key pair. The third hash value not matching the second hash value can indicate that the private key used to digitally sign the first hash value and the public key used to decrypt the digital signature correspond to different asymmetric key pairs, respectively.

[0123] An additional set of one or more digital certificates can be included in the certificate package. Alternatively, the additional set of one or more digital certificates can be included in a dataset to be packaged into the certificate package, or the set of one or more digital certificates can be a standalone digital certificate. The additional set of one or more digital certificates can include one or more CA certificates and / or one or more entity certificates. In one example, the additional set of one or more digital certificates can be close to expiring or currently expired. In one example, the additional set of one or more digital certificates can be expired and can have previously been trusted prior to expiring. In one example, the additional set of one or more digital certificates can be expired and can be trusted except for being expired. In one example, the additional set of one or more digital certificates can be replaced with a new set of one or more digital certificates. The new set of one or more digital certificates can be generated using a new private key of a new asymmetric key pair. The new set of one or more digital certificates can include a new public key corresponding to the new private key of the new asymmetric key pair.

[0124] The distribution service 612 can periodically poll the pending certificate repository 622 for pending certificate packages waiting for validation. The distribution service 612 can determine, based at least in part on polling the pending certificate repository 622, that a pending certificate package is stored in the pending certificate repository 622 and is waiting for validation. In one example, the distribution service can poll the certificate package configuration file to determine whether the certificate package configuration file includes a file pointer pointing to a certificate package stored in the pending certificate repository 622 that is waiting for validation. In response to determining that a pending certificate package is stored in the pending certificate repository 622 and is waiting for validation, the distribution service 612 can download the pending certificate package and the digital signature associated with the pending certificate package. Additionally, or alternatively, the distribution service 612 can receive a notification that a pending certificate package is available in the pending certificate repository 622. In response to receiving the notification, the distribution service 612 can download the pending certificate package and the digital signature associated with the pending certificate package from the pending certificate repository. Upon receiving the pending certificate package and the digital signature associated with the pending certificate package, the distribution service 612 can proceed with validating the pending certificate package.

[0125] In one example, the pending certificate repository 622 can include a first certificate package that includes a first set of one or more digital certificates. The first set of one or more digital certificates can include a first set of one or more first CA certificates. The first certificate package can be waiting for validation by the distribution service 612. The first set of one or more digital certificates can be generated by the CA service using a first private key associated with a first asymmetric key pair. A first public key corresponding to the first asymmetric key pair can be included in at least one first digital certificate in the first set of one or more digital certificates. Additionally, or alternatively, the first public key can be stored in the pending certificate repository 622 or the public key repository 610, e.g., in a data structure that associates the first public key with the first certificate package and / or the first set of one or more digital certificates. Further, the pending certificate repository 622 can include a first digital signature associated with the first certificate package. The first digital signature can be stored in the pending certificate repository 622 in a data structure that associates the first digital signature with the first certificate package.

[0126] In one example, the verified certificate repository 624 can include a second set of one or more digital certificates and / or a second certificate bundle including the second set of one or more digital certificates. The second set of one or more digital certificates can include a second set of one or more second CA certificates. The second certificate bundle and / or the second set of one or more digital certificates can have been previously verified by the distribution service 612. Additionally, or alternatively, the second certificate bundle and / or the second set of one or more digital certificates can be currently or previously trusted by the distribution service 612. The second set of one or more digital certificates can be generated by a CA service using a second private key of a second asymmetric key pair. A second public key of the second asymmetric key pair can be included in at least one second digital certificate of the second set of one or more digital certificates. Additionally, or alternatively, the second public key can be stored in the public key repository 610, e.g., in a data structure associating the second public key with the second certificate bundle and / or the second set of one or more digital certificates.

[0127] The private key used by the CA service 604 to generate the first digital signature associated with the first certificate bundle can be a second private key of a second asymmetric key pair. The distribution service 612 can verify the first digital signature using a second public key of the second asymmetric key pair associated with the second set of one or more digital certificates and / or the second certificate bundle. The second public key can be stored in the public key repository 610. The distribution service 612 can retrieve the second public key from the public key repository 610 and can use the second public key to verify the digital signature. In one example, the distribution service 612 can identify a file pointer in a public key configuration file pointing to the second public key in the public key repository and the distribution service 612 can retrieve the second public key from the public key repository based on the file pointer. The public key configuration file can be stored in the CA service repository 606 or the public key repository 610. The distribution service 612 can use the second public key to determine that the digital signature was generated using the second private key of the second asymmetric key pair. In response to determining that the digital signature was generated using the second private key, the distribution service 612 can store the first certificate bundle as a trusted certificate bundle in the verified certificate repository 624. The verified certificate repository 624 can include a data structure identifying the first certificate bundle as a trusted certificate bundle. Additionally, or alternatively, the distribution service 612 can store the first certificate bundle as a trusted certificate bundle in a certificate repository 618 associated with the distribution service repository 614. The certificate repository 618 can include a data structure identifying the first certificate bundle as a trusted certificate bundle.

[0128] In one example, the distribution service 612 can store the first certificate bundle in the certificate repository 618 in a data structure that identifies the first certificate bundle as a current certificate bundle. Identifying the first certificate bundle as a current certificate bundle can include identifying the first certificate bundle as a trusted certificate bundle. Identifying the first certificate bundle as a current certificate bundle can indicate that the first certificate bundle is currently available for distribution to one or more network entities 616 associated with the virtual cloud network 602. Additionally, or alternatively, identifying the first certificate bundle as a current certificate bundle can indicate that the first certificate bundle is a most recent version of one or more certificate bundles available for distribution to the one or more network entities 616. In one example, prior to storing the first certificate bundle in the certificate repository 618, the certificate repository 618 can include a second certificate bundle that includes a second set of one or more digital certificates. The certificate repository 618 can include a data structure that identifies the second certificate bundle as a current certificate bundle. In one example, the distribution service 612 can update the data structure to identify the second certificate bundle as a previous certificate bundle. Identifying the second certificate bundle as a previous certificate bundle can indicate that the second certificate bundle is an earlier version relative to one or more certificate bundles available for distribution to the one or more network entities 616, such as relative to the first certificate bundle and / or another current certificate bundle. Additionally, or alternatively, identifying the second certificate bundle as a previous certificate bundle can indicate that the second certificate bundle is scheduled to be removed from distribution to the one or more network entities 616 associated with the virtual cloud network 602, and / or that the second certificate bundle is no longer available for distribution to the one or more network entities 616 associated with the virtual cloud network 602. Additionally, or alternatively, identifying the second certificate bundle as a previous certificate bundle can include identifying the second certificate bundle as an untrusted certificate bundle.

[0129] After storing the first certificate bundle in the validated certificate repository 624 and / or the certificate repository 618 associated with the distribution service repository 614, the distribution service 612 can distribute the first certificate bundle to one or more network entities 616 associated with the virtual cloud network 602. In one example, after validating the first certificate bundle and storing the first certificate bundle in the validated certificate repository 624 and / or the certificate repository 618 associated with the distribution service repository 614, the distribution service 612 can delete the first certificate bundle from the pending certificate repository 622. Additionally, or alternatively, the distribution service can store the first public key in the public key repository 610, e.g., for use in validating subsequent digital signatures. In one example, prior to storing the first public key in the public key repository 610, the distribution service 612 can extract the first public key from the first digital certificate of the set of one or more first digital certificates. In one example, the distribution service 612 can update a public key configuration file, and / or a file pointer in the public key configuration file, to point to the first public key in the public key repository. In one example, storing the first public key in the public key repository can include replacing a second public key with the first public key. For example, the distribution service 612 can delete the second public key from the public key repository 610, and / or the distribution service 612 can overwrite the second public key with the first public key.

[0130] In one example, the distribution service 612 can distribute the first certificate package to one or more network entities 616 associated with the virtual cloud network. The first certificate package can include a first set of one or more first CA certificates for use by the network entities 616 to authenticate entity certificates presented by other network entities 616. In one example, after distributing the first certificate package to the one or more network entities 616, the first network entity 616a can determine that the first certificate package is a trusted certificate package. In one example, the first network entity 616a can determine that the first certificate package is a trusted certificate package based on a data structure of a certificate repository identifying the first certificate package as a trusted certificate package. In one example, the first network entity 616a can verify a digital signature associated with the first certificate package in a similar manner as the verification described herein with respect to the distribution service. Additionally, or alternatively, the first network entity 616a can determine that a first CA certificate of the first set of one or more first CA certificates is a trusted CA certificate. In one example, the first network entity 616a can determine that the first CA certificate is a trusted CA certificate based on a data structure of a certificate repository identifying the first certificate package corresponding to the first CA certificate as a trusted certificate package. Additionally, or alternatively, the first network entity 616a can determine that the first CA certificate is a trusted certificate by checking a certificate revocation list and determining that the first CA certificate is not identified in the certificate revocation list. The first network entity 616a can determine that the first CA certificate is a trusted certificate in response to a second network entity 616n presenting an entity certificate issued to the first network entity 616a for authentication. The entity certificate can have been issued by a CA corresponding to the first CA certificate, e.g., using a first private key. Additionally, or alternatively, the entity certificate and the first CA certificate can be included in a certificate chain verified by the first network entity 616a according to a security protocol.

[0131] In one example, after distributing the first certificate bundle to one or more network entities 616, a second network entity 616n can determine that the second certificate bundle is an untrusted certificate bundle. In one example, the second network entity 616n can determine that the second certificate bundle is an untrusted certificate bundle based on a data structure of the certificate repository identifying the second certificate bundle as an untrusted certificate bundle. In one example, the second network entity 616n can attempt to verify a digital signature associated with the second certificate bundle in a similar manner as the verification described herein with respect to the distribution service. The public key can not match the private key used to generate the digital signature, e.g., because the public key in the public key repository 610 has been replaced and / or the pointer to the public key in the public key repository 610 has been updated. Additionally, or alternatively, the second network entity 616n can determine that a second CA certificate of the second set of one or more second CA certificates is an untrusted CA certificate. In one example, the second network entity 616n can determine that the second CA certificate is an untrusted CA certificate based on a data structure of the certificate repository identifying the second certificate bundle corresponding to the second CA certificate as an untrusted certificate bundle. Additionally, or alternatively, the second network entity 616n can determine that the second CA certificate is an untrusted CA certificate by checking a certificate revocation list and determining that the second CA certificate is identified in the certificate revocation list. The second network entity 616n can determine that the second CA certificate is an untrusted certificate in response to an additional network entity 616 presenting an entity certificate issued to the second network entity 616n for authentication. The entity certificate can have been issued by a CA corresponding to the second CA certificate, e.g., using a second private key. The first public key identified by the pointer can not match the second private key. Additionally, or alternatively, the entity certificate and the first CA certificate can be included in a certificate chain that failed verification by the first network entity 616a in accordance with a security protocol.

[0132] In one example, the distribution service 612 can determine that the pending certificate repository 622 includes a third certificate package that includes a third set of one or more digital certificates. The third set of one or more digital certificates can include a third set of one or more third CA certificates. The third certificate package can be awaiting verification by the distribution service 612. The third set of one or more digital certificates can have been generated by the CA service using a third private key associated with a third asymmetric key pair. A third public key corresponding to the third asymmetric key pair can be included in at least one third digital certificate of the third set of one or more digital certificates. Additionally, or alternatively, the third public key can be stored in the pending certificate repository 622 or in the public key repository 610, e.g., in a data structure that associates the third public key with the third certificate package and / or the third set of one or more digital certificates. Further, the pending certificate repository 622 can include a third digital signature associated with the third certificate package. The third digital signature can be stored in the pending certificate repository 622 in a data structure that associates the third digital signature with the third certificate package.

[0133] The third digital signature can have been generated by the CA service 604 using a first private key of a first asymmetric key pair used by the CA service to generate the first set of one or more digital certificates. The distribution service 612 can verify the third digital signature using a first public key of the first asymmetric key pair associated with the first set of one or more digital certificates and / or the first certificate package. The distribution service 612 can retrieve the first public key from the public key repository 610 and can verify the third digital signature using the first public key. In one example, the distribution service 612 can identify a file pointer in a public key configuration file that points to the first public key in the public key repository and the distribution service 612 can retrieve the first public key from the public key repository based on the file pointer. The public key configuration file can be stored in the CA service repository 606 or in the public key repository 610. The distribution service 612 can determine that the third digital signature was generated using the first private key of the first asymmetric key pair using the second public key. In response to determining that the third digital signature was generated using the first private key, the distribution service 612 can store the third certificate package as a trusted certificate package in the verified certificate repository 624. The certificate repository can include a data structure that identifies the third certificate package as a trusted certificate package. Additionally, or alternatively, the distribution service 612 can store the third certificate package as a trusted certificate package in a certificate repository 618 associated with the distribution service repository 614. The certificate repository 618 can include a data structure that identifies the third certificate package as a trusted certificate package.

[0134] In one example, the distribution service 612 can store the third certificate bundle in the certificate repository 618 in a data structure that identifies the third certificate bundle as a current certificate bundle. Identifying the third certificate bundle as a current certificate bundle can include identifying the third certificate bundle as a trusted certificate bundle. Identifying the third certificate bundle as a current certificate bundle can indicate that the third certificate bundle is currently available for distribution to one or more network entities 616 associated with the virtual cloud network 602. Additionally, or alternatively, identifying the third certificate bundle as a current certificate bundle can indicate that the third certificate bundle is a most recent version of one or more certificate bundles available for distribution to the one or more network entities 616. In one example, prior to storing the third certificate bundle in the certificate repository 618, the certificate repository 618 can include a first certificate bundle that includes a first set of one or more digital certificates. The certificate repository 618 can include a data structure that identifies the first certificate bundle as a current certificate bundle. In one example, the distribution service 612 can update the data structure to identify the first certificate bundle as a previous certificate bundle. Identifying the first certificate bundle as a previous certificate bundle can indicate that the first certificate bundle is an earlier version relative to one or more certificate bundles available for distribution to the one or more network entities 616, such as relative to the third certificate bundle and / or another current certificate bundle. Additionally, or alternatively, identifying the first certificate bundle as a previous certificate bundle can indicate that the first certificate bundle is scheduled to be removed from distribution to the one or more network entities 616 associated with the virtual cloud network 602, and / or that the first certificate bundle is no longer available for distribution to the one or more network entities 616 associated with the virtual cloud network 602. Additionally, or alternatively, identifying the first certificate bundle as a previous certificate bundle can include identifying the first certificate bundle as an untrusted certificate bundle.

[0135] After storing the third certificate bundle in the validated certificate repository 624 and / or the certificate repository 618 associated with the distribution service repository 614, the distribution service 612 can distribute the third certificate bundle to one or more network entities 616 associated with the virtual cloud network 602. In one example, after validating the third certificate bundle and storing the third certificate bundle in the validated certificate repository 624 and / or the certificate repository 618 associated with the distribution service repository 614, the distribution service 612 can delete the third certificate bundle from the pending certificate repository 622. Additionally, or alternatively, the distribution service can store the third public key in the public key repository 610, e.g., for use in validating subsequent digital signatures. In one example, prior to storing the third public key in the public key repository 610, the distribution service 612 can extract the third public key from the third digital certificate of the set of one or more third digital certificates. In one example, the distribution service 612 can update a public key configuration file, and / or a file pointer in the public key configuration file, to point to the third public key in the public key repository. In one example, storing the third public key in the public key repository can include replacing the first public key with the third public key. For example, the distribution service 612 can delete the first public key from the public key repository 610, and / or the distribution service 612 can overwrite the first public key with the third public key.

[0136] Referring now to Figure 1 , the system 600 is further described with reference to an example virtual cloud network 650. The virtual cloud network 650 can include or correspond to the virtual cloud network 602 described with reference to Figure 1 . As shown in Figure 1 , the virtual cloud network 650 can include a substrate network 652, an overlay network 654, and a network interface 656 that provides communication between the substrate network 652 and the overlay network 654. The system 600 can include a plurality of network entities 658 located throughout the virtual cloud network 650. The plurality of network entities 658 can correspond to the plurality of network entities 616 described with reference to Figure 1 . The network entities 658 can reside on the substrate network 652, the overlay network 654, or the network interface 656. The network entities 658 can be implemented in hardware and / or software in association with the virtual cloud network, such as nodes, hosts, agents, services, components, endpoints, or other elements. The plurality of network entities 658 can include one or more substrate entities 660, one or more interface entities 662, and / or one or more overlay entities 664.

[0137] As used herein, the term“underlay entity” refers to a network entity 658 implemented in an underlay network 652. As used herein, the term“underlay network” refers to a physical network infrastructure. The underlay network generally provides the foundation for virtual cloud networks. The underlay network 652 can include physical network devices such as routers, switches, network links, and other networking components. The underlay network 652 can generally provide the basic connectivity and transport capabilities necessary for data transfer within and between data centers.

[0138] One or more underlay entities 660 can include underlay hosts, routers, firewall appliances, load balancers, storage devices, and / or underlay services. An underlay host can include an endpoint within the underlay network 652, such as a bare-metal host, a virtual machine, a container, or a physical server. An underlay service can include a service executed or executable on an underlay entity, such as a firmware service, a network connectivity service, an addressing service, a name resolution service, a security service, a network monitoring service, a load balancing service, and / or a storage service. A firmware service can be associated with functionality or management of a network infrastructure component or service, such as a network device, boot or initialization processes, hardware control, feature enablement, updates, hardware abstraction, network configuration, and / or network management. In one example, an underlay entity 660 can include a combination of hardware and software. In one example, one or more underlay entities 660 can include one or more underlay hosts and / or one or more underlay services. In one example, an underlay host can include a bare-metal host. In one example, an underlay service can include a firmware service. Underlay entities 660 can communicate with each other and / or with other network entities 658 using logical network addresses assigned within the overlay network.

[0139] As used herein, the term“network interface” refers to a communication interface between the underlay network and the overlay network, such as a network interface card, a smartNIC, and / or the like. A network interface 656 can include one or more interface entities 662, such as a node on the network interface 656, or an interface service executed or executable on the network interface 656. A node on the network interface 656 can include a programmable hardware component, a memory component, or a gateway component. In one example, a network interface 656 can include a network interface card, such as a smartNIC. Additionally, or alternatively, a network interface 656 can include a node or endpoint on a network interface card or smartNIC.

[0140] The gateway component can provide connectivity between the underlay network 652 and the network interface 656, and / or between the network interface 656 and the overlay network 654. For example, the gateway component can enable communication between the overlay entity 664 and the underlay entity 660. Additionally, or alternatively, the gateway component can provide connectivity between the overlay network 654 and an external network, such as the Internet or another network external to the overlay network. For example, the overlay gateway can enable communication between the overlay entity 664 and an external endpoint.

[0141] As used herein, the term “overlay network” refers to a virtual network built on an underlay network using software-defined networking (SDN), virtualization, tunneling, and / or encapsulation techniques. The overlay network generally operates independently of the underlying underlay network. The overlay network can provide logical separation and isolation of traffic, enabling virtual network provisioning, and / or allowing various network services and policies to be implemented. Virtual machines, hosts, containers, or virtual network functions running on the underlay network can be connected via the overlay network.

[0142] As used herein, the term “overlay entity” refers to a network entity 658 implemented on the overlay network 654. The overlay network 654 can include multiple overlay entities 664. The multiple overlay entities 664 can include overlay hosts, overlay services, subnets, overlay controllers, and / or overlay clients. In one example, the overlay network 654 can include multiple overlay entities 664, such as overlay entity 664c and overlay entity 664n. In one example, the overlay entity 664 can include an overlay host. Additionally, or alternatively, the overlay entity 664 can include an overlay service. The multiple overlay entities 664 can communicate with each other using logical network addresses assigned within the overlay network 654.

[0143] An overlay host can include an endpoint within the overlay network 654, such as a virtual machine, a container, or a physical server. An overlay service can include a service executing or executable on an overlay entity. The overlay service can include a client-specific service, such as a service installed by a client. Additionally, or alternatively, the overlay service can include a virtual network creation service, a virtual network management service, a virtual machine orchestration service, a container orchestration service, a network virtualization service, an overlay security service, a load balancing service, a multi-tenancy service, and / or a tenant isolation service.

[0144] Subnets can include virtual network segments with different addressing schemes and / or different sets of network policies and / or services. Subnets can include a set of overlay hosts. Multiple subnets can be utilized to partition respective sets of overlay hosts. An overlay controller can oversee management, control, provisioning, configuration, and / or monitoring of the overlay network, network entities on the overlay network, and / or network policies within the overlay. An overlay controller interacts with an underlay base network, for example, to coordinate operation of overlay hosts and / or communication across virtual switches and tunnels. Overlay clients can include endpoints or devices that initiate communications within the overlay network. Overlay clients can be particular instances or roles within an overlay host. An overlay host can include a set of overlay clients. Overlay clients can include consumers or users of services provided by an overlay host or an IaaS. Overlay clients can request and consume resources or services from an overlay host, thereby acting as consumers or clients of those resources or services.

[0145] With further reference to Figure 1 , system 600 can include at least one distribution service 666 and at least one certificate repository 668. At least one distribution service 666 can correspond to distribution service 612 described with reference to Figure 1 . Distribution service 666 can be configured to validate a certificate package, for example, as described with reference to Figure 1 . Additionally, or as an alternative, distribution service 666 can be configured to distribute a certificate package to at least some of network entities 658. The certificate package can be housed in certificate repository 668 accessible to distribution service 612. Certificate repository 668 can correspond to certificate repository 618 associated with distribution service repository 614, as described with reference to Figure 1 . Distribution service 666 can retrieve a certificate package from certificate repository 668 and transmit the certificate package to one or more of network entities 658. In one example, distribution service 666 can be configured to transition a plurality of network entities through a series of phases of a certificate package distribution process for distributing a new set of one or more CA certificates to a plurality of network entities 658 for use in a certificate authentication process, such as concurrently, for example, as further described in Section 6, “Example Certificate Package Distribution Process,” below.

[0146] In one example, a first distribution service 666a can be implemented on the substrate network 652. The distribution service 666 implemented on the substrate network 652 can be communicatively coupled with one or more substrate entities 660 on the substrate network 652. Additionally, or alternatively, the distribution service 666 implemented on the substrate network 652 can be communicatively coupled with the network interface 656, such as one or more interface entities 662 on the network interface 656. For example, the first distribution service 666a can obtain a certificate package from the certificate repository 668 and distribute the certificate package to one or more substrate entities 660 on the substrate network 652 and / or one or more interface entities 662 on the network interface 656.

[0147] In one example, a second distribution service 666b can be implemented on the network interface 656. The distribution service 666 implemented on the network interface 656 can be communicatively coupled with the overlay network 654 and / or the substrate network 662. For example, the second distribution service 666b implemented on the network interface 656 can be communicatively coupled with one or more overlay entities 664 on the overlay network 654. The second distribution service 666b can distribute a certificate package to one or more overlay entities 664 on the overlay network 654. In one example, the second distribution service 666b can obtain a certificate package from a storage medium associated with the network interface 656, such as from a storage medium associated with an interface entity 662 on the network interface 656. For example, the second distribution service 666b can distribute a certificate package that is already installed in a storage medium associated with the network interface 656 and / or the interface entity 662. In one example, the first distribution service 666a can distribute a certificate package to an interface entity 662 on the network interface 656, and the second distribution service 666b can distribute the certificate package to one or more overlay entities 664 on the overlay network 654 after the certificate package has been installed in a storage medium associated with the interface entity 662.

[0148] As shown in Figure 1 Each network entity 658 can include a provisioning module 670 and a storage medium 672, as shown in FIG. 6. The provisioning module 670 associated with a network entity 658 can receive a certificate package from the distribution service 666 and install the certificate package in the storage medium 672 associated with the network entity 658. The distribution service 666 can distribute the certificate package to the provisioning module 670 in connection with an initial provisioning of the network entity 658 and / or in connection with a periodic update. Additionally, or alternatively, the distribution service 666 can distribute the certificate package to the provisioning module 670 according to a respective phase of a certificate package distribution process.

[0149] In one example, the provisioning module 670 of overlay entity 664 can send a request for a certificate package to the distribution service 666 via a gateway 674 between network interface 656 and overlay entity 664. Alternatively, the distribution service 666 can send the certificate package to overlay entity 664 via gateway 674, for example, in response to a request from provisioning module 670. In one example, gateway 674 can be a metadata interface configured to exchange metadata between network interface 656 and overlay entity 664. In one example, gateway 674 can be utilized between network interface 656 and each overlay entity 664. Alternatively, network interface 656 can include a set of gateways 674, each gateway 674 corresponding to a specific overlay entity 664.

[0150] A virtual cloud network may include one or more data repositories. One or more data repositories may include references. Figure 1 The CA service store 606 and / or distribution service store 614 are described respectively. One or more data stores may also include a certificate store 608 and / or a public key store 610, respectively described in association with the CA service store 606. Additionally, or alternatively, one or more data stores may also include a certificate store 618 and / or a public key store 620, respectively described in association with the distribution service store 614. Additionally, or alternatively, one or more data stores may include references to... Figure 1 The described certificate store 668 and / or various storage media 672. Each of the one or more data stores may include any type of storage unit and / or device for storing data (e.g., file system, database, collection of tables, or any other storage mechanism). Additionally, a data store may include multiple different storage units and / or devices. These multiple different storage units and / or devices may or may not be of the same type or located in the same physical location. One or more data stores may share one or more storage units with each other. Additionally, or alternatively, one or more data stores may include one or more storage units that are different from each other. Furthermore, one or more data stores may be implemented or executed on the same computing system as one or more of the CA service 604, distribution service 612, and / or network entity 616. Additionally, or alternatively, one or more data stores may be implemented or executed on a separate computing system from one or more of the CA service 604, distribution service 612, and / or network entity 616. One or more data repositories may be coupled to one or more of the following network entities 616 via direct connection or via network communication: CA service 604, distribution service 612, and / or network entity 616.

[0151] In one or more embodiments, system 600 can include more or less components than those illustrated in Figure 1 and Figure 1 embodied in FIGS. 1-6. Figure 1 and Figure 1 The components illustrated in FIGS. 1-6 can be local to or remote from each other. Figure 1 and Figure 1 The components illustrated in FIGS. 1-6 can include software and / or hardware components. Each component can be distributed over multiple applications and / or machines. Multiple components can be combined into a single application and / or machine. An operation described with respect to one component can instead be performed by another component. Additional embodiments and / or examples related to system 600 are described in Section 2 above, entitled "Cloud Computing Technology."

[0152] In embodiments, system 600 can include various components implemented at one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device can refer to a physical device that executes an application or a virtual machine. Examples of digital devices include a computer, a tablet computer, a laptop computer, a desktop computer, a netbook, a server, a web server, a network policy server, a proxy server, a general-purpose machine, a function-specific hardware device, a hardware router, a hardware switch, a hardware firewall, a hardware firewall, a hardware network address translator (NAT), a hardware load balancer, a mainframe, a television, a content receiver, a set-top box, a printer, a mobile phone, a smart phone, a personal digital assistant (PDA), a wireless receiver and / or transmitter, a base station, a communication management device, a router, a switch, a controller, an access point, and / or a client device.

[0153] 6. authenticating network entities

[0154] A network entity can authenticate other network entities associated with a virtual cloud network with the CA certificate in the certificate package. For example, communications between network entities can be conducted in accordance with a security protocol. The security protocol can include authenticating a network entity based on an entity certificate issued to the network entity by the CA, e.g., prior to establishing communications with the network entity.

[0155] A distribution service can distribute the certificate package to network entities. In one example, a distribution service can determine whether a certificate package is a trusted certificate package prior to distributing the certificate package to network entities. The distribution service can reject certificate packages that the distribution service determines are not trusted certificate packages. Additionally, or alternatively, a network entity can determine whether a certificate package is a trusted certificate package prior to authenticating other network entities with the CA certificate in the certificate package. The network entity can reject certificate packages that the network entity determines are not trusted certificate packages.

[0156] As used herein, the term “certificate bundle” refers to a file that includes one or more digital certificates. In one example, the one or more digital certificates in a certificate bundle can include CA certificates, such as root CA certificates or intermediate CA certificates. In another example, the one or more digital certificates in a certificate bundle can include one or more entity certificates.

[0157] As used herein, the term “trusted certificate bundle” refers to a certificate bundle that has been validated based on a digital signature associated with the certificate bundle. The digital signature can be validated by a distribution service as described herein. A network entity that receives a certificate bundle from a distribution service can rely on the validation performed by the distribution service. In one example, a network entity can treat a certificate bundle received from a distribution service as a trusted certificate bundle, e.g., based on a system architecture in which the distribution service validates a certificate bundle prior to distributing the certificate bundle to the network entity. A network entity that receives a certificate bundle from a distribution service can inherently trust the certificate bundle such that a certificate bundle received by the network entity from the distribution service can be treated as a trusted certificate bundle. Additionally, or alternatively, a network entity can treat a certificate bundle received from a distribution service as a trusted certificate bundle based on a system architecture in which the distribution service stores certificate bundles that have been validated in a data structure that identifies the certificate bundles as trusted certificate bundles. In one example, a certificate bundle can be identified as a trusted certificate bundle, e.g., by a network entity, based on a file pointer in a certificate bundle configuration file that points to a file location that stores a certificate bundle that has been validated and is therefore a trusted certificate bundle. The certificate bundle configuration file can be stored in the CA service repository 606 or the certificate repository 608. The network entity can verify that the certificate bundle received from the distribution service corresponds to the location identified by the file pointer. Additionally, or alternatively, the network entity can determine that a certificate bundle is a trusted certificate bundle by validating a digital signature associated with the certificate bundle, e.g., as an addition or alternative to the validation performed by the distribution service.

[0158] As used herein, the term “untrusted certificate bundle” refers to a certificate bundle that (a) has not been validated based on a digital signature associated with the certificate bundle, (b) is not verifiable based on a digital signature, or (d) is associated with a digital signature that was previously validated or verifiable and is no longer valid or verifiable, or (e) has been identified by a distribution service as an untrusted certificate bundle. An untrusted certificate bundle can include a certificate bundle that fails to satisfy one or more criteria for validating a certificate bundle and / or for determining that a certificate bundle is a trusted certificate bundle. An untrusted certificate bundle can include a certificate bundle that was previously trusted by a network entity but is no longer trusted by the network entity. An untrusted certificate bundle can include a certificate bundle that is no longer used by a network entity to authenticate other network entities.

[0159] In one example, a network entity can treat a certificate bundle as an untrusted certificate bundle if the certificate bundle is not provided to the network entity from a distribution service, e.g., based on a system architecture in which the distribution service verifies a certificate bundle before distributing the certificate bundle to a network entity. A network entity that receives a certificate bundle from a source other than a distribution service can inherently distrust the certificate bundle, such that a certificate bundle received by a network entity from a source other than a distribution service can be treated as an untrusted certificate bundle. Additionally, or alternatively, a network entity can treat a certificate bundle as an untrusted certificate bundle based on a message or instruction received from a distribution service. In one example, a distribution service can transmit a message to a network entity that a certificate bundle that was previously a trusted certificate bundle is being replaced and is no longer a trusted certificate bundle. The network entity can treat the previously trusted certificate bundle as an untrusted certificate bundle, e.g., based on the message or instruction from the distribution service. In one example, a network entity can delete an untrusted certificate bundle. Additionally, or alternatively, a network entity can receive a new certificate bundle as a trusted certificate bundle, and the trusted certificate bundle can replace or overwrite the untrusted certificate bundle (e.g., the previously trusted certificate bundle). In one example, a certificate bundle can be identified as an untrusted certificate bundle, e.g., by a network entity, based on a file pointer in a certificate bundle configuration file pointing to a file location storing the certificate bundle as an untrusted certificate bundle. The certificate bundle configuration file can be stored in the CA service repository 606 or the certificate repository 608. The network entity can determine that the certificate bundle corresponds to a location for an untrusted certificate bundle identified by the file pointer, and based on the location identified by the file pointer, the network entity can determine that the certificate bundle is an untrusted certificate bundle. Additionally, or alternatively, a network entity can determine that a certificate bundle is an untrusted certificate bundle by performing a verification operation on a digital signature associated with the certificate bundle and determining that the digital signature fails the verification operation.

[0160] In one example, an entity certificate and a CA certificate corresponding to a CA that issued the entity certificate can represent at least a portion of a certificate chain. To authenticate a network entity, each signature-key pair in the certificate chain is verified. In one example, a top-level CA can issue an entity certificate, in which case the certificate chain can include one signature-key pair - i.e., a digital signature of the top-level CA in the entity certificate and a public key of the top-level CA. Such a top-level CA is sometimes referred to as a root CA. In another example, the certificate chain can include signature-key pairs corresponding to multiple CA certificates. For example, a root CA can issue an intermediate CA certificate to an intermediate CA, and the intermediate CA can issue an entity certificate to a network entity. In this case, the certificate chain includes two signature-key pairs - i.e., (i) a digital signature of the intermediate CA in the entity certificate and a public key of the intermediate CA; and (ii) a digital signature of the root CA in the intermediate CA certificate and a public key of the root CA.

[0161] A trusted certificate bundle can include one or more trusted CA certificates. An untrusted certificate bundle can include one or more untrusted CA certificates. As used herein, the term “trusted CA certificate” refers to a CA certificate included in a trusted certificate bundle. As used herein, the term “untrusted CA certificate” refers to a CA certificate included in an untrusted certificate bundle.

[0162] In one example, a network entity can determine that a CA certificate is a trusted CA certificate, e.g., prior to using the CA certificate to authenticate another network entity. A trusted CA certificate can be validated, e.g., as part of a certificate chain based on a signature-key pair corresponding to the trusted CA certificate. When a network entity successfully authenticates another network entity based on a certificate chain including an entity certificate presented by the other network entity and one or more CA certificates, each of which is a trusted CA certificate, the network entity can trust the other network entity. In one example, a network entity can trust another entity that presents an entity certificate that was issued by a CA based on a trusted CA certificate, such as a root CA certificate that is a trusted CA certificate.

[0163] In one example, a network entity can reject a CA certificate that is an untrusted CA certificate. For example, a network entity can determine whether a CA certificate is a trusted CA certificate or an untrusted CA certificate, e.g., prior to using the CA certificate to authenticate another network entity. In response to determining that the CA certificate is an untrusted CA certificate, the network entity can terminate or refrain from initiating an authentication process for the other network entity based on the untrusted CA certificate. In one example, based on a certificate chain including an entity certificate presented by another network entity for authentication and one or more untrusted CA certificates, the network entity can not trust the other network entity or can determine that the other network entity is not authenticated. For example, when another network entity presents an entity certificate that was issued by a CA based on an untrusted CA certificate, such as a root CA certificate that is an untrusted CA certificate, for authentication, the network entity can not trust the other network entity or can determine that the other network entity is not authenticated.

[0164] As used herein, the term “certificate authority certificate” or “CA certificate” refers to a digital certificate issued by a CA for establishing its own identity and authenticity. A CA certificate issued by a CA can include a public key corresponding to a private key held by the CA. A certificate authority certificate can be a root CA certificate or an intermediate CA certificate. A certificate authority certificate can be used to sign and issue other digital certificates, including digital certificates for secure communications between network entities.

[0165] As used herein, the term “certificate authority” or “CA” refers to an entity responsible for issuing and managing digital certificates. A CA verifies the identity of a network entity and digitally signs its certificate to prove its authenticity.

[0166] As used herein, the term “root certificate authority certificate” or “root CA certificate” refers to a top-level CA certificate in a certificate chain or hierarchy. A root CA certificate can be self-issued and / or self-signed by a root CA. As used herein, the term “root CA” refers to a top-level CA in a CA hierarchy. A root CA can issue a root CA certificate, an intermediate CA certificate, or an entity certificate.

[0167] As used herein, the term “intermediate certificate authority certificate” or “intermediate CA certificate” refers to an intermediate-level CA certificate in a certificate chain or hierarchy. An intermediate CA certificate can be issued by a root CA. An intermediate CA certificate is located in a certificate chain or hierarchy between a root CA certificate and an entity certificate. As used herein, the term “intermediate CA” refers to an intermediate-level CA in a CA hierarchy. For example, an intermediate CA can issue entity certificates, e.g., in accordance with permissions granted to the intermediate CA by a root CA.

[0168] As used herein, the term “entity certificate” refers to a digital certificate issued to an entity, such as a network entity associated with a virtual cloud network. An entity certificate can be used to verify the identity of an entity and enable secure communication between entities, such as network entities in a virtual cloud network. An entity certificate can be issued by a CA, such as a root CA or an intermediate CA.

[0169] In one example, an entity certificate can be an instance master certificate. As used herein, the term “instance master certificate” refers to a digital certificate used to authenticate and secure communications for an instance or VM associated with a virtual cloud network. In one example, instances and VMs can be dynamically created, scaled, and terminated. An instance master certificate can be associated with an instance or VM during its lifetime and can be automatically generated and managed by the virtual cloud network infrastructure. An instance master certificate can have limited access to communicate with certain network entities based on permissions assigned to the network entity to which the instance master certificate was issued.

[0170] As used herein, the term“digital certificate” refers to a digitally signed electronic document that binds a public key to the identity of an entity or certificate holder. The entity or certificate holder can hold a private key that corresponds to the public key. The public key can be included in or associated with the digital certificate. The digital certificate can be verified by matching the public key to the private key via the use of cryptography. The digital certificate can conform to International Telecommunication Union Standard X.509. The digital certificate can include the name of the issuer, the name of the certificate holder, the public key, issuer (CA) information, and an expiration date. The digital certificate can be used in various security protocols, such as SSL / TLS, to establish the identity and authenticity of a communicating party and to facilitate secure communications.

[0171] 6. Example certificate bundle distribution process

[0172] Reference is now made to Figure 1 , further describing operations related to an example certificate bundle distribution process. Reference is made to Figure 1 Operations 700 described in FIG. 7 can be associated with distributing a new set of one or more CA certificates to a plurality of network entities for use in a certificate authentication process. The CA certificates can include root CA certificates and / or intermediate CA certificates. The CA certificates can be stored in a certificate bundle. Figure 1 One or more operations 700 shown in FIG. 7 can be modified, rearranged, or omitted altogether. Accordingly, Figure 1 The particular order of operations 700 shown in FIG. 7 should not be construed as limiting the scope of one or more embodiments. As Figure 1 FIG. 7, operations 700 related to a certificate bundle distribution process can include a series or sequence of stages. In one example, as shown, operations 700 can include a series or sequence of stages, such as four (4) stages. In another example, the series or sequence of stages can include more or less than four (4) stages, for example, including Figure 1 all or a portion of the stages shown in FIG. 7.

[0173] In one example, operations 700 can include, at block 702, distributing a new certificate bundle containing a new set of one or more CA certificates to a set of network entities associated with a virtual cloud network. The new set of one or more CA certificates can include at least one new CA certificate. Additionally, or alternatively, a set of new CA certificates can be added to an existing certificate bundle. At block 704, operations 700 can include determining whether the new certificate bundle has been successfully distributed. When the new certificate bundle has been successfully distributed, operations 700 can proceed to the next stage in the distribution process. The operations at block 702 and / or 704 can represent stage 1 of the certificate bundle distribution process.

[0174] In one example, the operations 700 can include, at block 706, activating the CA certificate in the new certificate package. In one example, activating the CA certificate can include the CA corresponding to the CA certificate issuing one or more intermediate CA certificates. The operations at block 706 can represent phase 2 of the certificate package distribution process. In one example, the operations 700 can include, at block 708, distributing the new entity certificate to the set of network entities. Additionally, or alternatively, the operations 700 can include distributing the new intermediate CA certificate, e.g., the new intermediate CA certificate corresponding to the new entity certificate.

[0175] At block 710, the operations 700 can include determining whether the new entity certificate has been successfully distributed. Additionally, or alternatively, the operations can include determining whether the new intermediate CA certificate has been successfully distributed. When the new entity certificate (and / or the new intermediate CA certificate) has been successfully distributed, the operations 700 can proceed to the next phase in the distribution process. The operations at blocks 708 and 710 can represent phase 3 of the certificate package distribution process.

[0176] In one example, the operations 700 can include, at block 712, removing an earlier CA certificate that was distributed prior to the new CA certificate. For example, the earlier CA certificate can include a CA certificate that is being replaced by the new CA certificate. Removing the earlier CA certificate for a particular network entity can include deleting the earlier CA certificate from a storage medium associated with the particular network entity. For example, the operations 700 can include transmitting an instruction to the particular network entity to delete the earlier CA certificate from the storage medium. In response to receiving the instruction, the particular network entity can delete the earlier CA certificate from the storage medium.

[0177] Additionally, or alternatively, removing the earlier CA certificate for the network entity can include replacing a first new certificate package with a second new certificate package, where the first new certificate package includes the new CA certificate and the earlier CA certificate, and the second new certificate package includes only the new CA certificate, thereby effectively removing the earlier CA certificate from the first new certificate package. The second new certificate package can be distributed to the particular network entity and installed in a storage medium associated with the particular network entity, and the first new certificate package can be deleted from the storage medium. The operations at block 712 can represent phase 4 of the certificate package distribution process.

[0178] 7. Verifying a certificate package

[0179] Reference is now made to Figure 1 , which further describes operations 800 related to verifying a certificate package. Reference is made to Figure 1 The operations 800 described with reference to Figure 1One or more operations 800 described may be modified, combined, rearranged, or omitted together. Accordingly, refer to... Figure 1 The specific order of operations 800 described should not be construed as limiting the scope of one or more embodiments.

[0180] like Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 Figure 1 As shown, operation 800 may include, at block 802, receiving a certificate packet comprising a first set of one or more digital certificates and a digital signature associated with the certificate packet. At block 804, operation 800 may include retrieving the public key of an asymmetric key pair associated with a second set of one or more digital certificates. At block 806, operation 800 may include determining whether the digital signature was generated using the private key of the asymmetric key pair.

[0181] In response to determining that the digital signature was generated using the private key of an asymmetric key pair, operation 800 may proceed to 808. At box 808, operation 800 may include storing the certificate packet as a trusted certificate packet in a certificate store. The certificate store may include data structures that identify the certificate packet as a trusted certificate packet. Additionally, or alternatively, in response to determining that the digital signature was not generated using the private key of an asymmetric key pair, operation 800 may proceed to 810. At box 810, operation 800 may include rejecting the certificate packet as an untrusted certificate packet.

[0182] 8. Other matters; extension

[0183] The embodiments are directed to a system having one or more devices, which include a hardware processor and are configured to perform any of the operations described herein and / or any of the following claims. The embodiments are directed to a system including means for performing any of the operations described herein and / or any of the following claims. In the embodiments, a non-transitory computer-readable storage medium includes instructions that, when executed by one or more hardware processors, cause to perform any of the operations described herein and / or any of the claims.

[0184] Any combination of the features and functions described herein may be used according to one or more embodiments. In the foregoing description, embodiments have been described with reference to numerous specific details that may vary depending on the implementation. Accordingly, this specification and the accompanying drawings should be viewed in an illustrative rather than restrictive sense. The unique and exclusive reference to the scope of the invention, and what the applicant intends to define as the scope of the invention, is the literal and equivalent scope of the set of claims issued in this application, in the specific form of such claims, including any subsequent amendments.

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

Claims

1. One or more computer-readable media storing instructions, which, when executed by one or more hardware processors, cause to perform operations including: Receive the first certificate packet and the digital signature associated with the first certificate packet. The first certificate package includes a first set of one or more digital certificates; Using the public key of an asymmetric key pair associated with a second set of one or more digital certificates, determine that the digital signature was generated using the private key of the asymmetric key pair; In response to determining that the digital signature was generated using the private key, the first certificate package is stored as a trusted certificate package in the certificate store.

2. The medium according to claim 1, wherein the operation further comprises: Receive the first public key from the first asymmetric key pair associated with the first digital certificate in the first set of one or more digital certificates. The public key associated with the second set of one or more digital certificates is a second public key, and the private key used to generate the digital signature is a second private key; as well as In response to determining that the digital signature was generated using the second private key, the first public key is stored in a public key store, wherein the public key store includes a first data structure that identifies the first public key as associated with a first digital certificate in a first set of one or more digital certificates. The second public key is stored in the public key store before the first public key is stored therein, wherein the public key store includes a second data structure that identifies the second public key as associated with a second set of one or more digital certificates.

3. The medium of claim 2, wherein storing the first public key in the public key store includes replacing the second public key with the first public key.

4. The medium according to claim 2, wherein the first public key is included in the first digital certificate, and wherein the operation further includes: The first public key is retrieved from the first digital certificate before being stored in the public key store.

5. The medium according to claim 2, wherein the operation further comprises: Before determining that the digital signature was generated using the second private key, a file pointer in the public key profile is identified, wherein the file pointer points to the second public key in the public key store, and the second public key is retrieved from the public key store based on the file pointer; as well as After determining that the digital signature was generated using the second private key, the first public key is stored in the public key store and the public key configuration file and / or the file pointer in the public key configuration file are updated to point to the first public key in the public key store.

6. The medium according to claim 2, wherein the operation further comprises: Receive a third certificate packet and a third digital signature associated with the third certificate packet. The third certificate package includes (i) a third set of one or more digital certificates and (ii) a third public key of a third asymmetric key pair associated with a third digital certificate in the third set of one or more digital certificates. The third digital signature is generated using the first private key of the first asymmetric key pair associated with the first set of one or more digital certificates; Identify a file pointer in the public key configuration file, wherein the file pointer points to the first public key in the public key store; Retrieve the first public key from the public key store based on the file pointer; Using the first public key, it is determined that the third digital signature was generated using the first private key; In response to determining that the third digital signature was generated using the first private key: The third certificate package is stored as a trusted certificate package in the certificate store. The third public key is stored in the public key store, wherein the public key store includes a third data structure that identifies the third public key as associated with a third digital certificate in the third set of one or more digital certificates, wherein storing the third public key in the public key store includes replacing the first public key with the third public key; as well as Update the public key configuration file and / or the file pointer in the public key configuration file to point to the third public key in the public key store; The certificate store includes a fourth data structure, wherein before storing the third certificate package in the certificate store, the fourth data structure identifies the first certificate package as a trusted certificate package, and wherein storing the third certificate package as a trusted certificate package in the certificate store includes: The fourth data structure is updated to identify the first certificate package as an untrusted certificate package and the third certificate package as a trusted certificate package.

7. The medium of claim 1, wherein the private key is held by a Certificate Authority (CA), and wherein the trusted certificate package includes one or more CA certificates issued by the CA.

8. The medium of claim 1, wherein the trusted certificate package comprises one or more Certificate Authority (CA) certificates, and wherein the first network entity trusts the second network entity based on an authentication operation performed by the first network entity, wherein the authentication operation includes verifying a certificate chain comprising (a) an entity certificate presented by the second network entity and (b) at least one of the one or more CA certificates.

9. The medium according to claim 1, wherein the operation further comprises: Before receiving the first certificate package and the digital signature associated with the first certificate package: Poll the pending certificate store for each pending certificate packet; as well as In response to polling the pending certificate store for the pending certificate package, the first certificate package and the digital signature associated with the first certificate package are downloaded, wherein the first certificate package is the pending certificate package.

10. The medium according to claim 1, wherein the operation further comprises: Before receiving the first certificate package and the digital signature associated with the first certificate package: Receive notification that a pending certificate package is available in the pending certificate store; as well as In response to receiving the notification, the first certificate package and the digital signature associated with the first certificate package are downloaded from the suspended certificate store, wherein the first certificate package is the suspended certificate package.

11. The medium of claim 1, wherein the certificate store includes a data structure for identifying the first certificate package as a trusted certificate package, and wherein the second set of one or more digital certificates is included in a second certificate package stored in the certificate store, and wherein the operation further includes: The data structure is updated to identify the first certificate package as the current certificate package and the second certificate package as the previous certificate package.

12. The medium of claim 11, wherein the operation further comprises: After updating the data structure to identify the first certificate package as the current certificate package, the current certificate package is distributed to one or more network entities associated with the virtual cloud network.

13. The medium of claim 12, wherein updating the data structure to identify the second certificate package as the previous certificate package includes identifying the second certificate package as an untrusted certificate package.

14. The medium of claim 12, wherein the first set of one or more digital certificates comprises a first set of one or more first CA certificates, and wherein the second set of one or more digital certificates comprises a second set of one or more second CA certificates.

15. The medium of claim 14, wherein after the current certificate package is distributed to the one or more network entities associated with the virtual cloud network, (a) a first network entity among the one or more network entities determines that a first CA certificate in the first set of one or more first CA certificates is a trusted CA certificate, or (b) a second network entity among the one or more network entities determines that a second CA certificate in the second set of one or more second CA certificates is an untrusted CA certificate.

16. The medium of claim 1, wherein the digital signature is generated by (a) applying a hash function to the first certificate packet to obtain a first hash value and (b) digitally signing the first hash value using the private key of the asymmetric key pair associated with the second set of one or more digital certificates.

17. The medium of claim 16, wherein determining that the digital signature was generated using the private key includes: The second hash value is generated by applying the hash function to the first certificate packet; A third hash value is generated by decrypting the digital signature using the public key. as well as The third hash value is determined to match the second hash value.

18. The medium of claim 1, wherein the second set of one or more digital certificates is currently or previously trusted before receiving the first certificate packet.

19. A method comprising the operations described in any one of claims 1-18.

20. A system comprising: At least one hardware processor; The system is configured to use the at least one hardware processor to perform the operations described in any one of claims 1-18.

21. A computer program product storing instructions that, when executed by one or more hardware processors, cause to perform the operations described in any one of claims 1-18.

22. A system comprising means for performing the operations described in any one of claims 1-18.

Images