Hello I am using Helm Chart to issue cert-manager CLusterIssuer
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-cluster-issuer
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: {{ .Values.email }}
privateKeySecretRef:
name: letsencrypt-cluster-issuer-key
solvers:
- http01:
ingress:
class: nginx
however I am not using any Cloud DNS, but using Hover.com as my domain delegation, how can I solve the certificate from hover?
http01 does not require any interaction with the DNS provider from cert-manager. That is only needed for dns01 validations.
Related
I have a question about deploying a clusterIssuer with an acmedns api without an /update endpoint. The reason is that our company uses the acmedns/register for only generating the fullname for the CNAME(TXT) record, which is then written manually to the DNS server. So I noticed that when having this ClusterIssuer:
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-staging namespace: cert-manager spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: mail#company privateKeySecretRef: name: letsencrypt-staging solvers: - dns01: acmeDNS: host: https://acmedns.company.com accountSecretRef: name: acme-dns key: api-token # acme.json doesn't work as well cnameStrategy: Follow
the /update is called and the challenge gets only 401 answer, so the order doesn't get fullfilled.
Is there a way for achieving DNS01 with letsencrypt (http01 isn't working at our company) with this kind of acmedns setup? Achieving this with certbot is no problem.
Thanks a lot!
jim
I'm trying to achieve the same functionality offered by the --must-staple parameter of certbot, in a Kubernetes context (with nginx ingress and cert-manager). Is there any parameter in cert-manager, so generated Let's Encrypt certificates include the OCSP Must-Staple extension?
My current ClusterIssue config, which is where the parameter should be placed (I guess)
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-production
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: xxxxxx#xxxxxx.com
privateKeySecretRef:
name: letsencrypt-production
solvers:
- http01:
ingress:
class: nginx
I am setting up my first K8s cluster in Linode LKE and I have problem getting a trusted certificate from Lets Encrypt. firefox shows unsecure connection with certificate name "Kubernetes Ingress Controller Fake Certificate".
I can't figure out what is missing and how can I troubleshoot this.
Here is my ClusterIssuer and Ingress definitions. I tried the staging and the production acme urls but I couldn't get a trusted certificate.
`
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
email: example#gmail.com
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Secret resource that will be used to store the account's private key.
name: letsencrypt-staging
# Add a single challenge solver, HTTP01 using nginx
solvers:
- http01:
ingress:
class: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tb-https-loadbalancer
namespace: thingsboard
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
ingressClassName: nginx
tls:
- hosts:
- testing.com
secretName: letsencrypt-staging
rules:
- host: testing.com
http:
paths:
...
I would like to deploy the kube-prometheus-stack helm chart on a GKE cluster using the following values:
grafana:
ingress:
enabled: true
hosts:
- grafana.example.com
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-issuer"
acme.cert-manager.io/http01-edit-in-place: true
tls:
- secretName: "tls-grafana"
hosts:
- grafana.example.com
The following is the ClusterIssuer used for cert-manager:
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-issuer
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: changeme#gmail.com
privateKeySecretRef:
name: letsencrypt-secret
solvers:
- http01:
ingress:
class: nginx
The grafana ingress is created by no IP address is assigned to it by GCP.
Any suggestions?
Thanks
The ClusterIssuer has no bearing on whether the Grafana ingress is created or not. If your ingress is not getting an IP, you have no ingress controller configured on your cluster.
Alternatively do a kubectl describe on the ingress and look at the events section at the bottom of the output. Sometimes, there will be messages there that might tell you where you need to look.
I followed this instruction to set up a cert manager on my EKS cluster https://cert-manager.io/docs/tutorials/acme/ingress/.
here is my ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test
annotations:
kubernetes.io/ingress.class: "nginx"
cert-manager.io/issuer: "letsencrypt-staging"
spec:
tls:
- hosts:
- '*.test.com'
secretName: test-tls
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: test-service
port:
number: 80
Here is the issuer. I just copied the config from the instruction
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-staging
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
email: info#test.com
privateKeySecretRef:
name: letsencrypt-staging
solvers:
- http01:
ingress:
class: nginx
After deployment, I found the certificate ready state is false
kubectl get certificate
NAME READY SECRET AGE
test-tls False test-tls 2m45s
Then I followed this to troubleshoot https://cert-manager.io/docs/faq/troubleshooting/
I ran kubectl describe certificaterequest <request name>, found error Waiting on certificate issuance from order test-tls-xxx: "pending"
then ran kubectl describe order test-tls-xxx, found error
Warning Solver 20m cert-manager Failed to determine a valid solver configuration for the set of domains on the Order: no configured challenge solvers can be used for this challenge.
Any idea why it couldn't determine a valid solver? how do I test if solver is working?
It's not working due you are using the staging URL in cluster issuer to verify the image.
Please try with the Production URL.
here a simple and proper example of Clusterissuer and ingress YAML (do note you were trying with staging API https://acme-staging-v02.api.letsencrypt.org/directory if possible use the production server address so it works properly with all browsers)
Example:
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: cluster-issuer-name
namespace: development
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: harsh#example.com
privateKeySecretRef:
name: secret-name
solvers:
- http01:
ingress:
class: nginx-class-name
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx-class-name
cert-manager.io/cluster-issuer: cluster-issuer-name
nginx.ingress.kubernetes.io/rewrite-target: /
name: example-ingress
spec:
rules:
- host: sub.example.com
http:
paths:
- path: /api
backend:
serviceName: service-name
servicePort: 80
tls:
- hosts:
- sub.example.com
secretName: secret-name
Note : When you are trying again please try deleting the old objects like ingress, Clusterissuer first.
Issuer vs ClusterIssuer
An Issuer is a namespaced resource, and it is not possible to issue
certificates from an Issuer in a different namespace. This means you
will need to create an Issuer in each namespace you wish to obtain
Certificates in.
If you want to create a single Issuer that can be consumed in multiple
namespaces, you should consider creating a ClusterIssuer resource.
This is almost identical to the Issuer resource, however is
non-namespaced so it can be used to issue Certificates across all
namespaces.
Ref : https://cert-manager.io/docs/concepts/issuer/
Wildcard cert
You can use as per requirement, if you are using issuer you can update the ingress annotation line like
cert-manager.io/issuer: issuer-name
If you are trying to get the wildcard * certificate you won't be able to get it using HTTP auth method
solvers:
- http01:
ingress:
class: nginx-class-name
instead of this you have to use the DNS-auth method for wildcard cert.
solvers:
- dns01:
cloudDNS:
project: my-project
serviceAccountSecretRef:
name: prod-clouddns-svc-acct-secret
key: service-account.json
Read more at : https://cert-manager.io/docs/configuration/acme/dns01/
Ref article to get the wildcard cert : https://medium.com/#harsh.manvar111/wild-card-certificate-using-cert-manager-in-kubernetes-3406b042d5a2