On Wed, Sep 28, 2016 at 01:25:42AM -0700, li...@lazygranch.com wrote: > I don't want take this thread off course, but suggestions for low cost > certs would be appreciated. I don't like how Let's Encrypt works, else > that would be the obvious solution.
I am curious what you don't like about "Let's Encrypt" it seems usable enough. But, for SMTP, it only needed if you operate a port 587 MSA for submission clients that want to see WebPKI certificates. > Domain registration isn't free. Server time isn't free. Something like > $20 a year would be fine. I already have a self signed cert for email, > but would like to eventually encrypt my websites and attempt dnssec/dane. For DNSSEC/DANE you really don't need WebPKI certs, indeed you're much better off without them. The simplest configuration is a self-signed: _25._tcp.smtp.example.com. IN TLSA 3 1 1 <server public key digest> record, which you update shortly before rolling out new keys (as and when you feel like deploying a new key). A more advanced, but ultimately more convenient, configuration, is to create your own self-signed issuing CA whose private key or at least is "passphrase" is "off-line". You then make sure that your server certificate includes the MX hostname as one of the DNS "subjectAltName" values, that your server chainfile includes the issuing CA certificate and proceed to publish two TLSA records: _25._tcp.smtp.example.com. IN TLSA 3 1 1 <server public key digest> _25._tcp.smtp.example.com. IN TLSA 2 1 1 <CA public key digest> with this configuration, you can deploy new server keys without the annoying *prior* DNS changes described in: https://tools.ietf.org/html/rfc7671#section-8.1 When you first deploy the new server key (new private key and associated certificate), provided the certificate is issued by the same private CA, the unchanged "2 1 1" record will continue to validate your server certificate. You can then update the DNS to make the "3 1 1" record match again at your leisure, after everything checks out. At some point later, you may want to replace the CA, that's easy too, just retain the working "3 1 1" record (for the same underlying private key) and get a new CA to issue a certificate for the same key. You'll now have only the "3 1 1" record matching, but that's OK, just update the "2 1 1" when all looks good. This way, you can play "leap-frog" alternating a series of key changes with period CA changes, and DNS changes only after the certificate deployments check out good. The time-line is then: Server Key 1 + CA 1 ; Initial state Server Key 2 + CA 1 ; Update "3 1 1" after Key change Server Key 3 + CA 1 ; Update "3 1 1" after Key change ... Server Key N + CA 1 ; Update "3 1 1" after Key change Server Key N + CA 2 ; Update "2 1 1" after CA change Server Key N+1 + CA 2 ; Update "3 1 1" after Key change Server Key N+2 + CA 2 ; Update "3 1 1" after Key change ... Server Key N+M + CA 2 ; Update "3 1 1" after CA change Server Key N+M + CA 3 ; Update "2 1 1" after CA change ... So long as the CA changes don't coincide with the server key changes, this substantially simplifies keeping the DNS data in sync with reality. You could then automate the DNS updates too, updating the DNS when you observer the live server vending a chain that matches the expected CA and server cert files on disk. Automating pre-publishing ala RFC7671 section 8.1 is more complex. The above approach works a bit less well for public CAs, because issuing CA changes are no longer directly under your control. When I have some time, I may enhance the "postfix tls" sub-command http://www.postfix.org/postfix-tls.1.html to support not just self-signed certs, but also a CA + leaf cert combination as described above, so that folks who are not OpenSSL CLI wizards have an easier time of getting this to work. The only complication really is that ideally the CA private key is stored encrypted with a strong offline passphrase, so that Postfix would have to prompt for a passphrase when that's the case -- Viktor.
