Unable to Determine Zone Identifier


#1

Howdy,

First, thanks for making this really convenient software! As a first time webserver admin, it was really great to find a tool that handled cert creation, application, and HTTPS redirection all in one.

I’m working on obtaining a wildcard cert for my new website using certbot. Unfortunately, I keep running into an error pertaining zone identifiers when trying to run the commands provided in the documentation. I believe I’ve set everything else up correctly and it seems not too many other people are running into this issue online. I’ve stored the API key from my hosting provider in a file and permissions on it such that only root has access to it, as recommended in the documentation.

My domain is: tobinsoft.net

I ran this command: sudo certbot -a dns-linode -i apache -d “*.tobinsoft.net” -d tobinsoft.net --server https://acme-v02.api.letsencrypt.org/directory

It produced this output: sudo certbot -a dns-linode -i apache -d “*.tobinsoft.net” -d tobinsoft.net --server https://acme-v02.api.letsencrypt.org/directory --dns-linode-propagation-seconds 1000
[sudo] password for :
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-linode, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for tobinsoft.net
dns-01 challenge for tobinsoft.net
Input the path to your Linode credentials INI file (Enter ‘c’ to cancel): /path/to/key.ini
Starting new HTTPS connection (1): api.linode.com
Starting new HTTPS connection (1): api.linode.com
Cleaning up challenges
Starting new HTTPS connection (1): api.linode.com
Starting new HTTPS connection (1): api.linode.com
Starting new HTTPS connection (1): api.linode.com
Starting new HTTPS connection (1): api.linode.com
Unable to determine zone identifier for tobinsoft.net using zone names: [u’tobinsoft.net’, u’net’]

My web server is (include version): Apache 2.4.6 (CentOS)

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

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

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): 0.30.2

Sorry if I’m missing something silly, and thank you very much for your time.


#2

Your nameservers are hosted by Hover, not Linode:

$ dig +noall +answer tobinsoft.net ns
tobinsoft.net.          892     IN      NS      ns2.hover.com.
tobinsoft.net.          892     IN      NS      ns1.hover.com.

The DNS plugins work on the basis of updating your DNS zone, rather than where your webserver points.

If you’d like to migrate your DNS hosting to Linode (or anywhere else supported by Certbot’s DNS plugins or other DNS clients like acme.sh), what you’re doing might work.


#3

Oh jeez! OK, I started on the process of transferring my nameservers to Linode and will update this ticket when I finish that and try running the command again.


#4

And thanks for the quick reply!


#5

Did you remember to create your DNS zone in the Linode DNS Manager? https://www.linode.com/docs/platform/manager/dns-manager-new-manager/

You’ll need to copy each of your DNS records from Hover to Linode.

From what I can see, you changed your nameservers without bringing the records (the thing Hover was hosting) over.

All this good stuff (but there’s probably more):

tobinsoft.net.          900     IN      A       172.104.219.162
tobinsoft.net.          900     IN      MX      10 mx.hover.com.cust.hostedemail.com.

#6

Hey _az, I’ve reached out to Linode support as the DNS manager doesn’t appear to be available in my interface. When I get those records moved I’ll update this post.

Thanks for following up!


#7

That’s weird. I have multiple Linode accounts and they’ve always had access to DNS hosting.

If you’re using the old-school interface, it’s at https://manager.linode.com/dns
If you’re using the new interface, it’s at https://cloud.linode.com/domains


#8

Hi @lucasbtobin

currently, linode answers with a refused ( https://check-your-website.server-daten.de/?q=tobinsoft.net ).

Host T IP-Address is auth. ∑ Queries ∑ Timeout
tobinsoft.net Refused yes 1 0
www.tobinsoft.net Refused yes 1 0

Looks like the domain is blocked, not activated.

Same with TXT and CAA entries.


#9

OK! So I got access to the DNS Manager panel and moved my DNS hosting, after running the same command again it appears that the wildcard cert is being created and served up by Apache! Unfortunately, this only seems to be working when navigating to the site directly at tobinsoft.net; www.tobinsoft.net appears to be using a self-signed cert from my node.

Figuring I might have needed to expand the certificate to include the www domain, I ran the command with www specified but it appears that with the wildcard specified this is redundant.

The interactive prompt seems to recognized both domains and at least attempted to install it for both:

Which VirtualHosts would you like to install the wildcard certificate for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: File: /etc/httpd/conf.d/vhost-le-ssl.conf
Addresses: *:443
Names: tobinsoft.net, www.tobinsoft.net
HTTPS: Yes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Deploying Certificate to VirtualHost /etc/httpd/conf.d/vhost-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/conf.d/vhost-le-ssl.conf

vhost-le-ssl.conf is formatted thus:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin <my email>
    ServerName tobinsoft.net
    ServerAlias www.tobinsoft.net
    DocumentRoot /var/www/html/tobinsoft.net/public_html/
    ErrorLog /var/www/html/tobinsoft.net/logs/error.log
    CustomLog /var/www/html/tobinsoft.net/logs/access.log combined
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/tobinsoft.net-0001/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/tobinsoft.net-0001/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/tobinsoft.net-0001/chain.pem
</VirtualHost>
</IfModule>

Some googling seems to indicate that SeverName should be www.tobinsoft.net and ServerAlias tobinsoft.net, but I’m not sure if this is relevant.

@JuergenAuer: I ran my site in that website after these adjustments and my score seems to have improved! Not perfect yet of course, but getting there with your folks’ help!


#10

Congrats!

You probably have a default port 443 virtualhost that has ServerAlias www.tobinsoft.net in it. That can happen on some Linux distros.

You can locate it by using:

apachectl -t -D DUMP_VHOSTS

All you’ll need to do is remove that name from the default virtualhost.


#11

Yes, Apache allows for such duplication.
And it runs on a “first come first served” basis; So the default config will come first and be the one served.

The default server name should be something that doesn’t even resolve in Internet DNS.
[and that you would never be getting a cert for]
Like: LOCALHOST

If all else fails, try finding it with:
grep -i 'www.tobinsoft.net' /etc/apache2


#12

Victory!

It appears that since I had set ServerName in httpd.conf to www.tobinsoft.net that’s what it was working off of. After commenting out that directive and re-installing the certs, www.tobinsoft.net is being served up with a hot and fresh wildcard certificate! That’s a bit strange though, as it was specifically entered as www.tobinsoft.net:80

I started with httpd -t -D DUMP_VHOSTS (had to use httpd instead of apachectl for my system) and got the following output:

AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/httpd/conf.d/vhost.conf:1
VirtualHost configuration:
*:443                  is a NameVirtualHost
         default server <default-server>.tobinsoft.net (/etc/httpd/conf.d/ssl.conf:56)
         port 443 namevhost <default-server>.tobinsoft.net (/etc/httpd/conf.d/ssl.conf:56)
         port 443 namevhost tobinsoft.net (/etc/httpd/conf.d/vhost-le-ssl.conf:2)
                 alias www.tobinsoft.net
*:80                   tobinsoft.net (/etc/httpd/conf.d/vhost.conf:3)

Poking around in ssl.conf I found there were actually no references to my domain name at all, and vhost-le-ssl.conf of course was the file we believe was being pre-empted elsewhere.

I started thinking about what else might be pre-empting it and figured I’d try commenting out the ServerName directive which I had set manually after first installing Apache. Lo and behold!

@rg305 I’m not sure how my host was being exposed in the certificate, but it seems that before moving my DNS hosting from Hover to Linode I found I was able to ssh into the server using its hostname on the domain; since then, however, it seems I am only able to do so by IP as I have not made an association between the two in the hosts file of my workstation. Would you still recommend I change its hostname to something like localhost?


#13

Yes, but only in the Apache.conf file (httpd.conf).
[don’t change the actual system name]

But you already removed it altogether:


#14

Ah, I think I get you now. Well super!

Sorry it’s taken so long to get back to you, I spent Friday night obsessed with getting an A rank on that security grading site that @JuergenAuer and got caught up on getting HSTS working on redirects. After abstaining from the matter yesterday, I sat down for five minutes today and had the brain-genius idea of looking up HSTS on this site’s search engine. Thanks to this response by @sahsanu, I determined that all I had to do was add an always to my Header for the redirect. Now I’ve got my A!

Thanks for the help everyone! I’ll be leaving something in the tip jar to be sure! :slight_smile:


#15

Happy to read that the tool is helpful.

And yep, now you have a Grade A.

A+ requires a Google preload entry. But A (+HSTS) requires, that the certificate renew works.

If a site uses HSTS (which is good), users can’t create an exception if the certificate is invalide. So double-check your certificates in 2 months if the renew works.


closed #16

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