Was benutzt du denn? Webhosting oder eigener Server?
Du bist im SCP Forum daher wundert mich das.
Es kommt darauf an.
Möchtest du das Zertifikat selbst pinnen, z.B. für ein Zertifikat was über 1 Jahr ausgestellt ist,
oder möchtest du ein Wurzelzertifikat pinnen, z.B. weil du den Dienst auf Let's Encrypt beschränken möchtest, aber nicht alle 3 Monate den Record tauschen willst,
oder ist es dir egal, weil dein Public Key sowieso gleich bleibt?
So sieht das ganze für ein nicht LE Zertifikat bei mir aus:
_25._tcp.lambda.h6g-server.net. 300 IN TLSA 3 1 1 6D93625B38BCF062EB4359BB6C98D0B9FD41479742CF34471F36E3FC A5E5B9A9
Domain Issued, Public Key based, SHA256 Digest
Was läuft auf dem Server? Ein paar Infos wären gut...
oder ist es dir egal, weil dein Public Key sowieso gleich bleibt?
Das passt schon ganz gut mir geht es hauptsächlich im EMail
Das passt schon ganz gut
Dann: DANE-EE, Use public key, Digest deiner Wahl (256, oder 512), PEM Format vom Zertifikat selbst einfügen, Port 25, TCP, FQDN vom Mailserver.
Mich wundert, dass hier noch keiner die Frage des Lifecycles des verwendeten Schlüsselmaterials und Zertifikats gestellt hat.
Dann: DANE-EE, Use public key, Digest deiner Wahl (256, oder 512), PEM Format vom Zertifikat selbst einfügen, Port 25, TCP, FQDN vom Mailserver.
Ja, das kann man so machen.
ABER: Man muss auf Let's Encrypt / CertBot Seite auch zwingend dafür sorgen, dass das Schlüsselpaar bei der Erneuerung des Zertifikats wiederverwendet werden muss! Wie man das "zu Fuß" durchführt habe ich vor Jahren mal hier aufgeschrieben. Mittlerweile können die CertBot-Implementierungen das aber auch selbst, und man muss nicht mehr einen CSR mit OpenSSL selbst generieren.
Man muss auf Let's Encrypt / CertBot Seite auch zwingend dafür sorgen, dass das Schlüsselpaar bei der Erneuerung des Zertifikats wiederverwendet werden muss!
Hab nach Let's Encrypt gefragt, wurde aber indirekt ausgeschlossen...
Wenn kein CertBot / Let's Encrypt verwendet wird kann man auch den TLSA-Record beim Zertifikatstausch zeitgerecht ändern, bedeutet es müssen überschlagend mindestens zwei gültig sein. Braucht halt Vorlaufzeit, weil DNS ja bekanntlich Zeit zum Propagieren braucht. Den TLSA-Record unverändert beibehalten zu können hat jedenfalls Vorteile.
Ich habe beim Certbot auch einfach die Option --reuse-key verwendet. Mein TLSA-Record verwendet dann DANE-EE (3), SubjectPublicKeyInfo (1) und SHA-256 (1).
Und hier noch ein Tool, mit dem man das ganz gut testen kann: https://dane.sys4.de/
ZitatOption --reuse-key
Wenn man es "händisch" aufruft oder scriptet und der verwendete CertBot dies so unterstützt vermutlich die einfachste Variante.
Wer das Renewal dem Certbot-Cronjob-Automatismus überlässt kann je nach Implementierung "reuse_key = True" in der Config setzen.
Grundsätzlich ist ein RSA >= 2048 oder ECDSA Zertifikatspaar "gut" genug, um über längere Zeit mit gleichbleibendem privaten Schlüssel sicher zu bleiben. Dennoch frage ich mich, ob die so künstlich eingeführte Sicherheitseinbuße mit TLSA wett gemacht wird.
