Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-02-06 Thread Diane Trout 
version: 0.17+repack-3
tag: pending

I have a new version (hopefully uploaded successfully) where I fixed
dnssec-trigger-control-setup to not generate new keys or certificates
if called repeatedly. So now the code to delete small keys should get
called.

I also included upstream's fix for the segfault we were having.
(Also reported as #921227)

Unfortunately a bug #921538 showed up in unbound that is causing my CItests to 
fail

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-16 Thread Diane Trout 
On Wed, 2019-01-16 at 08:55 +0100, Axel Beckert wrote:
> 
> 
> # summary of how this script can be called:
> #*  `configure' 
> [...]
> case "$1" in
> configure)
> # configure the control channel if run for the first time
> if [ -z "$2" ]; then
> dnssec-trigger-control-setup
> fi
> ;;
> 
> So as I read it, dnssec-trigger-control-setup is only called if there
> was no previously configured version installed and is hence never
> called when upgrading the package and hence never removes, the too
> small old keys on upgrade.
> 

I'm tired enough I wanted to double check the logic of a solution
before trying to implement it.

the check to remove too small keys should probably be moved out of
dnssec-trigger-control-setup and into the postinst script.

Then the "if [ -z "$2" ]" conditional in the post should be replaced
with checking for the existence of the keys instead of the package
version number to decide if the control-setup script is called.


Something like

configure)
debian_remove_small_keys $SERVER
debian_remove_small_keys $CONTROL
if [ \! -e /etc/dnssec-trigger/dnssec_trigger_control.key ]; then
dnssec-trigger-control-setup
fi

How's that sound to you?

Diane

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-15 Thread Axel Beckert 
Control: reopen -1
Control: found -1 0.17+repack-2

Hi Diane,

Diane Trout wrote:
> I found the place that was causing the segfault on installation, made a
> patch, it worked for me, and I pushed a new release.

Thanks for caring and looking into it.

> Please let me know if dnssec-trigger-0.17+repack-2 works for you.

Unfortuantely not:

Preparing to unpack .../dnssec-trigger_0.17+repack-2_amd64.deb ...
Unpacking dnssec-trigger (0.17+repack-2) over (0.17+repack-1) ...
Setting up dnssec-trigger (0.17+repack-2) ...
[] Restarting : dnssec-triggerdJan 16 08:36:03 dnssec-triggerd[31539] 
error: Error for server-cert-file: /etc/dnssec-trigger/dnssec_trigger_server.pem
Jan 16 08:36:03 dnssec-triggerd[31539] error: Error in SSL_CTX 
use_certificate_file crypto error:140AB18F:SSL 
routines:SSL_CTX_use_certificate:ee key too small
Jan 16 08:36:03 dnssec-triggerd[31539] error: cannot setup SSL context
Jan 16 08:36:03 dnssec-triggerd[31539] fatal error: could not init server
 failed!

So the service start still failed, but the package upgraded now
properly (which I don't think happened before, but IMHO shouldn't
happen in this case anyway) while still failing to start, also on the
commandline:

# service dnssec-triggerd start
Jan 16 08:46:36 dnssec-triggerd[32323] error: Error for server-cert-file: 
/etc/dnssec-trigger/dnssec_trigger_server.pem
Jan 16 08:46:36 dnssec-triggerd[32323] error: Error in SSL_CTX 
use_certificate_file crypto error:140AB18F:SSL 
routines:SSL_CTX_use_certificate:ee key too small
Jan 16 08:46:36 dnssec-triggerd[32323] error: cannot setup SSL context
Jan 16 08:46:36 dnssec-triggerd[32323] fatal error: could not init server
#

Reason seems to be at least in this case that
dnssec-trigger-control-setup (which you patched for the key length
check) is never called in my case.

>From the postinst script:

# summary of how this script can be called:
#*  `configure' 
[...]
case "$1" in
configure)
# configure the control channel if run for the first time
if [ -z "$2" ]; then
dnssec-trigger-control-setup
fi
;;

So as I read it, dnssec-trigger-control-setup is only called if there
was no previously configured version installed and is hence never
called when upgrading the package and hence never removes, the too
small old keys on upgrade.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Processed: Re: Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-15 Thread Debian Bug Tracking System 
Processing control commands:

> reopen -1
Bug #919256 {Done: Diane Trout } [dnssec-trigger] 
dnssec-trigger: Failed to upgrade: installed dnssec-trigger package 
post-installation script subprocess returned error exit status 1
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions dnssec-trigger/0.17+repack-2.
> found -1 0.17+repack-2
Bug #919256 [dnssec-trigger] dnssec-trigger: Failed to upgrade: installed 
dnssec-trigger package post-installation script subprocess returned error exit 
status 1
Marked as found in versions dnssec-trigger/0.17+repack-2.

-- 
919256: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919256
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-15 Thread Diane Trout 
Ok

I found the place that was causing the segfault on installation, made a
patch, it worked for me, and I pushed a new release.

(Fixes also sent upstream)

dnssec-trigger should also now only look for configuration files in
/etc/dnssec-trigger, and it shouldn't try to create ones in /etc any
more.

This may cause problems with the location for your customized
configuration file, but that probably should be a new bug.

Please let me know if dnssec-trigger-0.17+repack-2 works for you.

Diane


signature.asc
Description: This is a digitally signed message part

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-14 Thread Diane Trout 
On Tue, 2019-01-15 at 00:08 +0100, Florian Schlichting wrote:
> 
> Before thinking about cleanup, I'd start by making sure that fresh
> installs don't re-create problems. At the moment, purging dnssec-
> trigger
> leaves two keypairs in /etc; and when I rm them manually, and again
> install dnssec-trigger, they're back (in addition to the identically
> named pair in /etc/dnssec-trigger, which does get cleaned up on
> purge).
> Does that not happen for you?

No dnssec-trigger has  been leaving configuration files all over the
place.

I think I've found more of the configuration file installation
locations and fixed them to point to /etc/dnssec-trigger/, but now I'm
encountering the segfault while installing, that caused Axel Beckert to
open this bug so I'm having trouble testing all the fixes.

I did a bit of test driven development, wrote tests for config files in
/etc/, made sure it failed, then fixed the paths, and made sure the
tests pass -- at least when running in autopkgtest.

But I'd like to find the segfault before making another release.

Diane

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-14 Thread Florian Schlichting 
On Mon, Jan 14, 2019 at 01:31:28PM -0800, Diane Trout wrote:
> I'm a little worried about just rm-ing previously invalid locations for
> configuration files. Might you have suggestions about how to safely
> clean up dnssec-triggers configuration file mess? (At the very least it
> seems like it should check that a configuration file was actually
> created by it before just deleting it)

Before thinking about cleanup, I'd start by making sure that fresh
installs don't re-create problems. At the moment, purging dnssec-trigger
leaves two keypairs in /etc; and when I rm them manually, and again
install dnssec-trigger, they're back (in addition to the identically
named pair in /etc/dnssec-trigger, which does get cleaned up on purge).
Does that not happen for you?

I think you can assume that files named /etc/dnssec_trigger_* belong to
your package. However I don't understand dnssec-trigger enough to judge
if these will always be autogenerated keys that are rendered obsolete by
the keys in /etc/dnssec-trigger, or if some sysadmin might have replaced
them with his own keys, for some reason. That is, if these are
"configuration files" or just "data" that could equally have been put
into /var/lib/dnssec-trigger for example...

Florian

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-14 Thread Diane Trout 
On Mon, 2019-01-14 at 21:25 +0100, Florian Schlichting wrote:
> Hi,
> 
> in the course of looking into the upgrade failure, I ended up purging
> dnssec-trigger and then installed it again. I notice this creates
> keys
> and config files in both /etc/ and /etc/dnssec-trigger?! Different to
> Alex, I get traceback in the middle of the log (also for subsequent
> attempts to 'apt-get install -f' etc):

... I thought I had fixed that... But apparently I had just found a few
other places that had hardcoded paths that weren't being updated.

Apparently there are still more hardcoded paths.

I'm a little worried about just rm-ing previously invalid locations for
configuration files. Might you have suggestions about how to safely
clean up dnssec-triggers configuration file mess? (At the very least it
seems like it should check that a configuration file was actually
created by it before just deleting it)

Diane

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-14 Thread Axel Beckert 
Hi Diane,

Diane Trout wrote:
> Was dnssec-triggerd running before the upgrade?

I think so.

> Was there then an
> upgrade to openssl 1.1.1? and then finally it wouldn't start?

That one was much earlier IIRC, like weeks ago.

Anyway, I've now got a second machine with the same symptoms, just now
with sysvinit instead of systemd:

Setting up dnssec-trigger (0.17+repack-1) ...
Installing new version of config file 
/etc/NetworkManager/dispatcher.d/01-dnssec-trigger ...

Configuration file '/etc/dnssec-trigger/dnssec-trigger.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** dnssec-trigger.conf (Y/I/N/O/D/Z) [default=N] ? d
--- /etc/dnssec-trigger/dnssec-trigger.conf 2017-01-15 19:10:09.588308480 
+0100
+++ /etc/dnssec-trigger/dnssec-trigger.conf.dpkg-new2019-01-13 
22:10:28.0 +0100
@@ -22,12 +22,10 @@

 # the domain example.com line (if any) to add to resolv.conf(5). default none.
 # domain: ""
-domain: deuxchevaux.org

 # domain name search path to add to resolv.conf(5). default none.
 # the search path from DHCP is not picked up, it could be used to misdirect.
 # search: ""
-search: kub.deuxchevaux.org deuxchevaux.org noone.org debian.org ethz.ch 
lugs.ch

 # the command to run to open login pages on hot spots, a web browser.
 # empty string runs no command.
@@ -50,7 +48,7 @@
 # control-cert-file: "/etc/dnssec-trigger/dnssec_trigger_control.pem"

 # check for updates, download and ask to install them (for Windows, OSX).
-# check-updates:
+# check-updates: no

 # webservers that are probed to see if internet access is possible.
 # They serve a simple static page over HTTP port 80.  It probes a random url:
@@ -65,6 +63,7 @@
 url: "http://fedoraproject.org/static/hotspot.txt OK"

 # fallback open DNSSEC resolvers that run on TCP port 80 and TCP port 443.
+# These relay incoming DNS traffic on the other port numbers to the usual DNS
 # the ssl443 adds an ssl server IP, you may also specify one or more hashes
 # the following on one line: ssl443:{}
 # hash is output of openssl x509 -sha256 -fingerprint -in server.pem
@@ -77,3 +76,12 @@
 ssl443: 185.49.140.67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF
 ssl443: 2a04:b900::10:0:0:67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF

+# Use VPN servers for all traffic
+# use-vpn-forwarders: no
+
+# Forward RFC 1918 private addresses to global forwarders
+# use-private-addresses: yes
+
+# Add domains provided by VPN connections into Unbound forward zones
+# add-wifi-provided-zones: no
+

Configuration file '/etc/dnssec-trigger/dnssec-trigger.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** dnssec-trigger.conf (Y/I/N/O/D/Z) [default=N] ? n
[] Restarting : dnssec-triggerdJan 14 21:10:59 dnssec-triggerd[12444] 
error: Error for server-cert-file: /etc/dnssec-trigger/dnssec_trigger_server.pem
Jan 14 21:10:59 dnssec-triggerd[12444] error: Error in SSL_CTX 
use_certificate_file crypto error:140AB18F:SSL 
routines:SSL_CTX_use_certificate:ee key too small
Jan 14 21:10:59 dnssec-triggerd[12444] error: cannot setup SSL context
Jan 14 21:10:59 dnssec-triggerd[12444] fatal error: could not init server
 failed!

On this machine, OpenSSL 1.1.1 was installed in August 2018, i.e.
about half a year ago.
 
> The error message looks like your openssl keys are too small and all
> attempts to control dnssec-triggerd will fail. I modified dnssec-
> trigger-control-setup to check the key size and delete it if it was too
> small. Did the certificates in /etc/dnssec-trigger get regenerated?

Clearly not. They're from 2016 (on the second machine, the other one
is currently sleeping in my backpack):

/etc/dnssec-trigger # ls -l
total 36
-rw-r--r-- 1 root root 3115 Jan 15  2017 dnssec-trigger.conf
-rw-r--r-- 1 root root 3338 Jan 13 22:10 dnssec-trigger.conf.dpkg-dist
-rw-r--r-- 1 root root 3095 Oct  4  2016 dnssec-trigger.conf~
-rw-r--r-- 1 root root 4640 Dec 20  2016 dnssec.conf
-rw-r--r-- 1 root root 1277 May 28  2016 dnssec_trigger_control.key
-rw-r--r-- 1 root root  822 May 28  2016 dnssec_trigger_control.pem
-rw-r- 1 root root 1277 May 28  2016 dnssec_trigger_server.key

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-14 Thread Florian Schlichting 
Hi,

in the course of looking into the upgrade failure, I ended up purging
dnssec-trigger and then installed it again. I notice this creates keys
and config files in both /etc/ and /etc/dnssec-trigger?! Different to
Alex, I get traceback in the middle of the log (also for subsequent
attempts to 'apt-get install -f' etc):

Jan 14 20:51:32 thinkpad systemd[1]: Starting Generate keys and certificates 
for dnssec-trigger...
Jan 14 20:51:32 thinkpad dnssec-trigger-control-setup[6806]: setup in directory 
/etc
Jan 14 20:51:32 thinkpad dnssec-trigger-control-setup[6806]: generating 
dnssec_trigger_server.key
Jan 14 20:51:32 thinkpad dnssec-trigger-control-setup[6806]: Generating RSA 
private key, 3072 bit long modulus (2 primes)
Jan 14 20:51:32 thinkpad dnssec-trigger-control-setup[6806]: 
.
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: 
..
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: e is 65537 
(0x010001)
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: generating 
dnssec_trigger_control.key
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: Generating RSA 
private key, 3072 bit long modulus (2 primes)
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: ...
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: 
.
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: e is 65537 
(0x010001)
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: create 
dnssec_trigger_server.pem (self signed certificate)
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: create 
dnssec_trigger_control.pem (signed client certificate)
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: Signature ok
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: subject=CN = 
dnssec-trigger-control
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: Getting CA Private 
Key
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: Setup success. 
Certificates created.
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: run this script 
again with -i to:
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: #011- enable 
remote-control in unbound.conf
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: #011- start 
unbound-control-setup
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: #011- add root 
trust anchor to unbound.conf
Jan 14 20:51:33 thinkpad dnssec-trigger-control-setup[6806]: if you have not 
done this already
Jan 14 20:51:33 thinkpad systemd[1]: Started Generate keys and certificates for 
dnssec-trigger.
Jan 14 20:51:33 thinkpad systemd[1]: Starting Reconfigure local DNSSEC resolver 
on connectivity changes...
Jan 14 20:51:33 thinkpad dnssec-trigger-script[6819]: Backing up 
/etc/resolv.conf as /run/dnssec-trigger/resolv.conf.backup...
Jan 14 20:51:33 thinkpad dnssec-triggerd: [6822] info: dnssec-trigger 0.17 start
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: Traceback (most recent call 
last):
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 774, in 
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: main()
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 761, in main
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: Application(sys.argv).run()
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 472, in run
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: self.method()
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 556, in run_setup
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: 
self._unbound_set_negative_cache_ttl(UNBOUND_MAX_NEG_CACHE_TTL)
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 641, in 
_unbound_set_negative_cache_ttl
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: subprocess.check_call(CMD, 
stdout=DEVNULL, stderr=DEVNULL)
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]:   File 
"/usr/lib/python3.7/subprocess.py", line 347, in check_call
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: raise 
CalledProcessError(retcode, cmd)
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: subprocess.CalledProcessError: 
Command '['unbound-control', 'set_option', 'cache-max-negative-ttl:', '5']' 
returned non-zero exit status 1.
Jan 14 20:51:34 thinkpad dnssec-triggerd[6822]: chattr: Datei oder Verzeichnis 
nicht gefunden beim Auslesen des Status von /etc/resolv.conf
Jan 14 20:51:34

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-14 Thread Diane Trout 
On Mon, 2019-01-14 at 14:35 +0100, Axel Beckert wrote:
> Hi,
> 
> Axel Beckert wrote:
> > The syslog shows again this:
> > 
> > Jan 14 07:18:59 c-cactus2 dnssec-triggerd[22039]: Jan 14 07:18:59
> > dnssec-triggerd[22039] error: Error in SSL_CTX use_certificate_file
> > crypto error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key
> > too small
> 
> Attached the output of "fgrep dnssec /var/log/syslog" from the time
> of
> the package upgrade.
> 
>   Regards, Axel

Was dnssec-triggerd running before the upgrade? Was there then an
upgrade to openssl 1.1.1? and then finally it wouldn't start?

The error message looks like your openssl keys are too small and all
attempts to control dnssec-triggerd will fail. I modified dnssec-
trigger-control-setup to check the key size and delete it if it was too
small. Did the certificates in /etc/dnssec-trigger get regenerated?

See dnssec-trigger/debian/patches/remove-small-keys.patch for the
implementation.

Diane



signature.asc
Description: This is a digitally signed message part

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-14 Thread Axel Beckert 
Hi,

Axel Beckert wrote:
> The syslog shows again this:
> 
> Jan 14 07:18:59 c-cactus2 dnssec-triggerd[22039]: Jan 14 07:18:59 
> dnssec-triggerd[22039] error: Error in SSL_CTX use_certificate_file crypto 
> error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small

Attached the output of "fgrep dnssec /var/log/syslog" from the time of
the package upgrade.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


dnssec-syslog-excerpt.txt.xz
Description: Binary data

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

2019-01-13 Thread Axel Beckert 
Package: dnssec-trigger
Version: 0.17+repack-1
Severity: serious

Setting up dnssec-trigger (0.17+repack-1) ...
Job for dnssec-triggerd.service failed because the control process exited with 
error code.
See "systemctl status dnssec-triggerd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript dnssec-triggerd, action "restart" failed.
# dnssec-triggerd.service - Reconfigure local DNSSEC resolver on connectivity 
changes
   Loaded: loaded (/lib/systemd/system/dnssec-triggerd.service; enabled; vendor 
preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2019-01-14 
07:20:18 CET; 16ms ago
  Process: 29431 ExecStartPre=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--prepare (code=exited, status=0/SUCCESS)
  Process: 29438 ExecStart=/usr/sbin/dnssec-triggerd -d (code=exited, 
status=1/FAILURE)
  Process: 29439 ExecStartPost=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--update_all (code=exited, status=0/SUCCESS)
  Process: 29443 ExecStopPost=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--cleanup (code=exited, status=1/FAILURE)
 Main PID: 29438 (code=exited, status=1/FAILURE)
dpkg: error processing package dnssec-trigger (--configure):
 installed dnssec-trigger package post-installation script subprocess returned 
error exit status 1
Processing triggers for libc-bin (2.28-5) ...
Errors were encountered while processing:
 dnssec-trigger

I said "no" to the new dnssec-trigger.conf, but except comments the only
difference is the search domain setting:

$ diff /etc/dnssec-trigger/dnssec-trigger.conf 
/etc/dnssec-trigger/dnssec-trigger.conf.dpkg-dist 
28c28
< search: "deuxchevaux.org noone.org ethz.ch debian.org"
---
> # search: ""
51c51
< # check-updates: 
---
> # check-updates: no
65a66
> # These relay incoming DNS traffic on the other port numbers to the usual DNS
76a78,86
> 
> # Use VPN servers for all traffic
> # use-vpn-forwarders: no
> 
> # Forward RFC 1918 private addresses to global forwarders
> # use-private-addresses: yes
> 
> # Add domains provided by VPN connections into Unbound forward zones
> # add-wifi-provided-zones: no

The syslog shows again this:

Jan 14 07:18:59 c-cactus2 dnssec-triggerd[22039]: Jan 14 07:18:59 
dnssec-triggerd[22039] error: Error in SSL_CTX use_certificate_file crypto 
error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small

So maybe https://bugs.debian.org/898969 is not fully fixed yet?

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnssec-trigger depends on:
ii  gir1.2-nm-1.0   1.14.4-4
ii  libc6   2.28-5
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libglib2.0-02.58.2-3
ii  libgtk2.0-0 2.24.32-3
ii  libldns21.7.0-3.1+b1
ii  libssl1.1   1.1.1a-1
ii  python3 3.7.1-3
ii  python3-gi  3.30.4-1
ii  python3-lockfile1:0.12.2-2
ii  sensible-utils  0.0.12
ii  unbound 1.8.1-1+b1

dnssec-trigger recommends no packages.

dnssec-trigger suggests no packages.

-- Configuration Files:
/etc/dnssec-trigger/dnssec-trigger.conf changed:
search: "deuxchevaux.org noone.org ethz.ch debian.org"
url: "http://ster.nlnetlabs.nl/hotspot.txt OK"
url: "http://fedoraproject.org/static/hotspot.txt OK"
tcp80: 185.49.140.67
tcp80: 2a04:b900::10:0:0:67
ssl443: 185.49.140.67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF
ssl443: 2a04:b900::10:0:0:67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF


-- no debconf information