Vlákno názorů k článku
NÚKIB: klíčové informační systémy musejí zabezpečit e-mail pomocí DNSSEC, TLS a DANE od Ondřej Caletka - Trošku to bohužel devalvuje ten bod 1.3.: 1.3. Certifikáty...

Trošku to bohužel devalvuje ten bod 1.3.:

1.3. Certifikáty všech SMTP serverů uvedených v MX záznamech jsou validní, vystaveny uznávanou certifikační autoritou a s doménovým názvem odpovídající názvu MX záznamu daného serveru.

Tohle je úplně zbytečný požadavek, protože shoda MX jména se jménem certifikátu se při doručování nikdy nevyhodnocuje. Zároveň to ale znamená víc práce pro adminy, kteří musí zařídit, aby se certifikát pravidelně obnovoval a pokud se během obnovy mění jeho veřejný klíč, aby došlo i k aktualizaci příslušných TLSA záznamů. Ty je navíc nutné aktualizovat v předstihu - tedy vystavit nové - provést změnu - smazat staré.

Je zde velké riziko, že se některý z těchto kroků nepovede, výsledkem čehož bude rozpor mezi TLSA záznamy a certifikáty serverů, což povede k nedoručitelnosti pošty pro danou doménu.

Přitom použití self-signed certifikátu, jehož otisk je v TLSA záznamu přináší přesně stejnou úroveň bezpečnosti a je pro adminy bez starostí.

Podle mne je důvod, aby bylo bezpečné obojí. Tj. aby certifikát správně ověřil ten, kdo ověřuje DANE, ale neřeší certifikační autority; a aby certifikát správně ověřil i ten, kdo důvěřuje uznávaným certifikačním autoritám, ale neověřuje DANE. Proto je potřeba, aby měl server v pořádku obojí – a toho se prakticky dosáhne jenom tím, že to bude dostatečné množství důležitých klientů ověřovat.

No je to zase všechno přesložitěné. Že by NÚKIB třeba dal k dispozici nějaký videonávod nebo prostě něco srozumitelného, jak to zařídit aby to šlapalo jak s Exchange tak nějakým populárním *NIXovým emailovým serverem třeba Postfixem, to holt ne.Tady zase budou lidi za tabulkový plat zkoumat, jak to teda jako udělat správně, aby to jako prošlo nebo se budou vypisovat drahé zakázky, aby jim nějaký expert poradil, jak na to.

Mezitím tu máme různé velmi populární registrátory domén, kteří DNSSec zapnou jen v prémiové variantě za dodatečnou úplatu. Ehm, GoDaddy. Jako dá se to převádět někam jinam, ale kam? Kde je to dobré? Kde mají rozumné API pro automatizaci? Kde může člověk platit nějak rozumně? Bude to mít dobrý výkon celosvětově?

Papír snese prostě hodně...

12. 10. 2021, 01:29 editováno autorem komentáře

aby se certifikát pravidelně obnovoval a pokud se během obnovy mění jeho veřejný klíč, aby došlo i k aktualizaci příslušných TLSA záznamů. Ty je navíc nutné aktualizovat v předstihu - tedy vystavit nové - provést změnu - smazat staré.
To sice ano, ale můžete použít
_25._tcp.host in tlsa 3 1 1
Pak se kontroluje obsah certifikátu, který se nemusí měnit - pokud při obnovení zachováte CSR.
Dá se to pěkně automatizovat (tedy před nasazením obnoveného certifikátu i kontrolovat). Nic extra složitého:

printf '_25._tcp.%s IN TLSA 3 1 1 %s\n' $srv \
    $(openssl x509 -in $pem -noout -pubkey |
        openssl pkey -pubin -outform DER |
        openssl dgst -sha256 -hex|cut -f2 -d" ")

pokud se během obnovy mění jeho veřejný klíč
pokud při obnovení zachováte CSR
Vždyť to Ondřej napsal, že jde o případ, kdy se veřejný klíč mění. Přičemž některé automaty na vystavování certifikátů nedávají na výběr a vždy vytváří novou klíčovou dvojici.

Přičemž některé automaty na vystavování certifikátů nedávají na výběr a vždy vytváří novou klíčovou dvojici.

Vždycky se dá zvolit složité řešení: tedy použít automat (nebo ho tak mít nakonfigurovaný), že se pořád generují nové csr a private key, pak každé 2 měsíce (Let's Encrypt) modifikovat TLSA v DNS...
No a anebo si automat nakonfigurovat (a když to neumí, tak přejít na jiný), aby mi csr nechal na pokoji. Pro certbot stačí --reuse-key
Zásada KISS.

No, a celé vlákno začalo správnou připomínkou, že složitá řešení mají tendenci se častěji rozbíjet – protože každý z těch více kroků může selhat.

Víte, co zásada KISS znamená? Rozhodně to není doporučení používat složitá řešení, právě naopak.