Certificate.yaml not creating a cert in the tls secret

Help
1

It's time to renew certs and I'm trying to generate new certificates through applying yaml files on my kubernetes cluster.

I've removed the old secret containing the expired cert and by updating the clusterissuer.yml and certificate.yml I hope to automatically generate a new.

Here's my config files

clusterissuer.yml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-dev
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: my@email.com
privateKeySecretRef:
name: letsencrypt-dev
solvers:
- http01:
ingress:
class: nginx
podTemplate:
spec:
nodeSelector:
"kubernetes.io/os": linux

certificate.yml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: epic-tls
namespace: default
spec:
secretName: epic-tls
issuerRef:
name: letsencrypt-dev
kind: ClusterIssuer
dnsNames:
- "subdomain.website.com"
- "subdomain2.website.com"

When I apply the certificate.yml file it creates a secret but there is only a pem key in the secret data and not a certificate.

2

@griffin I seem to remember something about you working with the terrible thing called kubernetes, does this stuff ring any bell to you? It totally makes no sense to me :roll_eyes:

3 Likes
3

@markehler,
Does this relate to your previous Help Topic?

Here is a list of issued certificates for that (those) domain names crt.sh | northviewweather.com.
I am not sure which one it's time to renew.

1 Like
4

@Bruce5051
This is a different domain. I'm on hold for that other ticket till I can resolve this.

1 Like
5

Hi @markehler,

It looks like you have information that you cannot share, that is :ok:!

But, please fill out the fields below that you can share so we can help you better.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Thank you for assisting us in helping YOU!

1 Like
6

My domain is:

I ran this command:
kubectl apply -f clusterissuer
kubectl apply -certificate

My web server is (include version):
chrome lastest stable, firefox latest stable
The operating system my web server runs on is (include version):
Ubuntu 20
My hosting provider, if applicable, is:
godaddy
I can login to a root shell on my machine (yes or no, or I don't know):yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): cert manager 1.0.4

Here's what I get get i run kubectl describe certificate:
Name: epic-tls
Namespace: default
Labels:
Annotations:
API Version: cert-manager.io/v1
Kind: Certificate
Metadata:
Creation Timestamp: 2023-02-14T20:51:43Z
Generation: 1
Managed Fields:
API Version: cert-manager.io/v1
Fields Type: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.:
f:kubectl.kubernetes.io/last-applied-configuration:
f:spec:
.:
f:dnsNames:
f:issuerRef:
.:
f:kind:
f:name:
f:secretName:
Manager: kubectl-client-side-apply
Operation: Update
Time: 2023-02-14T20:51:43Z
API Version: cert-manager.io/v1
Fields Type: FieldsV1
fieldsV1:
f:status:
.:
f:conditions:
f:nextPrivateKeySecretName:
Manager: controller
Operation: Update
Time: 2023-02-14T20:51:44Z
Resource Version: 72393485
UID: 6771c762-f833-42e7-bcbb-ffcff470ee49
Spec:
Dns Names:
epicdev.backend.disastertech.com
epic.dev.disastertech.com
Issuer Ref:
Kind: ClusterIssuer
Name: letsencrypt-dev
Secret Name: epic-tls
Status:
Conditions:
Last Transition Time: 2023-02-14T20:51:43Z
Message: Issuing certificate as Secret does not exist
Observed Generation: 1
Reason: DoesNotExist
Status: False
Type: Ready
Last Transition Time: 2023-02-14T20:51:44Z
Message: Issuing certificate as Secret does not exist
Observed Generation: 1
Reason: DoesNotExist
Status: True
Type: Issuing
Next Private Key Secret Name: epic-tls-7vgdc
Events:
Type Reason Age From Message

Normal Issuing 3m51s cert-manager Issuing certificate as Secret does not exist
Normal Generated 3m51s cert-manager Stored new private key in temporary Secret resource "epic-tls-7vgdc"
Normal Requested 3m51s cert-manager Created new CertificateRequest resource "epic-tls-sqjtc"

1 Like
7

See also my ingress yaml file
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: epic-ingress
namespace: default
annotations:
cert-manager.io/cluster-issuer: letsencrypt-dev
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/proxy-body-size: "500m"
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
tls:

1 Like
8

I know nothing of those commands nor the order they creating the tls secret.

Using the online tool https://unboundtest.com/ to check the DNS CAA record results https://unboundtest.com/m/CAA/disastertech.com/EUFV5YLG show

Query results for CAA disastertech.com

Response:
;; opcode: QUERY, status: NOERROR, id: 38867
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;disastertech.com.	IN	 CAA

;; ANSWER SECTION:
disastertech.com.	0	IN	CAA	0 issue "digicert.com"
disastertech.com.	0	IN	CAA	0 issue "pki.goog"

----- Unbound logs -----
Feb 14 20:59:39 unbound[308824:0] notice: init module 0: validator
Feb 14 20:59:39 unbound[308824:0] notice: init module 1: iterator
Feb 14 20:59:39 unbound[308824:0] info: start of service (unbound 1.16.3).

However Let's Debug is showing CAAIssuanceNotAllowed Fatal https://letsdebug.net/disastertech.com/1374241
Saying:
No CAA record on disastertech.com (wildcard=false) contains the issuance domain "letsencrypt.org". You must either add an additional record to include "letsencrypt.org" or remove every existing CAA record. A list of the CAA records are provided in the details.
disastertech.com. 0 IN CAA 0 issue "pki.goog"
disastertech.com. 0 IN CAA 0 issue "digicert.com"

All in all Let's Encrypt is not going to be allowed to issue Certificates with those DNS CAA records.

3 Likes
9

Okay, great. I've added a similar CAA record for letsencrypt.org. Thanks for sharing those links. I'll redeploy and let you know if it's fixed.

3 Likes
10

And here Certificate Authority Authorization (CAA) - Let's Encrypt more documentation.

1 Like
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.