DNSKEY Missing; DNS problem on .TOP domain

When i renew the certificate for this domain .TOP in the last days i get a DNSKEY missing error,
but i've not DNSSEC activated, the naming authority support has already reset the DNSSEC parameter, this problem only happens with this domain .TOP extension.
Do not happens with .com .net .org and all other extensions.

I also have this in the bind zone:

jaimeaymerichbrasile.top. CAA 1 issue "letsencrypt.org"

Any help?


My domain is: jaimeaymerichbrasile.top

I ran this command: uacme issue www.jaimeaymerichbrasile.top -h hook_jaimeaymerichbrasile_top.cmd

It produced this output:

uacme: the server reported the following error:
"type": "urn:ietf:params:acme:error:dns",
"detail": "DNS problem: looking up A for www.jaimeaymerichbrasile.top: DNSSEC: DNSKEY Missing; DNS problem: looking up AAAA for www.jaimeaymerichbrasile.top: DNSSEC: DNSKEY Missing",
"status": 400

My web server is (include version): Server Version: Apache/2.4.59 (OS/2) OpenSSL/1.1.1l

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

My hosting provider, if applicable, is: me

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): uacme: version 1.0.19 *

*We tried also Certbot on Ubuntu and give the same error.


I cannot reproduce the A or AAAA record lookup problem. Several DNS tools showed successful queries. Does this problem still occur?

The CAA record for your registered domain has an invalid flag value. But, that would not explain the error you post. Still, you should fix the flag

Your flag value is one: 1 issue "letsencrypt.org"

Should be zero like: 0 issue "letsencrypt.org"



the CAA record now should be OK
thank you

now the issue about DNSSEC/DNSKEY is over, the certificate has been renewed correctly

thank you a lot
you can close the ticket



Yes, you got a new cert but there are significant problems with your Apache config certificate settings.

HTTPS requests to your root name jaimeaymerichbrasile.top use an incorrect "leaf" cert. The cert it uses only has your www subdomain in it so these HTTPS requests fail.

More importantly HTTPS requests to your www subdomain use the wrong intermediate chain. Let's Encrypt has recently switched the intermediates to R10 or R11 (with others possible). But, you are using an older R3 intermediate.

You likely hard-coded this intermediate somehow. You need to change this so you use the chain provided by Let's Encrypt for the specific cert you got for your domain (the "leaf"). Usually for Apache that is just the "fullchain.pem" file.

For help fixing your Apache please show output of this:

sudo apache2ctl -t -D DUMP_VHOSTS

Here is what you are sending out now (see the R3 intermediate)

openssl s_client -connect www.jaimeaymerichbrasile.top:443
depth=0 CN = www.jaimeaymerichbrasile.top
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = www.jaimeaymerichbrasile.top
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = www.jaimeaymerichbrasile.top
verify return:1
Certificate chain
 0 s:CN = www.jaimeaymerichbrasile.top
   i:C = US, O = Let's Encrypt, CN = R11
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 16 09:19:22 2024 GMT; NotAfter: Sep 14 09:19:21 2024 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT


SSLCertificateFile /etc/ssl/uacme/www.jaimeaymerichbrasile.top/cert.pem
SSLCertificateKeyFile /etc/ssl/uacme/private/www.jaimeaymerichbrasile.top/key.pem
SSLCertificateChainFile /etc/ssl/uacme/ca/ca.pem

now i use this chain certificate:


please check it now
or you can try this other domain on the same server: https://www.ecomstation.it/
that i've renewed right now

i've tried to reissue the certificate for the domain and now it give again the issue of the DNS KEY missing (so i had to copy the cert.pem and the private key renewed yesterday)

thank you so much


1 Like

You should not use a "hard coded" chain. You must use the one given to your ACME Client by the Let's Encrypt ACME Server.

You can test your Apache certs yourself using any number of tools. I like this one below. It shows your chain is not correct.


As said, you should use the chain provided by the API. Not hardcode it.

Also, why would you choose R14? Seems kinda random? That intermediate is not even used currently, but is a backup. But I guess it doesn't matter, as you shouldn't hardcode it anyway. Doesn't uacme provide the chain with the cert?


I don't understand, sorry, this is the setup i use since a number of years.
(in the past i was using other kind of certificates (not LE), i recall this was needed)

So should i remove the chain certificate in apache httpd.conf?

SSLCertificateChainFile /etc/ssl/uacme/ca/ca.pem


1 Like

@massimo12 that does not mean it was totally correct, however it was stable.
But things changed in June 2024 see: Chains of Trust - Let's Encrypt

Edit: and Deploying Let's Encrypt's New Issuance Chains - #4 by mcpherrinm

1 Like

"When an ACME client downloads a newly-issued certificate from Let’s Encrypt’s ACME API, that certificate comes as part of a “chain” that also includes one or more intermediates."

ok, thank you


You should configure the chain provided by uacme that came with the cert (which CANNOT be R14 as R14 currently has not issued any cert) when it was issued. NOT a chain manually downloaded from some semi-random location.

1 Like

Do you have a link to the documentation for uacme - your ACME Client?

Googling shows various results so I can't guess how it works. I have never seen uacme before. If you show us the docs we might be able to give you the specific instructions you need.

You said Certbot on Ubuntu failed. That was probably because you did not use the correct, current, intermediate. With that system, your Apache SSL statements would look something like

SSLCertificateFile    /etc/letsencrypt/live/(domain)/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/(domain)/privkey.pem

You don't need the ChainFile statement on modern Apache systems if your ACME client provides a "fullchain" file


I believe this is the best information for uacme

And the regular unix man pages in HTML


i've removed the chain certificate, maybe it was needed years ago for Comodo certs, i don't recall, sorry

Uacme client docs:


anyway i've removed in all vhosts the chain certificate file entry

SSLCertificateChainFile /etc/ssl/uacme/ca/ca.pem

i've also reissued some certs and it works
even the check with SSL checker website is OK now



1 Like

i've removed the chain cert file entry in apache httpd.conf for the .top domain
i've renewed the certificate and it seems to work well
no dnskey issue



1 Like

Yes, the cert for www subdomain looks good and verifies correctly.

But, there is still a problem with your Apache config with its certs. It is possible it has been wrong for a very long time.

You redirect HTTP requests for your base name to your www subdomain as HTTPS. This is fine and the HTTPS request works.

curl -I http://jaimeaymerichbrasile.top
HTTP/1.1 302 Found
Server: Apache/2.4.59 (OS/2) OpenSSL/1.1.1l
Location: https://www.jaimeaymerichbrasile.top/

But if someone were to use HTTPS for your base name it will fail as you do not have a certificate that includes the base name. Your cert is only for the www subdomain.

curl -I https://jaimeaymerichbrasile.top
curl: (60) SSL: no alternative certificate subject name matches target host name
More details here: https://curl.se/docs/sslcerts.html

Do you want help fixing that?


The uacme docs do not explicitly say but its "cert" file includes the leaf and default chain provided by Let's Encrypt. This is what Certbot and some other clients call the "fullchain" file.

The uacme author describes this in a github query: chain and fullchain.pem · Issue #54 · ndilieto/uacme · GitHub

So, removing the Apache SSLCertificateChainFile was the proper action. I don't know how uacme would have provided for older Apache versions which required that ChainFile but that's not an issue here :slight_smile:


The OP might also what to use the Staging Environment - Let's Encrypt during debugging

to avoid

1 Like

Sure with proper precautions. The uacme staging support looks like it would put the staging cert in the same place as any prior production cert.

If you happen to reload Apache after that all requests will fail as Staging certs are not valid for production use.

Hopefully you could re-issue a production cert right away. If, for example, you had already gotten your weekly limit you may not be able to issue another right away. So, lots of caution is warranted.


" But if someone were to use HTTPS for your base name it will fail as you do not have a certificate that includes the base name. Your cert is only for the www subdomain."


yes, thanks
but i could request a cert for jaimeaymerichbrasile.top and one for the 3rd level "www."
am i right?
or there is another way?