J'ai acheté deux certificats SSL wildcard pour un seul domaine auprès de Namecheap/Sectigo/Comodo. J'ai généré mes CSRs de manière classique en utilisant openssl.
$ 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.csrJ'ai soumis les CSR et j'ai reçu chaque paquet de certificats, y compris le .crt et le .ca-bundle, comme prévu.
J'ai pu installer les deux certificats pour qu'ils soient utilisés par Postfix. Chacun d'entre eux nécessitait une version non chiffrée de la clé privée, les autorisations sécurisées ayant été maintenues.
$ 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.unencryptedJ'ai correctement configuré SPF, DKIM, DMARC et DNSSEC, chacun étant confirmé par des outils tiers, et j'ai envoyé et reçu du courrier avec des résultats positifs dans les en-têtes.
J'ai de nouveau utilisé openssl pour générer les hachages des certificats pour mes enregistrements DANE TLSA. J'ai créé deux jeux, un jeu pour chaque algorithme, et pour les ports 25 et 587. Ils ont été ajoutés à mon fichier de zone, vérifiés avec named-checkzone, signés avec dnssec-signzone et publiés dans le DNS.
J'ai commencé par utiliser deux outils externes pour vérifier la configuration. danecheck et le second à dane.sys4.de . Tous deux ont fait état d'une réussite globale dans l'utilisation du certificat RSA, mais d'un échec spécifique dans l'utilisation du certificat ECDSA.
Le premier a réussi, rapportant en partie :
DANE TLSA 3 1 1 [9679fc29..]: OK matched EE certificate
DANE TLSA 3 1 1 [ecd29ffd..]: FAIL did not match EE certificateCe dernier a réussi, en rapportant en partie :
3, 1, 1 9679fc296960a23c[...]149b990a680cad8b *in green*
3, 1, 1 ecd29ffd76d61326[...]dadbcfa42eae9158 - unable to get local issuer certificate: (20) *in red*J'ai tenté de résoudre ce problème en modifiant les différents champs d'utilisation, de sélection et de correspondance, 3 0 1, 3 1 1, etc. J'ai essayé de générer les hachages localement avec openssl et en utilisant des outils en ligne comme gen_tlsa . Les deux outils ont produit des résultats identiques pour les deux certificats. Une fois de plus, les TLSA RSA ont réussi alors que les enregistrements ECDSA ont échoué. J'ai finalement trouvé le script de chaingen script, qui génère tous les hachages 3 0 1, 3 1 1, 3 0 2, et 3 1 2 que j'ai inclus pour chaque port sans amélioration pour les enregistrements ECDSA.
J'ai passé plusieurs heures à essayer différentes permutations de chaque certificat, enregistrements TLSA, ports, etc. J'ai essayé d'ajouter des enregistrements TLSA (2 0 1) pour les clés parentes des enregistrements ECDSA dans le DNS. J'ai essayé de modifier le certificat disponible pour Postfix afin d'inclure le paquet ca avec le certificat dans un fichier .pem.
En faisant des recherches, j'ai trouvé ce billet sur exim-users intitulé "How to get ec cert used with DANE and ec+rsa certs" par Viktor Dukhovni, qui n'a plus besoin d'être présenté dans le cercle Postfix/DANE. Il a suggéré que les outils en ligne étaient peut-être opportunistes et que, dès qu'ils ont réussi avec les certificats RSA, ils n'ont pas pris la peine de tester avec les certificats ECDSA. Il a fourni des appels très utiles à openssl pour montrer que les clés étaient correctes dans la situation de l'auteur de l'article. J'ai reproduit cet effort avec deux courts Shell Shell utilisant le code de Viktor en substituant mes informations, l'un appelé checkrsa et l'autre appelé checkecdsa.
Les deux scripts exécutent chacun deux commandes avec la configuration suivante pour checkrsa (pour 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_sha512Et checkecdsa (pour 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_sha512Les résultats :
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
DONEAinsi, les deux certificats sont vérifiés localement, mais continuent d'échouer à l'extérieur.
Étant donné que le message de Viktor indiquait que les outils ayant réussi avec RSA avaient peut-être échoué avec les hachages ECDSA, j'ai également essayé de publier uniquement les enregistrements ECDSA TLSA. Les résultats ont montré un échec complet avec les hachages ECDSA seuls.
Je suis donc confronté à cette situation : J'ai deux jeux de certificats SSL, l'un RSA, l'autre ECDSA. Les deux certificats fonctionnent dans Postfix. Les deux certificats se vérifient avec openssl. La publication des deux certificats est réussie dans l'ensemble, sur la base des certificats RSA, en notant que les certificats ECDSA échouent. Les certificats ECDSA réussissent localement, mais échouent à l'extérieur.
Je ne sais pas trop où aller et je cherche de l'aide pour mettre en place mon certificat ECDSA en parallèle avec mes enregistrements RSA pour DANE.
Mise à jour 6/5/22
J'ai ajouté des informations supplémentaires fournies avec le certificat ECDSA par l'autorité de certification dans le fichier ca-bundle.
J'ai d'abord créé un fichier pem contenant à la fois le certificat et le contenu du paquet ca.
$ cat example.com.ecdsa.cert example.com.ecdsa.ca-bundle > example.com.ecdsa.pem.combinedJ'ai mis ce fichier à la disposition de postfix dans le fichier main.cf :
smtpd_tls_eccert_file=/etc/ssl/certs/example.com.ecdsa.pem.combinedEnsuite, j'ai utilisé un script appelé chaingen pour générer les différents enregistrements TLSA et les ajouter au 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...a0aef921feAu total, il y a quatre jeux d'enregistrements TLSA, mon certificat ecdsa et trois certificats d'autorité de certification parentale chaînés. J'ai également ajouté des jeux d'enregistrements supplémentaires pour les ports 465 et 587. Malheureusement, ces ajouts n'ont pas amélioré mon résultat.
