Git/email-toolbox-wiki
1
0
Fork 0
mirror of https://github.com/internetstandards/toolbox-wiki.git synced 2024-11-22 02:51:36 +01:00
Code Issues Packages Projects Releases Wiki Activity

Updated DANE How to (markdown)

Browse Source
This commit is contained in:
Dennis Baaten 2019-04-12 16:38:23 +02:00
parent 512270d38f
commit 79d74bd4c8
1 changed files with 29 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
DANE-How-to.md
View File

@ -20,65 +20,59 @@ This part of the How-to describes the steps that should be taken with regard to
* Mailserver is operational * Mailserver is operational
## Generating DANE records ## 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. 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 > (stdin)= 29c8601cb562d00aa7190003b5c17e61a93dcbed3f61fd2f86bd35fbb461d084
**secundairy mailserver (mail2.example.com)** **Secundairy mailserver (mail2.example.com)**
For the secundairy mailserver we generate the DANE SHA-256 hash using 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. `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 > (stdin)= 22c635348256dc53a2ba6efe56abfbe2f0ae70be2238a53472fef5064d9cf437
## Publishing DANE records ## Publishing DANE records
Configuration options Now that we have the SHA-256 hashes, we can construct the DNS records. We make the following configuration choices:
* Selector field is "1" because we used the certificates' public key to generate DANE hash/signature * Usage field is "**3**"; we generated a DANE hash of the leaf certificate itself (DANE-EE: Domain Issued Certificate).
* 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) * Selector field is "**1**"; we used the certificates' public key to generate DANE hash/signature.
* Matching-type is "1" because we use SHA-256. * 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.mail.example.com. IN TLSA 3 1 1 29c8601cb562d00aa7190003b5c17e61a93dcbed3f61fd2f86bd35fbb461d084
`_25._tcp.mail2.example.com. IN TLSA 3 1 1 22c635348256dc53a2ba6efe56abfbe2f0ae70be2238a53472fef5064d9cf437` > _25._tcp.mail2.example.com. IN TLSA 3 1 1 22c635348256dc53a2ba6efe56abfbe2f0ae70be2238a53472fef5064d9cf437
## Generating DANE roll-over records ## Generating DANE roll-over records
First we split the bundle file into multiple certificates. 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_.
`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_.
For each file we view the subject and the 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.
Command
`openssl x509 -in bundlecert.1.crt -noout -subject -issuer`
Output > subject=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
`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`
Command > issuer=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
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
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 ## 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 > (stdin)= c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde
`openssl x509 -in bundlecert.2.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256`
Output 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.
`(stdin)= c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde`
Configuration options Now that we have the SHA-256 hash, we can construct the DANE roll-over DNS records. We make the following configuration choices:
* Selector field is "1" because we use the certificate public key to generate DANE hash/signature * 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).
* 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) * Selector field is "**1**"; because we use the root certificate's public key to generate a DANE hash.
* Matching-type is "1" because I use SHA-256. * Matching-type field is "**1**"; because we use SHA-256.
With this information we can create a rollover DNS record for DANE: 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.mail.example.com. IN TLSA 2 1 1 c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde
`_25._tcp.mail2.traxotic.net. IN TLSA 2 1 1 c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde` > _25._tcp.mail2.example.com. IN TLSA 2 1 1 c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde
## Configuring mailserver ## Configuring mailserver