Fixed
Status Update
No update yet.
Comments
pv...@google.com
Hi,
Since this is still in private beta, there is not much on our side to be done now. I will forward this to the appropriate team beginning of December, when we can have more visibility into the tool :).
For future reference, I would suggest waiting until we can get access to the tool before asking for integration with it, as it makes our work easier :).
In the meantime, thank you anyway for your suggestion!
Cheers!
Since this is still in private beta, there is not much on our side to be done now. I will forward this to the appropriate team beginning of December, when we can have more visibility into the tool :).
For future reference, I would suggest waiting until we can get access to the tool before asking for integration with it, as it makes our work easier :).
In the meantime, thank you anyway for your suggestion!
Cheers!
mm...@mikecb.org
Sorry for jumping the gun! I didn't expect such a prompt acknowledgement. The spec is pretty firm, and there is an official client, as well as several third party implementations available on github. Thanks for taking the suggestion!
re...@gmail.com
I just used Let's Encrypt to create a certificate for my domain.
http://blog.seafuj.com/lets-encrypt-on-google-app-engine
The way I see it working is:
1. User adds a letsencrypt builtin to app.yaml that can respond to challenges during the verification process.
2. User checks a box to enable Let's Encrypt.
3. App Engine runs the letsencrypt command.
4. App Engine converts the private key into RSA format.
5. App Engine applies the certificate.
6. App Engine renews certificates automatically.
The way I see it working is:
1. User adds a letsencrypt builtin to app.yaml that can respond to challenges during the verification process.
2. User checks a box to enable Let's Encrypt.
3. App Engine runs the letsencrypt command.
4. App Engine converts the private key into RSA format.
5. App Engine applies the certificate.
6. App Engine renews certificates automatically.
an...@schuldei.org
mm...@mikecb.org
pv...@google.com
Hi!
Thanks for the reminder :). I had a reminder setup for early next week, but I can definitely go faster and start on this right away ;).
As soon as I have more information I'll reply on this thread.
Cheers!
Thanks for the reminder :). I had a reminder setup for early next week, but I can definitely go faster and start on this right away ;).
As soon as I have more information I'll reply on this thread.
Cheers!
pv...@google.com
Hey guys!
I have forwarded this request to engineering. Both updates about this feature and the final resolution will be posted here in time.
Cheers!
I have forwarded this request to engineering. Both updates about this feature and the final resolution will be posted here in time.
Cheers!
si...@gmail.com
It would be totally awesome if Google App Engine implemented something like renegadebum's suggestion in #3. Thanks for considering!
th...@thomassmith.info
Instead of implementing Let's Encrypt directly in App Engine, wouldn't it be more universal to allow adding or updating App Engine SSL certificates via 'gcloud'?
This could allow rolling a certificate addition or update into an automated deployment process. It could also allow non-Let's Encrypted certificates to be updated in an automated fashion (e.g. by adding the certificate to the app and then deploying it, or by running a separate command to just deploy the new or updated certificate).
This could allow rolling a certificate addition or update into an automated deployment process. It could also allow non-Let's Encrypted certificates to be updated in an automated fashion (e.g. by adding the certificate to the app and then deploying it, or by running a separate command to just deploy the new or updated certificate).
[Deleted User] <[Deleted User]>
Not sure about integration into gcloud as proposed in #10 but general SSL certificate management capabilities via API (as proposed by Issue #12615) would open up the possibility to handle whatever certificate authorities throw at us.
si...@gmail.com
I think direct support for Let's Encrypt would be better. It looks like it's going to be the future of low-end certificate provision, so I think it should be easy so we can encourage people to use it, in keeping with Google's policy of promoting HTTPS everywhere.
[Deleted User] <[Deleted User]>
I believe a SSL config API should be made available. If we are to use Letsencrypt there should be a plugin that we can run on build. This way it would accommodate multiple use-cases not only letsencrypt/ACME protocol.
Otherwise Google could provide SSL on all the custom domains by default using its own root certificate and infrastructure ala Amazon AWS Certificate Manager. After all GAE is a sandboxed environment so basically the whole infrastructure is managed/"insured" by Google.
Otherwise Google could provide SSL on all the custom domains by default using its own root certificate and infrastructure ala Amazon AWS Certificate Manager. After all GAE is a sandboxed environment so basically the whole infrastructure is managed/"insured" by Google.
al...@gmail.com
Dreamhost already included automatic support that works really well.
It would be great to have it here as well.
It would be great to have it here as well.
br...@gmail.com
fu...@gmail.com
Anything to reduce the barrier to use SSL with a custom domain would be appreciated. Don't know how anything automated would work with a java based app engine, I would think some package would need to be installed so all the servlets would exist.
mv...@gmail.com
[Comment deleted]
mv...@gmail.com
LetsEncrypt is out of beta today. Can you please now consider integrating?
Note that AWS now provides a Certificate Manager that allows certificates to be issued and used inside their services such as ElasticBeanstalk and CloudFront.
Note that AWS now provides a Certificate Manager that allows certificates to be issued and used inside their services such as ElasticBeanstalk and CloudFront.
si...@gmail.com
Am currently moving a few static sites to App Engine and trying to set up SSL with Lets Encrypt. Would be great to have automatic certificate renewal every 60 to 90 days without user intervention as requested in this Issue.
ro...@gmail.com
lets encrypt for app engine would be awesome!
ar...@gmail.com
would be great
[Deleted User] <[Deleted User]>
publishing the API for managing SSL certificates would be sufficient
[Deleted User] <[Deleted User]>
It would be nice though if Google would provide the SSL automatically as it does on appspot domains. That way we won't get the LetsEncrypt limitations(lack of wildcard) or have to deal with google proprietary APIs. I've created a separate issue for that https://code.google.com/p/googleappengine/issues/detail?id=13018 .
pa...@gmail.com
How hard would it be for google to provide it themselves and charge for it ? why even third party solution ?
[Deleted User] <[Deleted User]>
On Amazon you get it for free
ja...@catalyz.nl
On Firebase (which is now Google) you also get it for free.
be...@gmail.com
No progress so far? Still watching this space.
an...@gmail.com
We've created a tool to automate the process for Python AppEngine apps:
https://github.com/AirConsole/letsencrypt
[Deleted User] <[Deleted User]>
that's not automated since user has to manually update certificates in app engine console. API for SSL management would allow the creation of fully automatic solution
dl...@gmail.com
#28: Nice script! Not fully automated, though, because the very last step, "Upload the obtained certificates on ..." is still manual. This issue is about automating it as well (or even avoiding it altogether, so we don't need to have access to cert private keys).
Also, running shell commands (`openssl` in your script) and write-access to files is unavailable in GAE Standard Environment. So some other approach is needed to convert private key to unencrypted RSA.
Also, running shell commands (`openssl` in your script) and write-access to files is unavailable in GAE Standard Environment. So some other approach is needed to convert private key to unencrypted RSA.
an...@gmail.com
#30: correct it's not fully automated, but as far as it is possible today. It works on GAE, the openssl commands are executed on your local machine. It's a hybrid script that your local machine loads...
[Deleted User] <[Deleted User]>
What's good for if it can't be automated? Uploading the certs manually every month is not really feasible.
ml...@gmail.com
Well, I'm going to break the trend and say Thank You Andrin! You've gone as far as you can with AppEngine limitations on SSL cert management (hopefully they can add an API!), and packaged it all up quite nicely!
Sadly, I think you're going to get some hate because you used the word "automate" and end up dashing people's hopes, and some folks will end up ungrateful as a result. :(
(And personally, I'm on Appengine Flexible Runtimes, so even including openssl and running the command directly on the GAE server would work for me...if only there was a way to push the cert to the GAE admin console.)
Sadly, I think you're going to get some hate because you used the word "automate" and end up dashing people's hopes, and some folks will end up ungrateful as a result. :(
(And personally, I'm on Appengine Flexible Runtimes, so even including openssl and running the command directly on the GAE server would work for me...if only there was a way to push the cert to the GAE admin console.)
be...@gmail.com
#28: Thanks!
Wouldn't it be possible to automate the web upload part too, by mimicking what some people did with Apple Developer Center:https://spaceship.airforce
I would normally bounce a few files back and forth to the Apple dev site using my browser but they were able to automate that part and it was a huge time saver.
Wouldn't it be possible to automate the web upload part too, by mimicking what some people did with Apple Developer Center:
I would normally bounce a few files back and forth to the Apple dev site using my browser but they were able to automate that part and it was a huge time saver.
dg...@gmail.com
I believe is not possible to add a python sub-module to a php AppEngine project right?
Thanks, anyway for the code.
Thanks, anyway for the code.
ar...@gmail.com
Thank you. Will full Java automation be addressed?
[Deleted User] <[Deleted User]>
#36 java (and python) certificate request&renew can already be automated with lego by using dns based challenge: https://github.com/xenolf/lego . no need for extra code.
[Deleted User] <[Deleted User]>
#37 Isn't lego (https://github.com/xenolf/lego ) a Go client? I'm sorry, but how can Java call a Go client or library?
de...@derekperkins.com
It just compiles into a binary so it's language agnostic.
ra...@gmail.com
Basic App Engine can't just install binaries and run them...so something like lego would have to be set up and run somewhere else. But more to the point, any helper tool like this still can't automatically upload the certificates it generates because there's no API for that on Google's end.
mi...@kristovar.com
could a chrome extension be built as a helper tool to upload the certificates and private keys via the google cloud web interface? maybe a selenium script?
i can already run a local shell script that generates the certificate, submits it to let's encrypt, receives the challenge response, updates an app file with the correct challenge/response, deploy the updated app, single the let's encrypt process to continue, recieve the signed certificate, use openssl to convert the signed certificate and private key to something google can digest... from here it's manual and i just copy and paste into web interface. i've been thinking about passing it to something that can automate a browser session... but that seems dirty... way better if google supported this native, and they already get private keys, so no new liabilities.
google would be in charge of the /.well-known/acme-challenge/ handlers, so it would make sense if that was defined in the app.yaml file. maybe like this:
application: blah
version: 1
runtime: php55
api_version: 1
threadsafe: yes
acme_challenge: yes
...or
lets_encrypt: yes
that directive automatically creates a new handler for /.well-known/acme-challenge/* that routes to the global google service for echoing responses to let's encrypt that were generated by the shell script.
at that point it is just google storing that simple shell script and running it for every enabled project every few days... this isn't that hard. figure out the average compute engine time the script costs per run, and tack that onto the bill if you turn on the service. i'm sure it's less than $0.01.
so... what is the problem? seems like a slam dunk for both companies.
i can already run a local shell script that generates the certificate, submits it to let's encrypt, receives the challenge response, updates an app file with the correct challenge/response, deploy the updated app, single the let's encrypt process to continue, recieve the signed certificate, use openssl to convert the signed certificate and private key to something google can digest... from here it's manual and i just copy and paste into web interface. i've been thinking about passing it to something that can automate a browser session... but that seems dirty... way better if google supported this native, and they already get private keys, so no new liabilities.
google would be in charge of the /.well-known/acme-challenge/ handlers, so it would make sense if that was defined in the app.yaml file. maybe like this:
application: blah
version: 1
runtime: php55
api_version: 1
threadsafe: yes
acme_challenge: yes
...or
lets_encrypt: yes
that directive automatically creates a new handler for /.well-known/acme-challenge/* that routes to the global google service for echoing responses to let's encrypt that were generated by the shell script.
at that point it is just google storing that simple shell script and running it for every enabled project every few days... this isn't that hard. figure out the average compute engine time the script costs per run, and tack that onto the bill if you turn on the service. i'm sure it's less than $0.01.
so... what is the problem? seems like a slam dunk for both companies.
eg...@gmail.com
Any chance of putting that script somewhere others can get it? Sounds handy! :)
ar...@artooro.com
Hey guys, you are making it too complicated. Let's Encrypt also supports DNS challenges. I've written a script for letsencrypt.sh (https://github.com/lukas2511/letsencrypt.sh ) see the attached hook.sh script adds the challenge DNS record, and then deletes it when finished.
This way you don't have to modify your application on app engine or deploy updated code.
Of course we are still waiting for an API or gcloud command to update the certificate for the app engine app. I don't know what's taking so long as it already exists for the load balancer. Can't be that hard for the google team to make it available for app engine as well.
This way you don't have to modify your application on app engine or deploy updated code.
Of course we are still waiting for an API or gcloud command to update the certificate for the app engine app. I don't know what's taking so long as it already exists for the load balancer. Can't be that hard for the google team to make it available for app engine as well.
ml...@gmail.com
Thx to #28 Andrin...@gmail.com for https://github.com/AirConsole/letsencrypt
Code works very well, and simplifies a LOT the deployment of renewed certificates. Thx again!
:)
Code works very well, and simplifies a LOT the deployment of renewed certificates. Thx again!
:)
mi...@kristovar.com
RE: #42... sorry, but my script is for a custom framework and probably wouldn't be useful to anyone else... but the basic process can be done in Google Cloud Shell (link right next to your project name in the header)
# install letsencrypt
git clonehttps://github.com/letsencrypt/letsencrypt
cd letsencrypt
# generate cert request
sudo ./letsencrypt-auto -a manual certonly
# follow challenge response instructions...
# get private key
sudo openssl rsa -inform pem -in /etc/letsencrypt/live/www.example.com/privkey.pem -outform pem | less
# get public cert
sudo less /etc/letsencrypt/live/www.example.com/fullchain.pem
RE: #43, i don't see how DNS challenges are less complicated than web based acme-challenges... especially considering the end goal of having google automate everything. as it stands, google doesn't have access to alter my DNS records... i'd like to keep it that way. i'd also rather not have DNS admin credentials in automated scripts anywhere. take over my website, whatever... i can fix it. steal my domain and i'm really screwed.
either way, the API to update certificates is really the only thing that is needed for a "good enough" solution.
# install letsencrypt
git clone
cd letsencrypt
# generate cert request
sudo ./letsencrypt-auto -a manual certonly
# follow challenge response instructions...
# get private key
sudo openssl rsa -inform pem -in /etc/letsencrypt/live/
# get public cert
sudo less /etc/letsencrypt/live/
RE: #43, i don't see how DNS challenges are less complicated than web based acme-challenges... especially considering the end goal of having google automate everything. as it stands, google doesn't have access to alter my DNS records... i'd like to keep it that way. i'd also rather not have DNS admin credentials in automated scripts anywhere. take over my website, whatever... i can fix it. steal my domain and i'm really screwed.
either way, the API to update certificates is really the only thing that is needed for a "good enough" solution.
mi...@kristovar.com
i'm using the PHP environment... in order to process the acme-challenge requests, i added this handler to my app.yaml:
- url: /\.well-known/acme-challenge/.*
script: acme-challenge.php
then, my renew script generates a acme-challenge.php file in the root directory, similar to this:
<?php
// request handler for /.well-known/acme-challenge/*
header('Content-Type: text/plain');
if(preg_match('@^/\.well-known/acme\-challenge/(.+)@', $_SERVER['REQUEST_URI'], $matches)) {
switch($matches[1]) {
case '[challenge1]':
echo '[response1]';
break;
case '[challenge2]':
echo '[response2]';
break;
default:
}
}
- url: /\.well-known/acme-challenge/.*
script: acme-challenge.php
then, my renew script generates a acme-challenge.php file in the root directory, similar to this:
<?php
// request handler for /.well-known/acme-challenge/*
header('Content-Type: text/plain');
if(preg_match('@^/\.well-known/acme\-challenge/(.+)@', $_SERVER['REQUEST_URI'], $matches)) {
switch($matches[1]) {
case '[challenge1]':
echo '[response1]';
break;
case '[challenge2]':
echo '[response2]';
break;
default:
}
}
de...@gmail.com
Not sure why some of you update your app each time.
I'm using Python. I enabled and configured datastore and added some classes to my code to access it, routing it with:
(r'/\.well-known/acme-challenge/([\w-]+)', LetsEncryptHandler)
Whenever I have a new challenge, I just add it to the datastore.
class LetsEncryptResponse(db.Model):
response = db.StringProperty()
class LetsEncryptHandler(webapp2.RequestHandler):
def get(self, challenge):
response = self.response
result = LetsEncryptResponse.get_by_key_name(challenge)
if result:
response.headers['Content-Type'] = 'text/plain'
response.write(result.response)
else:
response.set_status(404)
response.write("<html>\n <head>\n <title>404 Not Found</title>\n </head>\n <body>\n <h1>404 Not Found</h1>\n The resource could not be found.<br /><br />\n\n\n\n </body>\n</html>")
I'm using Python. I enabled and configured datastore and added some classes to my code to access it, routing it with:
(r'/\.well-known/acme-challenge/([\w-]+)', LetsEncryptHandler)
Whenever I have a new challenge, I just add it to the datastore.
class LetsEncryptResponse(db.Model):
response = db.StringProperty()
class LetsEncryptHandler(webapp2.RequestHandler):
def get(self, challenge):
response = self.response
result = LetsEncryptResponse.get_by_key_name(challenge)
if result:
response.headers['Content-Type'] = 'text/plain'
response.write(result.response)
else:
response.set_status(404)
response.write("<html>\n <head>\n <title>404 Not Found</title>\n </head>\n <body>\n <h1>404 Not Found</h1>\n The resource could not be found.<br /><br />\n\n\n\n </body>\n</html>")
mi...@kristovar.com
i implemented a similar solution to yours until i thought better of it. (nitpicky)
the domain control verification step is meant to demonstrate full control of the domain. having the response values in the datastore is only demonstrating control of the datastore. an exploit of your app could enable writing a specific datastore key... and they might know how your acme-challenge script works, and obtain signed certs for your domain. those maybes are massive long-shots, but i don't see any downtime with the deploys, so it seems more in line with the intent of domain control verification.
DNS verification seems like a good alternative, but i use my domain registrar's nameservers... their API for updating nameserver records can also unlock and create transfer codes for my domain, so i don't use it. i probably shouldn't use their nameservers, but i haven't had an issue in 20 years. loyal to a fault. if you're using google for DNS, there is no additional risk to your domain... but DNS propagation isn't as predictable as an app deploy, so i still prefer the acme-challenge.
the domain control verification step is meant to demonstrate full control of the domain. having the response values in the datastore is only demonstrating control of the datastore. an exploit of your app could enable writing a specific datastore key... and they might know how your acme-challenge script works, and obtain signed certs for your domain. those maybes are massive long-shots, but i don't see any downtime with the deploys, so it seems more in line with the intent of domain control verification.
DNS verification seems like a good alternative, but i use my domain registrar's nameservers... their API for updating nameserver records can also unlock and create transfer codes for my domain, so i don't use it. i probably shouldn't use their nameservers, but i haven't had an issue in 20 years. loyal to a fault. if you're using google for DNS, there is no additional risk to your domain... but DNS propagation isn't as predictable as an app deploy, so i still prefer the acme-challenge.
mi...@kristovar.com
those same nitpicks are probably why google isn't jumping on automating this.
even if google completely isolated their internal service for storing the challenge/response values, anyone who could MITM between google and let's encrypt could trick google into storing arbitrary values for any domain. another massive long-shot, but it's a massive target.
making it acceptably secure would require a partnership deal between google and let's encrypt beyond the public API... still not that hard to coordinate.
even if google completely isolated their internal service for storing the challenge/response values, anyone who could MITM between google and let's encrypt could trick google into storing arbitrary values for any domain. another massive long-shot, but it's a massive target.
making it acceptably secure would require a partnership deal between google and let's encrypt beyond the public API... still not that hard to coordinate.
an...@gmail.com
Re #49:
> anyone who could MITM between google and let's encrypt could trick google into storing arbitrary values for any domain
You can't MITM ACME requests between Google and Let's Encrypt. ACME requests are encrypted with HTTPS and signed with JWS.
> anyone who could MITM between google and let's encrypt could trick google into storing arbitrary values for any domain
You can't MITM ACME requests between Google and Let's Encrypt. ACME requests are encrypted with HTTPS and signed with JWS.
mi...@kristovar.com
> You can't MITM ACME requests between Google and Let's Encrypt. ACME requests are encrypted with HTTPS and signed with JWS.
i'm not suggesting the transfers are in plaintext... i'm also not suggesting this is possible for any would-be hacker to pull off, but HTTPS is not immune to forged certificates... networks are not immune to inside actors... JWS requires a key exchange over those channels.
you're right though, *I* can't MITM ACME requests between google and let's encrypt, but claiming it CAN'T be done is ignorant. a partnership deal with physical public keys exchanged in briefcases mitigates a lot of the risk... at least until tom cruise shows up in a mask with a voice modulator...
i'm not suggesting the transfers are in plaintext... i'm also not suggesting this is possible for any would-be hacker to pull off, but HTTPS is not immune to forged certificates... networks are not immune to inside actors... JWS requires a key exchange over those channels.
you're right though, *I* can't MITM ACME requests between google and let's encrypt, but claiming it CAN'T be done is ignorant. a partnership deal with physical public keys exchanged in briefcases mitigates a lot of the risk... at least until tom cruise shows up in a mask with a voice modulator...
an...@gmail.com
Right, but if you're assuming the attacker has broken HTTPS (through a compromised CA or some other means), it seems kinda pointless to be worried about them using that ability to obtain fake certificates from Let's Encrypt. After all, they've already broken HTTPS! It's just not a reasonable threat model.
If you require a level of security beyond what the CA system is able to provide, you shouldn't be relying on Let's Encrypt (or for that matter, any other public CA) in the first place.
If you require a level of security beyond what the CA system is able to provide, you shouldn't be relying on Let's Encrypt (or for that matter, any other public CA) in the first place.
mi...@kristovar.com
for individual domain owners, that all makes perfect sense... and as individual domain owners, we all seem to be willing to take that risk with let's encrypt... but for google to take on that risk for everyone else is a much different situation. a single nation-state actor could make a single attack on google, and the end result would be a forged certificate for every single domain owner who ticked the "enable let's encrypt" box on google cloud. it's a giant liability.
google has already pointed out that they could generate these certificates themselves using their own CA, but they don't even trust their own domain verification process enough to risk their CA's trust.
maybe let's encrypt has the same worries, and has asked google not to automate anything... but what we're left with is a less secure process for individual domain owners, but no single target to attack.
breaking HTTPS for a single cert is a very hard problem, but it doesn't imply that they've universally broken HTTPS. having the single target to attack with a single forged HTTPS cert enables them to bootstrap that single extremely costly act to compromise a large number of domains nearly instantly, leaving the only option to revoke the Let's Encrypt CA, instead of revoking a forged CA.
i think we all require a level of security beyond what the CA system is able to provide, but as it stands, there is no other choice without an unworkable end-user experience.
google has already pointed out that they could generate these certificates themselves using their own CA, but they don't even trust their own domain verification process enough to risk their CA's trust.
maybe let's encrypt has the same worries, and has asked google not to automate anything... but what we're left with is a less secure process for individual domain owners, but no single target to attack.
breaking HTTPS for a single cert is a very hard problem, but it doesn't imply that they've universally broken HTTPS. having the single target to attack with a single forged HTTPS cert enables them to bootstrap that single extremely costly act to compromise a large number of domains nearly instantly, leaving the only option to revoke the Let's Encrypt CA, instead of revoking a forged CA.
i think we all require a level of security beyond what the CA system is able to provide, but as it stands, there is no other choice without an unworkable end-user experience.
ar...@artooro.com
Nobody really wants Google to automate Let's Encrypt specifically. All we need is a gcloud command to update the app engine SSL cert, and then we can use whatever certification authority we want to whether it's LE, or even StartEncrypt is going to start using ACME soon.
mi...@kristovar.com
yes... all we really need is the cert update API to roll our own solutions... but, come on... the title of this issue is "Support automatic certificate request via Lets Encrypt"... obviously someone wants them to specifically automate Let's Encrypt.
ar...@artooro.com
The title is to "Support automatic certificate request via" and to support that functionality all we need is the certificate update API. So the intention of this issue would be satisfied.
I'll argue against Google supporting Let's Encrypt directly because #1 it will take longer to get done which means we'll have to wait longer. #2 Security, we should be in control of our own private keys #3 Flexibility, we need to be able to use any authority not just LE/ACME.
I'll argue against Google supporting Let's Encrypt directly because #1 it will take longer to get done which means we'll have to wait longer. #2 Security, we should be in control of our own private keys #3 Flexibility, we need to be able to use any authority not just LE/ACME.
mi...@kristovar.com
maybe google doesn't trust us to be as careful as we need to be with our own private keys when we start piping them off to shell commands... i can't think of any other reason they wouldn't enable this immediately. it's 2 text fields. couldn't be much simpler.
ju...@gmail.com
For go(lang), I created a github repo with the way I configure https with Appengine. I have to do it each period of 3 months but I works.
https://github.com/jlandure/go-appengine-https
PS : I think it's time to go with Firebase with its https-custom-domain support.
PS : I think it's time to go with Firebase with its https-custom-domain support.
va...@gmail.com
Is there any progress on this?
Any options for Node.js using Custom Runtime (Docker File) ?
Any options for Node.js using Custom Runtime (Docker File) ?
an...@gmail.com
Up.
App Engine is all about development and minimising administrative effort. Having LetsEncrypt fully integrated would be awesome boost in than aspect.
App Engine is all about development and minimising administrative effort. Having LetsEncrypt fully integrated would be awesome boost in than aspect.
lk...@google.com
ar...@looker.com
I ended up forking letsencrypt-nosudo and writing a teeny handler that would accept well known facts (password protected) and managed to automate almost all the process.
You can see the results here
https://github.com/arkarkark/letsencrypt-nosudo
When the cert signer needs well known facts to be served, it posts them to your app engine (no need to keep deploying for each hostname to serve from). Right now I'm putting the result in pbcopy so I can just paste it into the google cloud ssl cert page.
I can't wait for a fully integrated solution though!
You can see the results here
When the cert signer needs well known facts to be served, it posts them to your app engine (no need to keep deploying for each hostname to serve from). Right now I'm putting the result in pbcopy so I can just paste it into the google cloud ssl cert page.
I can't wait for a fully integrated solution though!
pa...@gmail.com
I know the work is already started. Any estimated time ? Like , by end of this year ?
lk...@google.com
Nothing by end of year, but stay tuned for news early in 2017.
pe...@gmail.com
You can contact if you need a beta tester ;-)
se...@gmail.com
+1 for Automatic way
Until then i have solution for Java, I created REST endpoint (jax-rs annotation)
https://gist.github.com/sekys/60ecdc54b91707bdf12ed021640a763f
Choose HTTP challenge. Get your ID a set it with:
http://localhost:8080/.well-known/set-acme-challenge?id=145
Tutorial how you can make HTTP challenge (get your ID):
http://igorartamonov.com/2015/12/lets-encrypt-ssl-google-appengine/
Until then i have solution for Java, I created REST endpoint (jax-rs annotation)
Choose HTTP challenge. Get your ID a set it with:
Tutorial how you can make HTTP challenge (get your ID):
ja...@gmail.com
This is a deal breaker for me, zeit offers this automated service for free and at the moment I have no choice but to go with them: https://zeit.co/blog/now-alias
lk...@google.com
Noted and understood. I'll reach out to those on this issue when ready for some initial feedback on our solution.
[Deleted User] <[Deleted User]>
why not just expose the console certificate management api?
lk...@google.com
If you are interested in helping test an API for domain and cert management, please fill out this form:
https://goo.gl/forms/HiaLbCp63ZJqMe8m1
Thanks!
Thanks!
pe...@gmail.com
lk...@google.com
Thanks for all the responses for testing the new API functionality. We've closed the form as we have enough testers for now. Stay tuned for another round when we're ready to test the automatic certificate integration.
ad...@sherman.ca
I missed the opportunity to test this by only a few days! Really looking forward to it.
ch...@gratix.fr
gc...@gmail.com
can't wait for you guys to deliver the solution, would be so helpful to secure the internet with no excuses.
Thanks for our users.
Thanks for our users.
si...@gmail.com
Can anybody shed some light on the current status of this feature?
Should we expect beta API anywhere soon?
Should we expect beta API anywhere soon?
lk...@google.com
We're getting very close to a beta of the App Engine API/CLI for custom domains & SSL certificates. Automatic certificates will follow shortly after that. Stay tuned!
[Deleted User] <[Deleted User]>
I support for LetsEncrypt solutions, for other solutions even if you got an API, it's still not automated as you still need to purchase certificate somewhere which is most likely manually. If you manage hundreds if projects in the cloud like me, you'll definitely want an fully automatic solution.
to...@gmail.com
Interested in the CLI for cert management as well.
lk...@google.com
pa...@gmail.com
I have tons of personal domains, so I am interested in testing this out. the form link is no longer work. if possible send invite. thanks.
lk...@google.com
We're about ready to start testing!
Please sign up here and we'll send you more details shortly:
https://goo.gl/forms/rZi4EhTwsQaK5Ahl1
Please sign up here and we'll send you more details shortly:
dw...@cobwebb.com
Yes please - we can't get our OAuth working without ssl
dc...@gmail.com
Thanks so much, Google, for beginning to make this happen! I want to host multiple websites (each with its own custom domain) on a single App Engine app. It would be way too much work to have to create completely new certificates to all the domains every three months. We need an automated system (especially for Go apps on GAE).
lk...@google.com
Apologies for the delay here folks, we're just about ready for you. If you've filled out the form you'll be hearing from us shortly.
mi...@kristovar.com
very happy this is happening.... doing the letsencrypt dance for dozens of domains every 3 months wasn't fun.
thanks!
thanks!
ba...@gmail.com
Happy this is happening.
ml...@gmail.com
Looks like AppEngine now lists this in the release notes: "You can now use the beta-level features in the Admin API and gcloud command-line tool to create and manage your custom domains and SSL certificates."
I see documentation at:
https://cloud.google.com/appengine/docs/admin-api/reference/rest/
In particular, if one were motivated (like some folks above), I think one could write a lets-encrypt automator now. First, uploading an SSL key with:
https://cloud.google.com/appengine/docs/admin-api/reference/rest/v1beta/apps.authorizedCertificates/create
And then patching the domain mapping:
https://cloud.google.com/appengine/docs/admin-api/reference/rest/v1beta/apps.domainMappings/patch
to set the sslSettings:
https://cloud.google.com/appengine/docs/admin-api/reference/rest/v1beta/apps.domainMappings#SslSettings
to point at the new SSL certificate that was created above.
It also sounds like Google will be implementing this themselves: "Automatic certificates will follow shortly after that", so I'm not in a hurry or motivated to implement this myself. But wanted to point out the above progress, since it's exciting to see progress on this feature!
I see documentation at:
In particular, if one were motivated (like some folks above), I think one could write a lets-encrypt automator now. First, uploading an SSL key with:
And then patching the domain mapping:
to set the sslSettings:
to point at the new SSL certificate that was created above.
It also sounds like Google will be implementing this themselves: "Automatic certificates will follow shortly after that", so I'm not in a hurry or motivated to implement this myself. But wanted to point out the above progress, since it's exciting to see progress on this feature!
pe...@gmail.com
The native support is already added by Google, but still in closed beta. So, I guess it's better to wait for that.
de...@gmail.com
Before this feature is available, you can still fully automate Let's Encrypt SSL creation and renewal using `gcloud` tools which allow deployment (HTML DNS Verification) and upload SSL to server (using `gloud beta`). You need to configure `certbot` to run on external server though.
https://code.luasoftware.com/tutorials/google-app-engine/lets-encrypt-on-google-app-engine/
pi...@gmail.com
Very happy you are working on this feature. Do you have any idea when it would be released for everybody?
co...@gmail.com
Hope this feature comes very soon.
nh...@gmail.com
Looking forward to this!
fs...@gmail.com
Is it possible to sign up to the closed beta?
[Deleted User] <[Deleted User]>
Any updates here? The previous sign-up form has been closed..
sj...@gmail.com
Sjairul Bin Abdul Majid(DNS) i/c no : 800215-12-5907.(DNS)
T/Lahir / 15 / 02 / 1980.(DNS)
Passport no : H 12895112.(DNS)
All Document and Account i-Saving Bank Wadia in Malaysia.
T/Lahir / 15 / 02 / 1980.(DNS)
Passport no : H 12895112.(DNS)
All Document and Account i-Saving Bank Wadia in Malaysia.
lk...@google.com
Work is well underway to bring this feature to the public. Stay tuned and we'll be sure to update this issue when there is more to share.
[Deleted User] <[Deleted User]>
+1
sa...@gmail.com
Wondering if there is any update / ETA on this. This is literally the only thing stopping us from migrating all our infra from AWS to GCP.
This, or even better would be something like AWS Certificate Manager.
This, or even better would be something like AWS Certificate Manager.
cl...@gmail.com
I'm very interested too :) I'll keep waiting for new information.
da...@gmail.com
+1
gr...@gmail.com
+1
ma...@withorca.com
+1
ka...@gmail.com
+1
bo...@cbn-it.ro
Please stop spamming us with +1. THIS is not a chat. it's an issue tracker. If you want to +1, click on the little star at the top and you will get notifications when this feature will be ready.
Each time you add a comment, you send an email notification to all of us that has Stared the issue/feature request.
Each time you add a comment, you send an email notification to all of us that has Stared the issue/feature request.
nt...@gmail.com
When I select a domain name in the console and click 'Enable managed security', I receive the error message 'Failed to activate certificates'.
lk...@google.com
There is a glitch right now in the UI when enabling security on existing domains. Using gcloud works as expected and creating a new domain will also work, both from the UI and CLI. We're looking at the UI and will send an update with more detail shortly. Apologies and thanks for taking a look!
li...@gmail.com
using gcloud I get the following error:
ERROR: (gcloud.beta.app.domain-mappings.update) Error Response: [403] Operation not allowed
Details:
- '@type':type.googleapis.com/google.rpc.ResourceInfo
description: The "appengine.applications.update" permission is required.
resourceType: gae.api
The account I'm using is owner of the project. How can I get around this?
thanks
ERROR: (gcloud.beta.app.domain-mappings.update) Error Response: [403] Operation not allowed
Details:
- '@type':
description: The "appengine.applications.update" permission is required.
resourceType: gae.api
The account I'm using is owner of the project. How can I get around this?
thanks
lk...@google.com
Stefano, likely you have not verified the domain from your own account.
li...@gmail.com
Thanks for your reply, this domain was already set up with other certificates and was working fine. How can I verify the domain with my account?
thanks
UPDATE:
Never mind, I was using the wrong project id (gcloud)! Sorry for the bother
thanks
UPDATE:
Never mind, I was using the wrong project id (gcloud)! Sorry for the bother
je...@gmail.com
The gcloud command worked perfect for me on existing domain. Couple minutes later it was serving HTTPS and shows as Google managed in the console.
lk...@google.com
The UI glitch has been resolved, if you had trouble please give it another try!
br...@gmail.com
Having issues on a given domain - background info:
1. It was a pre-existing domain, served via AppEngine Standard
2. I deleted the existing keys
3. I clicked "Enable Managed Security" in the console
4. I received notice of "started" and "activated"
5. The domains fail in Chrome + Safari with ERR_CONNECTION_CLOSED
6. No logs showing connections appear in the Cloud Console
Feel free to email directly for further diagnostics.
1. It was a pre-existing domain, served via AppEngine Standard
2. I deleted the existing keys
3. I clicked "Enable Managed Security" in the console
4. I received notice of "started" and "activated"
5. The domains fail in Chrome + Safari with ERR_CONNECTION_CLOSED
6. No logs showing connections appear in the Cloud Console
Feel free to email directly for further diagnostics.
m....@gmail.com
The Google-managed SSL security does not yet seem to work with CNAME records which point to ghs.googlehosted.com .
The security manager tried to renew the certificate for hours, without success.
Creating certificates for the A and AAAA records did not cause any problems.
Previously this worked fine with manually verified LetsEncrypt certificates.
The security manager tried to renew the certificate for hours, without success.
Creating certificates for the A and AAAA records did not cause any problems.
Previously this worked fine with manually verified LetsEncrypt certificates.
ds...@gmail.com
I had a similar problem to #116 above - the A and AAAA records worked perfectly, while the CNAME record to ghs.googlehosted.com got stuck renewing the new cert for what appeared to be close to an hour.
Disabling the google managed SSL cert for the CNAME record and then enabling it again in the console seemed to fix this for me (I had to wait a few mins after cancelling before I could re-enable it due to a time based restriction).
Second attempt on the CNAME record cert worked like a charm and took no more than a few mins.
Hope that helps!
Disabling the google managed SSL cert for the CNAME record and then enabling it again in the console seemed to fix this for me (I had to wait a few mins after cancelling before I could re-enable it due to a time based restriction).
Second attempt on the CNAME record cert worked like a charm and took no more than a few mins.
Hope that helps!
m....@gmail.com
The workaround suggested in #117 did not solve my problem.
After investigating the matter a bit further I discovered that the manager was able to obtain a certificate for the CNAME record of one domain but
not for the CNAME records of three different domains.
Nothing about the setup changed and they all had working LetsEncrypt certificates before.
The records for the working domain and two of the non working domains are identical (apart from the domain).
All domains use the same name server.
Deleting and recreating the record for the custom domain in the web console of the application did not help either.
After investigating the matter a bit further I discovered that the manager was able to obtain a certificate for the CNAME record of one domain but
not for the CNAME records of three different domains.
Nothing about the setup changed and they all had working LetsEncrypt certificates before.
The records for the working domain and two of the non working domains are identical (apart from the domain).
All domains use the same name server.
Deleting and recreating the record for the custom domain in the web console of the application did not help either.
sj...@gmail.com
All Document & saving i-account Bank Follow My (DNS) Now
-mesej asal-
Perkara: Re:
Daripada: <buganizer-system@google.com>
Tarikh: 16.09.2017 1.49 PM
Replying to this email means your email address will be shared with the
team that works on this product.
https://issuetracker.google.com/issues/35900034
Changed
m....@gmail.com added
The workaround suggested in #117 did not solve my problem.
After investigating the matter a bit further I discovered that the manager
was able to obtain a certificate for the CNAME-Record of one domain but
not for the CNAME-Records of three different domains.
Nothing about the setup changed and they all had working LetsEncrypt
certificates before.
The records for the working domain and two of the non working domains are
identical (apart from the domain).
_______________________________
Reference Info: 35900034 Support automatic certificate request via Lets
Encrypt/ACME
component: Public Trackers > Cloud Platform > Compute > App Engine > Custom
Domains & SSL
status: Accepted
reporter: mm...@mikecb.org
assignee: lk...@google.com
cc: lk...@google.com, mb...@google.com, ng...@google.com, and 1 more
type: Feature Request P2 S2
blocked by: 22010324
duplicate issue: 35900617, 62474080
hotlist: Sjairul Abdul Majid, Sjairul Abdul Majid ( DNS), Sjairul Bin Abdul
Majid, Sjairul Bin Abdul Majid(DNS) i/c no : 800215-12-5907.
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google
IssueTracker
-mesej asal-
Perkara: Re:
Daripada: <buganizer-system@google.com>
Tarikh: 16.09.2017 1.49 PM
Replying to this email means your email address will be shared with the
team that works on this product.
Changed
m....@gmail.com added
The workaround suggested in #117 did not solve my problem.
After investigating the matter a bit further I discovered that the manager
was able to obtain a certificate for the CNAME-Record of one domain but
not for the CNAME-Records of three different domains.
Nothing about the setup changed and they all had working LetsEncrypt
certificates before.
The records for the working domain and two of the non working domains are
identical (apart from the domain).
_______________________________
Reference Info: 35900034 Support automatic certificate request via Lets
Encrypt/ACME
component: Public Trackers > Cloud Platform > Compute > App Engine > Custom
Domains & SSL
status: Accepted
reporter: mm...@mikecb.org
assignee: lk...@google.com
cc: lk...@google.com, mb...@google.com, ng...@google.com, and 1 more
type: Feature Request P2 S2
blocked by: 22010324
duplicate issue: 35900617, 62474080
hotlist: Sjairul Abdul Majid, Sjairul Abdul Majid ( DNS), Sjairul Bin Abdul
Majid, Sjairul Bin Abdul Majid(DNS) i/c no : 800215-12-5907.
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google
IssueTracker
fl...@fnkr.net
Can't confirm the problem mentioned in #116 and #117. I was able to successfully activate automatic certificate management for two AppEngine domains in two separate projects two days ago. Both domains work with CNAME records (ghs.googlehosted.com ). I was using the command below.
> gcloud components update
> gcloud --project PROJECT beta app domain-mappings update SUB.DOMAIN.TLD --certificate-management 'AUTOMATIC'
No downtime experienced, new certificate was online after about 10 minutes.
> gcloud components update
> gcloud --project PROJECT beta app domain-mappings update SUB.DOMAIN.TLD --certificate-management 'AUTOMATIC'
No downtime experienced, new certificate was online after about 10 minutes.
lk...@google.com
Hey folks, for those having issues, please open a new issue with the domains you are trying to secure.
m....@gmail.com
I might have discovered what is causing the problems with the certificate manager in my case and similar cases.
When I tried to verify it with one of my rather unimportant subdomains, it fixed the hangup.
My CNAME record pointed toghs.google.com , which is the entry that was recommended by the Google App Engine documentation when I created those records.
Later it was replaced byghs.googlehosted.com in the documentation.
The App Engine console displaysghs.google.com as ghs.googlehosted.com .
This should also apply tohttps://issuetracker.google.com/issues/65835474 since the domain mentioned in the article also has a www CNAME record which points to ghs.google.com .
I guess the best course of action would be to update the certificate manager so that it can work withghs.google.com , since many older App Engine configurations are still using those CNAME records and since they work normally for domains with http or https with certificates which are not managed by the SSL manager.
When I tried to verify it with one of my rather unimportant subdomains, it fixed the hangup.
My CNAME record pointed to
Later it was replaced by
The App Engine console displays
This should also apply to
I guess the best course of action would be to update the certificate manager so that it can work with
jm...@gmail.com
I can confirm that the comments in #122 solved the issue for me. I had a couple old domains that would hang trying to enable the managed cert. I switched my CNAME records from ghs.google.com to ghs.googlehosted.com , re-enabled the managed certificate, and it worked.
(Thanks to the author of #122!)
(Thanks to the author of #122!)
st...@google.com
The issue that prevented us from issuing certs for domains with CNAME set to ghs.google.com has now been resolved.
That said, we still encourage you to useghs.googlehosted.com in your CNAME records.
That said, we still encourage you to use
ch...@gratix.fr
Cloud CDN over HTTPS currently requires manual upload of a certificate. Does anyone know if there are plan to extend support for automatic certificate to Cloud CDN as well?
I cannot see any mention of the issue in the thread above
Many thanks
I cannot see any mention of the issue in the thread above
Many thanks
te...@gmail.com
I have a question related to the certificate authority used for the managed security feature which currently uses Letsencrypt certificates. Is it safe to assume it will stay Letsencrypt and won't e.g. be changed to pki.goog in the future? I'm asking because I'm not sure if it's safe to create a CAA DNS record with letsencrypt or not. Thanks.
is...@google.com
pa...@gmail.com
From what I can gather, this only applies to App Engine, not things like Kubernetes Engine or Network Load Balancing. Is this correct? Are there any plans to support automatic certificate management for domains pointing to these resources?
mb...@google.com
kn...@google.com
Hi everyone, I'm happy to let you know that Managed Certificates for App Engine are now Generally Available. I'm going to close this feature request.
To address the earlier question: we do plan to bring automatic certificate generation to Kubernetes Engine as well as to Network Load Balancing, but we don't have any timeline that we can share right now.
To address the earlier question: we do plan to bring automatic certificate generation to Kubernetes Engine as well as to Network Load Balancing, but we don't have any timeline that we can share right now.
to...@gmail.com
Hi, It appears managed certificates is still not supported for wildcard subdomains in app engine? Any plans for this?
pd...@gmail.com
Hi,
> To address the earlier question: we do plan to bring automatic certificate generation to Kubernetes Engine as well as to Network Load Balancing, but we don't have any timeline that we can share right now.
Great! Are there any public issues for tracking those?
> To address the earlier question: we do plan to bring automatic certificate generation to Kubernetes Engine as well as to Network Load Balancing, but we don't have any timeline that we can share right now.
Great! Are there any public issues for tracking those?
jo...@gmail.com
Any timeline yet?
[Deleted User] <[Deleted User]>
I second the request for wildcard domain certificates. Is this something we can expect in future? If yes, is there any timeline? We're thinking about switching off of AWS but we need this feature.
kn...@google.com
Automatically managed wildcard certificates are on the roadmap. Until we have support for that, as a workaround, you can use manually managed wildcard certificates or map each subdomain individually as a workaround.
I'm not aware of public feature requests for automatic certificate management on the other products, sorry.
I'm not aware of public feature requests for automatic certificate management on the other products, sorry.
pa...@gmail.com
or manually generate it and upload using gcloud command line.
good news is, certbot support google cloud dns to automatically set and
change the txt record for verification, so almost nothing needs to be done
On Thu, Oct 25, 2018 at 10:16 AM <buganizer-system@google.com> wrote:
good news is, certbot support google cloud dns to automatically set and
change the txt record for verification, so almost nothing needs to be done
On Thu, Oct 25, 2018 at 10:16 AM <buganizer-system@google.com> wrote:
[Deleted User] <[Deleted User]>
I'm glad to hear that wildcard certificates are on the roadmap! Mapping each subdomain individually is not an option for us as we dynamically create new subdomains for each new client. I did a bit of research and we might end up using https://github.com/jetstack/cert-manager for now.
sk...@gmail.com
so, it looks like https://cloud.google.com/load-balancing/docs/ssl-certificates#create-managed-ssl-cert-resource
andhttps://cloud.google.com/load-balancing/docs/https/#tls_support might solve this now? not sure if it's LetsEncrypt or not (haven't used) but it looks like this would solve the issue.
I would really like to see this stuff fully integrated into GKE though.
and
I would really like to see this stuff fully integrated into GKE though.
an...@qyberion.com
The App Engine docs states the following:
"After you set up your custom domain and update the DNS records, a managed SSL certificate is automatically provided within a few minutes. The managed certificate is signed by Let's Encrypt." (Seehttps://cloud.google.com/appengine/docs/standard/nodejs/securing-custom-domains-with-ssl )
I have verified it with some apps. Feature seems to be available for all environments in GAE.
So I believe this issue can be closed.
(And I agree with
"After you set up your custom domain and update the DNS records, a managed SSL certificate is automatically provided within a few minutes. The managed certificate is signed by Let's Encrypt." (See
I have verified it with some apps. Feature seems to be available for all environments in GAE.
So I believe this issue can be closed.
(And I agree with
kn...@google.com
[Deleted User] <[Deleted User]>
Is there a separate issue for wildcard certificates?
Description
Let's Encrypt promises a very easy way to automatically generate and manage short lived certificates and configurations for apache and nginx, but requires a great deal of work, even more than a traditional certificate, to get one for a platform such as Appengine. Many such platforms are baking in support for the ACME protocol underlying Letsencrypt so that users can get a certificate for a domain on that platform at the click of a button. Google has been at the forefront of pushing TLS forward, and supporting Lets Encrypt on Appengine for custom domains would help a lot in that mission.
The current approach, even once Let's Encrypt supports DNS verification, would require manual generation and management at least every 90 days, since the certificates last only that long. This isn't terrible, but the point of the project is for the process to be completely automated, so integration is a plus. In addition, if Google (Ryan Sleevi) and others in the CAB forum are successful in permitting very short lived certificates of a couple of days to become commonplace, the need for automation becomes critical.
Behavior:
Once a project has enabled a custom domain, in the ssl certificates tab, there would be more than one option: Use your own certificate, or request a certificate for this domain from Let's Encrypt. This second option would interface with LE via the acme protocol, verify the domain and install the cert and key, renew every 60-90 days without user intervention, and offer a button in the console to submit a revocation request.