> On May 13, 2018, at 4:55 AM, Hoggins! <[email protected]> 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.
