Home / server / Questions / 814885
Accepted
James B. Byrne
Asked: 2016-11-15 14:13:30 +0800 CST

DANE Trust Anchor - Self-signed or not

  • 772

We run a private CA and employ both DNSSEC and DANE. Recently we decided to reissue our CA root and issuer keys as these were generated at 1024 bits when our PKI was set up in 2008. Our original TLSA RR pointed to the issuing CA as the trust anchor. However re-reading the RFCs and various DANE related commentary raises the question of whether the ROOT public key should be used instead.

We are presently trialling this idea parallel to our existing DANE records. When we use https://dane.sys4.de/smtp/ to validate then our existing server key checks out, but the new ROOT TLSA record is also reported even though we have not switched the server key over to the new certificate chain. Further, the new trust anchor TLSA RR is reported thus:

Usable TLSA Records

2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)

Whereas the current TLSA RR for the same host is reported this way:

2, 0, 2 67274b3554289058[...]5fd3917510e6722a

The first record reported refers to the new Root CA. The second refers to the original Issuing CA (signed by the original Root CA).

When I check for the message self signed certificate in certificate chain: (19) the impression I form is that this is an error. However, if it is an error then exactly where does the CA Root public key fit into the DANE scheme?

domain-name-system dnssec

1 Answers

  1. Best Answer

    What I discovered through experimentation is this:

    If one places both the root and the issuing CA TLSA RRs in the DNS forward zone then the error reported above disappears. For example:

    Given this host RR:

    _443._tcp.inet04.hamilton.harte-lyne.ca.        300 IN  CNAME   _tlsa._dane.trust.harte-lyne.ca.

    If only the following record exists for the self-signed root CA in the forward zone then we see the error (or warning I am not sure which it is) reported in the original question:

    ;# CA_HLL_ROOT_2016 public key hashed sha512 Trust Anchor (active)
_tlsa._dane.trust.harte-lyne.ca.        300 IN  TLSA    ( 2 1 2 
c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b
17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e )

    Checking with this test site:

    https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca

    Produces this error or warning:

    Usable TLSA Records
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)

    However if the following TLSA RR is added for the issuing CA signed by the root CA together with the self-signed root CA; and the host RR remains unchanged; then both TLSA RRs are reported as usable without any error or warning message:

    ;# CA_HLL_ISSUER_2016 public key hashed sha512 Trust Anchor (active)
_tlsa._dane.trust.harte-lyne.ca.        300 IN  TLSA    ( 2 1 2 
380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c5
89b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f )

    Visiting the test site after the TTL expiry:

    https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca

    Gives this:

    Usable TLSA Records
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e
2, 1, 2 380259229e21a194[...]435a2a3e83c1f80f

    The inference being that a self-signed certificate is 'possibly' valid but untrusted, while the complete certificate chain is both valid and trusted.

    I would like to have the mechanics of the process explained nonetheless.

    • 0