DNS problem: NXDOMAIN looking up A for www.keligo.com - There is "A" record. Very convoluted, and failed

My domain is: keligo.com

I ran this command: sudo certbot --apache

At the finish of this section, I include a Summary.

12 domains and specific subdomains were included in my certificate application, two of them being keligo.com and www.keligo.com. But alpha.keligo.com (the FQDN of subject IP address; see DNS “A” record below) not included. That, I think is at the heart of the matter.

It produced this output:

  • The following errors were reported by the server:

    Domain: www.keligo.com
    Type: dns
    Detail: DNS problem: NXDOMAIN looking up A for www.keligo.com -
    check that a DNS record exists for this domain.

They A records do exist (registrar GoDaddy)
type name value
A @
A alpha

– IP for webserver:

– Primary domain for Linode web server: packetstacks.com (used to be keligo.com or the FQDN alpha.keligo.com) but changed by ____ when keligo.com was deemed “inactive”.
– DNS records: Just an email address record (ken@keligo.com) and five NS records all to subdomain “packetstacks.com

I verified the folders/files the certificate were written to /etc/letsencrypt . I don’t know how to interpret their meaning, they just look “official”. :slight_smile:

Notwithstanding the problem reported by Certbot, LetsDebug said all domains/subdomains were successful.

ssllabs.com/ssltest](http://ssllabs.com/ssltest) reports this:
*Certificate name mismatch

At the top of the certificate is “alpha” which I take to be the name of the “Certification name mismatch”.

Four possible reasons were offered. Here are two that seem relevant:

  • The website does not use SSL but shares an IP address with some other site that does.
  • The domain name is an alias for a website whose main name is different, but the alias was not included in the certificate by mistake. [That would be alpha.keligo.com, and that would be consistent with the fact that I was never offered alpha.keligo.com to include in the certificate.]

WhyNoPadlock reports this:
Tested URL: https://keligo.com
Your SSL certificate does not match your domain name!
Protected Domains: * No Domains Listed
Again, I verified the folders/files the the certificate were written to /etc/letsencrypt .

None of the domains/subdomains work with https.

Summary: Certbot closes with “DNS problem: NXDOMAIN looking up A for www.keligo.com” and those A records do exist. Certificate folder/files generated and stored at /etc/letsencrypt. LetsDebug says all domains are good, no problems. ssllabs says ‘Certificate name mismatch’. Godaddy DNS records for all domains point to, the IP address for the web server at Linode. Primary domain at Linode server is packetstacks.com, but that website has not yet been developed and therefore not hosted on the webserver. None of the domains work with https, instead display a waring message.

So (1) what went wrong with what should have been the simplest application possible (not --manual), and (2) what to do now? This is definitely not my area of expertise and hoping to see a straightforward solution.

My web server is (include version): CentOS 7

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

My hosting provider, if applicable, is: Linode

I can login to a root shell on my machine (yes or no, or I don’t know): Yes (su and sudo)

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

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

1 Like

The www subdomain has no record.

Compare https://letsdebug.net/www.keligo.com/235620 and https://letsdebug.net/keligo.com/235621, for example.


Well, that is straightforward. THANK YOU FOR THAT. Thought I checked them all with LetsDebug but missed that one. :expressionless:

I added the “CNAME www @” record, easy enough.

What do I do now to get it included? Do I run certbot again from the top? Or do I whack my computer Ike a pinball machine to get every thing to fall into place? Or is there a “retry” mechanism of some sort. (It’s pretty obvious this is the first time I’ve SSL’d my sites, so your help is appreciated.)

1 Like

If you haven’t already issued a certificate, you could try something like:

certbot --apache -d keligo.com -d www.keligo.com

@_az No, he/she wanted a cert with 12 SANs, among those two :wink:

@k44g Just run the same command again and do the same as before. With the www CNAME in place, it should work this time. No need to damage your computer when the solution is so simple.

1 Like

(1) Should I first delete the folder /etc/letsencrypt, i.e., delete my account credentials, before doing the certbot --apache so that certbot doesn’t trip up on the folder already existing? I think that’s tantamount to starting over and getting a new certificate … right?

(2) Can I add more subdomains at this time, by first adding, for “example”, the “CNAME example @” record to the corresponding DNS records?

(3) If so, does that mean I can add wildcards by adding a "CNAME * @"? Is that a legitimate entry? I was wanting to have wildcards for a number of my (second level) domains, but the process didn’t offer the opportunity to specify that, as I thought it would. Had I initially included those “wildcard CNAMEs”, does that mean the process would result in having those wildcard subdomains covered by my certificate?

Thank you so much, Osiris and _az !!

PS: _az, are you an arizona resident? I am.

1 Like

You’ve got the most recent version of certbot. It should recognise the current folder(s) and it shouldn’t generate extra folders.

Sure, Let’s Encrypt certs can contain up to 100 SANs.

You can have a wildcard as a CNAME, yes.

1 Like

In this case I’m afraid _az is named Alex Zorin

rather than being an Arizonan. :slight_smile:

1 Like

In order to trigger that behavior, you just have to make sure that you always ask for the existing names and others, never omitting an existing name. Certbot may then ask you whether to expand the existing certificate by adding on the new names. You can skip that question by adding the option --expand, which is equivalent to answering it with a yes.

Contrary to popular expectation, :crying_cat_face:, --expand has no effect at all if you specified a list of names that isn’t a strict superset of the coverage of a currently-existing certificate.

1 Like

Thanks for the clarification/addendum @schoen :slight_smile:

Luckily, currently @k44g doesn’t actually got any Let’s Encrypt certificate issued (according to crt.sh at least) and therefore there’s no certificate lineage to mess up :wink: Even less reason to delete /etc/letsencrypt! (Why do people always want to delete stuff? :pleading_face:)

1 Like

So I added a few extra domains by making the necessary DNS changes. And also some wildcard subdomains for some of the new ones and some of the existing ones.

Then started certbot. Quickly I was presented with an updated list per domains I added, but no wildcards listed. I think I’m being told that I can’t add wildcard subdomains. So I said to myself, get a life and move on. Figuring if there’s a burning need to have some new subdomains, I’ll just go through this certbot process again, now that I’m an expert at this. :crazy_face: :scream:

I’ll let you know as soon as I have something to say…

1 Like

Well, that took about 18 seconds to go to completion error-free with a Congratulations!

I https-tested most of the sites by just opening them, and all looks good. Well, except for the unexpected results for those sites using the jQuery-mobile platform. The others didn’t use anything except my own CSS or use W3.CSS framework. Looks like jQuery-mobile is biting the dust. I’ve also heard rumblings about unfixable security bugs and some are jumping ship.

Anyway, that makes me stop procrastinating my intent to convert those sites to W3.CSS. So in a weird way, I’m thankful.

I’m especially thankful to y’all for excellent, fast help. I was ready to sacrifice my body to Covid-19 research. But y’all prevented me making the news.


1 Like

So they can start from scratch? :slightly_smiling_face:

DNS wildcards, webserver wildcards and certificate wildcard are three entirely different things.

And learn nothing? Sounds a lot like “rebooting the *nix system” (don’t get me started on Windows…) or even “installing the system from scratch” to me.

All things which aren’t benificial in the process of autodidacticism and therefore aren’t benificial to the user.

1 Like

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