tlsa binary fails with certificate error

[Viktor Dukhovni]

> 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.

-- 
	Viktor.