I've setup my Google Cloud Project to use a load balancer in combination with auto scaling instance templates. Currently the instance group only has one instance.
My domain name successfully refers to the load balancers IP. Till these steps everything is working correctly.
Now I want to setup SSL for this project. I would like to do this with the Letsencrypt service, however I'm having no success when trying to set this up.
In the Google Cloud Engine load balancer window there is an option to setup an earlier created certificate with Google Cloud shell to the load balancer frontend. Unfortunately I can only create a .csr and .key file with the Google Cloud Shell. Furthermore, I can create an unsafe ssl certificate and get the .cert file from it, but I would like to create a safe SSL cert file using letsencrypt. The Letsencrypt services requires direct access to the domain from to command line interface the commando was executed on, this is probably the reason why I’m getting an error indicating the domain name cannot be retrieved.
I’m looking for a way to install the Letsencrypt certificate on the loadbalancer using Google Cloud. Is there a way how I can manually create a .cert file with letsencrypt instead of installing this directly? If not is there another way or service to create a .cert file from a .csr and .key file?
You can use sslforfree.com, which calls LetsEncrypt for you and gives you the keys for downloading. It can also remind you to renew your certs. (There's currently no way to auto-renew certs in Google LB)
You can use certbot
Here is an example of how to create only the certificates
$ ./certbot-auto certonly --standalone --email admin#example.com -d example.com -d www.example.com
If you use Kubernetes on top of Google Compute Engine, a good solution is cert-manager, which is a successor of kube-lego. Both can automatically requests certificates for Kubernetes Ingress resources from Let's Encrypt:
Features
Recognizes the need of a new certificate for this cases:
No certificate existing
Existing certificate is not containing all domain names
Existing certificate is expired or near to its expiry date (cf. option LEGO_MINIMUM_VALIDITY)
Existing certificate is unparseable, invalid or not matching the secret key
Creates a user account (incl. private key) for Let's Encrypt and stores it in Kubernetes secrets (secret name is configurable via LEGO_SECRET_NAME)
Obtains the missing certificates from Let's Encrypt and authorizes the request with the HTTP-01 challenge
Makes sure that the specific Kubernetes objects (Services, Ingress) contain the rights configuration for the HTTP-01 challenge to succeed
Official Kubernetes Helm chart for simplistic deployment.
A step-by-step tutorial for GCE is available.
A good way to achieve your goal is cloud function + cloud scheduler + https://github.com/bloomapi/letsencrypt-gcloud-balancer
Related
I have nodejs app using kafkajs package for connecting to AWS MSK.
We are moving to Strimzi Kafka because we already have a kubernetes cluster and we don't need the MSK anymore.
Until now we were connected with SSL but didn't have to specify any CA path or something. We used this way of connection both on our nodejs apps and kafka-ui and it worked with no issues.
We are trying to the same with Strimzi Kafka, but we get SSL handshake failed.
For my understanding is AWS MSK is using amazon certificates that are known while the Strimzi Kafka is generating self signed certificates which is ok by us.
How can I still using this way like we used with AWS MSK? With just use ssl: true in kafkajs (It works)
Thanks.
The easiest way to use a certificate signed by some public CA is using the listener certificate which lets you provide your own server certificate for given listener. I'm not sure how the Amazon CA works, but this blog post shows how to do it for example using Cert-Manager and Let's Encrypt.
Keep in mind that to use the public CAs, you usually need to use some proper domain names and not just internal Kubernetes services. This might for example increase costs or latency if your applications run in the same Kubernetes cluster because the traffic might need to go through a load balancer or ingress.
I have a website which is running on AWS windows EC2.
XAMPP is running and I already have my own Domain.
I need to put SSL certificate on my web server, but unfortunately I still haven't found a good guide.
In my opinion,
first step is to create CSR file,
second step is to make SSL by using CSR on SSL service,
final step is to put SSL certificate on my AWS windows EC2....
But I don't know how to do it for every step.
Looking forward to hearing from your answer.
We are researching the best solution to allow customers to use their domain names with our hosting services. The hosting services are based on Google App Engine standard. The requirements are:
Customers can point their domain name to our server via CNAME or A record
Our server should be able to generate SSL certs for them automatically using Let's Encrypt
Our server should be able to handle custom SSL certs uploaded by customers
Should be robust and reliable when adding new customers (new confs, SSL certs etc.) into our servers
Should be scalable, and can handle a large number of custom domains and traffic (e.g. from 0 to 10000)
Minimum operation costs (the less time needed for maintaining the infrastructure, the better)
It seems Google Kubernetes Engine (formerly known as Google Container Engine) would be the direction to go. Is there a specific, proven way to set it up? Any suggestions/experiences sharing would be appreciated.
I would recommend going through this link to get started with setting up a GKE cluster.
For your purpose of SSL on GKE I would recommend creating an Ingress as specified in this link which automatically creates a Loadbalancer Resource in GCP if you use the default GLBC ingress controller. The resulting LB's configuration (Ports, Host Path rules, Certificates, Backend Services, etc. ) are defined by the configuration of the Ingress Object itself. You can point the domain the domain name to the IP of the Loadbalancer.
If you want to configure your Ingress(and consequently the resulting LB) to use certs created by 'Let's Encrypt', you would be modifying the configuration presented in the YAML of the ingress.
For actually integrating Let's Encrypt for Kubernetes, it is actually possible by using a service called cert-manager to automate the process of obtaining TLS/SSL certificates and store them inside secrets.
This link shows how to use cert-manager with GKE.
If you want to use self managed SSL certificates please see this link for more information. The GKE is scalable by the GKE's cluster autoscaler which automatically resizes clusters based on the demands of the workloads you want to run.
I am trying to lunch new servers automatically when needed but I am having some difficulty getting the certificate before making the server live. What I want to do is run a setup script which gets all the packages, websites and certificates ready and after that add the server to production. However, Letsencrypt wants me to verify that the server requesting the certificate is actually the website which replies to requests. How can I get the Letsencrypt certificate before adding the server to production? I don't want requests to the real website to be routed to the new server until it is fully setup and has the certificates.
One solution I thought of is to save the certificates on an AWS S3 bucket and synchronize them whenever a renewal is needed. Then when I setup a new server I just get the latest certificate from my AWS S3 bucket and I don't have to worry about getting the certificate from the CA until after the server is added to production.But this solution doesn't seem "clean" and would require me to have an S3 bucket just for my Letsencrypt certificate which also adds another weakness where a certificate could be stolen from.
Is there a more simple solution which I haven't thought of yet?
In a load-balanced (LB) scenario, you should consider having exactly one entity responsible for performing LE certificate acquisition. Things get complicated with multiple entities doing this asynchronously - you'd need to be able to guarantee that the ACME challenges get routed to the relevant server(s), and your LB doesn't have that information (without additional complexity).
So I'd suggest either:
Terminating HTTPS at your load-balancer. Then none of your servers need to care about HTTPS or certificates.
Having one "special" server that's responsible for interacting with LE, and then distributing the cert to the other servers. The details of how you do that is implementation-dependent, because it depends on how you're managing server/service configuration.
I have an app (hosted in heroku) where customers have an individual subdomain e.g. client1.myapp.com, client2.myapp.com I am using a wildcard SSL cert here.
If however a client wants to use their own custom domain e.g. CNAME app.client1.com
How can i automatically provide an SSL cert (I'm guessing using Lets Encrypt) for the client without them providing me a certificate to upload in a similar way to firebase etc.. provides SSL certs for domains.
As long as app.client1.com is reachable from the internet, you are free to set up a lets-encrypt certificate.
If your applications run on unix-like system, then the cerbot docs describe all the steps for automating the renewal.
You basically have to set up a cronjob that launches the renewal command.
You can edit the crons in you linux machine with the command crontab -e and place something like this at the end of the file:
0 15 1 * * certbot renew
This will run the command the first day of each month and attempt the renewal of your certificate. Check crontab.guru if you need different settings.
If you want to call the cerbot command from a custom script, you can add such script to your cronjob (and save the output to a custom file).
E.g:
0 15 1 * * python cert_autorenew.py >> cron.log 2>&1
Keep in mind that if you want a certificate for app.client1.com, then the renewal request you send, must resolve to the server app.client1.com.
That's how you demonstrate the control over your domain to letsencrypt.
If you are hosting the new application in Heroku/new domain is directed to Heroku app, they will take care of the SSL Certificates for you, as long as you run the application on a paid dyno. Which you should as its a client's application!
https://devcenter.heroku.com/articles/ssl
Heroku provides free Automated Certificate Management (ACM) for all
applications running on paid dynos. With ACM, Heroku automatically
provisions and renews SSL certificates for your application. If you
prefer to upload your own certificate manually, follow the steps in
this article.
You only have to make an application in Heroku, upgrade the dyno and configure the custom domain name (app.client1.com) for the application, following instructions at https://devcenter.heroku.com/articles/custom-domains