joseph_halter

Danke euch. Ja klar. Bei uns gibt es intern die Weisung, sich an die Empfehlungen des BSI zu halten. Da ich zur Gültigkeitsdauer von Zertifikaten da nicht wirklich was finde...bzw. ok, es gibt eine Website zu öffentlichen PKIs mit Sicherheitsstandard "Hoch", aber das sind wir nicht.

 

Aber jetzt kann ich mich an eure Empfehlungen halten. Wegen den 4096Bit RSA-Keys habe ich in irgendeinem Online-Artikel zu PKIs gelesen, dass man sich bewusst sein soll, dass bei der Verwendung dieser Keys höhere Leistung und auch Netzwerkleistung benötigt wird. Ich frage mich aber irgendwie auch, was damit gemeint sein soll. 4Kibibit sind ja nicht gerade sehr viele Daten zu übertragen und wenn der Key eh nur am Anfang der Übertragung für den Schlüsselaustausch genutzt wird...?

vor 8 Stunden schrieb NilsK:

Moin,

 

ich glaube, bezüglich der Performance hast du falsche Vorstellungen. Ein Zertifikat mit 4096 Bit auszustellen (was heute übliche Empfehlung ist), ist keine ernsthafte Herausforderung. Ein CA-Server ist typischerweise nicht groß dimensioniert, die meisten Kunden betreiben sowas als eine eher kleine VM. 

 

Die Zertifikatslaufzeit berechnet man normalerweise rückwärts, ausgehend von der maximalen Laufzeit der Endzertifikate. Eine typische Rechnung geht so:

• Laufzeit ausgestellter Zertifikate nicht über 2 Jahre (wobei der typische Wert darunter liegt, etwa 1/2 oder 1 Jahr; manchmal auch nur Wochen oder Tage)
• Die Issuing CA soll Zertifikate mindestens einmal verlängern können, bevor ihr eigenes Zertifikat ausläuft, also: Lifetime Issuing CA = 2 * Laufzeit Zertifikat + Puffer; im Beispiel also: 2 * 2 Jahre + 1 Jahr = 5 Jahre
• Genauso auch die Root CA, deren Zertifikat es auch zulassen soll, die CA-Zertifikate einmal zu verlängern: Lifetime Root CA = 2 * Laufzeit Issuing CA + Puffer; also: 2 * 5 Jahre + 1 Jahr = 11 Jahre

Wichtig ist, dass das Design der PKI zu den Anforderungen des Unternehmens passt und dass man die Technik einordnen kann. Eine interne CA setzt man praktisch nur noch für interne Zwecke ein, extern erreichbare Systeme versorgt man mit kommerziellen Zertifikaten oder per Let's Encrypt. Die Laufzeit eines (internen) Webserver-Zertifikats ist dann weniger kritisch, wobei ich da heute auch nicht mehr über 1 Jahr setzen würde, eher weniger. Der Bequemlichkeitsgewinn durch lange Laufzeiten rächt sich zumeist durch mangelnde Routine mit dem Wechselvorgang.

 

Gruß, Nils

 

Ich danke dir, das ist deutlich.

 

In einem modernen, internen Netzwerk mit hunderten Clients, einigen Appliances und vielen VPN-S2S-Tunnel meinst du also, dass es von der Netzwerkperformance her kein Problem ist, alle RSA-Zertifikate auch für interne Webserver (ungefähr 50 interne Webserver) auf 4096 Bit zu heben?

 

Was für Quellen fügst du zu deinen Empfehlungen oben an, wenn jemand kritisch ist und diese Laufzeiten länger haben will. Worauf beziehst du dich da außer dass es "Best Practice" ist?

Hallo zusammen,

 

diese Dokumente: https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr02102/tr02102_node.html

Davon kann man ableiten, dass, wenn man eine RSA-Verschlüsselung mit Länge 2000 Bit einsetzt, man nach Empfehlung des BSI "sicher" verschlüsselt (bis Ende 2023).

Wenn man beispielsweise intern zig Webserver betreibt und dafür alle Zertifikate firmenintern selber ausstellt, ist das schon eine Performance-relevante Entscheidung, ob man RSA 2048 Bit oder RSA 4096 Bit benutzt, also eine Kostenfrage.

Viele Fragen aber bleiben noch ungeklärt. Mich beschäftigen vorallem folgende Fragen, die ich euch gerne stellen würde.

Gibt es Empfehlungen des BSI zu Laufzeiten von Zertifikaten? Eben auch zu Stammzertifizierungsstellenzertifikaten?

Falls nein: Was sind eure Empfehlungen? Was sind eure Quellen dieser Empfehlungen? Große Schlüssellängen und kurze Laufzeiten bedeuten ja oft mehr Kosten. Selbst wenn automatisiert verteilt wird, verursacht das Netzwerktraffic und Rechnerbelastung. Das muss man begründen. Gibt es irgendwo eine zentrale Website zu diesem Thema, die auch aktualisiert wird mit solchen Empfehlungen? Eine verständliche Seite, die die wichtigsten Daten wie empfohlene Laufzeit, etc. zusammenfasst?

 

Einfache Empfehlung die beispielsweise sagt: rootCA = RSA4096 Bit, max. 10 Jahre, subCA = RSA4096 Bit ohne dass man gleich ein ganzes Buch lesen muss.

 

Wie lange wählt ihr die Gültigkeitsdauer euer Zertifizierungsstellenzertifikate in einer ein- oder zweistufigen PKI? Wie handhabt ihr eure Verschlüsselungstechnologien und Schlüssellängen in euren Unternehmen?

Wie lange sind eure internen Webserverzertifikate gültig?

 

Mich interessiert vor allem wie ihr das ganze begründet wenn einer kritisch fragt. Sorry für die vielen Fragen.

 

Grüße

Um zu booten schaltet ihr die IP-Steckdose remote aus und wieder an? 

vor 22 Minuten schrieb BOfH_666:

 

Selbst wenn das Datum 2029 wäre, gäbe es im Moment trotzdem keinen guten Grund zu wechseln ... das ist doch das was ich meine ... Du hast noch ca. 4,32857 Jahre Zeit, Dir darüber Gedanken zu machen .... bis dahin kann uns alle noch Covid-20, 21, 22 oder 23 dahinraffen.    

Wenn das Datum 2029 wäre, würde ich eine Migration planen und wohl auch bald durchführen.

vor 58 Minuten schrieb testperson:

 

Ich hätte hier die Frage, was den KMU dazu bewegt, die Emails hausintern zu behalten?

Bei unseren Kunden (viel K wenig M) sind die "Gründe" jedenfalls äußerst "kreativ".

?Jede Anwaltskanzlei?  Und die Gründe liegen auf der Hand. Wenn eine Anwaltskanzlei ihre Daten bei einer IT-Firma hat, gegen die rechtlich ermittelt wird, haben die ermittelnden Behörden (mit den nötigen Durchsuchungsbefehlen gegen die IT-Firma) plötzlich Zugriff auf heikle Daten der Anwaltskanzlei. Wenn die Anwaltskanzlei diese Daten (und Mails) hausintern hält, haben die Behörden nur Zugriff, wenn auch die Anwaltskanzlei direkt angeklagt (mit den nötigen Durchsuchungsbefehlen gegen die Anwaltskanzlei) wird.

 

Das ist überhaupt nicht "kreativ" sondern völlig legitim.

 

 

Zitat

Alle weiteren Spekulationen bringen doch im Moment sowieso niemandem nix. Oder seh' ich da irgendwas nicht? 

Jedenfalls gibt es, solange das Enddatum des erweiterten Supports für Exchange 2019 nicht verlängert wird, keinen mir bekannten triftigen Grund von Exchange 2016 auf 2019 zu wechseln. Und da könnte es doch sein, dass ihr in so einer Diskussion Überlegungen einbringt, die ich bisher nicht gemacht habe.

 

 

 

 

Wird es nach 2025 immer noch eine on-Premise Version von Microsoft Exchange geben für KMUs, die ihre Emails hausintern behalten möchten? Oder wird sich Microsoft aus diesem Markt zurückziehen?

 

Was ist eure Vermutung?

 

vor 51 Minuten schrieb Horstenberg:

Derzeit sehe ich den auch nicht, wegen des verringerten Supportzeitraums bei Exchange 2019. Aber mal sehen, ob Exchange 2016 auch mit Outlook 2022 oder Outlook 2025 zusammenarbeiten wird.

Eigentlich ist es ein Nachteil, von 2016 auf 2019 up zu graden. Schlichtweg verschwendete Arbeitszeit. Erweiterter Support wird eingestellt zum gleichen Datum. Was kommt nach Exchange 2019? Ein Exchange mit Lifecycle 24 Monate?

 

 

Für die Anwaltskanzleien gäbe es noch Zimbra auf Linux. Denke aber nicht, dass das Konfigurieren weniger komplex ist. Etwas schlanker wäre ein reiner Mailserver mit postfix und sendmail realisierbar. Aber freigegebene Kalender wollen sie dann trotzdem....

 

 

 

 

Abend,

 

ich bin neu und habe mir ein Windows 2019 Standard gekauft. Nun habe ich IIS, DNS installiert und den Server als Domänencontroller aufgesetzt (ja, ich nutze die GUI). Das funktioniert soweit alles bestens. Ich solle aber noch die "AD RMS", das Active Directory Rechteverwaltungssystem konfigurieren. Ich habe dazu 2 Servicekonten eingerichtet unter "Active Directory Benutzer...", die vom Konfigurator auch angenommen werden.

 

Im IIS habe ich neben der "Default Web Site" eine Website namens "RMSAD" eingerichtet, die über die lokale IP des Domänencontrollers aber über einen separaten Hostnamen läuft: rmsad.domain.local . Ich habe einen CNAME-Eintrag im DNS-Server auf dem Domaincontroller hinzugefügt sowie das lokale Verzeichnis für diese Website erstellt. Die index.html in diesem Verzeichnis wird mir angezeigt, wenn ich rmsad.domain.local im Webbrowser eingebe. ABER:

 

Ich konfiguriere AD RMS über die GUI:

Eingabe 1. Servicekonto, AD RMS Stammcluster erstellen, Internet Windows-Datenbank auf diesem Server verwenden, Eingabe 2. Servicekonto, Krypt. 2, Zentral verw. Schlüsselspeicher, Passworteingabe

 

Bis hierher ohne irgendwelche Warnungen. Nun wähle ich mein virtuelles IIS-Verzeichnis: rmsad und SSL-verschl. Verbindung

Gebe meinen kompletten Pfad ein:  rmsad.domain.local

 

Nun meldet der oben: "Für die ausgewählte Cluster-URL ist bereits eine SSL-Zertifikatbindung vorhanden.". Er soll also das bereits vorhandene verwenden. Folgend gebe ich bei Name "rmsad" ein., SCP jetzt registrieren und bestätige mit Installieren.

 

Lange Rede, kurzer Sinn.

 

Der meint jetzt die angehängte Fehlermeldung. Ich habe auch schon versucht, nur eine IIS-Website zu erstellen ohne https. Es kommt am Schluss aber immer die gleiche Meldung.

 

Gut, das IIS-Verzeichnis ist schon vorhanden. Wenn ich es aber lösche, kann ich im Konfigurationsdialog nur "Default Website" auswählen. Dann kommt ebenso, dass das IIS-Verzeichnis vorhanden ist...

 

Was ist hier das Problem?