20.10.2016: Wichtige Änderungen für Zertifikate mit SHA1 Hashverfahren.

Ab dem 01.01.2017 beginnen verschiedene Betriebssysteme und Webbrowser damit, auf Anwendungen, die noch Zertifikate mit dem unsicheren Hashverfahren SHA1 verwenden, hinzuweisen.

Die Bandbreite reicht von:“Das Schlosssymbol wird nicht mehr angezeigt“, über „Das Schlosssymbol wird rot oder geöffnet angezeigt“ bis hin zu „Dieser Verbindung wird nicht mehr vertraut“ oder ähnlich.

Detailinformationen finden Sie im Internet zum Beispiel mit den Suchbegriffen „SHA1, SHA-1 oder SHA1 deprecation“. Exemplarisch finden Sie hier eine Ankündigung von Microsoft

Falls Sie noch Zertifikate mit SHA1 Hashverfahren verwenden, müssen Sie ab diesem Zeitpunkt mit Einschränkungen rechnen!

Daher bieten wir Ihnen nach wie vor die Möglichkeit, innerhalb der Gültigkeit eines Zertifikats mit SHA-1, das betreffende Zertifikat durch den Vorgang „Re-Issue“ im Kundenportal auf das aktuelle SHA256 Verfahren umzustellen. Eine Beschreibung finden Sie in der FAQ.

19.10.2015: Am 15.12.2015 endet der Support von TLS-/SSL-Zertifikaten mit SHA1 Hashverfahren (Secure Hash Algorithm).

Am 15.12.2015 beendet das T-Systems Trust Center den Support des Hash Verfahrens SHA1 (Secure Hash Algorithm). Da das Hashverfahren SHA1 Sicherheitsmängel aufweist, werden ab diesem Zeitpunkt auch im Bedarfsfall keine TLS/SSL-Zertifikate mehr mit SHA1 ausgestellt.

T-Systems erfüllt damit unter anderem die Anforderungen der aktuellen Baseline Requirements BR-1.3.0 des CA Browserforums

T-Systems hat alle ServerPass-Zertifizierungsstellen seit längerem aktualisiert und bietet für alle neuen ServerPass Produkte das Hashverfahren SHA2 an. Bestehende SHA1-Zertifikate können im Kundenportal kostenlos per <Re-Issue> aufgewertet werden.

Alle älteren SHA1-Zertifikate, deren Gültigkeitsdauer über das Datum 31.12.2016 hinaus geht, werden spätestens am 01.12.2016 gesperrt.

 

22.10.2014: Ausstellung von EV Zertifikaten durch ServerPass

Ab dem 22.10. wird ServerPass auch EV-SSL-Zertifikate (EV = Extended Validation) ausstellen. In den aktuellen Browsern werden mit EV-SSL-Zertifikaten abgesicherte Webseiten mit dem Sicherheitsindikator (Gründe Adressleiste) gut sichtbar gekennzeichnet.

Extended Validation SSL Zertifikate sind X.509 SSL Zertifikate deren Ausgabe an die strenge Vergaberichtlinien des CA/Browser Forums gebunden sind. So werden u.a. Identität und Adresse des Antragstellers, Zeichnungsbefugnis der unterschreibenden Person, Domainbesitz oder Nutzungsberechtigung der Domain besonders geprüft.

EV-SSL-Zertifikate können für Kapitalgesellschaften, Personengesellschaften, Einzelunternehmen, Behörden oder eingetragene Vereine ausgestellt werden.

Die EV-SSL-Zertifikate werden durch die deutsche Root „TeleSec ServerPass Extended Validation Class 3 CA“ ausgestellt, die in den Browsern und aktuellen Betriebssystemen eingebunden ist.

 

01.09.2014: Neues Sub-CA-Zertifikat ersetzt TeleSec ServerPass CA 1

Am 01.09.2014 wird die Zertifizierungshierarchie für TeleSec ServerPass aktualisiert. Die bisher verwendete Sub-CA TeleSec ServerPass CA 1 wird durch die neue Sub-CA TeleSec ServerPass CA 2 ersetzt. Die neue Sub-CA verwendet den zukunftssichereren SHA-2 (Secure Hash Algorithm) Algorithmus. Ab dem oben genannten Datum werden automatisch alle Zertifikate vom neuen Sub-CA Zertifikat ausgestellt.

Das bisher verwendete Root-Zertifikat (Vertrauensanker) ist von dieser Anpassung nicht betroffen. Die bekannte und etablierte Baltimore CyberTrust Root bietet Ihnen auch weiterhin die maximale Marktdurchdringung und hervorragende Kompatibilität mit aktuellen Applikationen.

Mit der Aktualisierung der Zertifizierungshierarchie werden alle ServerPass Zertifikate, die bisher von der TeleSec ServerPass CA 1 ausgestellt wurden, von der neuen Zertifizierungsstelle TeleSec ServerPass CA 2 ausgestellt.

Was ist zu beachten:
Wir empfehlen bei der ServerPass Installation zusätzlich auch immer die Installation des mitgelieferten Sub-CA Zertifikat in Ihrer Webserveranwendung. Mit dieser Vorgehensweise sind Sie auf der sicheren Seite und die Vertrauenskette wird immer zuverlässig gebildet.

 

Ab 01.10.2013: Änderung der IP-Adressen beim Zugriff aus einem Firmennetzwerk heraus auf unseren OCSP- oder CRL- Service

Aufgrund einer technischen Umstellung der Internet-Anbindung des T-Systems Trust Center wird der Wechsel auf neue IPv4-Adressen erforderlich. Wenn Sie unsere Dienste (z.B. OCSP oder CRL) aus einem Firmennetzwerk per Namen adressieren (z.B. telesec.de), wird die ab 1. Oktober 2013 startende Umstellung in unserem DNS für Sie transparent sein.

Anpassungen Ihrerseits sind (mindestens) in folgenden Fällen erforderlich:

  • Sie betreiben ein Sicherheitssystem (z.B. Proxy-Server oder Firewall) und haben explizit IP-Adressen unserer Dienste freigeschaltet.
  • Sie betreiben eigene DNS-Server, in denen Sie statische Einträge für die Verwendung unserer Dienste gesetzt haben
  • Sie betreiben Server oder Applikationen, die keine externe Namensauflösung unterstützen und somit lokal angepasst wurden (z.B. durch Verwendung einer IP anstelle eines Namens in einer Applikations-Konfiguration oder durch Eintrag in eine lokale hosts-Datei)
  • haben zur Erreichbarkeit unserer Adressen dedizierte Routen in Ihren Netzen hinzugefügt.

 

Im Fall einer erforderlichen Freischaltung in Sicherheitssystemen, empfehlen wir die Berücksichtigung des kompletten Adress-Block 217.150.144.128/25, so dass Sie auch bei Erweiterung (sei es aufgrund Funktionalität oder auch Performance) unserer Dienste keine Probleme erwarten.

 

Technische Details:
Aktuell sind unsere Dienste im Adressblock 195.243.179.128/25 angesiedelt und werden zum neuen Block 217.150.144.128/25 transferiert, wobei sich das letzte Oktett nicht ändert. Die Umstellung findet auf unserer Seite durch änderung der Dienste-spezifischen DNS-Einträge statt.

Öffentliche Links zum Thema:
Wikipedia - IP-Adresse
Wikipedia - Domain Name Service (DNS)
Wikipedia - Routing

 

 

Ab dem 01.01.2013 stellt T-Systems keine Zertifikate mit internen IP-Adressen oder lokalen Host-Namen mehr aus.

T-Systems stellt mit dem PKI-Service ServerPass SSL/TLS Webserver-Zertifikate aus, die durch die Nutzung öffentlicher Root-Zertifikate in vielen aktuellen Applikationen und Betriebssystemen vertrauenswürdig sind. Die Ausstellung setzt einen Verifikationsprozess voraus, in dem unter anderem der CommonName (CN) in Form des FQDN (Fully Qualified Domain Name) geprüft wird. Zertifikate, die eine interne IP-Adresse aus dem reservierten Adressbereich oder einen lokalen Host-Namen beinhalten, können nicht über DNS aufgelöst werden und sind von der T-Systems Registrierungsstelle nicht vollständig verifizierbar.

Dennoch ist solch ein ausgestelltes Zertifikat für jeden, dem es präsentiert wird, grundsätzlich vertrauenswürdig und könnte für Angriffsszenarien relativ leicht und mit großer Schadenswirkung missbraucht werden.
Daher nehmen diese Zertifikate eine Sonderrolle ein und werden vom internationalen CA/Browserforum, vielen Certification Authorities und Sicherheitsexperten als sehr kritisch eingestuft und missbilligt.

Worin besteht diese Bedrohung?

Zertifikate für private IP-Adressen unterstützen besonders in großen Firmennetzen ein individuelles Routing. Daher werden in unterschiedlichen Netzen sehr oft die gleichen IP-Adressbereiche verwendet. Dies ist teilweise auch dadurch bedingt, dass Gerätehersteller bei Auslieferung ihrer Komponenten identische Adressen (z.B. 192.168.1.x) vorkonfiguriert haben.

Außerdem sorgt in nahezu allen Firmen-Netzen ein sogenannter DNS-Suffix auf den Arbeitsplätzen dafür, dass beim Aufruf von z.B. https://mail in Wirklichkeit die Seite https://mail.example.com (steht exemplarisch für die jeweilige Firmen-Domäne) geladen wird.
 
Ein Angreifer kann sich diese Umstände zu Nutze machen, indem er sich von einer vertrauenswürdigen Zertifizierungsstelle ein Zertifikat auf eine solche private/reservierte Adresse (technische Details: siehe RFC 5735 @ ietf.org) oder einen häufig verwendeten Namen ausstellen lässt. Dieses Zertifikat könnte er dann, entweder bei einem direkten Zugriff oder indirekt durch einen Trojaner, in einem fremden Netz zum Einsatz bringen und verschlüsselte Daten ausspähen oder auch abfangen.
 
Das T-Systems Trust Center schließt sich der Einschätzung des Bedrohungspotenzials an und wird, auch im Sicherheitsinteresse seiner Kunden, ab dem 01.01.2013 keine Zertifikate mit internen IP-Adressen oder lokalen Host-Namen mehr ausstellen.

Keine Ausstellung von Zertifikaten mit internen IP-Adressen oder lokalen Host-Namen mit einer Gültigkeit über den 31.10.2015 hinaus

Die für "ServerPass" verwendeten CAs erfüllen die "Baseline Requirements for the Issuance and Management" des CA/Browserforums, siehe hierzu:

www.cabforum.org

Gemäß den Anforderungen "CA/Browser Forum Approves Baseline Requirements for SSL/TLS Certificates" vom 01.07.2012 werden Aufträge für SSL-Zertifikate, die interne IP-Adressen oder lokale Host-Namen enthalten mit einer maximalen Gültigkeitsdauer bis zum 31.10.2015 versehen. Daher werden ab sofort solche SSL-Zertifikate mit einer vorgesehenen Gültigkeit von 3 Jahren nicht mehr ausgestellt.

Zertifikate dieser Art, die vor dem 01.07.2012 ausgestellt wurden, werden spätestens am 01.10.2016 gesperrt, falls deren Gültigkeitsdauer an diesem Tag noch nicht abgelaufen ist.

 

Neues Root-CA und CA-Zertifikat zum 16.12.2010

Ab dem 16.12.2010 wird die Zertifizierungshierarchie für TeleSec ServerPass aktualisiert. Alle ZertifizierungsstellenEine Zertifizierungsstelle (englisch Certificate Authority, kurz CA) ist allgemein eine Organisation, die Zertifizierungen in bestimmten Bereichen durchführt. Im digitalen Bereich ist eine Zertifizierungsstelle eine Organisation, die digitale Zertifikate herausgibt. in der Vertrauenskette bieten durchgängig das hohe Qualitätsniveau von 2048 Bit RSARSA ist ein asymmetrisches Kryptosystem, das sowohl zur Verschlüsselung als auch zur digitalen Signatur verwendet werden kann. Es verwendet ein Schlüsselpaar, bestehend aus einem privaten Schlüssel, der zum Entschlüsseln oder Signieren von Daten verwendet wird, und einem öffentlichen Schlüssel, mit dem man verschlüsselt oder Signaturen prüft. Der private Schlüssel wird geheimgehalten und kann nur mit extrem hohem Aufwand aus dem öffentlichen Schlüssel berechnet werden. und somit weiterhin Zukunfts- und Planungssicherheit an. Mit Umstellung der Zertifizierungshierarchie werden alle ServerPass Zertifikate nur noch von der Zertifizierungsstelle TeleSec ServerPass CA 1 ausgestellt. Die Spitze der Zertifizierungshierarchie bildet die international etablierte Baltimore CyberTrust Root. Dieser neue Vertrauensanker (Root-Zertifikat) für TeleSec ServerPass bietet Ihnen maximale Marktdurchdringung und hervorragende Abdeckung aktueller Applikationen.

Ihre Vorteile auf einen Blick
  • Bei der Beauftragung ist keine Rootauswahl mehr erforderlich
  • Längere Zertifikatslaufzeiten reduzieren den Aufwand beim Management Ihrer Serverapplikationen
  • Reduzierte Kosten durch den Einsatz von Zertifikaten mit einer Laufzeit von 2 und 3 Jahren
  • Zunkunftssicherheit durch den Einsatz moderner Sicherheitsverfahren
  • Planungssicherheit durch lange Zertifikatslaufzeiten
Weitere Neuigkeiten
Mit der neuen Zertifizierungshierarchie können Sie nun Zertifikate mit einer Laufzeit von 1, 2 oder 3 Jahren beauftragen. Weiterhin bieten wir Ihnen für Microsoft Exchange 2007 & Office Communication Server 2007 den neuen TeleSec ServerPass SAN/UCC an.

Wichtiger Hinweis
Bitte berücksichtigen Sie, dass bei der Installation von ServerPass auch immer das Zwischenstellen-Zertifikat mit installiert wird. Sie vermeiden damit, dass es zu Inkompatibilitäten und irritierenden Hinweisen kommt.