Option for certonly when using danectl certbot for the first time

[ran-deh]

Again, Thank you for creating danectl - DNSSEC DANE implementation manager.

When generating a certificate for the first time using danectl it fails if certonly is added as an option (new server).

I understand this is more of a preference rather than a necessity, although I thought I would share my findings with you.

[raforg]

Thanks. I'm glad you find it useful.

Sorry, but I'm not sure that I understand what you mean when you say "if certonly is added as an option". Can you show me the command(s) and the output?

It sounds like you might be trying this, but that won't work:

danectl certbot certonly
danectl new example.org

Danectl's "certbot" subcommand is only for supplying certbot authentication/installation options to be remembered. It's not for certbot subcommands.

If the problem is that you need to authenticate without installing "in your current webserver", perhaps certbot's --standalone option does what you need. i.e.:

danectl certbot --standalone
danectl new example.org

Certbot's "certonly" subcommand is for obtaining a new certificate without installing it. I might be wrong, but the --standalone option seems to be another way to do the same thing. At least, that's the impression I get from the certbot manpage. Certbot's --manual option might be another alternative.

Let me know if I've misunderstood your problem. I could add a way to indicate that certbot's "certonly" subcommand, rather than its "new" subcommand, should be used, if it's important.

Of course, it's also possible to create the certificate lineage directly with certbot, and then have danectl adopt it, but that sounds a bit defeatist.

[raforg]

Certbot's user guide says that certonly and --standalone are used together. So --standalone might not work with the run subcommand. But it might. Could you test it?

[ran-deh]

Yes, certonly is a sub command.

I saw that "certonly" is coded into the dup function and figured that I would give it a try with the complete understanding that "danectl is opinionated and inflexible".

I first included it in the options: danectl certbot "certonly --nginx --reuse-key --staple-ocsp --agree-tos --email info@example.com --no-eff-email"

I ran: danectl new "mail.example.com mta-sts.example.com"

which returned: "usage: certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates. By default, it will attempt to use a webserver both for obtaining and installing the certificate. certbot: error: unrecognized arguments: certonly danectl: new mail.example.com mta-sts.example: certbot failed"

I then tried danectl new certonly "mail.example.com mta-sts.example.com" and that was a failure.

I gave --standalone a try which returned: With the standalone plugin, you probably want to use the "certonly" command, eg: certbot certonly --standalone

The reason I use "certonly" is so that my configuration files are not modified by certbot. I can first generate my certs with certbot and then use the adopt and dup functions of danectl - DNSSEC DANE implementation manager.

Thank you, Ran

[ran-deh]

One suggestion for function danectl tlsa-check example.com When records match maybe echo "Nothing to do here."

[ran-deh]

I did some more testing with danectl and found that when I use the Certbot options listed below, Certbot does generate the cert although danectl fails. It returns "danectl: new example.com mail.example.com mta-sts.example.com: certbot failed."

I then used the adopt and dup functions and those worked just fine. I am sure the problem is with one or more of the options that I am using.

Certbot options: danectl certbot "--nginx --reuse-key --staple-ocsp --agree-tos --email info@example.com --no-eff-email"

root@mail:~# danectl new "example.com mail.example.com mta-sts.example.com" Saving debug log to /var/log/letsencrypt/letsencrypt.log Account registered. Requesting a certificate for example.com and 2 more domains

Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem This certificate expires on 2021-12-14. These files will be updated when the certificate renews. Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate Successfully deployed certificate for example.com to /etc/nginx/sites-enabled/example.com.conf Successfully deployed certificate for mail.example.com to /etc/nginx/sites-enabled/mail.example.com.conf Successfully deployed certificate for mta-sts.example.com to /etc/nginx/sites-enabled/mta-sts.example.com.conf Congratulations! You have successfully enabled HTTPS on https://example.com, https://mail.example.com, and https://mta-sts.example.com

---

If you like Certbot, please consider supporting our work by:

• Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
• Donating to EFF: https://eff.org/donate-le

  ---

  danectl: new example.com mail.example.com mta-sts.example.com: certbot failed

[raforg]

Hi Ran,

I've done some research and it's more complicated. The certbot "run" subcommand, which danectl always uses with its "new" subcommand can only be used when there will be installation (not just authentication). If it's used for authentication only, it will error out. So whether "run" can be used or not depends on which authentication/installation options are provided with danectl's "certbot" subcommand. So danectl is currently broken. It always uses "run" for "new", even when it definitely won't work.

I'm going to change it today so that it's smarter about what it does by default (i.e. not just assume --apache, but default to --apache, --nginx, or --standalone depending on what's installed), and make it use "run" or "certonly" as appropriate when it can tell which is needed (not always possible), and also allow the user to override its decision about which to use (for when it gets it wrong). So danectl's "certbot" subcommand will be able to accept a certbot subcommand, as well as options.

So, in your case, it will detect that nginx is installed, so you won't have to tell it that (but you can), and that will make it default to using "run" assuming that you want to install the certificate (since the nginx plugin is capable of doing that). But you can override it to use "certonly" instead. Something like this:

danectl certbot certonly --nginx --agree-tos --no-eff-email danectl new mail.example.com mta-sts.example.com danectl dup mail.example.com

Or you can avoid the nginx plugin entirely and use --standalone (and danectl will know to use "certonly" rather than "run"):

danectl certbot --standalone --agree-tos --no-eff-email danectl new mail.example.com mta-sts.example.com danectl dup mail.example.com

But if you do that, you will have to arrange to stop nginx beforehand and start it again afterwards with certbot hooks. It's probably better to use the nginx plugin.

Note that you don't need to specify --reuse-key because danectl takes care of that. Also, don't use quotes to group arguments together, particularly for the domain names. That's a mistake. It's like saying that there is one domain called "mail.example.com mta-sts.example.com", rather than two domains.

Also, trying "danectl new certonly..." would treat "certonly" as a domain name. It doesn't belong with the "new" subcommand. But it will soon be OK with the "certbot" subcommand.

By the way, I could be wrong, but I think that --staple-ocsp does nothing unless you are installing the certificate into nginx's configuration. I think it only affects how the web server's configuration is modified.

Also, I suspect that you don't need to specify an email address either if you have --no-eff-email. But that's not important for danectl. I just thought I'd mention it.

Thanks again for alerting me to this problem. It's not just a matter of style. It is a real problem that needed to be fixed, and danectl will be much better as a result.

cheers, raf

[raforg]

On Wed, Sep 15, 2021 at 01:02:43PM -0700, ran-deh @.***> wrote:

One suggestion for function danectl tlsa-check example.com When records match maybe echo "Nothing to do here."

Sorry, but that's not a great idea. Silence when nothing needs to be done might seem unfriendly, but it's the UNIX way. More importantly, the idea is that the tlsa-check command can be used in a daily cronjob to monitor whether or not TLSA reecords are correctly published. When they are correct, there should be no output, otherwise, cron will send a useless email every day. It's much better that it only send email when an action needs to be taken, and that requires that the tlsa-check command only produce output when an action needs to be taken. But thanks for the suggestion.

[raforg]

I think the problem is that you grouped the domains together with quotes. After certbot creates the certificate, danectl looks for a directory in /etc/letsencrypt/live with a name that matches the first domain given, but the first domain given was "example.com mail.example.com mta-sts.example.com", so it's looking for:

"/etc/letsencrypt/example.com mail.example.com mta-sts.example.com"

The documentation states not to use quotes for the "certbot" subcommand. I'll add a similar statement about the "new" subcommand. Or maybe make it cope with that usage, since no domain will ever contain spaces.

I'm actually surprised that certbot accepted the list that way. It's supposed to accept multiple domains as either:

-d example.com -d mail.example.com -d mta-sts.example.com

or:

-d example.com,mail.example.com,mta-sts.example.com

Thanks again.

[raforg]

On Thu, Sep 16, 2021 at 11:40:46AM +1000, raf @.***> wrote:

I'm actually surprised that certbot accepted the list that way. It's supposed to accept multiple domains as either:

-d example.com -d mail.example.com -d mta-sts.example.com

or:

-d example.com,mail.example.com,mta-sts.example.com

Ah, danectl did call certbot correctly. It was just the symlink check that failed.

[raforg]

I've think I've fixed everything. You can now specify whether you want to use certbot's "run" or "certonly" command by putting it at the start of the "danectl certbot" command.

Also, danectl is now smarter about the default certbot command and plugin. Now it'll use "certbot run --apache" by default, if /etc/apache2 exists. Otherwise, it'll use "certbot run --nginx" by default, if /etc/nginx exists. Otherwise, it'll use "certbot certonly --standalone" by default. If any other plugin is used, it'll default to "certonly" rather than "run". And if it defaults to the wrong certbot command, it can be overridden.

Also, if quotes are used where they aren't needed, it'll either just work, or detect it and tell you to remove the quotes.

I think these commands will do what you want:

danectl certbot certonly --nginx --agree-tos --no-eff-email
danectl new example.com mail.example.com mta-sts.example.com
danectl dup example.com

If you have nginx installed (and don't have apache installed), it'll default to --nginx, so you don't actually need that, but it does no harm to have it.

It would be great if you could test it.

[ran-deh]

I did some more testing with danectl and found that when I use the Certbot options listed below, Certbot does generate the cert although danectl fails. It returns "danectl: new example.com mail.example.com mta-sts.example.com: certbot failed."

I then used the adopt and dup functions and those worked just fine. I am sure the problem is with one or more of the options that I am using.

Certbot options: danectl certbot "--nginx --reuse-key --staple-ocsp --agree-tos --email info@example.com --no-eff-email"

root@mail:~# danectl new "example.com mail.example.com mta-sts.example.com" Saving debug log to /var/log/letsencrypt/letsencrypt.log Account registered. Requesting a certificate for example.com and 2 more domains

Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem This certificate expires on 2021-12-14. These files will be updated when the certificate renews. Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate Successfully deployed certificate for example.com to /etc/nginx/sites-enabled/example.com.conf Successfully deployed certificate for mail.example.com to /etc/nginx/sites-enabled/mail.example.com.conf Successfully deployed certificate for mta-sts.example.com to /etc/nginx/sites-enabled/mta-sts.example.com.conf Congratulations! You have successfully enabled HTTPS on https://example.com, https://mail.example.com, and https://mta-sts.example.com

---

If you like Certbot, please consider supporting our work by:

• Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
• Donating to EFF: https://eff.org/donate-le

  ---

  danectl: new example.com mail.example.com mta-sts.example.com: certbot failed

On Wed, Sep 15, 2021 at 01:02:43PM -0700, ran-deh @.***> wrote: One suggestion for function danectl tlsa-check example.com When records match maybe echo "Nothing to do here." Sorry, but that's not a great idea. Silence when nothing needs to be done might seem unfriendly, but it's the UNIX way. More importantly, the idea is that the tlsa-check command can be used in a daily cronjob to monitor whether or not TLSA reecords are correctly published. When they are correct, there should be no output, otherwise, cron will send a useless email every day. It's much better that it only send email when an action needs to be taken, and that requires that the tlsa-check command only produce output when an action needs to be taken. But thanks for the suggestion.

Understood. Tunnel vision on my part.

[ran-deh]

I think the problem is that you grouped the domains together with quotes. After certbot creates the certificate, danectl looks for a directory in /etc/letsencrypt/live with a name that matches the first domain given, but the first domain given was "example.com mail.example.com mta-sts.example.com", so it's looking for: "/etc/letsencrypt/example.com mail.example.com mta-sts.example.com" The documentation states not to use quotes for the "certbot" subcommand. I'll add a similar statement about the "new" subcommand. Or maybe make it cope with that usage, since no domain will ever contain spaces. I'm actually surprised that certbot accepted the list that way. It's supposed to accept multiple domains as either: -d example.com -d mail.example.com -d mta-sts.example.com or: -d example.com,mail.example.com,mta-sts.example.com Thanks again.

Ah, Yes. I had recorded this in my findings but mistakenly started a new tab in my editor after this first entry. I knew from your documentation that I should not use quotes although the only way "danectl new" would run was to wrap the domains in quotes. Without quotes it returned the following.

Thank you,

Ran

danectl new example.com mail.example.com mta-sts.example.com /usr/local/bin/danectl: 574: local: mail.example.com: bad variable name

[ran-deh]

I've think I've fixed everything. You can now specify whether you want to use certbot's "run" or "certonly" command by putting it at the start of the "danectl certbot" command. Also, danectl is now smarter about the default certbot command and plugin. Now it'll use "certbot run --apache" by default, if /etc/apache2 exists. Otherwise, it'll use "certbot run --nginx" by default, if /etc/nginx exists. Otherwise, it'll use "certbot certonly --standalone" by default. If any other plugin is used, it'll default to "certonly" rather than "run". And if it defaults to the wrong certbot command, it can be overridden. Also, if quotes are used where they aren't needed, it'll either just work, or detect it and tell you to remove the quotes. I think these commands will do what you want: danectl certbot certonly --nginx --agree-tos --no-eff-email danectl new example.com mail.example.com mta-sts.example.com danectl dup example.com If you have nginx installed (and don't have apache installed), it'll default to --nginx, so you don't actually need that, but it does no harm to have it. It would be great if you could test it.

Okay I will test it and get back to you. Thank you!

[raforg]

Regarding:

danectl new example.com mail.example.com mta-sts.example.com
/usr/local/bin/danectl: 574: local: mail.example.com: bad variable name

That's unexpected. That line was (in a function):

local certname="$1"

The only way that error should happen is if the quotes were missing, and if quotes had been used on the command line. But every version of danectl has had the quotes there.

Please keep an eye out for this happening again. I've run much the same command without problem. I just tried it again and it seems fine.

[ran-deh]

Regarding:

danectl new example.com mail.example.com mta-sts.example.com
/usr/local/bin/danectl: 574: local: mail.example.com: bad variable name

That's unexpected. That line was (in a function):

local certname="$1"

The only way that error should happen is if the quotes were missing, and if quotes had been used on the command line. But every version of danectl has had the quotes there.

Please keep an eye out for this happening again. I've run much the same command without problem. I just tried it again and it seems fine.

Hi raf,

I have listed the steps I took and my findings.

1. Unistall make uninstall

2. Replaced danectl file with updated version. make installed

3. rm .danectl file # Removed existing file

When adding certbot options it returns the following:

root@mail:~# danectl certbot --nginx --agree-tos --no-eff-email /usr/local/bin/danectl: 583: local: --agree-tos: bad variable name

Left out --agree-tos root@mail:~# danectl certbot certonly --nginx --no-eff-email /usr/local/bin/danectl: 583: local: --no-eff-email: bad variable name

Left out --agree-tos --no-eff-email and it works. danectl certbot certonly --nginx

For danectl new it returns the following: root@mail:~# danectl new example.com mail.example.com mta-sts.example.com /usr/local/bin/danectl: 635: local: mail.example.com: bad variable name

Thank you,

Randy

[raforg]

Thanks. That's really interesting. It's not the line I thought. It's lines that look like this:

local blah="$@"

That actually makes sense, and it's something I expected to be a problem but wasn't. The behaviour of "$@" is special. It results in nothing at all (i.e. the quotes vanish when there are no arguments), and it results in multiple arguments when there are multiple arguments (i.e. it acts like there separate pairs of quotes around each argument). By that definition, these errors should happen. But for an assignment, they don't. At least, they don't on systems that I have access to, where /bin/sh is bash (or dash).

I think your /bin/sh must be something other than bash, where the special "$@" behaviour even applies to variable assignments.

I can fix it by replacing var="$@" with var="$*" everywhere, but I'd like to know what your /bin/sh actually is (for the commit message). Can you tell me what your /bin/sh is, and what operating system you are using?

[ran-deh]

I use Ubuntu 20.04 for production and testing. I will be back online in the morning EST. Thank you, Ran

root@mail:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal

root@mail:~$ bash --version GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

root@mail:~$ readlink /proc/$$/exe /bin/bash

root@mail:~$ cat /etc/shells

/etc/shells: valid login shells

/bin/sh /bin/bash /bin/rbash /bin/dash

root@mail:~$ echo $0 -bash

root@mail:~$ /bin/sh $

[raforg]

Thanks. That doesn't show exactly what /bin/sh is, but I'm sure it must be dash. On my recent debian systems, and an old ubuntu system, /bin/sh is dash. I was wrong thinking it was still bash. That was many many years ago.

Dash for me is behaving OK on debian-11 (version 0.5.11+git20200708+dd9ef66-5). My old ubuntu-16 or 18 system has dash version 0.5.8-2.1ubuntu2. It looks like ubuntu-20.04 has dash 0.5.10.2-6, so I wouldn't expect such a huge behavioural difference. The Ubuntu wiki page about how to change bashisms to posix/dash doesn't mention "$@" at all.

However, dash on my old ubuntu system is behaving very very differently to dash on my debian system. So differently, that it looks like a massive bug in dash (but which one?).

The following script behaves well on debian, but badly on ubuntu.

#!/bin/sh
chk()
{
    local a="$1"
    local b="$@"
    echo "a <$a>"
    echo "b <$b>"
}
chk "$@"

On debian, this happens (ok, ok, ok, ok):

# ./chk abc def ghi
a <abc>
b <abc def ghi>
# ./chk "abc def ghi"
a <abc def ghi>
b <abc def ghi>
# ./chk a.b c.d e.f
a <a.b>
b <a.b c.d e.f>
# ./chk "a.b c.d e.f"
a <a.b c.d e.f>
b <a.b c.d e.f>

On Ubuntu, this happens (bad, ok, bad, ok):

# ./chk abc def ghi
a <abc>
b <abc>
# ./chk "abc def ghi"
a <abc def ghi>
b <abc def ghi>
# ./chk a.b c.d e.f
./chk: 6: local: c.d: bad variable name
# ./chk "a.b c.d e.f"
a <a.b c.d e.f>
b <a.b c.d e.f>

However, although the debian version of dash behaves "well", and the same as /bin/sh on macOS, I think it's actually the ubuntu version that is more strictly correct in terms of POSIX compliance (at least as I understand it).

And when I change "$@" to "$*", they both work correctly.

Thanks so much for bringing this to my attention. I actually was surprised that "$@" was working the way it was with assignments on debian and macOS, and just assumed that I didn't understand Bourne shell well enough. I should have trusted my instincts and used "$*" to start with.

Please try the latest commit.

[raforg]

I've made more changes since the last message. Please test commit d6cab03 if that's OK.

[raforg]

By the way, the debian behaviour agrees with /bin/sh on FreeBSD and Solaris (both /bin/sh and /usr/xpg4/bin/sh), so maybe it is the ubuntu behaviour that's buggy. But it doesn't matter. The current version of danectl should work with all of them.

[raforg]

I've done some checking and Debian's dash behaviour doesn't just match macOS. It also matches FreeBSD and Solaris. So maybe it is Ubuntu's dash that is "wrong". But it doesn't matter. The latest version should work with all of them.

[ran-deh]

I saw that you had updated the Makefile, so I started with the latest version but reverted to the previous version when I saw an error. Everything else worked perfectly for the updates to danectl.

Again, thank you for creating danectl. This is what I was looking for when I came across your post https://community.letsencrypt.org/t/a-dane-friendly-certbot-workflow/158324/2 . Actually, it is a lot more than what I anticipated. To show my appreciation, I would be willing to test future updates for you. Kind regards, Ran

Installed updated Makefile.

root@mail:~/danectl-0.6# make install
mkdir -p /usr/local/bin
install -m 755 danectl /usr/local/bin
[ -x /usr/xpg4/bin/sh ] && sed 's,^#!/bin/sh$,#!/usr/xpg4/bin/sh,' < danectl > /usr/local/bin/danectl
make: *** [Makefile:57: install-bin] Error 1

Uninstalled Updated Makefile.

root@mail:~/danectl-0.6# root@mail:~/danectl-0.6# make uninstall
rm -r /usr/local/bin/danectl
rm -r /usr/local/share/man/man1/danectl.1
rm: cannot remove '/usr/local/share/man/man1/danectl.1': No such file or directory
make: *** [Makefile:68: uninstall-man] Error 1

Used pervious version of Makefile for testing.

root@mail:~/danectl-0.6# make install
mkdir -p /usr/local/bin
install -m 755 danectl /usr/local/bin
./danectl help | perl -pe 's/^([A-Z ]+)$/=head1 $1/' | pod2man --section='1' --center='User Commands' --name='DANECTL' --release='danectl-0.6' --date='20210906' --quotes=none > danectl.1
mkdir -p /usr/local/share/man/man1
install -m 644 danectl.1 /usr/local/share/man/man1

Remvoed existing .danectl file.

root@mail:~/danectl-0.6# cd
root@mail:~# rm .danectlrc
root@mail:~# danectl certbot certonly --nginx --agree-tos --no-eff-email
root@mail:~# cat .danectlrc
certbot_command="certonly"
certbot_options="--nginx --agree-tos --no-eff-email"

Executed danectl new.

root@mail:~# danectl new example.com mail.example.com mta-sts.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for example.com and 2 more domains

Successfully received certificate.

Verify symbolic link was created.

root@mail:/etc/letsencrypt/current# ll
total 8
drwxr-xr-x  2 root root 4096 Sep 17 08:07 ./
drwxr-xr-x 11 root root 4096 Sep 17 08:07 ../
lrwxrwxrwx  1 root root   46 Sep 17 08:07 example.com -> /etc/letsencrypt/live/example.com/

Added services to reload.

root@mail:~# danectl add-reload example.com nginx spamassassin postfix dovecot
root@mail:~# danectl show-reload example.com
nginx spamassassin postfix dovecot

Added tlsa.

root@mail:~# danectl add-tlsa example.com _25._tcp.mail _465._tcp.mail _587._tcp.mail
root@mail:~# danectl show-tlsa example.com
_25._tcp.mail _465._tcp.mail _587._tcp.mail

Executed tlsa-current.

root@mail:~# danectl tlsa-current example.com
; example.com current
_25._tcp.mail.example.com. IN      TLSA    3 1 1 0e900c1ba99bd915636b47a38d43090a72030429e030a6e48758b2993ce228b3
_465._tcp.mail.example.com.        IN      TLSA    3 1 1 0e900c1ba99bd915636b47a38d43090a72030429e030a6e48758b2993ce228b3
_587._tcp.mail.example.com.        IN      TLSA    3 1 1 0e900c1ba99bd915636b47a38d43090a72030429e030a6e48758b2993ce228b3

Executed danectl dup.

root@mail:~# danectl dup example.com mail.example.com mta-sts.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for example.com and 2 more domains
Successfully received certificate.

Executed danectl tlsa-next

root@mail:~# danectl tlsa-next example.com
; example.com next
_25._tcp.mail.example.com. IN      TLSA    3 1 1 4e39d7f4b2ffec6831ddbb1046ff97ea31f31b1fb7515696cf80e273ccec0e8c
_465._tcp.mail.example.com.        IN      TLSA    3 1 1 4e39d7f4b2ffec6831ddbb1046ff97ea31f31b1fb7515696cf80e273ccec0e8c
_587._tcp.mail.example.com.        IN      TLSA    3 1 1 4e39d7f4b2ffec6831ddbb1046ff97ea31f31b1fb7515696cf80e273ccec0e8c

Executed danectl rollover. (Note service not found because I had not completed my setup for this test environment).

root@mail:~# danectl rollover example.com
Failed to reload spamassassin.service: Unit spamassassin.service not found.
Failed to reload postfix.service: Unit postfix.service not found.
Failed to reload dovecot.service: Unit dovecot.service not found.
;; Remove the following old records from the DNS
;; example.com previous
;_25._tcp.mail.example.com.        IN      TLSA    3 1 1 0e900c1ba99bd915636b47a38d43090a72030429e030a6e48758b2993ce228b3
;_465._tcp.mail.example.com.       IN      TLSA    3 1 1 0e900c1ba99bd915636b47a38d43090a72030429e030a6e48758b2993ce228b3
;_587._tcp.mail.example.com.       IN      TLSA    3 1 1 0e900c1ba99bd915636b47a38d43090a72030429e030a6e48758b2993ce228b3
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for example.com and 2 more domains
Reloading nginx server after certificate renewal
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; Publish the following new records in the DNS
; example.com next
_25._tcp.mail.example.com. IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa
_465._tcp.mail.example.com.        IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa
_587._tcp.mail.example.com.        IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa

Executed danectl tlsa-next.

root@mail:~# danectl tlsa-next example.com
; example.com next
_25._tcp.mail.example.com. IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa
_465._tcp.mail.example.com.        IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa
_587._tcp.mail.example.com.        IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa

Executed danectl tlsa-check.

root@mail:~# danectl tlsa-check example.com
; Missing example.com current (must be published)
_25._tcp.mail.example.com. IN      TLSA    3 1 1 4e39d7f4b2ffec6831ddbb1046ff97ea31f31b1fb7515696cf80e273ccec0e8c
_465._tcp.mail.example.com.        IN      TLSA    3 1 1 4e39d7f4b2ffec6831ddbb1046ff97ea31f31b1fb7515696cf80e273ccec0e8c
_587._tcp.mail.example.com.        IN      TLSA    3 1 1 4e39d7f4b2ffec6831ddbb1046ff97ea31f31b1fb7515696cf80e273ccec0e8c
; Missing example.com next (must be published)
_25._tcp.mail.example.com. IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa
_465._tcp.mail.example.com.        IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa
_587._tcp.mail.example.com.        IN      TLSA    3 1 1 a1a618a2578141871f8ac8694d934aa0623c59300eab354c2bb62acf0e0603fa
;; Superfluous example.com (should be removed)
;_25._tcp.mail.example.com.        TLSA    3 1 1 1cba5d8786a4afb554afd0b0f83e1e76f483ee8ade8a0e77521741f2dd059b47
;_25._tcp.mail.example.com.        TLSA    3 1 1 ae3f05a040a9a7ffe025b02457e4bf7ea8a4dcae5560942dad0db043cf80b638
;_465._tcp.mail.example.com.       no TLSA record
;_587._tcp.mail.example.com.       no TLSA record

[ran-deh]

Thanks. That doesn't show exactly what /bin/sh is,

If you can share a command(s) to show what /bin/sh is I would appreciate that.

[raforg]

On Fri, Sep 17, 2021 at 06:12:47AM -0700, ran-deh @.***> wrote:

I saw that you had updated the Makefile, so I started with the latest version but reverted to the previous version when I saw an error. Everything else worked perfectly for the updates to danectl.

Oops. Sorry about that. That's fixed now. And I've also fixed the make uninstall problem where it complained when trying to uninstall the manpage that wasn't there (although it's wierd that it wasn't there but danectl was installed).

Again, thank you for creating danectl. This is what I was looking for when I came across your post https://community.letsencrypt.org/t/a-dane-friendly-certbot-workflow/158324/2 . Actually, it is a lot more than what I anticipated. To show my appreciation, I would be willing to test future updates for you. Kind regards, Ran

That's very kind. Thank you. You've been a tremendous help in improving danectl. It's much better now than it was.

[raforg]

On Fri, Sep 17, 2021 at 06:14:50AM -0700, ran-deh @.***> wrote:

Thanks. That doesn't show exactly what /bin/sh is,

If you can share a command(s) to show what /bin/sh is I would appreciate that.

This should do it:

ls -l /bin/sh

It should show something like this:

lrwxrwxrwx 1 root root 4 Dec 11  2020 /bin/sh -> dash

/bin/sh isn't a symlink on every system, so it can be hard to tell, but it is a symlink to dash on debian and ubuntu.

By the way, I've submitted a bugreport for dash to ubuntu, pointing out that the behaviour of "$@" in « local v="$@" » is very different to the behaviour of /bin/sh on debian, macos, freebsd and solaris (except that the bourne shell on solaris is /usr/xpg4/bin/sh and its /bin/sh doesn't support « local » at all), and that it's even different to the behaviour in (non-local) « v="$@" ». They probably won't fix it, because any change to a shell will break something. :-) But it is the odd one out, and that's not helpful, so they might.

[ran-deh]

So the output for my bash is: lrwxrwxrwx 1 root root 4 Jul 18 2019 /bin/sh -> dash

I tested the make install and uninstall and there are no errors.

Kind regards, Ran

[raforg]

That's great to hear. Many thanks for all your help.

cheers, raf