Devuan bug report logs - #53
Website not working when using TLSA

Package: devuan-www; Maintainer for devuan-www is Devuan Developers <>;

Reported by: Klaus Ethgen <>

Date: Mon, 3 Apr 2017 20:03:01 UTC

Severity: grave

Done: "Ralph Ronnquist (rrq)" <>

Full log

🔗 View this message in rfc822 format

MIME-Version: 1.0
X-Mailer: MIME-tools 5.509 (Entity 5.509)
From: "Devuan bug Tracking System" <>
To: "Ralph Ronnquist (rrq)" <>
Subject: bug#53: marked as done (Website not working when using TLSA)
Message-ID: <>
References: <>
X-Devuan-PR-Message: closed 53
X-Devuan-PR-Package: devuan-www
Date: Sat, 18 Jan 2020 00:48:02 +0000
Content-Type: multipart/mixed; boundary="----------=_1579308482-17414-0"
[Message part 1 (text/plain, inline)]
Your message dated Sat, 18 Jan 2020 11:30:04 +1100
with message-id <>
and subject line fixed
has caused the Devuan bug report #53,
regarding Website not working when using TLSA
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact

Devuan Bug Tracking System
Contact with problems
[Message part 2 (message/rfc822, inline)]
From: Klaus Ethgen <>
Subject: Website not working when using TLSA
Date: Mon, 3 Apr 2017 20:53:04 +0100
Hash: SHA512

Package: devuan-www
Severity: important

Since several months, the web page ( is not viewable for
those who care about security and trust only the certificate that the
owner has access to instead of every untrusted CA.

The way to do that is DNSSEC with TLSA and thankfully, devuan does
support that.

Unfortunately, since several months, (I believe, when devuan switched to
that horrable Let's encrypt) the page doesn't match the TLSA record
anymore. That leads to a unviewable page if one cares about security.

So the TLSA record should be updated to match the SSL certificate of the
page (or the right SSL certificate should be used).

There are few solutions for this if it is really the switch to Let's
encrypt that is the cause:
- - Every time you replace the SSL certificate, update the TLSA record
  too. That is very painful as Let's encrypt drives security adabsurdum
  by replacing the certificate with every single new load. (Keep in
  mind, not everyone is checking the side every hour.) That is the most
  stupid (sorry) way.
- - Get a certificate from a more stable source that is not replacing the
  certificates that often. You still need to change the TLSA record
  every time you replace the certificate. That is, in my opinion, the
  most reliable way.
- - If you don't care about the fucked up CA stuff, just generate a self
  signed certificate and put the right stuff into TLSA record. This is
  the most honest way to go but realistically, as browser vendors seems
  to passively boycott DNSSEC, this is no way to go for a site like
- - The last way would be to use the CA fingerprint instead of the one of
  the actual certificate. Or use the fingerprint of the key if you don't
  change it with every certificate renewal. This is making good face on
  a bad matter but it is working too.

- -- 
Klaus Ethgen                             
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
Comment: Charset: ISO-8859-1

[Message part 3 (message/rfc822, inline)]
From: "Ralph Ronnquist (rrq)" <>
Subject: fixed
Date: Sat, 18 Jan 2020 11:30:04 +1100

Send a report that this bug log contains spam.

Devuan BTS -- Powered by Debian bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.

Devuan Bugs Owner <>.
Last modified: Mon Oct 25 07:13:17 2021;