I have been working on a renew-hook for letsencrypt/certbot.
The idea was that it would generate new TLSA records when the certificates were updated, automatically install them and automatically remove the old ones after a suitable delay.
While I was putting it together I made some assumptions about the environment that TLSA records would be found in, in particular the DNS configuration. It seems I am probably wrong.
Is an automatic TLSA update system worth doing? Are the prerequisites that I think might make it work too onerous. Eg. Linux servers, need SRV records in order to determine the port and host for each TLSA record.
John A
I'm not sure what you mean by linux servers need SRV records. SRV is not a linux thing, and linux doesn't need them.
It could be whatever application you are using needs SRV records though.
My use case is for https (really for my own personal use) and smtp, and my hook script to install and remove tlsa records works perfect, and no SRV records are used.
Quoting john john@klam.ca:
I have been working on a renew-hook for letsencrypt/certbot.
The idea was that it would generate new TLSA records when the certificates were updated, automatically install them and automatically remove the old ones after a suitable delay.
While I was putting it together I made some assumptions about the environment that TLSA records would be found in, in particular the DNS configuration. It seems I am probably wrong.
Is an automatic TLSA update system worth doing? Are the prerequisites that I think might make it work too onerous. Eg. Linux servers, need SRV records in order to determine the port and host for each TLSA record.
John A
On Apr 26, 2017, at 12:29 PM, john john@klam.ca wrote:
Is an automatic TLSA update system worth doing?
Portability across multiple deployment architectures may be difficult, so a tool for the public is difficult. It is certainly worth doing for your own private deployment.
Linux servers, need SRV records in order to determine the port and host for each TLSA record.
For SMTP the port is always 25, and the hostnames come from the MX records, and you already need the hostnames for the certificate.
For XMPP, indeed the hostnames and ports may come from the appropriate SRV records. Once again, you'll need the hostnames to obtain the requisite certificates, with our without TLSA records in the picture.
Of course the hostnames could be in a separate configuration file, and be used to manage all of the underlying configurations:
* Generate the SRV and MX records * Configure certbot * Automate TLSA record creation
all from a single primary source managed by the administrator.
The problem is not mail servers, they tend to be fairly conventional in their setup, certainly for smtp/25. It is all the other stuff.
I started this because as a SOHO/small business I want to automate everything I can. Partly because I am away from the office fairly often, secondly if I can automate things they don't get overlooked until someone or something (eg your DANE check) complains.
From the your tone, Victor, you sound as though you may already know of a better solution.
JohnA
On 2017-04-26 1:01 PM, Viktor Dukhovni wrote:
On Apr 26, 2017, at 12:29 PM, john john@klam.ca wrote:
Is an automatic TLSA update system worth doing?
Portability across multiple deployment architectures may be difficult, so a tool for the public is difficult. It is certainly worth doing for your own private deployment.
Linux servers, need SRV records in order to determine the port and host for each TLSA record.
For SMTP the port is always 25, and the hostnames come from the MX records, and you already need the hostnames for the certificate.
For XMPP, indeed the hostnames and ports may come from the appropriate SRV records. Once again, you'll need the hostnames to obtain the requisite certificates, with our without TLSA records in the picture.
Of course the hostnames could be in a separate configuration file, and be used to manage all of the underlying configurations:
- Generate the SRV and MX records
- Configure certbot
- Automate TLSA record creation
all from a single primary source managed by the administrator.
On Apr 26, 2017, at 1:31 PM, john john@klam.ca wrote:
From your tone, Victor, you sound as though you may already know of a better solution.
An design principle is not a solution. I don't have a concrete alternative. All I'm saying is that I'd gather the key data in one place, manage it there, and drive multiple systems from a common data store.
''' /chuckle ''' /Which is what I thought I could use the DNS for. you live and learn
Thanks for the input.
JohnA
participants (4)
-
john -
John
-
Patrick Domack -
Viktor Dukhovni