From 79d74bd4c893abfc2f12b597349225b7fa4a4254 Mon Sep 17 00:00:00 2001 From: Dennis Baaten Date: Fri, 12 Apr 2019 16:38:23 +0200 Subject: [PATCH] Updated DANE How to (markdown) --- DANE-How-to.md | 64 +++++++++++++++++++++++--------------------------- 1 file changed, 29 insertions(+), 35 deletions(-) diff --git a/DANE-How-to.md b/DANE-How-to.md index 418d45c..74e0ed4 100644 --- a/DANE-How-to.md +++ b/DANE-How-to.md @@ -20,65 +20,59 @@ This part of the How-to describes the steps that should be taken with regard to * Mailserver is operational ## Generating DANE records -**primairy mailserver (mail1.example.com)** +**Primairy mailserver (mail1.example.com)** Generate the DANE SHA-256 hash with `openssl x509 -in /path/to/primairy-mailserver.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256`. This command results in the following output. > (stdin)= 29c8601cb562d00aa7190003b5c17e61a93dcbed3f61fd2f86bd35fbb461d084 -**secundairy mailserver (mail2.example.com)** +**Secundairy mailserver (mail2.example.com)** + For the secundairy mailserver we generate the DANE SHA-256 hash using `openssl x509 -in /path/to/secundairy-mailserver.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256`. This command results in the following output. > (stdin)= 22c635348256dc53a2ba6efe56abfbe2f0ae70be2238a53472fef5064d9cf437 ## Publishing DANE records -Configuration options -* Selector field is "1" because we used the certificates' public key to generate DANE hash/signature -* Usage is "3". In this case we generated a DANE hash of the leaf certificate itself. Therefore we use usage field "3" (DANE-EE: Domain Issued Certificate) -* Matching-type is "1" because we use SHA-256. +Now that we have the SHA-256 hashes, we can construct the DNS records. We make the following configuration choices: +* Usage field is "**3**"; we generated a DANE hash of the leaf certificate itself (DANE-EE: Domain Issued Certificate). +* Selector field is "**1**"; we used the certificates' public key to generate DANE hash/signature. +* Matching-type field is "**1**"; we use SHA-256. -With this information we can create a DNS record for DANE: +With this information we can create the DNS record for DANE: -`_25._tcp.mail.example.com. IN TLSA 3 1 1 29c8601cb562d00aa7190003b5c17e61a93dcbed3f61fd2f86bd35fbb461d084` -`_25._tcp.mail2.example.com. IN TLSA 3 1 1 22c635348256dc53a2ba6efe56abfbe2f0ae70be2238a53472fef5064d9cf437` +> _25._tcp.mail.example.com. IN TLSA 3 1 1 29c8601cb562d00aa7190003b5c17e61a93dcbed3f61fd2f86bd35fbb461d084 +> _25._tcp.mail2.example.com. IN TLSA 3 1 1 22c635348256dc53a2ba6efe56abfbe2f0ae70be2238a53472fef5064d9cf437 ## Generating DANE roll-over records -First we split the bundle file into multiple certificates. -`cat ca-bundle-file.crt | awk 'BEGIN {c=0;} /BEGIN CERT/{c++} { print > "bundlecert." c ".crt"}'` -In this case this results in two files: _bundlecert.1.crt_ and _bundlecert.2.crt_. +We use the provided bundle file for generating the DANE hashes belonging to the root certificate. In order to do that, we first split the bundle file into multiple certificates using `cat ca-bundle-file.crt | awk 'BEGIN {c=0;} /BEGIN CERT/{c++} { print > "bundlecert." c ".crt"}'`. In this specific case this results in two files: _bundlecert.1.crt_ and _bundlecert.2.crt_. -For each file we view the subject and the issuer. -Command -`openssl x509 -in bundlecert.1.crt -noout -subject -issuer` +For each file we view the **subject** and the **issuer**. We start with the first file using `openssl x509 -in bundlecert.1.crt -noout -subject -issuer`. This results in the following output. -Output -`subject=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA` -`issuer=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority` +> subject=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA -Command -openssl x509 -in bundlecert.2.crt -noout -subject -issuer -Output -subject=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority -issuer=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority +> issuer=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority -The second certificate (bundlecert.2.crt) is the root certficate as the subject and the issuer are the same. Root certificates are self-signed, while intermediate certificates are signed by another certificate (being a root certificate, of another intermediate certificate). +For the second file we use `openssl x509 -in bundlecert.2.crt -noout -subject -issuer`. This results in the following output. +> subject=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority + +> issuer=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority + +Based on the information of these two certificates, we can conclude that the second certificate (bundlecert.2.crt) is the root certificate; since root certificates are self-signed the **subject** and the **issuer** are the same. The other certificate (bundlecert.1.crt) is an intermediate certificate which is (in this case) signed by the root certificate. ## Publishing DANE roll-over records -In this case we select the root certificate as a roll-over anchor. +Because we prefer the root certificate to be our roll-over anchor, we generate the DANE SHA-256 hash using `openssl x509 -in bundlecert.2.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256`. This results in the following output. -Command -`openssl x509 -in bundlecert.2.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256` +> (stdin)= c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde -Output -`(stdin)= c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde` +Since both certificates for the primary and secondary come from the same Certificate Authority, they both have the same root certificate. So we don't have to repeat this with a different bundle file. -Configuration options -* Selector field is "1" because we use the certificate public key to generate DANE hash/signature -* Usage is "2". In this case I generated a DANE hash of a certificate in the chain the chain of trust, instead of the certificate itself. Therefore we use usage field "2" (DANE-TA: Trust Anchor Assertion) -* Matching-type is "1" because I use SHA-256. +Now that we have the SHA-256 hash, we can construct the DANE roll-over DNS records. We make the following configuration choices: +* Usage field is "**2**"; we generated a DANE hash of the root certificate which is in the chain the chain of trust of the actual leaf certificate (DANE-TA: Trust Anchor Assertion). +* Selector field is "**1**"; because we use the root certificate's public key to generate a DANE hash. +* Matching-type field is "**1**"; because we use SHA-256. With this information we can create a rollover DNS record for DANE: -`_25._tcp.mail.traxotic.net. IN TLSA 2 1 1 c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde` -`_25._tcp.mail2.traxotic.net. IN TLSA 2 1 1 c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde` +> _25._tcp.mail.example.com. IN TLSA 2 1 1 c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde +> _25._tcp.mail2.example.com. IN TLSA 2 1 1 c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde ## Configuring mailserver