Re: certificate creation in postinst, potentially using letsencrypt script
On 2 August 2015 16:20:51 CEST, Jonas Smedegaard <dr@jones.dk> wrote:
>Quoting Marco d'Itri (2015-08-02 12:36:19)
>> On Aug 02, Daniel Pocock <daniel@pocock.pro> wrote:
>>
>>> Does anybody prefer to see packages create certificates during
>>> postinst or is there any preference not to try that and let people
>do
>>> so manually?
>> There is no point in trying to get a certificate from letsencrypt
>> every time you install a package if you already have one that you
>want
>> to use.
>
>On the other hand, there is a point in extending ssl-cert to optionally
>
>use letsencrypt.
>
>E.g. this debconf question during install:
>
> a) Always use self-signed cert (a.k.a. Snakeoil cert) [default]
> b) Ask each time which cert to use
>
>..and then some routine (e.g. debconf with custom throw-away cache)
>triggered when b) is selected, which by default uses Snakeoil (which is
>
>then also used when in non-interactive mode) but consulting a conf.d
>list of alternatives that might include letsinclude package and a
>custom
>local script for a sysadmin using some other custom routine.
>
>I am not volunteering to extend the script, just sharing the idea here.
>
I apologize for not being more explicit, this is the sort of thing I was thinking too, it wouldn't be up to dpkg or postinst to guess or insist on a particular CA. Rather, it would be an optional prompt and there would be some script or function that postinst can call to help out.
Having such a script would then mean having some menu where people can choose between letsencrypt or manual CSR or anything else that appears in future.
Having the certificates in standard locations and using standard filenames would mean such a script could use existing certificates, sharing them between packages. This may also require some attention to managing groups for reading the private keys.
A further issue that comes to mind is automatically managing different variations of PEM file. Some applications require the intermediate certs to be in the same PEM file as the server cert. Some require a PEM file containing both server cert and private key. Having standard filenames and locations for each permutation and a utility to recreate all the permutations each time the cert is renewed would make TLS much easier to support.
Reply to: