Status Update
No update yet.
Comments
jj...@gmail.com
Could you share you cloudflare config ? Disabled always use HTTPS ? Created WAF rule to allow certificate renewal ?
za...@getdocent.com
error showed for the --no-default-url but worked for the ones with
--default-url were:
- The Development mode was turned on, which temporarily bypasses
Cloudfare's cache
- In the SSL/TLS section:
- *Total TLS was kept ON* with "Google Trusted Services" as the selected
Certificate Authority.
- *Always Use HTTPS was turned OFF* (because this was causing issues
months ago, and the logs show that the requests to generate certs were
being done through regular HTTP call (which I don't agree with - but you
can look online at how some users got some of the certs problems resolved
by turning this feature off)
- HTTP Strict Transport Security (HSTS) was not changed and it is set to:
- Enforce web security policy for your website.
Status: On
Max-Age: 5 months
Include subdomains: On
Preload: On
- *The minimum TLS version was downgraded to TLS 1.0 (default)*
- *Opportunistic Encryption was turned off*
- *TLS 1.3 was turned off*
- *Automatic HTTPS Rewrites was turned off*
- *Encrypted Client Hello was turned off*
I don't have WAF rules to allow certificate renewal, and I don't even know
that would be configured, as I assume Google should provide the config
setting to set the WAF with Cloudflare.
The issue is that if I deploy two cloud-run endpoints, one with
the—-no-default-url flag and the other with the—- URL flag, and I generate
a domain mapping at the same time, the one with the—-no-default-flag is the
only one that fails, and I get the "internal error" on Google's side, not
mine.
There are two issues. The first is the cloud run flag preventing SSL certs
from being generated, and the second is the certs not regenerating after
they expire. They have an expiration of three months.
On Sun, Oct 27, 2024 at 5:36 PM <buganizer-system@google.com> wrote:
--
*-*
------------------------------
This email and any files transmitted with it may contain confidential
information and is intended only for the individual or entity to whom they
are addressed. If you are not the intended recipient you are notified that
disclosing, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. If you have received
this transmission in error, please notify the sender and delete this email
from your computer. Email transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.
------------------------------
Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521.
------------------------------
va...@google.com
ku...@google.com
Hello,
Thank you for reaching out to us with your request.
We have duly noted your feedback and will thoroughly validate it. While we cannot provide an estimated time of implementation or guarantee the fulfillment of the issue, please be assured that your input is highly valued. Your feedback enables us to enhance our products and services.
We appreciate your continued trust and support in improving our Google Cloud Platform products. In case you want to report a new issue, please do not hesitate to create a new issue on the
Once again, we sincerely appreciate your valuable feedback; Thank you for your understanding and collaboration.
Description
This issue is different from the previous one that was fixed in:
That past issue happened on already deployed working endpoints, where the domain mapping was breaking when the flag was switched from --no-default-url to --default-url or vice versa.
This error that we are getting now is different. It only happens if there is a cloud-run endpoint that was already deployed with the flag of "--no-default-url," and then we try to do a domain mapping. It is unable to generate the certs, which results in the error. The picture shows successful cloud-run endpoint mappings because they were deployed with the --default-URL flag. The only one deployed with a flag of --no--default-url is the one with the error.
Our only fix at this point is to:
- re-deploy all of our services with the flag --default-url thus exposing this URL publicly (which is what we wanted to avoid from
- generate the cloud-run URL mappings to allow the generation of SSL certs
- Then we would have to re-deploy all of our services again, with the flag --no-default-url, to turn off the public URL
The process would then have to be repeated in 3 months because Google SSL certs are set to last only 3 months, and there doesn't seem to be a mechanism to auto-generate SSL certs, at least between Google and Cloudfare, which is what we are using in the meantime to proxy.