On May 13, 2018, at 4:55 AM, Hoggins! fuckspam@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.