자체 인증서를 사용합니다. 개발자가 인증서를 가져오고 갱신해야 합니다. 제한사항의 설명처럼 경우에 따라 자체 인증서를 사용해야 합니다.
또한 관리형 인증서를 사용할 경우 커스텀 도메인을 매핑해야 관리형 인증서 기능을 사용할 수 있습니다.
HTTPS 및 HTTP 사용
기본적으로 관리형 인증서, 클러스터 또는 Knative serving 서비스를 관리형 인증서와 함께 사용하면 HTTP 트래픽과 HTTPS 트래픽에 모두 노출됩니다.
HTTPS 트래픽만 원할 경우 HTTPS 리디렉션을 사용 설정하여 모든 트래픽에서 HTTPS만 사용하도록 강제하면 됩니다.
문제 해결
관리형 TLS 인증서를 사용할 때 문제가 발생하면 관리형 TLS 문제 해결 페이지를 참조하세요.
제한사항
다음은 관리형 TLS 인증서 기능을 사용할 때 고려해야 하는 사항입니다.
Google Cloud의 Knative serving 비공개 클러스터에서는 관리형 TLS 인증서가 중지되어 있고 지원되지 않습니다.
관리형 인증서 기능을 사용하려면 서비스가 외부에 노출되어야 합니다. 가상 프라이빗 클라우드를 통해 노출된 서비스나 클러스터 로컬 서비스에는 사용할 수 없습니다.
관리형 인증서 기능은 Cloud Service Mesh에서만 작동합니다. Istio 부가기능 또는 기타 Istio 구성은 지원되지 않습니다.
온프렘 또는 AWS와 같은 다른 플랫폼에서 Knative serving 클러스터를 실행하면 이 기능이 중지됩니다. 이 기능을 사용하려면 클러스터가 Let's Encrypt에 액세스할 수 있고 Cloud Service Mesh 인그레스 서비스가 공개 인터넷에 노출되어 있는지 확인해야 합니다.
Kcert를 준비하는 데 20초에서 2분 정도 걸릴 수 있습니다. 문제가 발생하면 이 기능에 대한 문제 해결 안내를 참조하세요.
성공 여부 확인
다음 명령어를 실행하여 DNS 레코드가 적용되었는지 확인합니다.
gcloudrundomain-mappingsdescribe--domainDOMAIN
DOMAIN을 이미 소유한 도메인 이름(예: your-domain.com)으로 바꿉니다.
위 명령어의 반환에서 url: 필드를 확인합니다. URL에는 http가 아닌 https가 있어야 합니다.
resourceRecords:rrdata에 나열된 위 명령어에서 IP 주소를 확인하고 명령어 host DOMAIN을 실행할 때 표시되는 값과 비교합니다. 이 두 값은 동일해야 합니다.
Knative serving을 위한 HTTPS 리디렉션 사용 설정
관리형 TLS 인증서 기능을 사용하면 기본적으로 이전 버전과의 호환성 목적으로 클러스터가 HTTP 트래픽과 HTTPS 트래픽에 모두 노출됩니다. 모든 트래픽이 HTTPS만 사용하도록 강제하려면 다음 명령어를 호출하여 기존 도메인 매핑에 HTTPS 리디렉션을 사용 설정하면 됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-31(UTC)"],[],[],null,["# Using managed TLS certificates and HTTPS\n\nThis page shows how to turn off and re-enable the managed TLS certificates feature that automatically provides and renews TLS certificates to support HTTPS connections on Knative serving.\n\n\u003cbr /\u003e\n\nIf you want to use HTTPS,\n\n- Your container should continue listening on `$PORT`\n- You must choose how you are supplying TLS certificates:\n\n - Use managed TLS certificates, where TLS certificates are automatically created as needed, and are automatically renewed. This page describes this feature, which is available in the [supported Google Kubernetes Engine versions](/kubernetes-engine/enterprise/knative-serving/docs/cluster-versions).\n - [Use your own certificates](/kubernetes-engine/enterprise/knative-serving/docs/bring-your-own-cert), where you are responsible for obtaining and renewing certificates. In some situations, described under [Limitations](#limitations), you must use your own certificates.\n- If you are using managed certificates, you must also\n [map your custom domain](/kubernetes-engine/enterprise/knative-serving/docs/mapping-custom-domains) in order to use the\n managed certificates feature.\n\nUsing HTTPS and HTTP\n--------------------\n\nBy default, if you use managed certificates, clusters or Knative serving\nservices with managed certificates are exposed to both HTTP and HTTPS traffic.\nIf you want only HTTPS traffic, you can [enable HTTPS redirects](#redirects) to\nforce all traffic to use HTTPS only.\n\nTroubleshooting\n---------------\n\nIf you experience issues when using managed TLS certificates, refer to the\n[managed TLS troubleshooting](/kubernetes-engine/enterprise/knative-serving/docs/troubleshooting#managed-tls) page.\n\nLimitations\n-----------\n\nThe following considerations apply to the use of the managed TLS certificates\nfeature:\n\n- Managed TLS certificates are disabled and not supported for Knative serving private clusters on Google Cloud.\n- To use the managed certificates feature, your service must be [exposed externally](/kubernetes-engine/enterprise/knative-serving/docs/managing/services#connectivity): it cannot be a cluster-local service or a service exposed by [Virtual Private Cloud](/vpc).\n- The managed certificates feature works only with Cloud Service Mesh. The Istio addon or other Istio configurations are not supported.\n- This feature uses [Let's Encrypt](https://letsencrypt.org/), which has an initial quota limit of 50 TLS certificates per week per registered domain. You can ask for a quota increase by following the [Let's Encrypt documentation](https://letsencrypt.org/docs/rate-limits/).\n- When running a Knative serving cluster on other platforms, such as on-prem or AWS, this feature is disabled. To use this feature, you must make sure your cluster is able to access [Let's Encrypt](https://acme-v02.api.letsencrypt.org/directory), and your Cloud Service Mesh ingress service is exposed to the public internet.\n\nBefore you begin\n----------------\n\nThe instructions on this page assume the following:\n\n- You have [deployed your Knative serving service](/kubernetes-engine/enterprise/knative-serving/docs/deploying) to the cluster.\n- You own a domain. If you don't have a domain, you can obtain one from [Google](https://domains.google/) or from another domain vendor.\n- You created a domain mapping for your service and updated your DNS record accordingly following the instructions at the [domains mapping page](/kubernetes-engine/enterprise/knative-serving/docs/mapping-custom-domains).\n- Use [Cloud DNS](/dns/docs/set-up-dns-records-domain-name), or a DNS server of your choice.\n\n| **Note:** By default, `gke-system-gateway` supports HTTP requests that have the Host header. However, if you have customized this gateway, make sure it still accepts the HTTP requests that contain the Host header.\n\nDisabling managed TLS certificates and HTTPS for a whole cluster\n----------------------------------------------------------------\n\nDisable managed TLS for a cluster by updating the ConfigMap\n`config-domainmapping`:\n\n\u003cbr /\u003e\n\n```bash\nkubectl patch cm config-domainmapping -n knative-serving -p '{\"data\":{\"autoTLS\":\"Disabled\"}}'\n```\n\n\u003cbr /\u003e\n\nDisabling managed TLS and HTTPS for a specific domain mapping\n-------------------------------------------------------------\n\nIf needed, you can turn off managed TLS for a specific domain mapping:\n\n1. Add the annotation `domains.cloudrun.com/disableAutoTLS: \"true\"`\\`:\n\n ```bash\n kubectl annotate domainmappings DOMAIN domains.cloudrun.com/disableAutoTLS=true\n ```\n2. Verify that HTTPS does not work:\n\n ```bash\n curl https://DOMAIN\n ```\n\n \u003cbr /\u003e\n\n3. Verify that HTTP is being used for the service:\n\n ```bash\n gcloud run domain-mappings describe --domain DOMAIN\n ```\n\n Replace \u003cvar translate=\"no\"\u003eDOMAIN\u003c/var\u003e with your own domain name, for example:\n `your-domain.com`\n\n Check the `url:` field in the return from the above command: the URL should\n have `http`, not `https`.\n\nRe-enabling managed TLS certificates and HTTPS\n----------------------------------------------\n\nTo re-enable managed TLS:\n\n1. If you haven't already done so, create a domain mapping for your service and\n update your DNS record accordingly following the instructions at the\n [domains mapping page](/kubernetes-engine/enterprise/knative-serving/docs/mapping-custom-domains).\n\n2. Turn on managed TLS certificates and HTTPS by updating the ConfigMap\n `config-domainmapping`:\n\n ```bash\n kubectl patch cm config-domainmapping -n knative-serving -p '{\"data\":{\"autoTLS\":\"Enabled\"}}'\n ```\n3. Wait for a few minutes after the command succeeds, then make sure the\n certificates feature is working:\n\n ```bash\n kubectl get kcert\n ```\n\n If the certificate is ready, you should see a message similar to this one: \n\n ```bash\n NAME READY REASON\n your-domain.com True\n ```\n\n It may take from 20 seconds to 2 minutes for the `Kcert` to become ready. If\n you experience any issues, see the\n [troubleshooting instructions](/kubernetes-engine/enterprise/knative-serving/docs/troubleshooting) for this\n feature.\n\n### Verifying success\n\n1. Verify that the DNS record has gone into effect by running the command:\n\n ```bash\n gcloud run domain-mappings describe --domain DOMAIN\n ```\n\n Replace \u003cvar translate=\"no\"\u003eDOMAIN\u003c/var\u003e with your own domain name, for example:\n `your-domain.com`\n2. Check the `url:` field in the return from the above command: the URL should\n have `https`, not `http`.\n\n3. Check the IP address from the above command, listed under\n `resourceRecords:rrdata`, and compare it to the value you see when you execute\n the command `host `\u003cvar translate=\"no\"\u003eDOMAIN\u003c/var\u003e. They should be the same.\n\nEnabling HTTPS redirects for Knative serving\n--------------------------------------------\n\n| **Important:** HTTPS redirect is available for cluster version `1.17.7-gke.8` and later.\n\nIf you use the managed TLS certificates feature, by default the cluster is\nexposed to both HTTP and HTTPS traffic for backwards compatibility reasons. If\nyou want to force all traffic to use HTTPS only, you can enable HTTPS redirects\nfor [an existing domain mapping](/kubernetes-engine/enterprise/knative-serving/docs/mapping-custom-domains) by invoking\nthe command \n\n kubectl annotate domainmappings \u003cvar translate=\"no\"\u003eDOMAIN\u003c/var\u003e domains.cloudrun.com/httpsRedirect=Enabled\n\nwhere \u003cvar translate=\"no\"\u003eDOMAIN\u003c/var\u003e is the name of the domain mapping.\n\nRelated topics\n--------------\n\n- [Troubleshooting managed TLS](/kubernetes-engine/enterprise/knative-serving/docs/troubleshooting#managed-tls) for details on checking domain mappings, certificate quotas, order status and order timeouts, and authorization failures.\n- [Bring your own TLS certificates](/kubernetes-engine/enterprise/knative-serving/docs/bring-your-own-cert) for instructions on using your own TLS certificates instead of the managed TLS certificates."]]
