Am achiziționat două certificate SSL cu un singur domeniu, wildcard de la Namecheap/Sectigo/Comodo. Mi-am generat CSR-urile în mod tipic folosind 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.csr
Am trimis CSR-urile și mi s-a eliberat fiecare pachet de certificate, inclusiv pachetul .crt și .ca, totul conform așteptărilor.
Am reușit să instalez ambele certificate pentru utilizare de către Postfix. Fiecare avea nevoie de o versiune necriptată a cheii private, permisiunile securizate fiind menținute.
$ openssl rsa -in example.com.rsa.key -out example.com.rsa.key.uneencrypted
$ openssl ec -in example.com.ecdsa.key -out example.com.ecdsa.key.uneencrypted
Am configurat corect SPF, DKIM, DMARC și DNSSEC, fiecare confirmat de instrumente terțe și am trimis și primit e-mail cu scoruri de promovare în anteturi.
Am folosit din nou openssl pentru a genera hash-urile certificatelor pentru înregistrările mele DANE TLSA. Am creat două seturi, câte un set pentru fiecare algoritm și atât pentru portul 25, cât și pentru 587. Acestea au fost adăugate la fișierul meu de zonă, verificate cu named-checkzone, semnate cu dnssec-signzone și publicate în DNS.
Am început prin a folosi două instrumente externe pentru a verifica configurația, primul la danecheck iar al doilea la dane.sys4.de. Ambele au raportat succes general folosind certificatul RSA, dar eșecul specific al certificatului ECDSA.
Primul a reușit, raportând parțial:
DANE TLSA 3 1 1 [9679fc29..]: Certificat EE potrivit OK
DANE TLSA 3 1 1 [ecd29ffd..]: FAIL nu s-a potrivit cu certificatul EE
Acesta din urmă a reușit, raportând parțial:
3, 1, 1 9679fc296960a23c[...]149b990a680cad8b *în verde*
3, 1, 1 ecd29ffd76d61326[...]dadbcfa42eae9158 - nu se poate obține certificatul de emitent local: (20) *în roșu*
Am încercat să remediez acest lucru modificând diferitele câmpuri de utilizare, selector și potrivire, 3 0 1, 3 1 1 etc. Am încercat să generez hash-urile local cu openssl și folosind instrumente online precum gen_tlsa. Ambele instrumente au produs rezultate hashing identice pentru ambele certificate. Din nou, RSA TLSA a reușit în timp ce înregistrările ECDSA au eșuat. În cele din urmă, am găsit scriptul chaingen, care generează toate 3 0 1, 3 1 1, 3 0 2 și 3 1 2 hash-uri pe care le-am inclus pentru fiecare port fără nicio îmbunătățire pentru înregistrările ECDSA.
Am petrecut câteva ore încercând diferite permutări ale fiecărui certificat, înregistrări TLSA, porturi etc. Am încercat să adaug înregistrări TLSA (2 0 1) pentru cheile părinte ale înregistrărilor ECDSA la DNS. Am încercat să schimb certificatul disponibil pentru Postfix pentru a include ca-bundle-ul împreună cu certificatul într-un fișier .pem.
Cercetând am găsit această postare la utilizatorii exim intitulat „Cum se folosește certificatul ec cu certificatele DANE și ec+rsa” de Viktor Dukhovni, care nu are nevoie de prezentare în cercul Postfix/DANE.El a sugerat că poate instrumentele online au fost oportuniste și, de îndată ce au reușit cu certificatele RSA, nu s-au obosit să testeze cu certificatele ECDSA. A oferit apeluri foarte valoroase către openssl pentru a arăta că într-adevăr cheile erau corecte în situația afișului. Am duplicat acest efort cu două scripturi shell scurte folosind codul lui Viktor înlocuind informațiile mele, unul numit checkrsa și celălalt numit checkecdsa.
Cele două scripturi execută două comenzi fiecare cu următoarea configurare pentru checkrsa (pentru IPv4):
$ cat checkrsa
ecou „renunț” | 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 c487cdb079b49d12ee357d9547c6f67448a2ec2e789c86c65d213a57aaec4ac9" \
-dane_tlsa_rrdata „3 1 1 9679fc296960a23c89fed73d8e6a6d0ab33f0abc99d48c44149b990a680cad8b” \
-sigalgs rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:rsa_pkcs1_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sh
Și checkecdsa (pentru IPv6):
$ cat checkecdsa
ecou „renunț” | 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 87a8c75581c9d022062416a37387de1ec30d311e4d7afbeb892be287fb13bfc5" \
-dane_tlsa_rrdata "3 1 1 ecd29ffd76d6132629ddbf7ccd31460e23ac3b4a50d47bccdadbcfa42eae9158" \
-sigalgs ecdsa_secp256r1_sha256:ecdsa_secp384r1_sha384:ecdsa_secp521r1_sha512
Rezultatele:
root@server:~/bin# ./checkrsa
verificați adâncimea este de 9
CONECTAT(00000003)
adâncime=0 CN = *.example.com
verifica returnarea:1
---
Lanț de certificate
0 s:CN = *.example.com
i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
---
Certificat de server
-----ÎNCEPE CERTIFICAT-----
MIIHNDCCBhygAwIBAgIQAzfJZrX65NjG2FvLmk0I0jANBgkqhkiG9w0BAQsFADCB
...
Xw8UgZDYihDaIxT8SUQUgV9weQg5Lkru
-----CERTIFICAT FINAL-----
subiect=CN = *.example.com
emitent=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
---
Nu s-au trimis nume de CA de certificat de client
Rezumat peer signing: SHA256
Tip semnătură peer: RSA-PSS
Cheie Temp Server: X25519, 253 de biți
---
SSL handshake a citit 2904 de octeți și a scris 386 de octeți
Verificare: OK
Nume de familie verificat: *.example.com
DANE TLSA 3 1 1 ...99d48c44149b990a680cad8b certificat EE potrivit la adâncimea 0
---
Nou, TLSv1.3, Cipher este TLS_AES_256_GCM_SHA384
Cheia publică a serverului este de 4096 de biți
Renegocierea sigură NU ESTE acceptată
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Datele timpurii nu au fost trimise
Verificați codul de returnare: 0 (ok)
---
250 BĂRĂTIRE
TERMINAT
root@server:~/bin# ./checkecdsa
verificați adâncimea este de 9
CONECTAT(00000003)
adâncime=0 CN = *.example.com
verifica returnarea:1
---
Lanț de certificate
0 s:CN = *.example.com
i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo
ECC Domain Validation Secure Server CA
---
Certificat de server
-----ÎNCEPE CERTIFICAT-----
MIIEqDCCBE6gAwIBAgIRAIIKQBNWh2R9wwvn2/j30PgwCgYIKoZIzj0EAwIwgY8x
...
YemreHq/Cd5HPgIgE6InSF5ko6mWo9GMpR7w1ijpbsnShlS6EiYrpZozD0s=
-----CERTIFICAT FINAL-----
subiect=CN = *.example.com
emitent=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
---
Nu s-au trimis nume de CA de certificat de client
Rezumat peer signing: SHA256
Tip semnătură peer: ECDSA
Cheie Temp Server: X25519, 253 de biți
---
SSL handshake a citit 1811 de octeți și a scris 348 de octeți
Verificare: OK
Nume de familie verificat: *.example.com
DANE TLSA 3 1 1 ...50d47bccdadbcfa42eae9158 certificat EE potrivit la adâncimea 0
---
Nou, TLSv1.3, Cipher este TLS_AES_256_GCM_SHA384
Cheia publică a serverului este de 256 de biți
Renegocierea sigură NU ESTE acceptată
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Datele timpurii nu au fost trimise
Verificați codul de returnare: 0 (ok)
---
250 BĂRĂTIRE
TERMINAT
Așadar, ambele certificate se înregistrează local, dar continuă să eșueze extern.
Văzând că mesajul lui Viktor a indicat că, probabil, instrumentele, având succes cu RSA, au scapat pe hash-urile ECDSA, am încercat de asemenea să public doar înregistrările ECDSA TLSA. Rezultatele au arătat un eșec complet cu doar hash-urile ECDSA pe cont propriu.
Deci, sunt lăsat cu această situație:
Am două seturi de certificate SSL, unul RSA, celălalt ECDSA.
Ambele certificate au succes în Postfix.
Ambele certificate checkout cu openssl.
Publicarea ambelor certificate trece în general, pe baza certificatelor RSA, observând că certificatele ECDSA eșuează.
Certificatele ECDSA reușesc la nivel local, dar eșuează extern.
Nu sunt sigur de unde să merg de aici și caut ajutor pentru a obține configurarea certificatului meu ECDSA în paralel cu înregistrările mele RSA pentru DANE.
