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
Related
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 trying to configure tls for my Kubernetes cluster using cert-manager and lets encrypt but seems to be running into a problem that I cannot seem to resolve.
I have installed cert-manager using the following command
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.1/cert-manager.yaml
And have configured cluster issuer with the yaml file below
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
namespace: tardis
spec:
acme:
# The ACME server URL
server: https://acme-v02.api.letsencrypt.org/directory
# Email address used for ACME registration
email: adamlee#tardistechnology.com
# Name of a secret used to store the ACME account private key
privateKeySecretRef:
name: letsencrypt-prod
# Enable the HTTP-01 challenge provider
solvers:
- http01:
ingress:
class: nginx
And I have tried issuing a certificate with the yaml file below
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: home.tardis.kr
namespace: tardis
spec:
secretName: home.tardis.kr-tls
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
commonName: home.tardis.kr
dnsNames:
- home.tardis.kr
However, when I get the status of the certificate, it seems to be 'False' and the status seems to be 'Issuing certificate as Secret does not exist'
Some of the solutions that I have found seems to indicate that this is due to the fact that the fact that the domain listed on the ingress is not connected properly, but this does not seem to be the case for me, and the domain seems to be connected fine.
It would be deeply appreciated if anyone could provide any feedback on this matter.
Thank you in advance!
I was applying certificate instead of secret. I changed the ingress so that it will apply the secret and the problem was solved
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.
I am experiencing a rather weird issue and have been stuck on this for 2 days. I have a kubernetes cluster running nginx-ingress and cert-manager. Everything seems to be working fine though when visiting my website through HTTPS, it gives the following error (in chromium edge):
NET::ERR_CERT_AUTHORITY_INVALID
If I continue anyways, it loads the site normally but without the certificate.
The certificate is properly being given, secret created, no errors anywhere.
I have the following annotations in my ingress resource:
kubernetes.io/ingress.class: "nginx"
kubernetes.io/tls-acme: "true"
cert-manager.io/cluster-issuer: "letsencrypt-production"
ingress.kubernetes.io/ssl-redirect: "true"
My cluster issuer:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-production
spec:
acme:
# The ACME production api URL
server: https://acme-staging-v02.api.letsencrypt.org/directory
# Email address used for ACME registration
email: *********
# Name of a secret used to store the ACME account private key
privateKeySecretRef:
name: letsencrypt-production
# Enable the HTTP-01 challenge provider
solvers:
- http01:
ingress:
class: nginx
The certificate resource returns:
Normal Issuing 108s cert-manager The certificate has been successfully issued
I am relatively new to kubernetes so let me know if there are any other debugging steps I can take.
You are using acme staging server: https://acme-staging-v02.api.letsencrypt.org/directory server which does not provide valid certificate.
To get valid certificate you have to use acme production server server: https://acme-v02.api.letsencrypt.org/directory.
you can try this.
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-production
spec:
acme:
# The ACME production api URL
server: https://acme-v02.api.letsencrypt.org/directory
# Email address used for ACME registration
email: *********
# Name of a secret used to store the ACME account private key
privateKeySecretRef:
name: letsencrypt-production
# Enable the HTTP-01 challenge provider
solvers:
- http01:
ingress:
class: nginx
I Created two files, one is for ClusterIssuer and the Second is for Certificate.
My Domain is an example.com and I need to create a new subdomain with wildcard *.testing.example.com and I already created an entry in Route53 called *.testing.example.com with A record and mapped with nlb.
Below are my profile and which good to me, but I am getting error " msg"="propagation check failed" "error"="DNS record for \"testing.example.com\" not yet propagated"
ClusterIssuer.yaml
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
# The ACME server URL
server: https://acme-v02.api.letsencrypt.org/directory
# Email address used for ACME registration
email: devops#example.com
privateKeySecretRef:
name: letsencrypt-prod
solvers:
# example: cross-account zone management for example.com
# this solver uses ambient credentials (i.e. inferred from the environment or EC2 Metadata Service)
# to assume a role in a different account
- selector:
dnsZones:
- "example.com"
dns01:
route53:
region: ap-south-1
hostedZoneID: 71MYVttggee
role: arn:aws:iam::123456:role/dns-manager
Certificate.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: example-cert
spec:
secretName: acme-crt
issuerRef:
kind: ClusterIssuer
name: letsencrypt-prod
commonName: testing.example.com
dnsNames:
- '*.testing.example.com'
acme:
config:
- dns01:
provider: route53
domains:
- '*.testing.example.com'
What you have is correct, you just need to wait for DNS propagation so that the verification records can be checked by LetsEncrypt.
You have to use the method of DNS-01 for verification auth.
You can use the issuer
https://cert-manager.io/docs/configuration/acme/dns01/
however, you also have to create one another YAML for certificate
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: le-crt
spec:
secretName: tls-secret
issuerRef:
kind: Issuer
name: letsencrypt-prod
commonName: "*.example.in"
dnsNames:
- "*.example.in"
above yaml certificate will point to issuer that you created and as you get the certificate it will be get stored into the kubernetes secret name as : tls-secret
You can inject or use this secret on the ingress.
Also if you are facing the 403 error of CAA record please add the CAA record in the DNS zone first same we add the A or CNAME record.
For more ref : https://stackoverflow.com/a/68476135/5525824