> On Jan 21, 2018, at 4:07 PM, Danny Horne <da...@trisect.uk> 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.
