tlsa binary fails with certificate error

[Hoggins!]

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! <fuckspam at wheres5.com> 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.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://mail.sys4.de/pipermail/dane-users/attachments/20180522/d3a3af64/attachment-0001.asc>