Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The 45-day transition concerns Google-managed public certificates issued by Google Public CA. It is gradual; the announcement does not say every certificate changed on October 14.
- Existing 90-day certificates retain their 90-day validity until their next renewal. Do not calculate a new 45-day expiry from the announcement date.
- Certificates with EDGE_CACHE scope have 30-day validity, while certificates issued by Let's Encrypt retain 90-day validity. Neither should be treated as 45-day certificates.
- Certificate Manager continues automatic issuance and renewal without manual configuration changes for this transition. You also cannot change the default validity of publicly trusted Google-managed certificates.
What the announcement changes
Google's October 14 release notes describe a Certificate Manager change: Google-managed public SSL certificates issued by Google Public CA are gradually moving from 90-day to 45-day validity. Google says more frequent certificate rotation improves the security of load balancers.
For cloud-platform, SRE and domain teams, the immediate answer is to keep the existing automatic management process. Google explicitly says this transition requires no manual intervention or configuration changes because Certificate Manager handles issuance and renewal. Whether a particular certificate has already received 45-day validity depends on its actual certificate record, rather than the announcement date alone.
Check the issuer and certificate scope first
Certificate Manager supports Google Public CA and Let's Encrypt CA, with Public CA issuing Google-managed certificates by default.
The documentation also describes a fallback to Let's Encrypt when Public CA cannot issue for a domain, for example when the domain's CAA record explicitly prohibits Public CA. A Google-managed label alone therefore does not establish the certificate's validity period; the issuer matters too.
For scopes other than EDGE_CACHE, public Google-managed certificates have default validity of 45 or 90 days depending on the issuing CA. Public CA certificates are gradually transitioning from 90 to 45 days, while Let's Encrypt certificates retain 90-day validity. EDGE_CACHE is a separate 30-day exception, so the 45-day assumption does not apply to that scope.
These durations describe different certificate categories. They do not provide a setting that lets users freely choose 30, 45 or 90 days. Google explicitly states that the default validity period of publicly trusted Google-managed certificates cannot be changed.
Existing 90-day certificates do not restart their clock
The core-components documentation preserves the existing-certificate rule: existing 90-day certificates remain valid for 90 days until their next renewal. The announcement neither cuts their validity short nor assigns every project the same transition instant. A certificate's validity period is also distinct from the service's exact renewal timing.
Consider a hypothetical Google-managed public certificate issued by Public CA with 90-day validity, outside EDGE_CACHE scope. After the October 14 announcement, its owner should keep the current certificate's actual validity record instead of replacing its expiry with 45 days after the announcement.
After renewal, check the replacement certificate's record to confirm the result. A gradual transition does not establish that every project must switch during the same renewal cycle.
Use the documented categories for read-only checks
The useful check is to match each certificate's type, issuer, scope and actual validity. This transition does not call for forcing a replacement; start by classifying the existing certificate records using Google's documentation.
Identify whether the certificate is Google-managed or self-managed, and distinguish public certificates from private certificates obtained through CA Service.
For a Google-managed public certificate, check whether its actual issuer is Public CA or Let's Encrypt and whether it has EDGE_CACHE scope.
Record the current certificate's actual validity. Keep the separate rules for existing 90-day certificates, 90-day Let's Encrypt certificates and 30-day EDGE_CACHE certificates.
Keep the existing automatic issuance and renewal configuration. When a renewed certificate becomes available, update the record from its actual validity instead of prepopulating an unconfirmed 45-day result.
Keep self-managed and private certificates in their own workflows
With self-managed certificates, users obtain certificates from external CAs, provision them and handle renewal themselves. Google's documentation says these certificates must be issued and renewed manually. The automatic-management wording in this announcement does not transfer responsibility for an external certificate's renewal to Certificate Manager.
Google-managed private certificates come from CA Service, a different scope from this Public CA transition. The core-components documentation describes certificate issuance configurations that can specify issuance and expiration parameters for that private CA path. Those controls do not establish that publicly trusted Google-managed certificates can be configured to retain 90-day validity. Distinguish public from private certificates before applying either management rule.
Sources
Frequently Asked Questions
Does 45-day validity mean renewal always happens on day 45?
No such schedule follows from the announcement. Validity describes the certificate's valid period, while Certificate Manager manages renewal automatically. These two sources do not specify a fixed renewal day or advance-renewal interval for every certificate.
Do I need to generate a new private key for each automatic renewal?
This transition does not require manual key generation. The core-components documentation says Certificate Manager uses a freshly generated private key when a Google-managed certificate is issued or renewed. Keys and renewal for self-managed certificates remain part of the user's own workflow.
Must I move from DNS authorization to load balancer authorization?
The announcement does not require that migration and explicitly says the transition needs no configuration changes. The documentation describes both DNS authorization and load balancer authorization. Shorter validity alone is not a reason to replace the existing authorization method.
Does this establish that every country or project has completed the transition?
No. The sources describe a gradual transition without a completion list by country or project or a universal completion time. Use the actual certificate record to establish the situation for a particular certificate.
Will more frequent renewal introduce new charges?
The release note does not announce a pricing change or explain how charges might change with this validity adjustment. More frequent renewal alone proves neither an additional charge nor free service. Confirm applicable costs against official pricing and contract terms.