为什么我的RSA DANE TLSA能工作，但我的ECDSA DANE TLSA却失败了？

Question

我从Namec堆/Sectigo/Comodo购买了两个单一域的通配符SSL证书。我使用openssl以典型的方式生成了我的CSR。

$ openssl req -newkey rsa:4096 -keyout example.com.rsa.key -out example.com.rsa.csr
$ openssl genpkey -genparam -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out example.com.ecdsa.pem
$ openssl req -newkey ec:example.com.ecdsa.pem -keyout example.com.ecdsa.key -out example.com.ecdsa.csr

我提交了CSR，并得到了每个证书包(包括.crt和..ca包)，这一切都如期而至。

我能够安装这两个证书供后缀使用。每个都需要私钥的未加密版本，安全权限已被维护。

$ openssl rsa -in example.com.rsa.key -out example.com.rsa.key.unencrypted
$ openssl ec -in example.com.ecdsa.key -out example.com.ecdsa.key.unencrypted

我已经正确地设置了SPF，DKIM，DMARC和DNSSEC，每个都是由第三方工具确认的，并且已经发送和接收了带有传递分数的邮件。

我再次使用openssl为我的DANE记录生成证书的散列。我创建了两个集合，每个算法一组，以及端口25和587。这些内容被添加到my文件中，使用命名-checkzone进行检查，用dnssec-signzone签名，并在DNS中发布。

我首先使用两个外部工具来检查配置，第一个在德内切克，第二个在dane.sys4.de。两家公司都报告了使用RSA证书取得的总体成功，但都报告了ECDSA证书的具体失败。

前者成功，部分报告：

DANE TLSA 3 1 1 [9679fc29..]: OK matched EE certificate
DANE TLSA 3 1 1 [ecd29ffd..]: FAIL did not match EE certificate

后者成功，部分报告：

3, 1, 1 9679fc296960a23c[...]149b990a680cad8b *in green*
3, 1, 1 ecd29ffd76d61326[...]dadbcfa42eae9158 - unable to get local issuer certificate: (20) *in red*

我试图通过更改各种用法、选择器和匹配字段(3 0 1、31 1等)来解决这个问题。我尝试使用openssl在本地生成散列，并使用在线工具(如gen_tlsa )。这两个工具为两个证书产生相同的散列结果。同样，RSA TLSA成功，而ECDSA记录失败。我最终找到了chaingen脚本，它生成了我为每个端口包含的所有3 0 1、31 1、3 0 2和3 12散列，但对ECDSA记录没有任何改进。

我花了几个小时尝试每个证书、TLSA记录、端口等的不同排列，我尝试将ECDSA记录的父密钥的TLSA记录(2 0 1)添加到DNS中。我尝试将可用的证书更改为后缀，以便将ca包与证书一起包含在.pem文件中。

通过研究，我发现了由维克多·杜科霍夫尼( Viktor )撰写的名为“如何获得与丹麦和丹麦认证一起使用的电子商务证书”(How to cert with DANE and ec+rsa certs)的ec+rsa，他不需要在后缀/丹麦圈子里做介绍。他认为，也许这些在线工具是机会主义的，一旦它们成功了，RSA证书就不会费心用ECDSA证书进行测试了。他向openssl提供了非常有价值的调用，以表明在海报的情况下密钥确实是正确的。我使用Viktor的代码替换了我的信息，一个名为checkrsa，另一个称为checkecdsa，我用两个简短的shell脚本重复了这一工作。

这两个脚本执行两个命令，每个命令为checkrsa (用于IPv4)设置如下：

$ cat checkrsa

echo "quit" | openssl s_client -starttls smtp -connect mail.example.com:25 -4 -verify 9 \
    -dane_tlsa_domain mail.example.com \
    -dane_tlsa_rrdata "3 0 1 c487cdb079...57aaec4ac9" \
    -dane_tlsa_rrdata "3 1 1 9679fc2969...0a680cad8b" \
    -sigalgs rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512

和checkecdsa (用于IPv6)：

$ cat checkecdsa
echo "quit" | openssl s_client -starttls smtp -connect mail.example.com:25 -6 -verify 9 \
    -dane_tlsa_domain mail.example.com \
    -dane_tlsa_rrdata "3 0 1 87a8c75581...87fb13bfc5" \
    -dane_tlsa_rrdata "3 1 1 ecd29ffd76...a42eae9158" \
    -sigalgs ecdsa_secp256r1_sha256:ecdsa_secp384r1_sha384:ecdsa_secp521r1_sha512

结果：

root@server:~/bin# ./checkrsa 
verify depth is 9
CONNECTED(00000003)
depth=0 CN = *.example.com
verify return:1
---
Certificate chain
 0 s:CN = *.example.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHNDCCBhygAwIBAgIQAzfJZrX65NjG2FvLmk0I0jANBgkqhkiG9w0BAQsFADCB
...
Xw8UgZDYihDaIxT8SUQUgV9weQg5Lkru
-----END CERTIFICATE-----
subject=CN = *.example.com

issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2904 bytes and written 386 bytes
Verification: OK
Verified peername: *.example.com
DANE TLSA 3 1 1 ...99d48c44149b990a680cad8b matched EE certificate at depth 0
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 CHUNKING
DONE
root@server:~/bin# ./checkecdsa 
verify depth is 9
CONNECTED(00000003)
depth=0 CN = *.example.com
verify return:1
---
Certificate chain
 0 s:CN = *.example.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo 
ECC Domain Validation Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEqDCCBE6gAwIBAgIRAIIKQBNWh2R9wwvn2/j30PgwCgYIKoZIzj0EAwIwgY8x
...
YemreHq/Cd5HPgIgE6InSF5ko6mWo9GMpR7w1ijpbsnShlS6EiYrpZozD0s=
-----END CERTIFICATE-----
subject=CN = *.example.com

issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1811 bytes and written 348 bytes
Verification: OK
Verified peername: *.example.com
DANE TLSA 3 1 1 ...50d47bccdadbcfa42eae9158 matched EE certificate at depth 0
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 CHUNKING
DONE

因此，这两个证书都在本地签出，但继续在外部失败。

鉴于Viktor的信息表明，在RSA中成功使用的工具可能在ECDSA哈希中获得了成功，所以我也尝试过发布ECDSA记录。结果显示，仅用ECDSA散列本身就完全失败了。

因此，我可以接受这种情况:我有两组SSL证书，一个是RSA，另一个是ECDSA。这两个证书都在后缀成功。这两个证书都使用openssl签出。基于RSA证书发布这两个证书总体上通过，注意ECDSA证书失败。ECDSA证书在本地成功，但在外部失败。

我不知道从这里去哪里，并正在寻求帮助，以获得我的ECDSA证书设置与我的RSA记录的DANE平行。

Update 6/5/22

我从ca-bundle文件中添加了CA提供的ECDSA证书提供的其他信息。

首先，我创建了一个pem文件，包括cert和ca包的内容。

$ cat example.com.ecdsa.cert example.com.ecdsa.ca-bundle > example.com.ecdsa.pem.combined

我将此文件提供给main.cf中的后缀：

smtpd_tls_eccert_file=/etc/ssl/certs/example.com.ecdsa.pem.combined

接下来，我使用一个名为链根的脚本生成各种TLSA记录，并将它们添加到DNS中。

;; subject=CN = *.example.com
;; issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
;; notBefore=May 17 00:00:00 2022 GMT
;; notAfter=Jun 17 23:59:59 2023 GMT
;;
_25._tcp.mail   IN      TLSA 3 0 1      87a8c75581...87fb13bfc5
_25._tcp.mail   IN      TLSA 3 1 1      ecd29ffd76...a42eae9158
_25._tcp.mail   IN      TLSA 3 0 2      d09f24a28f...cc8e69b13d
_25._tcp.mail   IN      TLSA 3 1 2      b83f332b52...4634ec6dce

;; subject=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
;; issuer=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
;; notBefore=Nov  2 00:00:00 2018 GMT
;; notAfter=Dec 31 23:59:59 2030 GMT
;;
_25._tcp.mail   IN      TLSA 2 0 1      61e97375e9...8f5f65825f
_25._tcp.mail   IN      TLSA 2 1 1      e98044f242...db029d719a
_25._tcp.mail   IN      TLSA 2 0 2      2d44d5fbb5...33970c93c9
_25._tcp.mail   IN      TLSA 2 1 2      2042bc624d...a0aef921fe

总共有四套TLSA记录，我的ecdsa证书和三个父CA链证书。另外，我还为端口465和587添加了额外的记录集。不幸的是，这些添加并没有改善我的结果。

Answer 1

Yup，您提到的工具不适合测试您的设置。使用一个测试，该测试将逐步检查并返回清晰的消息。

一个好的测试需要单独测试可能组合的笛卡尔积，净结果为：

• 对于每一个IP
• 对于每种算法
• 对于每种方法，PKI和DANE
• 可能对每一次TLSA的使用，TLS版本，SNI，。

不幸的是，一些测试只尝试第一个IP，一些测试只尝试第一个协商密码套件。大多数测试都无法以明确的语言报告，无论是DANE还是PKI匹配失败。

• 您的s_client -dane_tlsa_...命令很好。当我检查的时候，你的DANE装置很好。
• 因为您的证书意味着您也希望PKI验证能够工作，所以您还想配置Postfix来发送中间服务器，而现在看来它已经起作用了。用s_client -CApath /etc/ssl/certs验证

编辑:我怀疑你现在添加了比你需要的更多的TLSA记录。与其提供两种用法2和3，两种选择器(0&1)，以及提供多个has算法(1&2)，我建议只为RSA和EC中的每一个提供一个主备份和一个备份，而不是一个完整的证书关联。(不过，我不认为任何以这种方式产生的记录都会造成伤害。)

Answer 2

我不是DANE或TLSA方面的专家(只是在这里学习诀窍)，但我的猜测是@anx是非常正确的:每个端口都有太多条目。应该足够了，最好是3 1 1 (或者3 1 2，如果您喜欢SHA512)，因为这应该允许发送端检查整个信任链。

这主要是因为我所知道的DNS解析器的默认行为(这意味着可能还有许多其他我不知道的！)请求所有匹配查询的记录(例如:用于_25._tcp.mail的所有记录)，并从可能的选项中随机选择一个。有些DNS RR允许加权选择(例如MX记录)；一些关于TXT字段的约定可能有自己的编码优先级和首选项的方式，但在默认情况下，大多数解析器只会随机选择一个答复并使用它。

因此，这样的解析器可能只得到一个1 x x答复(因为它是随机选择的)，并且严格要求DANE检查.并拒绝它，因为它无法验证整个信任链。

请注意，我只是在推测。我的上述推理未能解释为什么要接受RSA，而不是ECDSA。从理论上讲，既然两者都有相同的设置，那么两者都应该会失败--但我假设我在这里遗漏了一些东西。

我自己的DNS几乎完全由Cloudflare管理(少数DynDNS域除外)，Cloudflare强制执行的一件事是，每个端口只能有一个TLSA规则在区域中活动。这样，您就不会犯添加多个条目的“错误”--它们的后台界面永远不会允许这样做，即使假设这样做有很好的理由。因此，对于我自己的DANE设置，我只有3 1 1条目。就我所能测试到的.