Intervall für Lets encrypt
- Thread starter Lazybone
- Start date
D
Deleted member 11740
Guest
GwenDragon
Registered User
90 Tage sind bei Lets Encrypt so festgelegt.
Wo ist nun das Problem bei dir? Die Zertifikate werden doch automatisch vor Ablauf verlängert.
Why ninety-day lifetimes for certificates?
We’re sometimes asked why we only offer certificates with ninety-day lifetimes. People who ask this are usually concerned that ninety days is too short and wish we would offer certificates lasting a year or more, like some other CAs do. Ninety days is nothing new on the Web. According to Firefox...
letsencrypt.org
Wo ist nun das Problem bei dir? Die Zertifikate werden doch automatisch vor Ablauf verlängert.
Lazybone
Member
ich nutze ein Cert auch für den Mailverkehr. Und da meckern alle Clients immer, und auch die Kunden. Die wollen das nicht begreifen. :-/
GwenDragon
Registered User
@Lazybone Wieso? Das Zertifikat hat doch eine gültige Zertifikatskette, mit der das Zertifikat validiert wird. Wieso meckern da die Mail-Clients? Und welche? Haben die so alte Windows-PCs ohne aktuelle Zertifikate?
Ich frage mich, welches Schlangenöl (aka Sicherheitstool) beim Kunden zwingt, selbst auch noch Zertifikat zu installieren oder Updates zu fahren!
Jedenfalls bin ich gerade in Bezug auf dich im Grübelmodus.
Ach so, du benutzt ein Zertifikat für den Mailserver z.B. mail.meinedomain.tld.
Aber Plesk lässt doch auch zu, dass jede Domain ein extra Mailzertifikat bekommt.
Und eigentlich kann Plesk auch mittlerweile Autoconfig-Erkennung für Mailclients.
Ich frage mich, welches Schlangenöl (aka Sicherheitstool) beim Kunden zwingt, selbst auch noch Zertifikat zu installieren oder Updates zu fahren!
Jedenfalls bin ich gerade in Bezug auf dich im Grübelmodus.
Ach so, du benutzt ein Zertifikat für den Mailserver z.B. mail.meinedomain.tld.
Aber Plesk lässt doch auch zu, dass jede Domain ein extra Mailzertifikat bekommt.
Und eigentlich kann Plesk auch mittlerweile Autoconfig-Erkennung für Mailclients.
d4f
Kaffee? Wo?
Als Anmerkung für Programme wo Clients komplett ohne externe chain-of-trust fahren (bspw Filezilla):
Es gibt auch weiterhin kommerzielle Zertifikate mit den üblichen Laufzeitein von bis zu 4 Jahren. Ist aber nur sinnvoll falls alle Benutzer "ftp.servername.de" o.ä. verwenden und nicht zB "eigenedomain.tld".
Ein günstiger Anbieter von Zertifikaten für Reseller den ich empfehlen kann, wäre zB: https://www.gogetssl.com/dv-ssl/
Sectigo PositiveSSL (ehemals Comodo) wäre eines der günstigsten SSL-Produkte.
Aber wie GwenDragon sagt; falls reguläre EMail-Clients sich beschweren und diese nicht grade Office 2013 im extended Support haben... dann ist vermutlich entweder bei dem Kunden oder bei dir schlecht eingestellt. Eine einmalige Umstellungsaktion ist sinnvoller als alle 3 Monate zig Kunden an der Strippe zu haben dass "nichts geht!!"
Es gibt auch weiterhin kommerzielle Zertifikate mit den üblichen Laufzeitein von bis zu 4 Jahren. Ist aber nur sinnvoll falls alle Benutzer "ftp.servername.de" o.ä. verwenden und nicht zB "eigenedomain.tld".
Ein günstiger Anbieter von Zertifikaten für Reseller den ich empfehlen kann, wäre zB: https://www.gogetssl.com/dv-ssl/
Sectigo PositiveSSL (ehemals Comodo) wäre eines der günstigsten SSL-Produkte.
Aber wie GwenDragon sagt; falls reguläre EMail-Clients sich beschweren und diese nicht grade Office 2013 im extended Support haben... dann ist vermutlich entweder bei dem Kunden oder bei dir schlecht eingestellt. Eine einmalige Umstellungsaktion ist sinnvoller als alle 3 Monate zig Kunden an der Strippe zu haben dass "nichts geht!!"
D
Deleted member 16573
Guest
Ich kenne auch einen Fall eines mittelständischen Unternehmens im Bankensektor, bei dem man sich bewusst dafür entscheidet hochpreisige und manuelle SSL-Zertifikate einzusetzen(also weder einen der günstigen Anbieter zu verwenden, noch LE), weil das weniger Arbeit und Störungen(u. a. Supportaufwand für Browser- und App-probleme) verursacht als z. B. LE.
Wenn man SSL im größeren Stil einsetzt, dann ist es gut, die Zertifikate und deren Ablaufzeiten auch zu überwachen. Mit LE wurde das nur etwas dringender, weil die Verlängerungen und die Probleme damit auch tatsächlich häufiger wurden.
Ich verlängere die LE-Zertifikate täglich. D. h. ein Job läuft da täglich und wenn z. B. der Certbot sieht, dass die Zertifikate noch länger als 14(?) Tage gültig sind, dann macht der halt nix. Auf die Art und Weise werden auch bei Ausfall der LE-Infrasturktur die Verlängerungen noch so häufig versucht, dass es funktioniert, auch wenn die Technik mal für ein paar Tage down ist(War ja jetzt glaube ich nur insgesamt einmal so, wenn ich mich recht erinnere).
Wenn ich mit JKS zu tun hätte, dann würde ich dass aber auch wegautomatisieren. Und zum Thema JKS-Passwort: Wenn die Anwendung hochfährt, dann muss ja dass Passwort ohnehin irgendwo auf der Platte(oder in einer DB und der DB-Zugang im Dateisystem) stehen in der Anwendungskonfiguration. Dann kann man sich das Passwort vom Keystore eigentlich auch gleich sparen.
Ansonsten ist LE auch ein gewisser Aufwand für eine grössere Umgebung. (Ich habe das für meine Hauptumgebung mittels DNS-Verifikation programmtechnisch umgesetzt und verteile das dann über Chef). Meiner Bevorzugung nach ist das aber wesentlich angenehmer als diese ganze manuelle Arbeit, die es vorher war.
Wenn man SSL im größeren Stil einsetzt, dann ist es gut, die Zertifikate und deren Ablaufzeiten auch zu überwachen. Mit LE wurde das nur etwas dringender, weil die Verlängerungen und die Probleme damit auch tatsächlich häufiger wurden.
Ich verlängere die LE-Zertifikate täglich. D. h. ein Job läuft da täglich und wenn z. B. der Certbot sieht, dass die Zertifikate noch länger als 14(?) Tage gültig sind, dann macht der halt nix. Auf die Art und Weise werden auch bei Ausfall der LE-Infrasturktur die Verlängerungen noch so häufig versucht, dass es funktioniert, auch wenn die Technik mal für ein paar Tage down ist(War ja jetzt glaube ich nur insgesamt einmal so, wenn ich mich recht erinnere).
Wenn ich mit JKS zu tun hätte, dann würde ich dass aber auch wegautomatisieren. Und zum Thema JKS-Passwort: Wenn die Anwendung hochfährt, dann muss ja dass Passwort ohnehin irgendwo auf der Platte(oder in einer DB und der DB-Zugang im Dateisystem) stehen in der Anwendungskonfiguration. Dann kann man sich das Passwort vom Keystore eigentlich auch gleich sparen.
Ansonsten ist LE auch ein gewisser Aufwand für eine grössere Umgebung. (Ich habe das für meine Hauptumgebung mittels DNS-Verifikation programmtechnisch umgesetzt und verteile das dann über Chef). Meiner Bevorzugung nach ist das aber wesentlich angenehmer als diese ganze manuelle Arbeit, die es vorher war.
Last edited by a moderator:
D
Deleted member 11740
Guest
Sowas hier?: https://www.youtube.com/embed/x_OWvcC8YY0
Da geht aber nicht um Lets Encrypt, sondern daraum wie man eine eigene CA intern programmatisch verwaltet.
Let's Encrypt kann man aber auch selbst automatisieren und wenn man Lust hat, kann man gleich selbst den Client dazu entwickeln oder man bindet den Certbot mit ein.
Da geht aber nicht um Lets Encrypt, sondern daraum wie man eine eigene CA intern programmatisch verwaltet.
Let's Encrypt kann man aber auch selbst automatisieren und wenn man Lust hat, kann man gleich selbst den Client dazu entwickeln oder man bindet den Certbot mit ein.
Last edited by a moderator:
Lazybone
Member
GwenDragon
Registered User
Was genau erklären?
Lazybone
Member
wie man das anstellt.
dass jede Domain ein extra Mailzertifikat bekommt.
und Autoconfig-Erkennung für Mailclients
Lazybone
Member
hab ich, Sig aktualisiert
GwenDragon
Registered User
@Lazybone
In der Liste neben dem Domainamen das Lets Encrypt Zertifikat anklicken
E-Mails schützen
support.plesk.com
Und in Domains → E-Mail-Einstellungen nicht vergessen das Autodiscover zu aktivieren.
Erweiterungen → Meien Erweiterungen → Lets Encrypt → Öffnen
In der Liste neben dem Domainamen das Lets Encrypt Zertifikat anklicken
E-Mails schützen
Tools & Einstellungen → Mailservereinstellungen → Mail autodiscover
How to manage mail autodiscover in Plesk Obsidian?
Applicable to: Plesk Obsidian for Linux Question How to manage mail autodiscover in Plesk? Answer Autodiscover is enabled by default on all new Plesk Obsidian installations for all domains. For...
GwenDragon
Registered User
Bitte sehr!