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: Klaus Ethgen <>
Subject: bug#53 closed by "Ralph Ronnquist (rrq)" <>
Message-ID: <>
References: <>
X-Devuan-PR-Message: they-closed 53
X-Devuan-PR-Package: devuan-www
Date: Sat, 18 Jan 2020 00:48:05 +0000
Content-Type: multipart/mixed; boundary="----------=_1579308485-17414-1"
[Message part 1 (text/plain, inline)]
This is an automatic notification regarding your bug report
which was filed against the devuan-www package:

#53: Website not working when using TLSA

It has been closed by "Ralph Ronnquist (rrq)" <>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact "Ralph Ronnquist (rrq)" <> by
replying to this email.

Devuan Bug Tracking System
Contact with problems
[Message part 2 (message/rfc822, inline)]
From: "Ralph Ronnquist (rrq)" <>
Subject: fixed
Date: Sat, 18 Jan 2020 11:30:04 +1100
[Message part 3 (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


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 06:59:19 2021;