tlsa binary fails with certificate error
ietf-dane at dukhovni.org
Sun May 13 18:10:42 CEST 2018
> 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.
Also see the listing for your domains at:
please do read the DANE misconfiguration notices sent when the
DANE survey finds problems, you were notified on 28/Apr, 30/Apr
More information about the dane-users