letoams/hash-slinger

tlsa fails with "name 'chain' is not defined"

hgshoggins opened this issue · 23 comments

hgshoggins commented

I'm using LetsEncrypt for my certificates and something that has always worked was to generated the TLSA DNS records with /usr/bin/tlsa --create --selector 1 --mtype 2 --certificate <PEM file with intermediate and certificate concatenated> <domain.com> but since an event I cannot determine, it's not working anymore, on any of my signing machines. The certificates are successfully used on several systems, including HAProxy, Sendmail or Dovecot without issues.
Here is the output of the command:

    Could not verify local certificate: no start line.
    Traceback (most recent call last):
      File "/usr/bin/tlsa", line 889, in <module>
        genRecords(args.host, args.protocol, args.port, chain,
    args.output, args.usage, args.selector, args.mtype)
    NameError: name 'chain' is not defined

Is there something I should check to ensure tlsa properly recognizes the certificate files?

hgshoggins commented

Certificate files are not malformed, they are correctly decoded with openssl x509 -in cert.pem -text -noout.

After a bit more investigation, what I can see is that:

  • it's not working on a Fedora 28 with python2-libs-2.7.15-1.fc27.x86_64
  • it's working on a Fedora 24 with python-libs-2.7.13-2.fc24.x86_64

On the non working system, in the def getLocalChain(), I tried to put some ugly debugging by placing print chain in some specific places.

  • case 1, print chain placed outside of the loop:
        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:

RESULT: no output, the chain variable seems empty

  • case 2, print chain placed inside the loop:
        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:

RESULT: chain array contents correctly filled with elements:
[<M2Crypto.X509.X509 instance at 0x7f5416506dd0>, <M2Crypto.X509.X509 instance at 0x7f54165066c8>]

So there is a behavior change between the two versions of Python (I guess) that makes the scope of the chain variable different, and not accessible outside of the loop.

What is happening?

letoams commented
  • 👍2
stoecker commented

Are you sure your analysis is correct?
I'd simply say that lines 887 to 889 access non-existing variables in case there was an exception.

The "No start line" exception may be a difference between the Fedora versions. Some subroutine call going wrong (which is hidden by the catching of the exception). If you comment the try block in line 883 your should get an indication what goes wrong.

stoecker commented

I fixed the illegal variable access. You still need to find out where the "No start line" comes from.

hgshoggins commented

Yes. Can't figure out why I get this, as they actually have their start line, are used as is and recognized as such.

stoecker commented

Can you please disable the try/except at the end of tlsa and post the full stack trace of the exception you get when the code is called without catching the exception?

hgshoggins commented

Here is what I get when commenting out the try / except sections at the end of the file:

Traceback (most recent call last):
  File "/usr/bin/tlsa", line 884, in <module>
    chain, verify_result = getLocalChain(args.certificate, args.debug)
  File "/usr/bin/tlsa", line 376, in getLocalChain
    cptr = m2.x509_read_pem(bio._ptr())
M2Crypto.X509.X509Error: no start line
GieltjE commented

The debian testing branch has recently begun displaying this behaviour, might be worth fixing and getting a package pushed before the whole bunch goes through to stable.

Using the git tlsa version results in a clean message: "Could not verify local certificate: no start line (Expecting: CERTIFICATE)."

stoecker commented

I'll fix it, when I know what I need to fix. I can't reproduce.

Can you give a description how to get that error. I can setup an VM according to your documentation if you provide detailed description what is required to get this error.

GieltjE commented

Set up a debian install with the following sources.list:

deb http://ftp.debian.org/debian/ testing main contrib non-free deb http://security.debian.org/ testing/updates main contrib

Update everything acordingly and install tlsa, example command:
tlsa --create -o rfc --protocol tcp --port 443 --certificate /etc/apache2/ssl/<site>.crt --ca-cert /etc/apache2/ssl/ --usage 3 --selector 1 --mtype 1 <site>

If you need any additional information let me know,

stoecker commented

I don't use debian at all. Can you start a bit earlier. 😌
Which ISO do I use for install, I assume there are different versions.

GieltjE commented

No problem, assuming you have an X64 capable VM just pop in the iso below, 20GB should be plenty of space, 512M ram should suffice (256 would do just fine if just going for a console only installation).

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.6.0-amd64-netinst.iso

Let me know if you run into any problems.

stoecker commented

I have a vm running now based on your installation with the newest tlsa from this git. Don't get the same error. Can you drop all arguments beside --create --certificate and sitename. Same issue? Does a "cat" for your site crt file output the file? Can you send me the file?

GieltjE commented

have you removed all lines from sources.list except the supplied, and ran the following commands?

apt-get update

apt dist-upgrade

apt-get upgrade

stoecker commented

Ah, fine. Can reproduce now. I though that the system update is not necessary for a fresh install :-)

  • 👍2
hgshoggins commented

Per-fect!

GieltjE commented

Any chance of a new release so Debian (and others) can update?

hgshoggins commented

I'm using Fedora and I decided to "override" the official package with a simple download of the script from @stoecker's last commit, replacing the installed one. Works like a charm.

GieltjE commented

I'm using Fedora and I decided to "override" the official package with a simple download of the script from @stoecker's last commit, replacing the installed one. Works like a charm.

True, did so myself on Debian, the point I'm trying to make is that if this package breaks and os'es push mayor updates they might choose to drop this package instead of using "custom" versions.
This tool is pretty usefull for generating TLSA records (and others), so it's functionality is best preserved.

  • 👍1
letoams commented
  • 👍2
andrejpodzimek commented

A polite ping. 😉 I can still see the same error on Arch and this is because the last release is from 2016, so the fix doesn't get included automatically.

stoecker commented

I did a new release a few minutes ago.

letoams commented