Self-signed TLS certificates
Hi all, Apologies if this has been discussed before, but currently I use self-signed certificates on my Postfix servers for TLS negotiation, I'm doing this mainly to keep the costs down. As far as I'm aware I don't have any problems sending / receiving email to / from the major providers, but could that change in the future? Could the likes of Google start insisting on a chain of trust for mail delivery? I see wildcard SSL certificates are coming down in price, I use SSL on one or two websites and am starting to consider one of these to cover everything I do. Am I right in assuming a standard wildcard SSL certificate will be usable on both web and email servers? Thanks for looking
Re: Request for feedback on SMTPD restrictions
On 1/20/2018 11:56 PM, J Doe wrote: > Hi, > > I have a basic SMTP server set up with what I believe to be good smtpd_*_ > restrictions, but I was wondering if anyone could provide any insight on how > to improve them or if I have been redundant in the restrictions. Even with > reading the man pages, I find some of the restrictions tricky. > > I am eventually having a submission service (with an -o > smtpd_relay_restrictions=permit_sasl_authenticated in master.cf), for this > server but right now what follows is just for a SMTP server on port 25. > > smtpd_client_restrictions = permit_mynetworks, > reject_unauth_pipelining, > check_client_access hash:/etc/postfix/client_acl, > reject_unknown_client_hostname, > permit reject_unknown_client_hostname is likely to reject legit mail. Use with caution. Consider instead using reject_unknown_reverse_client_hostname, which rejects clients with no PTR record. This is similar to what many large providers do and is fairly low risk. The "permit" at the end is unnecessary, but doesn't break anything. Same with all the other "permit" in restrictions below. > > smtpd_helo_required = yes > smtpd_helo_restrictions = permit_mynetworks, > reject_unauth_pipelining, > reject_invalid_helo_hostname, > reject_non_fqdn_helo_hostname, > check_helo_access hash:/etc/postfix/helo_acl, > reject_unknown_helo_hostname, > permit reject_unknown_helo_hostname is likely to reject legit mail. Use with caution. -- Noel Jones > > smtpd_sender_restrictions = permit_mynetworks, > reject_unauth_pipelining, > reject_non_fqdn_sender, > check_sender_access hash:/etc/postfix/sender_acl, > reject_unknown_sender_domain, > permit > > smtpd_recipient_restrictions = permit_mynetworks, > permit_auth_destination, > > reject > > > > smtpd_relay_restrictions = permit_mynetworks, > > permit_auth_destination, > > reject > > Thanks, > > - J >
Re: Self-signed TLS certificates
> On Jan 21, 2018, at 3:26 PM, Danny Horne wrote: > > Apologies if this has been discussed before, but currently I use > self-signed certificates on my Postfix servers for TLS negotiation, I'm > doing this mainly to keep the costs down. The current cost of TLS certificates that chain up to broadly trusted CAs is $0. For example, from Let's Encrypt. So cost should not be your primary motivation. But read on, ... > As far as I'm aware I don't have any problems sending/receiving > email to/from the major providers, but could that change in the > future? Could the likes of Google start insisting on a chain of > trust for mail delivery? This is rather unlikely in the near term. No standards exist for meaningful use of client certificates to authenticate MTA-to-MTA email transport. So certainly you won't need a CA issued cert to send email, indeed most SMTP servers don't ask for your TLS client certificate even if you're careless enough to configure one. It is possible that at some time in the future (at least 5 or more years out) valid certificate chains might be need to receive email, but there no indication that this is looming. > I see wildcard SSL certificates are coming down in price, I use > SSL on one or two websites and am starting to consider one of these > to cover everything I do. Am I right in assuming a standard wildcard > SSL certificate will be usable on both web and email servers? You *really* should AVOID wildcard certificates, they are a magnet for both security and operational issues. Get a distinct self-signed or free CA certificate for each server. Space out certificate rotation in time for the different servers that provide redundancy for each service so as to avoid a single point of failure when certificate rotation is accidentally mishandled. Finally, for SMTP, your best security gambit is DANE, and here self-signed certificates are just as good or better than CA issued certificates. You're far less likely to mess up certificate rotation when doing it yourself than when integrating certbot and forgetting to care to pre-stage DNS TLSA record updates (3 1 1) before obtaining a new cert for the underlying public key. See: http://www.postfix.org/TLS_README.html#client_tls_limits http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://www.ietf.org/mail-archive/web/uta/current/msg01498.html https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 -- Viktor.
Re: Self-signed TLS certificates
On 1/21/2018 2:26 PM, Danny Horne wrote: > Hi all, > > Apologies if this has been discussed before, but currently I use > self-signed certificates on my Postfix servers for TLS negotiation, I'm > doing this mainly to keep the costs down. As far as I'm aware I don't > have any problems sending / receiving email to / from the major > providers, but could that change in the future? Could the likes of > Google start insisting on a chain of trust for mail delivery? > Since SMTP TLS is opportunistic best-effort, it's unlikely anyone will reject self-signed certificates in the foreseeable future. A "real" certificate is useful if you have customers connecting to your server as a submission service. While self-signed certs work fine for that purpose too, sometimes it's easier to avoid talking folks into how to import your self-signed cert. > I see wildcard SSL certificates are coming down in price, I use SSL on > one or two websites and am starting to consider one of these to cover > everything I do. Am I right in assuming a standard wildcard SSL > certificate will be usable on both web and email servers? Yes, one certificate will work everywhere, but it's generally better to limit certificates for each purpose eg. a wildcard for all your websites, then either another wildcard or dedicated cert for your mail. https://letsencrypt.org/ offers free short-term renewable certificates. There are scripts available to automate renewing them. If you want to move away from self-signed certs and have limited funds, these are worth looking into. -- Noel Jones
Re: Self-signed TLS certificates
On 21/01/2018 8:47 pm, Viktor Dukhovni wrote: >> I see wildcard SSL certificates are coming down in price, I use >> SSL on one or two websites and am starting to consider one of these >> to cover everything I do. Am I right in assuming a standard wildcard >> SSL certificate will be usable on both web and email servers? > You *really* should AVOID wildcard certificates, they are a magnet > for both security and operational issues. Get a distinct self-signed > or free CA certificate for each server. Space out certificate rotation > in time for the different servers that provide redundancy for each service > so as to avoid a single point of failure when certificate rotation is > accidentally mishandled. > > Finally, for SMTP, your best security gambit is DANE, and here self-signed > certificates are just as good or better than CA issued certificates. > You're far less likely to mess up certificate rotation when doing it > yourself than when integrating certbot and forgetting to care to > pre-stage DNS TLSA record updates (3 1 1) before obtaining a new cert > for the underlying public key. > Thanks for the response Viktor, I won't ask you to expand on why wildcard certificates should be avoided (unless you want to). I use DANE, so based on what you're saying, wildcard certificates may not be cost effective for me anyway (since you advise against using them and say self-signed is fine for email)
Re: Self-signed TLS certificates
> On Jan 21, 2018, at 4:07 PM, Danny Horne wrote: > > I won't ask you to expand on why wildcard certificates should be avoided > (unless you want to). The short version: 1. People who use wildcard certs tend to DoS themselves by breaking every server with the shared key+certificate chain when incorrectly updating that key+certificate chain 2. Sharing of certificates across services enables attacks that redirect clients to the wrong service that happens to use the same certificate. 3. Sharing of certificates across services facilitates cross-protocol attacks (e.g. https://drownattack.com/) by exposing the same key material via both weak and strong protocols and implementations. > I use DANE, so based on what you're saying, > wildcard certificates may not be cost effective for me anyway (since you > advise against using them and say self-signed is fine for email) Indeed stick with what you've got. You could (if not intimidated by the logistics, but we may have more tools for you in this space soonish) also implement a private CA that signs your no-longer self-signed server cert. This makes it possible to publish "3 1 1" + "2 1 1" TLSA records, with the "2 1 1" matching the key of your private CA, with that you can rotate the server key more frequently, while keeping the CA key password protected. As it stands your DANE implementation is fine for the next ~10 years: trisect.uk. IN MX 10 mail.trisect.uk. ; NoError AD=1 trisect.uk. IN MX 20 2mail.trisect.uk. ; NoError AD=1 _25._tcp.mail.trisect.uk. IN TLSA 3 0 1 c2a13da6b4b38a329dd2671640d24045e65acbc2e1f378436cd1b466d09fe4bf ; NoError AD=1 mail.trisect.uk[87.98.165.212]: pass: TLSA match: depth = 0, name = mail.trisect.uk TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384 name = mail.trisect.uk depth = 0 Issuer CommonName = mail.trisect.uk Issuer Organization = Trisect notBefore = 2017-12-06T18:19:26Z notAfter = 2027-12-06T18:19:26Z Subject CommonName = mail.trisect.uk Subject Organization = Trisect cert sha256 [matched] <- 3 0 1 c2a13da6b4b38a329dd2671640d24045e65acbc2e1f378436cd1b466d09fe4bf pkey sha256 [nomatch] <- 3 1 1 5f328d20ab5459373e85444b0a8614c1fd18c4aa88f900b017082de1b90946e4 _25._tcp.2mail.trisect.uk. IN TLSA 3 0 1 d58b69ef28f0055f17e146338f9993e46d8e11154e2333b86978e28db5ddb3c6 ; NoError AD=1 2mail.trisect.uk[94.23.165.25]: pass: TLSA match: depth = 0, name = 2mail.trisect.uk TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384 name = 2mail.trisect.uk depth = 0 Issuer CommonName = 2mail.trisect.uk Issuer Organization = Trisect Networks notBefore = 2017-12-27T20:32:04Z notAfter = 2027-12-27T20:32:04Z Subject CommonName = 2mail.trisect.uk Subject Organization = Trisect Networks cert sha256 [matched] <- 3 0 1 d58b69ef28f0055f17e146338f9993e46d8e11154e2333b86978e28db5ddb3c6 pkey sha256 [nomatch] <- 3 1 1 6bd7eb84836144f694600d7bebea60662f2b3d1250ed3a6d2aa4fed647211eed And separate certificates for the two servers are more reliable, just don't neglect to publish new TLSA records prior to replacing the certificate of either server and do that one at a time (some weeks apart). -- Viktor.
Re: Request for feedback on SMTPD restrictions
On Sun, 21 Jan 2018 14:35:42 -0600 Noel Jones wrote: > On 1/20/2018 11:56 PM, J Doe wrote: > > Hi, > > > > I have a basic SMTP server set up with what I believe to be good > > smtpd_*_ restrictions, but I was wondering if anyone could provide > > any insight on how to improve them or if I have been redundant in > > the restrictions. Even with reading the man pages, I find some of > > the restrictions tricky. > > > > I am eventually having a submission service (with an -o > > smtpd_relay_restrictions=permit_sasl_authenticated in master.cf), > > for this server but right now what follows is just for a SMTP > > server on port 25. > > > > smtpd_client_restrictions = permit_mynetworks, > > reject_unauth_pipelining, > > check_client_access hash:/etc/postfix/client_acl, > > reject_unknown_client_hostname, > > permit > > reject_unknown_client_hostname is likely to reject legit mail. Use > with caution. > > Consider instead using reject_unknown_reverse_client_hostname, which > rejects clients with no PTR record. This is similar to what many > large providers do and is fairly low risk. > > The "permit" at the end is unnecessary, but doesn't break anything. > Same with all the other "permit" in restrictions below. > > > > > smtpd_helo_required = yes > > smtpd_helo_restrictions = permit_mynetworks, > > reject_unauth_pipelining, > > reject_invalid_helo_hostname, > > reject_non_fqdn_helo_hostname, > > check_helo_access hash:/etc/postfix/helo_acl, > > reject_unknown_helo_hostname, > > permit > > reject_unknown_helo_hostname is likely to reject legit mail. Use > with caution. > > > > -- Noel Jones > > > > > smtpd_sender_restrictions = permit_mynetworks, > > reject_unauth_pipelining, > > reject_non_fqdn_sender, > > check_sender_access hash:/etc/postfix/sender_acl, > > reject_unknown_sender_domain, > > permit > > > > smtpd_recipient_restrictions = permit_mynetworks, > > permit_auth_destination, > > > > reject > > > > > > > > smtpd_relay_restrictions = > > permit_mynetworks, > > permit_auth_destination, reject > > > > Thanks, > > > > - J > > > Doing some reading on the PTR record, I believe I've have been doing my MX record incorrectly. The reverse DNS can only point to one domain name. If you are hosting multiple domains on one server, all MX records should point to the domain name that has the PTR record. For example, suppose the "main" domain of the server is example.com. In this case, example.com has the PTR record. If you also host something.com at the same IP address, the MX record for something.com should point to example.com, not something.com. https://serverfault.com/questions/158828/ptr-record-rdns-for-multiple-domains-on-a-shared-ip-address Is my interpretation correct? As an aside, note the superfluous "permit" shows up in many guides online, but not all of them. I experimented dropping the extra permit and things worked, but put them back in anyway out of paranoia. I'm going to drop them now.
Re: Self-signed TLS certificates
On 21 Jan 2018, at 21:47, Noel Jones wrote: > On 1/21/2018 2:26 PM, Danny Horne wrote: >> Hi all, >> >> Apologies if this has been discussed before, but currently I use >> self-signed certificates on my Postfix servers for TLS negotiation, I'm >> doing this mainly to keep the costs down. As far as I'm aware I don't >> have any problems sending / receiving email to / from the major >> providers, but could that change in the future? Could the likes of >> Google start insisting on a chain of trust for mail delivery? > > Since SMTP TLS is opportunistic best-effort, it's unlikely anyone > will reject self-signed certificates in the foreseeable future. > > A "real" certificate is useful if you have customers connecting to > your server as a submission service. While self-signed certs work > fine for that purpose too, sometimes it's easier to avoid talking > folks into how to import your self-signed cert. Sadly, there are folks who think that a certificate they cannot verify all the way up to a trusted root means that they should fall back to plain text. Mailgun is an example of this, and they are quite widely used despite this and several other problems. We stopped using self-signed certificates on public-facing MTAs several years ago for reasons like this, and just went with a multi-domain certificate instead, since spending time to try and convince companies like this that this is not how it is supposed to work was more expensive, and mostly proved futile. >> I see wildcard SSL certificates are coming down in price, I use SSL on >> one or two websites and am starting to consider one of these to cover >> everything I do. Am I right in assuming a standard wildcard SSL >> certificate will be usable on both web and email servers? > > Yes, one certificate will work everywhere, but it's generally better > to limit certificates for each purpose eg. a wildcard for all your > websites, then either another wildcard or dedicated cert for your mail. > > https://letsencrypt.org/ offers free short-term renewable > certificates. There are scripts available to automate renewing > them. If you want to move away from self-signed certs and have > limited funds, these are worth looking into. Regular DV certificates can be had for less than $10/year these days, and they can be registered for 1-3 years easily. Multi-domain certificates are also a possibility, in case you want/need more than one distinct hostname on a certificate without resorting to a wildcard, or when you need hostnames under more than one distinct domain. For example, the following use case is not covered by a wildcard; mx.example.com smtp.domain.example mail.company.example But is supported by a multi-domain certificate. Let's Encrypt certificates are multi-domain certificates, by the way, and will support multiple distinct domains in the same manner. Just remember that reliably automating certificate issuance takes time too, and it tends to be really hard to compete with $10/year for one, or even a few certificates. Also, whenever you deploy certificates, make sure to monitor them. For example; openssl x509 -noout -checkend 2419200 -in /path/to/certificate-file.crt will exit with 1 if the certificate expires within four weeks, or 28 days, meaning you can easily build a cron job that checks the validity of your certificates on a daily basis, warning you whenever you should take action. Other monitoring tasks can be set up to verify the certificate from the outside, to make sure that, if something does go wrong, you have a higher likelihood of being the first one to notice. Mvg, Joni
