search

raforg / danectl

DNSSEC DANE implementation manager
https://raf.org/danectl
GNU General Public License v2.0
22 stars 5 forks source link

danectl fails to find the email address in my S/MIME certificate #12

Closed jscott0 closed 1 year ago

jscott0 commented 1 year ago

Here is my certificate. Maybe I'm using too new of an OpenSSL or something, I'm on Debian Bookworm. Anyway, the script whines (when trying to make or check the record) that it doesn't know what my email address is. Fortunately the code is quite readable, so I monkeypatched it on-the-fly with my email address in the $email variable. Of course, this still should be fixed.

raforg commented 1 year ago

Sorry about that, and thanks for supplying your certificate. Please check that the latest commit fixes it. It does when I try it. Unfortunately, the identification of the email address is lame, since it's based on scanning the text output of an openssl command, and the text output of openssl can change. But it keeps the number of dependencies low.

jscott0 commented 1 year ago

Thank you @raforg for looking at this so quickly and for writing it in the first place! The smimea-check gives some unexpected results that don't make sense to me, but oh well.

raforg commented 1 year ago

The smimea-check is comparing what it would generate with what's already in the DNS. If you show me the unexpected results, I might be able to explain it, or if there's another bug, I could address that. I did change both the smima and smimea-check to detect your email address, but I couldn't test smimea-check myself.

raforg commented 1 year ago

I just tested simea-check with your cert.txt, and it looks as though there is an existing SMIMEA DNS record published in the DNS for a different certificate, so it's reporting that the existing SMIMEA DNS record should be deleted and replaced with a new SMIMEA DNS record for the new certificate. Does that make sense? Is the certificate that is currently in the DNS for a different certificate?

raforg commented 1 year ago

I've had a closer look. The only difference between the new proposed SMIMEA record and the existing published one is the first two bytes. The new one starts with "3082" and the existing one starts with "4813", so it looks like they should be for the same certificate. But "3082" is the file signature (magic number) for x509 certificates in der format. "4813" doesn't seem to be a file signature for anything. I don't know where the existing record came from but it looks wrong. It's not valid der data. If I convert it to binary (i.e., a der file), and try to parse it with openssl x509 -inform der -noout -text < bindata, openssl outputs:

unable to load certificate
140397549069632:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1149:
140397549069632:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:309:Type=X509

But doing the same thing with the new proposed record works.

So it looks to me as though danectl is working. If it created the existing published record, then that's a concern, but I'm hoping that it was created some other way.

Thanks for helping to improve danectl. It's much appreciated.