On Sun, Nov 19, 2023 at 01:30:29PM +0100, Slavko via Exim-users wrote:
> > I don't recommend DANE-TA(2), and encourage use of DANE-EE(3) instead.
>
> I am far from DANE expert, but my understanding is, that DANE-TA is
> good for own CAs, where one have full control on (intermediate) CA's
> certs and its renews.
Ah, yes, most users of DANE-TA(2) use it with a public CA, but indeed
the story is very different with a self-managed CA, where it does make
more sense, because you're then not subject to the whims and lax (DV)
issuance practices of the public CA.
> If one use that for foreign CA, soon or latter can meet unexpected CA
> certificate replace, and monitoring can only avoid to problem persist
> for long time, but not avoid to happen. Right?
With careful monitoring and "gating" (as you also point out), it can
be managed, but no longer the "simple" set up and neglect that the users
opting for the public CA imagined.
https://community.letsencrypt.org/t/short-chain-and-dane/208422/22?u=ietf-dane
> > You do however need to be more sophisticated about any key rollovers
> > that you do perform from time to time.
>
> IMO not as sophisticated is needed. I still don't use DANE yet, but i am
> in stage of preparation for it.
Preparing, is exactly what's missing from some naïve users' practice.
> For now i have SMTP's cert with persistent key already. I have deploy
> (shell) script on MX, which detects certificate change (systemd's path
> unit), and on change it compares old and new cert's keys and if they
> match, it copies new certificate to right place (and exim auto-reloads
> it). This part works for some time (months) already.
It is possible for the path unit to fail to run, but the ACME client
believes it is done. Does systemd's path unit guarantee "at least once"
execution.
> If keys doesn't match, it has to reject cert update/replace and
> notifies me (as i need manually modify DNS), but this part is not
> tested yet.
I called that "gating" in the linked thread. You're (at least compared
to most :-) a sophisticated user.
> > I have a partial (usabel work-in-progress) solution to that workflow
> > for "certbot" in the form of:
> >
> > https://github.com/tlsaware/danebot
> >
> > Any motivated and suitably skilled volunteers?
>
> I take quick look on it. I am not very open to "wrapper" solution. Does
> it something, what is not possible from certbot's deploy hook?
Yes, but the wrapper addresses two issues that are difficult without it.
* Staging a future key, that the ACME client will conditionally
switch to, once the TLSA record is live.
* Avoiding reliance on "certbot" hooks, which (last I checked) don't
guarantee "at least once" execution.
--
Viktor.
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
