I am going around in circles for the past hour trying to change the domain for HTTP(S) Load Balancer's SSL certificates.
I can't seem to find an option from the console or CLI to change/update the domains. After created a new one, I cannot delete the old one because it is attached to the load balancer. To remove the old SSL certificate, I have to delete the LB and its dependencies, and to go through all the steps to create the load balancer again.
May I know if it is a bug or expected behavior?
Thanks.
Before you can delete an SSL certificate, you must first update each target proxy that references the certificate. For each target proxy, run the appropriate gcloud update command to update the target proxy's CERTIFICATE_LIST such that it no longer includes the SSL certificate you need to delete.
Please find below steps to replacing SSL certificates.
1.Create a new SSL certificate resource. The new SSL certificate must have a unique name within the project.
2. Update the target proxy so that its list of SSL certificate(s) includes the new SSL certificate in the first position to make it the primary certificate. After the new certificate, include any existing SSL certificates that you want to retain. Make sure to exclude the old SSL certificate that you no longer need. To avoid downtime, run a single gcloud command with the --ssl-certificates flag. For example:
For external HTTP(S) load balancers:
Use the gcloud compute target-https-proxies update command with the --global flag.
gcloud compute target-https-proxies update TARGET_PROXY_NAME
--global
--ssl-certificates=new-ssl-cert,other-certificates
--global-ssl-certificates.
For internal HTTP(S) load balancers:
gcloud compute target-https-proxies update TARGET_PROXY_NAME
--region REGION
--ssl-certificates=new-ssl-cert,other-certificates
--global-ssl-certificates
For SSL proxy load balancers:
Use the gcloud compute target-ssl-proxies update command with the --backend-service flag.
gcloud compute target-ssl-proxies update TARGET_PROXY_NAME
--ssl-certificates=new-ssl-cert,other-certificates
Verify that the load balancer is serving the replacement certificate by running the following OpenSSL command:
echo | openssl s_client -showcerts -connect IP_ADDRESS:443 -verify 99 -verify_return_error
Wait 15 minutes to ensure that the replacement certificate is available to all Google Front Ends (GFEs).
(Optional) Delete the old SSL certificate.
For further reading please follow the links below:
Deleting/ Replacing SSL certificates :
https://cloud.google.com/load-balancing/docs/ssl-certificates/self-managed-certs#delete-ssl-cert-resource
Replacing an existing SSL certificate
https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#replace-ssl
Related
I'm currently trying to setup GlusterFS integration for a Kubernetes cluster. Volume provisioning is done with Heketi.
GlusterFS-cluster has a pool of 3 VMs
1st node has Heketi server and client configured. Heketi API is secured with a self-signed certificate OpenSSL and can be accessed.
e.g. curl https://heketinodeip:8080/hello -k
returns the expected response.
StorageClass definition sets the "resturl" to Heketi API https://heketinodeip:8080
When storageclass was created successfully and I try to create a PVC, this fails:
"x509: certificate signed by unknown authority"
This is expected, as ususally one has to allow this insecure HTTPS-connection or explicitly import the issuer CA (e.g. a file simply containing the pem-String)
But: How is this done for Kubernetes? How do I allow this insecure connection to Heketi from Kubernetes, allowing insecure self-signed cert HTTPS or where/how do I import a CA?
It is not an DNS/IP problem, this was resolved with correct subjectAltName settings.
(seems that everybody is using Heketi, and it seems to be still a standard usecase for GlusterFS integration, but always without SSL, if connected to Kubernetes)
Thank you!
To skip verification of server cert, caller just need specify InsecureSkipVerify: true. Refer this github issue for more information (https://github.com/heketi/heketi/issues/1467)
In this page, they have specified a way to use self signed certificate. Not explained thoroughly but still can be useful (https://github.com/gluster/gluster-kubernetes/blob/master/docs/design/tls-security.md#self-signed-keys).
I use cert-manager to generate TLS certificates for my application on Kubernetes with Let's Encrypt.
It is running and I can see "ca.crt", "tls.crt" and "tsl.key" inside the container of my application (in /etc/letsencrypt/).
But "ca.crt" is empty, and the application complains about it (Error: Unable to load CA certificates. Check cafile "/etc/letsencrypt/ca.crt"). The two other files look like normal certificates.
What does that mean?
With cert-manager you have to use the nginx-ingress controller which will work as expose point.
ingress nginx controller will create one load balancer and you can setup your application tls certificate there.
There is nothing regarding certificate inside the pod of cert-manager.
so setup nginx ingress with cert-manager that will help to manage the tls certificate. that certificate will be stored in kubernetes secret.
Please follow this guide for more details:
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes
I noticed this:
$ kubectl describe certificate iot-mysmartliving -n mqtt
...
Status:
Conditions:
...
Message: Certificate issuance in progress. Temporary certificate issued.
and a related line in the docs:
https://docs.cert-manager.io/en/latest/tasks/issuing-certificates/index.html?highlight=gce#temporary-certificates-whilst-issuing
They explain that the two existing certificates are generated for some compatibility, but they are not valid until the issuer has done its work.
So that suggests that the issuer is not properly set up.
Edit: yes it was. The DNS challenge was failing, the debug line that helped was
kubectl describe challenge --all-namespaces=true
More generally,
kubectl describe clusterissuer,certificate,order,challenge --all-namespaces=true
According to the documentation, cafile is for something else (trusted root certificates), and it would probably be more correct to use capath /etc/ssl/certs on most systems.
You can follow this guide if you have Windows Operating System:
tls.
Article is about how to enable Mosquitto and clients to use the TLS protocol.
Establishing a secure TLS connection to the Mosquitto broker requires key and certificate files. Creating all these files with the correct settings is not the easiest thing, but is rewarded with a secure way to communicate with the MQTT broker.
If you want to use TLS certificates you've generated using the Let's Encrypt service.
You need to be aware that current versions of mosquitto never update listener settings when running, so when you regenerate the server certificates you will need to completely restart the broker.
If you use DigitalOcean Kubernetes try to follow this instruction: ca-ninx, you can use Cert-Manager and ingress nginx controller, they will work like certbot.
Another solution is to create the certificate locally on your machine and then upload it to kubernetes secret and use secret on ingress.
When creating my certificate initially I had to do it manually by running the following command.
sudo certbot certonly --manual -d www.example.com
What is the correct process of renewing the certificate now? Do I simply rerun the same command? I've researched this a bit and the it seems that the automatic renewal is not possible as I had created this certificate manually.
Will renewing the certificate by running the same command create new fullchain.pem, cert.pem, chain.pem and private.pem files. I am asking this because this would require me to update the information on my Compute Engine that is using the certificate I'm trying to renew.
I'm not using certbot, but I used acme-tiny: https://github.com/diafygi/acme-tiny (I found it on Let's Encrypt page)
In the README you can read about renew: Step 6: Setup an auto-renew cronjob
And the conclusion is that renew is only execute again the program with the same files (account key, domain key and csr).
So I supose that if you did a manual request with certbot (I supose that you provide some info like keys) you only need to execute again the command and get your new cert.
I am using wget in my program to get some file using HTTP protocol. Here i need to set security so we moved HTTP protocol to HTTPS.
After changing to HTTPS how to perform wget. I mean how to make trusted connection between two machines then perform wget.
I want to make sure that wget can be performed from certain system only.
Step 1: SSL Certificates
First things first, if this machine is on the internet and the SSL certificate is signed by a trusted source, there is no need to specify a certificate.
However, if there is a self signed certificate involved things get a little more interesting.
For example:
if this machine uses a self signed certificate, or
if you are on a network with a proxy that re-encrypts all https connections
Then you need to trust the public key of the self signed certificate. You will need to export the public key as a .CER file. How you got the SSL certificate will determine how you get the public key as a .CER
Once you have the .CER then...
Step 2: Trust the Certificate
I suggest two options:
option one
wget --ca-certificate={the_cert_file_path} https://www.google.com
option two
set the option on ~/.wgetrc
ca_certificate={the_cert_file_path}
Additional resources
Blog post about this wget and ssl certificates
wget manual
macOS users can use the cert.pem file:
wget --ca-certificate=/etc/ssl/cert.pem
or set in your ~/.wgetrc:
ca_certificate = /etc/ssl/cert.pem
On Linux (at least on my Debian and Ubuntu distributions), you can do the following to install your cert to be trusted system-wide.
Assuming your certificate is ~/tmp/foo.pem, do the following:
Install the ca-certificates package, if it is not already present, then do the following to install foo.pem:
$ cd ~/tmp
$ chmod 444 foo.pem
$ sudo cp foo.pem /usr/local/share/ca-certificates/foo.crt
$ sudo update-ca-certificates
Once this is done, most apps (including wget, Python and others) should automatically use it when it is required by the remote site.
The only exception to this I've found has been the Firefox web browser. It has its own private store of certificates, so you need to manually install the cert via its Settings interface if you require it there.
At least this has always worked for me (to install a corporate certificate needed for Internet access into the Linux VMs I create).
I am using the EC2 Load Balancer to handle HTTPS requests. For Chrome & Safari, having the Load Balancer Protocol set HTTPs at Port 443 with the the SSL cert handles most traffic correctly. HTTPS requests from Safari & Chrome are fine. However in Firefox, I get the connection is insecure "(Error code: sec_error_unknown_issuer)." In checking with a cert checker, I get
The certificate is not signed by a trusted authority (checking against
Mozilla's root store). If you bought the certificate from a trusted
authority, you probably just need to install one or more Intermediate
certificates.
In talking with my cert provider, the information I got was :
As we can see certificate has been installed improperly at the server.
There is no CA bundle at the server that is why browsers may show
warning messages.
How do you install a CA Bundle using the Load Balancer?
The solution is to add the ca_bundle to your load_balancer under "Certificate Chain"
That depends on how you are creating the ELB (Elastic Load Balancer).
If you are creating it from the AWS Console, then, when you create the ELB you can create a new SSL sercificate and, when promted, and as #Emile said, you have to specify the contents of the provided "CA Bundle" under the "Certificate Chain" field.
If you are creating it from the command line or using the API, then when you create the SSL certificate you have to specify the "CA Bundle" contents in the "Certificate Chain" parameter.
Right now, what you probably have to do is to create a new ELB specifying the right paramenters, modify your DNS accordingly and once the change has been applied, delete the old load balancer.
First you'll need to obtain a copy of the appropriate certificate bundle from your certificate authority.
Then you'll need to update the SSL certificate on your AWS ELB. Select "Upload a new SSL Certificate" from the ELB Select Certificate window. Paste your current private and public certificate keys into the appropriate fields and then paste the certificate bundle into the "Certificate Chain" field.