To me, you're talking a lot of gibberish, probably because I lack an understanding of the setup you're talking about. Let's start with the basics, in the form of the questionnaire you should have been presented with (or which you have deleted, either one of those) when opening this thread in the #help section. Please answer all the questions to the best of your knowledge:
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):
Sorry Osiris, I am not getting your point.
The workstation is not in 192.168.x.x , it is in 10.x.x.x series.
What will be the reason that A.example.com is able to retrieve the certificate.
However, B.example.com is unable to get lets encrypt certicate.
The subdomain B.example.com has connected with Ingress-controller.
Issuer Ref:
Name: letsencrypt-prod-mvp-preview2
Secret Name: B.example.com.centralus.cloudapp.azure.com
Status:
Conditions:
Last Transition Time: 2022-09-12T14:18:37Z
Message: Issuing certificate as Secret does not exist
Observed Generation: 1
Reason: DoesNotExist
Status: True
Type: Issuing
Last Transition Time: 2022-09-12T14:18:38Z
Message: Issuing certificate as Secret contains an invalid key-pair: tls: failed to find any PEM data in certificate input
Observed Generation: 2
Reason: InvalidKeyPair
Status: False
Type: Ready
Next Private Key Secret Name: mvp-preview2-idp-ra.centralus.cloudapp.azure.com-6mq88
Events:
k get svc -n ingress-nginx-mvp-preview-2
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller LoadBalancer 10.0.130.70 52.189.31.62 80:30081/TCP,443:31400/TCP 20h
ingress-nginx-controller-admission ClusterIP 10.0.217.214 443/TCP 20h
The questionnaire is usually the starting point of a thread to have the most basic information present to start with, instead of diving deep into very specific details. Having many details without the basics and without any cohesion often makes it difficult to understand the situation for outsiders.
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):
We have mvp-preview-idp-ra.centralus.cloudapp.azure.com, which already have TLS certificate and in the same subnet.
I am not getting why the mvp-preview2-idp-ra.centralus.cloudapp.azure.com, not able to retrieve certificate.
kubectl describe certificate output:
Issuer Ref:
Name: letsencrypt-prod-mvp-preview2
Secret Name: mvp-preview2-idp-ra.centralus.cloudapp.azure.com
Status:
Conditions:
Last Transition Time: 2022-09-12T14:18:37Z
Message: Issuing certificate as Secret does not exist
Observed Generation: 1
Reason: DoesNotExist
Status: True
Type: Issuing
Last Transition Time: 2022-09-12T14:18:38Z
Message: Issuing certificate as Secret contains an invalid key-pair: tls: failed to find any PEM data in certificate input
Observed Generation: 2
Reason: InvalidKeyPair
Status: False
Type: Ready
Next Private Key Secret Name: mvp-preview2-idp-ra.centralus.cloudapp.azure.com-6mq88
Events:
These both subdomains belongs to same aks cluster and isolated with different namespace .
DNS is created with Public IP Address which has IP address provided by DHCP.
And does that DHCP up DNS with updated A and/or AAAA Records when it issues a new IP Address?
And does that propagate all the way out to the Internet visible DNS servers?
And what is the TTL for those DNS Records?
A wildcard cert requires using a DNS Challenge. You said DNS was limited to you so that may not be possible.
But, if you want you could try the cert-manager docs. Kubernetes setups can be very complicated. We can point out some serious problems (like we have) but ultimately you need to understand how to operate your system.
I've been dealing with cert-manager and AKS every day in my job for months now. I'm happy you're trying to help, but if you're not really familiar with this type of setup you will likely cause more harm than good making most recommendations.