US-12621168-B1 - Connector for private certificate authority and directory service

Abstract

A method includes receiving, by a service operating in a provider network comprising a plurality of tenants, a request from a user device of one or more user devices in a user VPC of a first tenant of the plurality of tenants, wherein the request includes service identity information and authentication information. The method also includes providing, by the service, the request to an intermediary service operating in the provider network, wherein the intermediary service associates the service identity information with information maintained by the intermediary service associated with the tenants, and authenticating, by the intermediary service and with a domain controller, the request based on the authentication information. The method further includes, after the request is successfully authenticated, generating, by a private certificate authority (PCA) in a service VPC separate from the user VPC, a certificate based on the request, and providing the certificate to the user device.

Inventors

• Kyle Benjamin Schultheiss
• Daniel Jiyoung Choi
• Divyansh Gupta

Assignees

• AMAZON TECHNOLOGIES, INC.

Dates

Publication Date

20260505

Application Date

20230929

Claims (20)

1. 1 . A method, comprising: receiving, by a service operating in a provider network comprising a plurality of tenants, a request from a user device of one or more user devices in a user virtual private cloud (VPC) of a first tenant of the plurality of tenants, wherein the request includes service identity information and authentication information; providing, by the service, the request to an intermediary service operating in the provider network, wherein the intermediary service associates the service identity information with information maintained by the intermediary service associated with the tenants; authenticating, by the intermediary service and with a domain controller, the request based on the authentication information; after the request is successfully authenticated, generating, by a private certificate authority (PCA) in a service VPC separate from the user VPC, a certificate based on the request; and providing, by the service, the certificate to the user device.
2. 2 . The method of claim 1 , further comprising, before receiving the request: generating a private network connection between the service VPC and the user VPC based on private network credentials provided by the user device; generating a domain controller connection between the intermediary service and the domain controller based on domain controller credentials stored by the intermediary service; and providing, from the PCA to the domain controller, a certificate chain to establish trust between the PCA and the domain controller based on the certificate chain.
3. 3 . The method of claim 1 , wherein the service VPC includes a plurality of intermediary services including the intermediary service, wherein each of the plurality of intermediary services is associated with a tenant including the user VPC.
4. 4 . The method of claim 3 , further comprising, after receiving the request: identifying, by the service, the intermediary service from the plurality of intermediary services based on the service identity information of the request.
5. 5 . The method of claim 1 , wherein authenticating the request comprises: generating a domain controller connection between the intermediary service and the domain controller via a proxy service; and verifying, with the domain controller and via the proxy service, the authentication information of the request for authenticating the request.
6. 6 . A system, comprising: at least one compute node operating in a provider network, the compute node configured to perform operations comprising: receiving, by a service device, a request from a user device of one or more user devices in a user virtual private cloud (VPC), the request including service identity information and authentication information; providing, by the service device, the request to an intermediary service, the intermediary service associated with the service identity information; authenticating, by the intermediary service and with a domain controller, the request based on the authentication information; after the request is successfully authenticated, generating, by a private certificate authority (PCA), a certificate based on the request; and providing, by the service device, the certificate to the user device.
7. 7 . The system of claim 6 , wherein the intermediary service and the PCA are in a service VPC separate from the user VPC.
8. 8 . The system of claim 7 , wherein the at least one compute node is configured to perform operations further comprising, before receiving the request: generating a private network connection between the service VPC and the user VPC based on private network credentials provided by the user device; generating a domain controller connection between the intermediary service and the domain controller based on domain controller credentials stored by the intermediary service; and providing, from the PCA to the domain controller, a certificate chain to establish trust between the PCA and the domain controller based on the certificate chain.
9. 9 . The system of claim 6 , wherein the service VPC includes a plurality of intermediary services including the intermediary service.
10. 10 . The system of claim 9 , wherein the at least one compute node is configured to perform operations further comprising, after receiving the request: identifying, by the service device, the intermediary service from the plurality of intermediary services based on the service identity information of the request.
11. 11 . The system of claim 6 , wherein the service device comprises one or more of the intermediary service or the PCA.
12. 12 . The system of claim 6 , wherein authenticating the request comprises: generating a domain controller connection between the intermediary service and the domain controller via a proxy service; and verifying, with the domain controller and via the proxy service, the authentication information of the request for authenticating the request.
13. 13 . The system of claim 12 , wherein the proxy service and the domain controller are in the user VPC.
14. 14 . A non-transitory computer-readable medium, comprising: one or more instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving a request from a user device of one or more user devices in a user virtual private cloud (VPC), the request including service identity information and authentication information; providing the request to an intermediary service of a plurality of intermediary services, the intermediary service associated with the service identity information; authenticating, using the intermediary service and with a domain controller, the request based on the authentication information; after the request is successfully authenticated, generating, by a private certificate authority (PCA), a certificate based on the request; and providing the certificate to the user device.
15. 15 . The non-transitory computer-readable medium of claim 14 , wherein the one or more instructions cause the one or more processors to perform operations further comprising, before receiving the certificate request: generating a private network connection between a service VPC and the user VPC based on private network credentials provided by the user device wherein the service VPC includes a plurality of intermediary services including the intermediary service; generating a domain controller connection between the intermediary service and the domain controller based on domain controller credentials stored by the intermediary service; and providing, from the PCA to the domain controller, a certificate chain to establish trust between the PCA and the domain controller based on the certificate chain.
16. 16 . The non-transitory computer-readable medium of claim 14 , wherein the service VPC includes a plurality of intermediary services including the intermediary service.
17. 17 . The non-transitory computer-readable medium of claim 16 , wherein the one or more instructions cause the one or more processors to perform operations further comprising, after receiving the request: identifying the intermediary service from the plurality of intermediary services based on the service identity information of the request.
18. 18 . The non-transitory computer-readable medium of claim 14 , wherein the intermediary service and the PCA are running on the same device.
19. 19 . The non-transitory computer-readable medium of claim 14 , wherein authenticating the request comprises: generating a domain controller connection between the intermediary service and the domain controller via a proxy service; and verifying, with the domain controller and via the proxy service, the authentication information of the request for authenticating the request.
20. 20 . The non-transitory computer-readable medium of claim 19 , wherein the proxy service and the domain controller are in the user VPC.

Description

BACKGROUND Some directory environments rely on a dedicated certificate services server role to provide autoenrollment for directory-joined users and computers. Customers may be required to either run the role themselves or can opt to pay for a third-party-managed certificate authority (CA) service (e.g., private CA). Users who choose to run the service themselves may encounter licensing fees as well as other hidden costs in terms of operation including costs for staff, configuration, maintenance, patching, server hardware, backup, disaster recovery, and secure hardware for protecting cryptographic secrets. Running a private CA securely may involve complex security work that is time-consuming, easy to get wrong, and requires teams with specialized talent. Users who lack the expertise to handle all of these tasks therefore may choose to outsource CA operations and expertise to consultants and legacy managed CA service providers at an even higher cost. BRIEF DESCRIPTION OF THE DRAWINGS Certain features of the subject technology are set forth in the appended claims. However, for purpose of explanation, several embodiments of the subject technology are set forth in the following figures. FIG. 1 illustrates a diagram of an example private CA system, in accordance with one or more embodiments of the subject technology. FIG. 2 illustrates an example communication with an intermediary service, in accordance with one or more embodiments of the subject technology. FIG. 3 illustrates an example communication with a proxy service, in accordance with one or more embodiments of the subject technology. FIG. 4 illustrates an example certificate issuance, in accordance with one or more embodiments of the subject technology. FIG. 5A illustrates a diagram of the example private CA system of FIG. 1 in a multi-tenant configuration, in accordance with one or more embodiments of the subject technology. FIG. 5B illustrates a diagram of the example intermediary service, in accordance with one or more embodiments of the subject technology. FIG. 6 illustrates a flow diagram of an exemplary process for issuing a certificate, in accordance with one or more embodiments of the subject technology. FIG. 7 illustrates an example computing environment in which aspects of the disclosed system may be used, in accordance with one or more embodiments of the subject technology. FIG. 8 illustrates an example electronic system in which aspects of the disclosed system may be used, in accordance with one or more embodiments of the subject technology. DETAILED DESCRIPTION The description set forth below describes various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology may be practiced. The appended drawings are incorporated herein and constitute a part of the description. The description includes specific details for the purpose of providing an understanding of the subject technology. However, the subject technology is not limited to the specific details set forth herein and may be practiced using one or more other embodiments of the subject technology. In one or more embodiments of the subject technology, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology. In light of the problems described above, users want to be able to use third party CAs for maintaining their public key infrastructure for use with their directory service because third party CAs may allow for reduced complexity (e.g., during setup), improved security (e.g., dedicated hardware-based security), and outsourced infrastructure maintenance (e.g., maintained by a cloud service provider). Aspects of the subject technology offer approaches to addressing the challenges in compatibility between certain private CAs and directory services (e.g., managed and/or on-premises directory service environments). To improve security and customer experience, the connector (also referred to as an “intermediary service”) may be a managed, drop-in certificate services replacement for directory services where the private CA can act as the issuance layer for certificates. To accomplish this, the connector may be compatible with specifications such as X.509 and other certificate enrollment protocols (e.g., MS-XCEP and MS-WSTEP). By running a private CA with the connector described herein, users may forgo specialized hardware or staff, reducing costs while improving security. FIG. 1 illustrates a diagram of an example private CA system 100, in accordance with one or more embodiments of the subject technology. Aspects of the system 100 may be discussed in further detail with respect to FIGS. 2-8. Not all depicted components may be used in all embodiments, however, and one or more embodiments may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from