Wildcard Certificate is issued. But APP URL is not secure. (fake certificate)

Help
1

Hi Team,
I successfully created dns01 cluster issuer and certificate for wildcard domain.
But when I create Ingress Route for application , the URL showing not secure.(Generated Fake certificate).
P.S. if I create certificate with http01, it is working. But for long domains it is failing. it has 64 character limit. Because of that I want to use dns01 wildcard certificate .

Below you can find 3 object:

  1. CLUSTER ISSUER
    apiVersion: v1
    items:
  • apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
    annotations:
    name: letsencrypt-prod
    spec:
    acme:
    email: devops@xmail.com
    preferredChain: ""
    privateKeySecretRef:
    name: letsencrypt-secret
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
    ingress:
    class: nginx
    - dns01:
    azureDNS:
    clientID: b8dadb94-1af9-4f74-a60c-daaac7b24e16
    clientSecretSecretRef:
    key: client-secret
    name: azuredns-config
    hostedZoneName: mainapp.rick.ext-env.xyz.org
    resourceGroupName: aktenbewertung
    subscriptionID: 772c3f08-fdd6-4a43-9066-2443177e3ef4
    tenantID: ecd106db-905e-428b-a596-a35a36d07bb0
    status:
    acme:
    lastRegisteredEmail: devops@xmail.com
    uri: https://acme-v02.api.letsencrypt.org/acme/acct/808517377
    conditions:
    • lastTransitionTime: "2022-11-04T11:38:12Z"
      message: The ACME account was registered with the ACME server
      observedGeneration: 8
      reason: ACMEAccountRegistered
      status: "True"
      type: Ready
      kind: List
      metadata:
      resourceVersion: ""
      ============================================
  1. CERTIFICATE
    kubectl get certificate wildcard-tls -o yaml
    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
    annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
    {"apiVersion":"cert-manager.io/v1","kind":"Certificate","metadata":{"annotations":{},"name":"wildcard-tls","namespace":"default"},"spec":{"dnsNames":["*.mainapp.rick.ext-env.xyz.org"],"issuerRef":{"group":"cert-manager.io","kind":"ClusterIssuer","name":"letsencrypt-prod"},"secretName":"wildcards-tls"}}
    creationTimestamp: "2023-01-15T18:25:14Z"
    generation: 1
    name: wildcard-tls
    namespace: default
    resourceVersion: "103945341"
    uid: 2e697591-5f83-4141-aad2-9c0a98b818ba
    spec:
    dnsNames:
  • '*.mainapp.rick.ext-env.xyz.org'
    issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: letsencrypt-prod
    secretName: wildcards-tls
    status:
    conditions:
  • lastTransitionTime: "2023-01-15T18:26:22Z"
    message: Certificate is up to date and has not expired
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: Ready
    notAfter: "2023-04-15T17:26:20Z"
    notBefore: "2023-01-15T17:26:21Z"
    renewalTime: "2023-03-16T17:26:20Z"
    revision: 1
    =======================================
  1. INGRESS
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
    annotations:
    certmanager.k8s.io/acme-challenge-type: dns01
    certmanager.k8s.io/acme-dns01-provider: azuredns
    certmanager.k8s.io/issuer: letsencrypt-prod
    name: test-wildcard-ingress
    namespace: default
    spec:
    ingressClassName: nginx
    rules:

I tested by removing below parameters from Ingress. But no luck:
certmanager.k8s.io/acme-challenge-type: dns01
certmanager.k8s.io/acme-dns01-provider: azuredns
certmanager.k8s.io/issuer: letsencrypt-prod

2

Hello @jet, welcome to the Let's Encrypt community. :slightly_smiling_face:

From here Domain Name System - Wikipedia
" A label may contain zero to 63 characters. The null label, of length zero, is reserved for the root zone. The full domain name may not exceed the length of 253 characters in its textual representation.[22] In the internal binary representation of the DNS the maximum length requires 255 octets of storage, as it also stores the length of the name."

2 Likes
3

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

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!

2 Likes
4

Hi Bruce,
Thanks for clarification. As I mentioned ,due to that limit, I want to use dns01. The wildcard certificate is issued for *.mainapp.rick.ext-env.xyz.org. But app endpoint is still not secure: wildcerttest.mainapp.rick.ext-env.xyz.org

3 Likes
5

There have been no (production) certificates issued for that domain. So either you aren't giving us your real domain name (and as Bruce says above, that is required in order for us to help you), or you've issued certs through the staging server rather than production.

4 Likes
6

You might have more luck asking about this on the cert-manager Slack Channel. We haven't had many (or any) users able to answer this type of question in the past.

5 Likes
7

I do not believe the endpoint is visible to the publicly viewable Internet.
Using this online tool https://check-host.net/ nobody from around the world can find an IP Address for the endpoint Permanent link to this check report nor able to connect via http Permanent link to this check report

$ nslookup wildcerttest.mainapp.rick.ext-env.xyz.org
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find wildcerttest.mainapp.rick.ext-env.xyz.org: NXDOMAIN
2 Likes
8

Using this online tool https://dnsspy.io/ doesn't show much for DNS Records DNS Spy report for xyz.org

DNS records: 100%

Our scans detected the following publicly available DNS records.
	Record 	TTL 	Value
A 	xyz.org 	600s 	34.102.136.180
NS 	xyz.org 	1h 	ns15.domaincontrol.com.
ns16.domaincontrol.com.
SOA 	xyz.org 	1h 	ns15.domaincontrol.com. dns.jomax.net. 2021110500 28800 7200 604800 600
CNAME 	www.xyz.org 	1h 	xyz.org.

Using this online tool https://www.hardenize.com/ also doesn't show much for DNS Records Hardenize Report: xyz.org

DNS Records

Correctly functioning name servers are necessary to hold and distribute information that's necessary for your domain name to operate correctly. Examples include converting names to IP addresses, determining where email should go, and so on. More recently, the DNS is being used to communicate email and other security policies.
Test passed
Everything seems to be well configured. Well done.
DNS Records

These are the results of individual DNS queries against your nameserver for common resource record types.
Name 	TTL 	Type 	Data
xyz.org.     	600 	A 	34.102.136.180            
www.xyz.org.     	3600 	CNAME 	xyz.org.            
xyz.org.     	3600 	NS 	ns15.domaincontrol.com.            
xyz.org.     	3600 	NS 	ns16.domaincontrol.com.            
xyz.org.     	3600 	SOA 	ns15.domaincontrol.com. dns.jomax.net. 2021110500 28800 7200 604800 600
2 Likes
9

Also I do not believe you actually have control over the domain xyz.org
Which from LET’S ENCRYPT SUBSCRIBER AGREEMENT Version 1.3 September 21, 2022
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf Section 3.1

You warrant to ISRG and the public-at-large that You are the legitimate registrant of the
Internet domain name that is, or is going to be, the subject of Your Certificate, or that You are
the duly authorized agent of such registrant

Plus a lot more.

image
image1067×859 22.1 KB

2 Likes
10

But you are presently not near the limit.

$ echo wildcerttest.mainapp.rick.ext-env.xyz.org | wc
       1       1      42
2 Likes
11

For future reference, I can answer this type of topic now as I have been using cert-manager with k8s and ingress-nginx in Azure in my position at work for a while now. :wink:

4 Likes
12

I suggest following a tutorial like this one:

The primary path is to deploy cert-manager (I use a ClusterIssuer to save myself some headache with namespace issues), deploy your ingress controller, then deploy your ingress manifest (endpoints). You do NOT need to create a certificate resource yourself.

5 Likes
13

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