Setting up Dane again from start
Hi,
just from start i did the following steps:
1.) Our DNS provider has secured the domain veka.com with DNSSEC: http://dnssec-debugger.verisignlabs.com/veka.com
2.) I’ve computed "openssl x509 -in mail.veka.com.crt -outform DER | openssl sha256“ the 256bit hash from the complete certificate chain which is used by Postfix as well. 04459a87d803ee5d2450114c09e8370dc51b27716431378cfa5560e153aed957
3.) Our DNS provider has added this to the domain and has signed it again (no idea why there is a blank!). _*._tcp.mail.veka.com. 3600 IN TLSA 3 0 1 04459A87D803EE5D2450114C09E8370DC51B27716431378CFA5560E1 53AED957
4.) I am still getting the error https://dane.sys4.de/smtp/veka.com
In TLSA 3 0 1 should be correct, right? I ma using the whole certificate chain for the hash, the same certificate file i’ve configured within Postfix. _*._tcp.mail.veka.com. should be also working!
So what might be the problem now?
Kind regards! Frank -- Frank Fiene IT-Security Manager VEKA Group
Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com http://www.veka.com
PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW
VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
On 2/11/2015 6:07 AM, Frank Fiene wrote:
Hi,
just from start i did the following steps:
1.) Our DNS provider has secured the domain veka.com with DNSSEC: http://dnssec-debugger.verisignlabs.com/veka.com
2.) I’ve computed "openssl x509 -in mail.veka.com.crt -outform DER | openssl sha256“ the 256bit hash from the complete certificate chain which is used by Postfix as well. 04459a87d803ee5d2450114c09e8370dc51b27716431378cfa5560e153aed957
3.) Our DNS provider has added this to the domain and has signed it again (no idea why there is a blank!). _*._tcp.mail.veka.com. 3600 IN TLSA 3 0 1 04459A87D803EE5D2450114C09E8370DC51B27716431378CFA5560E1 53AED957
4.) I am still getting the error https://dane.sys4.de/smtp/veka.com
In TLSA 3 0 1 should be correct, right? I ma using the whole certificate chain for the hash, the same certificate file i’ve configured within Postfix. _*._tcp.mail.veka.com. should be also working!
So what might be the problem now?
Kind regards! Frank -- Frank Fiene IT-Security Manager VEKA Group
Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com http://www.veka.com
PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW
VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
I am not 100% certain, but I don't think you can use _*.tcp...... I think it has to be an actual port. In this case _25._tcp. ma.......
That should have read - I am not 100% certain, but I don't think you can use _*._tcp...... I think it has to be an actual port. In this case _25._tcp. ma.......
Damned, don’t any short documentation. :-(
I’ve seen this on a website with a howto.
I will test with all smtp Ports. This should work for pop3s and imaps, too, shouldn’t it? What is about pop3 and imap with TLS, the same?
Frank
Am 11.02.2015 um 12:44 schrieb John john@klam.ca:
That should have read - I am not 100% certain, but I don't think you can use _*._tcp...... I think it has to be an actual port. In this case _25._tcp. ma.......
John Allen KLaM
How many of you believe in telekinesis? Raise my hand...
Viele Grüße! i.A. Frank Fiene -- Frank Fiene IT-Security Manager VEKA Group
Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com http://www.veka.com
PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW
VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
On 2/11/2015 6:59 AM, Frank Fiene wrote:
Damned, don’t any short documentation. :-(
I’ve seen this on a website with a howto.
I will test with all smtp Ports. This should work for pop3s and imaps, too, shouldn’t it? What is about pop3 and imap with TLS, the same?
Frank
Am 11.02.2015 um 12:44 schrieb John john@klam.ca:
That should have read - I am not 100% certain, but I don't think you can use _*._tcp...... I think it has to be an actual port. In this case _25._tcp. ma.......
John Allen KLaM
How many of you believe in telekinesis? Raise my hand...
Viele Grüße! i.A. Frank Fiene -- Frank Fiene IT-Security Manager VEKA Group
Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com http://www.veka.com
PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW
VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
This is my setup for smtp and submission -
_25._tcp.smtp.klam.ca. IN CNAME tlsa301a._dane.klam.ca. _587._tcp.smtp.klam.ca. IN CNAME tlsa301a._dane.klam.ca. tlsa301a._dane.klam.ca. IN TLSA ( 3 0 1 5bf12300255d
The credit for this goes to Viktor Dukhovni who advised me on how to set it up, without his input I would still be flailing around.
Am Mittwoch, 11. Februar 2015, 07:16:54 schrieb John:
On 2/11/2015 6:59 AM, Frank Fiene wrote:
Damned, don’t any short documentation. :-(
I’ve seen this on a website with a howto.
I will test with all smtp Ports. This should work for pop3s and imaps, too, shouldn’t it? What is about pop3 and imap with TLS, the same?
Frank
Am 11.02.2015 um 12:44 schrieb John john@klam.ca:
That should have read - I am not 100% certain, but I don't think you can use _*._tcp...... I think it has to be an actual port. In this case _25._tcp. ma....... -- John Allen KLaM
How many of you believe in telekinesis? Raise my hand...
Viele Grüße! i.A. Frank Fiene -- Frank Fiene IT-Security Manager VEKA Group
Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com http://www.veka.com
PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW
VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
This is my setup for smtp and submission -
_25._tcp.smtp.klam.ca. IN CNAME tlsa301a._dane.klam.ca. _587._tcp.smtp.klam.ca. IN CNAME tlsa301a._dane.klam.ca. tlsa301a._dane.klam.ca. IN TLSA ( 3 0 1 5bf12300255d
The credit for this goes to Viktor Dukhovni who advised me on how to set it up, without his input I would still be flailing around.
Yes. Carsten wrote a nice article in German. https://sys4.de/de/blog/2014/05/24/einen-tlsa-record-fuer-dane-mit-bind-9-pu...
It is really time to translate that doc.
Mit freundlichen Grüßen,
Michael Schwartzkopff
On Wed, Feb 11, 2015 at 12:59:01PM +0100, Frank Fiene wrote:
This should work for pop3s and imaps, too, shouldn?t it? What is about pop3 and imap with TLS, the same?
For a shared key for multiple services that use distinct protocols:
_dane.mail.example.com. IN TLSA 3 1 1 <sha256 SPKI digest> _25._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _110._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _143._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _587._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _993._tcp.mail.example.com. IN CNAME _dane.mail.example.com.
This only makes sense if you need the certificate to be from a public CA trusted by some SMTP/IMAP/POP clients. For port 25, you should just go with a distinct self-signed key. Not sharing keys avoids simultaneously breaking all the services that share that key when a mistake is made during key rotation.
To generate the "3 1 1" SPKI digest:
printf '_dane.%s. IN TLSA 3 1 1 %s\n' \ mail.example.com \ $(openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')
* Never make the mistake of using a certificate digest with a "3 1 1" TLSA record or an SPKI (i.e. SubjectPublicKeyInfo or, in other words, the public key algorithm id, parameters and key bits) digest with a "3 0 1" TLSA record.
* Never make the mistake of installing a new key or certificate without following the TLSA record update process described in:
http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1 http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4
That DNS setup looks better, thx.
For this time i will go for the CA-signed certificate.
Am 11.02.2015 um 17:55 schrieb Viktor Dukhovni ietf-dane@dukhovni.org:
On Wed, Feb 11, 2015 at 12:59:01PM +0100, Frank Fiene wrote:
This should work for pop3s and imaps, too, shouldn?t it? What is about pop3 and imap with TLS, the same?
For a shared key for multiple services that use distinct protocols:
_dane.mail.example.com. IN TLSA 3 1 1 <sha256 SPKI digest> _25._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _110._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _143._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _587._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _993._tcp.mail.example.com. IN CNAME _dane.mail.example.com.
This only makes sense if you need the certificate to be from a public CA trusted by some SMTP/IMAP/POP clients. For port 25, you should just go with a distinct self-signed key. Not sharing keys avoids simultaneously breaking all the services that share that key when a mistake is made during key rotation.
To generate the "3 1 1" SPKI digest:
printf '_dane.%s. IN TLSA 3 1 1 %s\n' \ mail.example.com \ $(openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')
- Never make the mistake of using a certificate digest with a "3 1 1"
TLSA record or an SPKI (i.e. SubjectPublicKeyInfo or, in other words, the public key algorithm id, parameters and key bits) digest with a "3 0 1" TLSA record.
- Never make the mistake of installing a new key or certificate without
following the TLSA record update process described in:
http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1 http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4
-- Viktor.
Viele Grüße! i.A. Frank Fiene -- Frank Fiene IT-Security Manager VEKA Group
Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com http://www.veka.com
PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW
VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
On Wed, Feb 11, 2015 at 06:20:32PM +0100, Frank Fiene wrote:
That DNS setup looks better, thx.
For a shared key for multiple services that use distinct protocols:
_dane.mail.example.com. IN TLSA 3 1 1 <sha256 SPKI digest> _25._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _110._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _143._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _587._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _993._tcp.mail.example.com. IN CNAME _dane.mail.example.com.
Note, I am not aware of any IMAP, POP or SMTP submission client software that uses DANE, so the records for ports other than 25 are largely pointless at present.
On 2/11/2015 12:25 PM, Viktor Dukhovni wrote:
On Wed, Feb 11, 2015 at 06:20:32PM +0100, Frank Fiene wrote:
That DNS setup looks better, thx.
For a shared key for multiple services that use distinct protocols:
_dane.mail.example.com. IN TLSA 3 1 1 <sha256 SPKI digest> _25._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _110._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _143._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _587._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _993._tcp.mail.example.com. IN CNAME _dane.mail.example.com.
Note, I am not aware of any IMAP, POP or SMTP submission client software that uses DANE, so the records for ports other than 25 are largely pointless at present.
Just curious, you put the actual TLSA record first and then the CNAMEs. Any particular reason for the order?
On Wed, Feb 11, 2015 at 06:19:16PM -0500, John wrote:
Just curious, you put the actual TLSA record first and then the CNAMEs. Any particular reason for the order?
Clarity of exposition. You're outsourcing thinking about this to the list.
* A DNS zone is a key-value database:
(owner-name, class, type) => RRset
* As with any key-value database the relative order of keys cannot be significant.
* Even the relative order of RRs within an RRset is not significant for DNSSEC purposes, as the RRset signature is calculated over the canonical ordering. So RRsets in which the order matters cannot rely on DNSSEC to protect that order.
John wrote:
Just curious, you put the actual TLSA record first and then the CNAMEs. Any particular reason for the order?
the order of records in a zonefile has no impact on, it is purely for us humans and a matter of taste.
A DNS server will read the zonefile and will create a binary in-memory data-structure.
Carsten
Hello Frank,
Frank Fiene wrote:
3.) Our DNS provider has added this to the domain and has signed it again (no idea why there is a blank!). _*._tcp.mail.veka.com. 3600 IN TLSA 3 0 1 04459A87D803EE5D2450114C09E8370DC51B27716431378CFA5560E1 53AED957
this is an incorrect use of an DNS wildcard.
See http://www.ietf.org/rfc/rfc4592
The asterisk must be the leftmost character in the domain name, an asterisk inside a domain name is just that, an asterisk. The TLSA record above does not match port 25.
The record *._tcp.mail.veka.com. 3600 IN TLSA would be valid, it would match all ports on the machine mail.veka.com, but I'm not sure if that is useful.
Best regards
Carsten Strotmann
On 11. feb. 2015 12.09.05 Frank Fiene ffiene@veka.com wrote:
So what might be the problem now?
posttls-finger veka.com
gives here Verified TLS
Thx Benny, it is working now!
You are right!
Am 11.02.2015 um 18:45 schrieb Benny Pedersen me@junc.eu:
On 11. feb. 2015 12.09.05 Frank Fiene ffiene@veka.com wrote:
So what might be the problem now?
posttls-finger veka.com
gives here Verified TLS
Viele Grüße! i.A. Frank Fiene -- Frank Fiene IT-Security Manager VEKA Group
Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com http://www.veka.com
PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW
VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
participants (7)
-
Benny Pedersen -
Carsten Strotmann (sys4) -
Frank Fiene -
John -
John Allen
-
Michael Schwartzkopff -
Viktor Dukhovni