No RRSIG correctly signed the SOA RRset

Bonjour,

Après avoir constaté un problème lors du renouvellement de certificats SLL avec Let’s Encrypt, je me suis rendu compte que j’avais un bug incompréhensible avec DNSSEC (qui fait planter le challenge de let's encrypt).

Ce bug n’apparaît que sur une poignée de noms de domaine (3 sur 22).

Les erreurs semblent indiquer une incohérence de signature au niveau du SOA, mais que clairement, je ne comprends pas :

"Une erreur 'Bogus DNSSEC signature' a été obtenue en essayant de vérifier l'ensemble des enregistrements de type "SOA" avec la signature 36504."
"Aucune signature correcte ne signe l'ensemble des enregistrements de type "SOA"."
"Le serveur de noms ns1.une-issue.com/62.210.206.23 répond avec une signature (RRSIG) qui ne peut pas être vérifiée avec la clé (DNSKEY) de tag 36504 correspondante."
"Le serveur de noms nssec.online.net/62.210.16.8 répond avec une signature (RRSIG) qui ne peut pas être vérifiée avec la clé (DNSKEY) de tag 36504 correspondante."

À court d’idées, sur un domaine non critique, j’ai même supprimer les clés DNSSEC de ma zone, le DS Record chez mon registrar, supprimé le domaine sur mon service de DNS Slave, vérifier le fichier zone (qui ne présente pas d’erreur, est très banale et est identique à d’autres domaines non problématiques), remis mon slave, recréé mes clés DNSSEC et remis mes clés DS chez mon registrar (sans oublier de redémarrer bind quand nécessaire).

Le truc bizarre, c’est qu’à la suite de cette procédure, le problème semble réglé pendant quelques minutes, j’arrive sans problème à recréer mes certificats SSL et les outils de diagnostics ne me sortent aucune erreur.

Puis, de nouveau la même erreur, comme si quelque chose se passait mal au niveau de la propagation (ou alors, lors de la tentative de création d’un nouveau certificat SSL ?).

Bref, je sais que ce problème ne provient pas de Let's Encrypt (c'est juste lui qui m'en a informé), mais si quelqu'un à une idée de ce qui provoque ce problème, je suis preneur !

• Résultats DNSViz : mrsoul.org | DNSViz
• Résultats ZoneMaster : Zonemaster
• Résultats Let's Debug (http-01) : Let's Debug
• Résultats Let's Debug (dns-01) : Let's Debug

62.210.206.23 mrsoul.org (domain)
62.210.206.23 ns1.une-issue.com (primary DNS)
62.210.16.8 nssec.online.net (slave DNS)

Debian Stretch 9.13 / Webmin 1.973 / Usermin 1.823 / Virtualmin 6.15 / Certbot 0.28.0 / Bind 9.10

1 Like

Hi @MrSoul

checking your zone manual - the SOA RRSIG is wrong.

It's curious, see the DNSViz result, see "check your website" you have used - https://check-your-website.server-daten.de/?q=mrsoul.org

DS and your DNSKEYs are ok. Checking your DNSKEY the RRSIG has the correct signature. So a correct chain of trust is created.

But doing the same (manual, not implemented in "check-your-website") with your SOA, the validation fails.

Why?

Looks like your SOA RRSIG isn't updated if the Serialnumber has changed. But that's only a speculation.

2 Likes

Effectivement, je pense que c’est un bug de Virtualmin !

Prenons l’exemple de mrsoul.org, quand je créer son certificat SSL, pas de problème, ça fonctionne.

Mais dès que je veux créer le certificat d’un sous serveur (par exemple blog.mrsoul.org), déjà, le certificat refuse de se générer, indiquant l’erreur au niveau du SOA, qu’on retrouve logiquement sur mrsoul.org.

Pour corriger le problème, je suis obligé de resigner la zone manuellement.

Du coup, j’imagine que dans le script virtualmin, quand je tente de créer un sous-domaine, il inscrit la clé de challenge pour la zone, mais ne resigne pas celle-ci avant de lancer le challenge, ce qui mène à l’erreur.

Merci de m’avoir aiguillé, je vais tenter de faire un post sur le forum de virtualmin pour signaler le bug.


Indeed, I think it's a Virtualmin bug!

Let's take the example of mrsoul.org, when I create its SSL certificate, no problem, it works.

But as soon as I want to create the certificate of a sub-server (for example blog.mrsoul.org), the certificate refuses to be generated, indicating the error at the SOA level, which is also logically found on mrsoul.org.

To correct the problem, I have to resign the zone manually.

I guess that in the virtualmin script, when I try to create a sub-domain, it writes the challenge key for the zone, but does not re-sign it before launching the challenge, which leads to the error.

Thanks for the tip, I'll try to make a post on the virtualmin forum to report the bug.

1 Like

Virtualmin manages the DNS zone? Didn't know that.

Then it's a Virtualmin bug -> ask in the Virtualmin forum.

But why isn't that done without manual intervention? Isn't there an option?

1 Like

Yes, there is a pretty good interface for bind (although I prefer to set it up from the command line).

I didn't know this until I discovered this strange bug (Thanks to your comment), but as I say at the end of the post, that's what I intended to do (and did).

Normally, everything is automatic, but since a recent update, it doesn't re-sign the area (for sub-servers). So that's why it's a bug...

1 Like