[[["์ดํดํ๊ธฐ ์ฌ์","easyToUnderstand","thumb-up"],["๋ฌธ์ ๊ฐ ํด๊ฒฐ๋จ","solvedMyProblem","thumb-up"],["๊ธฐํ","otherUp","thumb-up"]],[["์ดํดํ๊ธฐ ์ด๋ ค์","hardToUnderstand","thumb-down"],["์๋ชป๋ ์ ๋ณด ๋๋ ์ํ ์ฝ๋","incorrectInformationOrSampleCode","thumb-down"],["ํ์ํ ์ ๋ณด/์ํ์ด ์์","missingTheInformationSamplesINeed","thumb-down"],["๋ฒ์ญ ๋ฌธ์ ","translationIssue","thumb-down"],["๊ธฐํ","otherDown","thumb-down"]],["์ต์ข ์ ๋ฐ์ดํธ: 2024-12-21(UTC)"],[[["\u003cp\u003ePublic CA allows users to request and deploy publicly trusted TLS certificates through an automated process using the ACME protocol, ensuring they are recognized by major browsers and operating systems.\u003c/p\u003e\n"],["\u003cp\u003ePublic CA is designed for high-volume use cases, offering benefits like automation, compliance, security, reliability, ubiquity, and streamlined TLS solutions for various setups including on-premises and cross-cloud environments.\u003c/p\u003e\n"],["\u003cp\u003eThe service helps minimize certificate-related issues by automating provisioning, renewal, and revocation, reducing the risk of website errors and service outages due to expired certificates.\u003c/p\u003e\n"],["\u003cp\u003eWhile Public CA offers robust support for public certificates, Google Cloud also offers solutions for private certificate needs, such as Anthos Service Mesh and Certificate Authority Service, for non-public requirements.\u003c/p\u003e\n"],["\u003cp\u003ePublic CA's security features include regular audits and multi-perspective domain validation, which helps protect against BGP and DNS hijacking attacks, further enhancing the security of the certificates it issues.\u003c/p\u003e\n"]]],[],null,["# Public CA\n\nYou can use the Public Certificate Authority CA to\nprovision and deploy widely trusted X.509 certificates after validating that the certificate requester\ncontrols the domains. Public CA lets you directly and programmatically\nrequest publicly trusted TLS certificates that are already in the root of trust stores used by\nmajor browsers, operating systems, and applications. You can use these TLS certificates to\nauthenticate and encrypt internet traffic.\n\nPublic CA lets you manage high volume use cases that traditional\nCAs have been unable to support. If you are a Google Cloud customer, you can\nrequest TLS certificates for your domains directly from Public CA.\n\nMost certificate-related problems are due to human error or oversight, so we\nrecommend automating certificate lifecycles. Public CA uses the\n[Automatic Certificate Management Environment (ACME)](https://tools.ietf.org/html/rfc8555)\nprotocol for the automated provisioning, renewal, and revocation of\ncertificates. Automated certificate management reduces downtime that expired\ncertificates can cause and minimizes operational costs.\n\nPublic CA provisions TLS certificates for several Google Cloud\nservices, such as [App Engine](/appengine/docs), [Cloud Shell](/shell/docs),\n[Google Kubernetes Engine](/kubernetes-engine/docs) and [Cloud Load Balancing](/load-balancing/docs).\n\nWho should use Public CA\n------------------------\n\nYou can use Public CA for the following reasons:\n\n- If you are looking for a TLS provider with high ubiquity, scalability, security, and reliability.\n- If you want most, if not all, TLS certificates for your infrastructure, including on-premises workloads and cross-cloud provider setups, from a single cloud provider.\n- If you need control and flexibility over the TLS certificate management to customize it to your infrastructure requirements.\n- If you want to automate the TLS certificate management but cannot use managed certificates in Google Cloud services, such as [GKE](/kubernetes-engine/docs/how-to/managed-certs) or [Cloud Load Balancing](/load-balancing/docs/ssl-certificates/google-managed-certs).\n\nWe recommend that you only use publicly trusted certificates when your business requirements\ndo not allow another option. Given the historical cost and complexity of maintaining public\nkey infrastructure (PKI) hierarchies, many enterprises use public PKI\nhierarchies even when a private hierarchy makes more sense.\n\nMaintaining public and private hierarchies has become much simpler with multiple\nGoogle Cloud offerings. We recommend that you carefully choose the right type of\nPKI for your use case.\n\nFor non-public certificate requirements, Google Cloud offers two easy-to-manage\nsolutions:\n\n- **Anthos Service Mesh** : [Cloud Service Mesh](/anthos/service-mesh) includes\n fully automated mTLS certificate provisioning for workloads running in\n GKE Enterprise using [Cloud Service Mesh certificate authority (Cloud Service Mesh certificate authority)](/service-mesh/docs/overview#security_features).\n\n- **Certificate Authority Service** :\n [Certificate Authority Service](/certificate-authority-service/docs) lets you deploy,\n manage and secure custom private CAs efficiently without managing\n infrastructure.\n\nBenefits of Public CA\n---------------------\n\nPublic CA provides the following benefits:\n\n- **Automation**: As internet browsers aim for fully encrypted traffic and\n the reduction of certificate validity periods, there is a risk of using\n expired TLS certificates. Certificate expiration can lead to website errors,\n and can cause service outages. Public CA avoids the\n problem of certificate expiration by letting you set up your HTTPS server to\n automatically obtain and renew the necessary TLS certificates from our ACME\n endpoint.\n\n- **Compliance** : Public CA undergoes regular rigorous independent\n audits of security, privacy, and compliance controls. The [Webtrust\n seals](https://pki.goog/) granted as a result of these annual audits\n demonstrate Public CA's conformity with all relevant\n industry standards.\n\n- **Security** : The architecture and operations of Public CA are\n designed to the highest level of security standards and regularly runs\n independent assessments to confirm the security of the underlying\n infrastructure. Public CA either meets or exceeds all the\n controls, operational practices, and security measures mentioned in the\n [Google Security whitepaper](/security/overview/whitepaper).\n\n Public CA's focus on security extends to features such as\n multi-perspective domain validation. Public CA's infrastructure is\n globally distributed. Therefore, Public CA requires a high degree\n of agreement across geographically diverse perspectives, which provides\n protection against [Border Gateway Protocol (BGP) hijacking](https://wikipedia.org/wiki/BGP_hijacking)\n and [Domain Name Server (DNS) hijacking](https://wikipedia.org/wiki/DNS_hijacking) attacks.\n- **Reliability**: The use of Google's proven technical infrastructure makes\n Public CA a highly available and scalable service.\n\n- **Ubiquity:** The strong browser ubiquity of [Google Trust\n Services](https://pki.goog/) helps ensure that services using\n certificates that Public CA issues work on the widest possible\n range of devices and operating systems.\n\n- **Streamlined TLS solutions for hybrid setups**: Public CA lets\n you build a custom TLS certificate solution that uses the same CA for\n diverse scenarios and use cases. Public CA effectively serves\n the use cases where workloads are running on-premises or in a cross-cloud\n provider environment.\n\n- **Scale**: Certificates have often been costly to obtain and difficult to\n provision and maintain. By offering access to large volumes of certificates,\n Public CA lets you utilize and manage certificates in ways that\n were previously considered impractical.\n\nUse Public CA with Certificate Manager\n--------------------------------------\n\nTo use the public CA feature of Certificate Manager, you must be familiar\nwith the following concepts:\n\n- **ACME client** . An Automatic Certificate Management Environment (ACME) client is a certificate\n management client that uses the [ACME protocol](https://datatracker.ietf.org/doc/html/rfc8555).\n Your ACME client must support external account binding (EAB) to work with Public CA.\n\n- **External account binding (EAB)** . You must bind each ACME account you are using with Certificate Manager\n public CA to the target Google Cloud project using external account binding. To do this, you must register each\n ACME account using a secret linked to its corresponding Google Cloud project. For more information, see [External account\n binding](https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.4).\n\n### Public CA challenges\n\nWhen you use Public CA to request a certificate,\nCertificate Manager asks you to prove your control over the domains\nlisted in that certificate. You can prove domain control by solving challenges.\nPublic CA authorizes the domain names after you prove your\ncontrol of the target domains.\n\nAfter you obtain the required authorizations, you can request certificates that are valid only\nfor a specific time duration. After this duration, you must revalidate the domain name\nby solving one of the three challenge types to continue requesting certificates.\n\n#### Challenge types\n\nPublic CA supports the following types of challenges:\n\n- **HTTP challenge** . This challenge involves creating a file at a well-known\n location on an HTTP server (port 80) for Public CA to retrieve\n and verify. For more information, see [HTTP challenge](https://datatracker.ietf.org/doc/html/rfc8555#section-8.3).\n\n- **TLS-Application Layer Protocol Negotiation (ALPN) challenge** . Requires a\n server to provide a specific certificate during a TLS negotiation on port 443\n to prove control over a domain. For more information, see\n [ACME TLS-ALPN challenge extension](https://datatracker.ietf.org/doc/html/rfc8737).\n\n- **DNS challenge** . Requires adding a specific DNS record at\n a defined location to prove control over a domain.\n For more information, see [DNS challenge](https://datatracker.ietf.org/doc/html/rfc8555#section-8.4).\n\nIf you use the HTTP challenge or the TLS-ALPN challenge to validate a\ndomain name, the client can only request the validated domain\nnames to be included in a certificate. If you use the DNS challenge, the\nclient can also request subdomains of that domain name to be included in a\ncertificate.\n\nFor example, if you validate `*.myorg.example.com` using the DNS challenge then\n`subdomain1.myorg.example.com` and `subdomain2.myorg.example.com` are automatically covered\nby the wildcard certificate. However, if you validate `myorg.example.com` using an HTTP or\nTLS-ALPN challenge the client can only request to include `myorg.example.com` in\nthe certificate and you cannot validate `*.myorg.example.com` using the non-DNS challenges.\n\n#### Challenge solution logic\n\nThe public CA challenge logic is as follows:\n\n1. Public CA provides a random token.\n2. The client makes the token available at a well-defined location. The location depends on the challenge.\n3. The client indicates to Public CA that it has prepared the challenge.\n4. Public CA checks if the token present at the expected location matches the expected value.\n\nThe domain name is authorized after this process is completed. The client can\nrequest a certificate with that domain name in it. You need to solve only one\nchallenge per domain name.\n\nWhat's next\n-----------\n\n- [Request a certificate using Public CA (tutorial)](/certificate-manager/docs/public-ca-tutorial)"]]
