I can not delete Google-managed SSL certificate - when I delete it it comes back. This certificate is not used by any other services.
I can delete other certificates and they are not coming back.
I am also having this issue. I found in the docs that certs can only be deleted if
SSL certificates can only be deleted when no other resources (for example, target HTTPS proxies) refer to them.
I suspect this is what is causing this issue but I am unable to confirm this. On the cert page itself https://console.cloud.google.com/net-services/loadbalancing/advanced/sslCertificates/list it clearly says In use by: Not used.
I think there is some issue with google cloud not cleaning up references somewhere, but I am unable to find where. I have confirmed that none of my target proxies are referring to the cert. #dharmik-chauhan and #kerem-yazar have either of you found a solution?
I had the same issue.
What ended up working for me is to delete the certificate through the CLI instead of Cloud Console. After deleting the Ingress that was using the certificate, I ran the following command to delete the certificate:
kubectl delete ManagedCertificate [CERTIFICATE-NAME]
After doing this, the certificate stopped coming back.
I had the same exact issue. However, when I attempted to delete through kubectl delete ManagedCertificate [CERTIFICATE-NAME] as previously suggested, it responded with a "certificate not found" error. I fixed this by running the following command(s):
gcloud compute ssl-certificates list
to get the name of the reappearing certificate.
gcloud compute ssl-certificates delete [NAME] to delete the reappearing certificate.
They stopped coming back after this.
Related
I am new in Kubernetes and stuck on the issue. I was trying to renew letsencrypt SSL certificate. But when I try to get certificate by running following command
kubectl get certificate
System throwing this exception
Error from server: conversion webhook for cert-manager.io/v1alpha2, Kind=Certificate failed: Post https://cert-manager-webhook.default.svc:443/convert?timeout=30s: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "cert-manager-webhook-ca")
I have checked the pods also
The "cert-manager-webhook" is in running state. When I check logs of this pod, I get the following response
I have also tried to apply cluster-issuer after deleting it but face same issue
kubectl apply -f cluster-issuer.yaml
I also have done R&D about this but could not find any suitable solution. Whats the issue here? Can someone please help me regarding this? Thanks.
The problem was with "cert-manager-cainjector" pod status which was "CrashLoopBackOff" due to FailedMount as secret was not found for mounting. I have created that secret and after that it start working fine.
In my case, I was attempting to install an older version of cert-manager onto my cluster, and Simply pulling the latest version of cert-manger (1.10.1 at time of writing) and installing that worked.
When attempting to install an older version of cert-manager I saw the following error from the cainjector pod.
error registering secret controller: no matches for kind "MutatingWebhookConfiguration" in version "admissionregistration.k8s.io/v1beta1"
I assume that the API admissionregistration.k8s.io/v1beta1 has been removed between K8s versions 1.21 and 1.24, and that's why I encountered an issue.
if you are using webhook, check if you have injected the ca, if not you could do it using:
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
...
annotations:
cert-manager.io/inject-ca-from: "<namespace>/<certificate_name>"
I purchased my SSL certificate from GoDaddy.
I made the common name www.mywebsite.com.
In my DNS settings I have the website forwarding from the naked domain to the www.mywebsite.com.
I removed any settings inside Heroku regarding the SSL certificate from the GUI.
Then I went through the instructions here.
To recap, I generated my server.key by first creating the crs files and sending those to GoDaddy.
I purchased the $20/mo endpoint.
GoDaddy gives me a downloadable ZIP for my certificates, one with one certificate, and one with 3 certificates inside of it.
I run the following command to install the bundled version first with the following failing message that follows:
heroku certs:add server.crt server.key --type endpoint
No certificate given is a domain name certificate.
The reason I even tried to use the bundle is that my SSL doesn't work in firefox, and intermediary cert is not being included. After looking around for an answer on this, I couldn't find one.
So to get my website back up and running in the short term, I decided to just do what I did before, and upload the single cert. That works, but not really.
Now I get this message when I run the cUrl test:
* error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
Also, my website is down. :(
How do I fix this?
The answer in my case seems to be that purchasing an SSL cert is not necessary on Heroku. When you purchase a paid hosting package they provide SSL certificates by default without having to buy their SSL add-on endpoint.
There are likely other use-cases for using a paid SSL cert, but in my case I didn't have to do that.
If this answer helped you please upvote this question as some people seem to think it's a question worth down voting.
I'd like to be able to go get from my Stash server with a nice URL. My stash server works only over HTTPS. The problem is that my SSL certificate I'm using with stash is self-signed and any go get to my server gets me the following error:
x509: certificate signed by unknown authority
Is there a way to authorize self-signed certificates from go get?
go get -insecure has been deprecated.
As of go 1.14, the correct way to do this is by setting the GOINSECURE environment variable to a comma-separated list of domains from which you'd like to ignore the certs.
E.g. Setting in within ~/.zshrc (if zsh shell)
GOINSECURE=example.com
Then you will be able to install the packages like:
go get example.com/some/pkg
Use go get -insecure https://xxxxx.
From go get -h:
The -insecure flag permits fetching from repositories and resolving
custom domains using insecure schemes such as HTTP. Use with caution.
On Debian, using GitLab, I ran into issues with my self-signed certificate.
Reading through the code after a lot of searching on the Internet (I guess, it's the last resort, FOSS is helpful), I found the following lines in gitlab-shell/lib/gitlab_net.rb which left me... perplexed.
if config.http_settings['self_signed_cert']
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
Most Stack Overflow responses about the diverse issues I've had until now have led me to believe that VERIFY_NONE, as you'd expect, doesn't verify anything. VERIFY_PEER seems, based on my reading, to be the correct setting for self-signed.
As I read it, it feels like taking steps to secure my connection using a certificate, and then just deciding to not use it? Is it a bug, or am I misreading the source?
gitlab-shell (on the GitLab server) has to communicate to the GitLab instance through an HTTPS or SSH URL API.
If it is a self-signed certificate, it doesn't want any error/warning when trying to access those GitLab URLs, hence the SSL::VERIFY_NONE.
But, that same certificate is also used by clients (outside of the GitLab server), using those same GitLab HTTPS URLs from their browser.
For them, the self-signed certificate is useful, provided they install it in their browser keystore.
For those transactions (clients to GitLab), the certificate will be "verified".
The OP Kheldar point's out in Mislav's post:
OpenSSL expects to find each certificate in a file named by the certificate subject’s hashed name, plus a number extension that starts with 0.
That means you can’t just drop My_Awesome_CA_Cert.pem in the directory and expect it to be picked up automatically.
However, OpenSSL ships with a utility called c_rehash which you can invoke on a directory to have all certificates indexed with appropriately named symlinks.
(See for instance OpenSSL Verify location)
cd /some/where/certs
c_rehash .
I just want to say that this is not normally something I do, but I have been tasked with it recently...
I have followed the heroku documentation for setting up SSL closely, but I am still encountering a problem.
I have added my cert to heroku using the following command:
heroku certs:add path_to_crt path_to_key
This part seems to work. I receive a message saying:
Adding SSL Endpoint to my_app ... done
I have also setup a CNAME for my hosting service to point to the endpoint associated with the cert command above. However, when I browse to the site I still receive a SSL error. It says my certificate isn't trusted and points to the *.heroku.com license, not the one I have just uploaded.
I have noticed that when I execute the following command:
heroku ssl
I receive the following:
my_domain_name has no certificate
My assumption is that there should be a certificate associated with this domain at this point.
Any ideas?
Edit: It appears that I did not wait long enough for the certificate stuff to trickle through the internets... however, my question regarding the "heroku ssl" command still puzzles me.
The Heroku ssl command is for legacy certificates:
$ heroku ssl -h
Usage: heroku ssl
list legacy certificates for an app
The command you need is heroku certs which will output the relevant certificate info for that project.