Hello Viktor,
Thank you for your answers. I've performed all the checks I could, the
certificates are well formed ("openssl x509 -in cert.pem -text -noout"
succeeds), I'm starting to think there may be a problem with my Python
version.
At least I'm pretty sure that the issue comes from a system update on
both the ones I'm using for generating the signatures : on an old
system, I'm successfully generating the records with the exact same files.I'm really not a Python guy, so I tried some ugly debugging with "print" placed here and there to check what was going on. Here are the differences between a "working" and a "non working" system (both using Python 2.7, although the binaries don't have the same checksums), inside routine getLocalChain() : -- non working system : Fedora 28, python2-libs-2.7.15-1.fc28.x86_64 <snip> while True: cptr = m2.x509_read_pem(bio._ptr()) if not cptr: break chain.append(X509.X509(cptr, _pyfree=1)) print chain if not chain: <snip> If I put the "print chain" inside the while loop, I get the correct chain array (one pass with only one item, and second pass with two items, output is as expected). *BUT* <snip> while True: cptr = m2.x509_read_pem(bio._ptr()) if not cptr: break chain.append(X509.X509(cptr, _pyfree=1)) print chain if not chain: <snip> I the "print chain" is placed after the loop, *it does not print anything*, so the script will eventually complain about "chain" not being defined. -- working system : Fedora 24, python-libs-2.7.13-2.fc24.x86_64 With this system and Python version, both tests are functional : either inside the loop or after the loop, I get something in the "chain" variable. So that makes me look at the Python version, but I could be wrong. I'm open to discussion. And as you were saying Viktor, it is confirmed here : since my servers have bad DANE signatures, communicating on this list is quite complicated for me. Thank you ! Hoggins! Le 13/05/2018 à 18:10, Viktor Dukhovni a écrit : > >> On May 13, 2018, at 4:55 AM, Hoggins! <[email protected]> wrote: >> >> Not sure this is the right place to post, maybe I'd better mail the >> maintainer of the package, but you might have encountered the same issue. > This list is a reasonable place to share experiences with the use of > DANE-related tools. Though you may have trouble receiving email from > this list, until your TLSA records are correct. The list MTA may be > doing DANE-validation, and your TLSA records have been incorrect since > ~28/Apr/2018. [This reply is also Bcc'd to you directly, just in case]. > > >> Now for about a few weeks now, the tlsa script fails, complaining with >> the following error message: >> >> Could not verify local certificate: no start line. > This suggests that the file it is trying to use is either not a PEM > file, or contains no certificate. A PEM certificate is enclosed > between two lines of the form: > > ----- BEGIN CERTIFICATE ----- > ----- END CERTIFICATE ----- > > Double check that the file exists and is well-formed. > >> I'm using LetsEncrypt for my certificates, and I can't see what changed >> recently. I'm running the tlsa script against a concatenated >> (intermediate + domain certificate) PEM file, and it has always worked >> just fine. > This should be OK, but you're posting the syntax you're using, and not > showing the file permissions, what id the cron job is running as, ... > >> During my investigations, I found that an "openssl verify" will fail on >> the file, saying "unable to get local issuer certificate". > To verify a chain file, try: > > $ chainfile=chain.pem # adjust appropriately > $ rootCA=root.pem # adjust appropriately > $ openssl verify -untrusted $chainfile -CAfile $rootCA $chainfile > > the "-untrusted ..." option makes the intermediate certificates in > the chain file available for verification and of course the root CA > needs to be locally available. Mind you, for DANE-EE(3) you really > don't need to verify your certificate, so this is likely a distraction. > >> I have no way >> to tell if this has always failed, or if this is new behavior. > Your TLSA records used to be correct until ~28/Apr/2018 > >> I'd be glad to hear if you have any thoughts about my issue. > Please review the slides (and if you wish audio) from ICANN61 talk, > that recommends a more robust key rotation approach. Stick with > "3 1 1" rather than "3 1 2", in DNS smaller replies work better, and > SHA2-256 is plenty secure. > > http://imrryr.org/~viktor/ICANN61-viktor.pdf > http://imrryr.org/~viktor/icann61-viktor.mp3 > > Also see the listing for your domains at: > > https://github.com/danefail/list/blob/master/dane_fail_list.dat > > please do read the DANE misconfiguration notices sent when the > DANE survey finds problems, you were notified on 28/Apr, 30/Apr > and 05/May. >
signature.asc
Description: OpenPGP digital signature
