Letsencrypt *never* generates keys for you. He talked about the lezsencrypt client he uses, which generates a key locally, submits a CSR to letsencrypt and provides 2 files (the generated key and the obtained certificate) afterwards.
Am 2. Oktober 2019 04:25:44 MESZ schrieb Olivier <olivier.nic...@cs.ait.ac.th>: >Viktor Dukhovni <postfix-us...@dukhovni.org> writes: > >>> On Oct 1, 2019, at 12:39 PM, linkcheck <post...@linkcheck.co.uk> >wrote: >>> >>> Letsencrypt supplies 2 files. I don't think it combines them inso a >single >>> one, though I may be wrong. I know it's possible to combine them on >the >>> server but the auto-update of the cert then becomes complicated. >> >> That's mostly OK. You can use two files if you wish, there's a tiny >> chance of a Postfix SMTP server reading a mismatched pair of key and >> cert during a rollover, if you're changing both the cert and the key. >> >> This can be avoided by staging a single file with both, which is >> verified to have a matching key and cert before it atomically >> replaces the live Postfix key + cert file. > >But why letting let's Encrypt generate your key file? > >Generate your own key file, so you can be sure that the private key has >never been seen by anymody. > >Generate your csr and use that csr to have it signed by Let's Encrypt. > >That way, you only get one certificate file to install, no risk of >atomic race gap. > >The key and csr can be reused as much as you like, they don't expire >unless you want to do so, so it is 10 minutes well used. > >Possibly, I check about it, but I haven't yet faced the case since I >use >let's Encrypt, the intermediate ca could change, but in that case, >having your own key or a key provided by ;let's Encrypt woul dnot >change >anything to the proble, you'd have to reinstall the new intermediate >ca, >with a possible race condition in the mean time. > >Best regards, > >Olivier >--
