Chrome und Safari limitieren SSL Zertifikate auf ein Jahr Gültigkeit

Autor Uwe GradeneggerVeröffentlicht am Kategorien Zertifikat-BenutzungSchlagwörter , , , , , , , , ,

Apple hat vor kurzem angekündigt, dass der Safari-Browser künftig nur noch Zertifikate mit einer Gültigkeit von 398 Tagen akzeptieren wird, sofern diese ab 1. September 2020 ausgestellt wurden.

Mozilla und Google wollen in ihren Browsern ein vergleichbares Verhalten implementieren. Es stellt sich also die Frage, ob diese Änderung Auswirkungen auf interne Zertifizierungsstellen haben wird – ob künftig also auch interne SSL-Zertifikate diese Regeln befolgen müssen, wie es beispielsweise bei der Erzwingung des RFC 2818 durch Google der Fall war.

Sind interne Zertifizierungsstellen betroffen?

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

In der offiziellen Dokumentation von Apple findet sich folgender Satz, der klar festlegt, dass interne Zertifizierungsstellen von der Prüfung ausgeschlossen sind:

This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.

About upcoming limits on trusted certificates (APPLE)

Vom Chromium Projekt gibt es hierzu keine schriftliche Aussage, jedoch zeigt ein Einblick in dessen Quelltext, dass die exakt gleiche Logik in der Funktion CertVerifyProc::HasTooLongValidity verwendet wird wie bei der vorigen Reduzierung auf 825 Tage.

// For certificates issued on-or-after 1 March 2018: 825 days.
   if (start >= time_2018_03_01 &&
       validity_duration > base::TimeDelta::FromDays(825)) {
     return true;
   }
// For certificates issued on-or-after 1 September 2020: 398 days.
   if (start >= time_2020_09_01 &&
       validity_duration > base::TimeDelta::FromDays(398)) {
     return true;
   }

Tests mit Chrome und Edge ergaben jedoch, dass bei internen Zertifizierungsstellen bereits das aktuelle Limit von 825 Tagen nicht zu einer Fehlermeldung führen – im Gegensatz zur Erzwingung des RFC 2818, welches 2017 in Chromium eingeführt wurde.

Im Gegensatz zu Chrome und Edge schränkt Apple die Zertifikatgültigkeit auch für Webserver-Zertifikaten von internen Zertifizierungsstellen auf höchstens 825 Tage ein, wenn diese nach dem 01. Juli 2019 ausgestellt wurden.

Update

Mittlerweile hat Google einen entsprechenden Artikel veröffentlicht, in welchem die Vermutung bestätigt wird.

This only applies to the set of CAs that are trusted by default by Google Chrome, and not CAs that are operated by an enterprise and that have no certification paths to CAs that are trusted by default.

Warum werden interne Zertifikate ohne SAN von Chrome bemängelt, interne Zertifikate mit einer langen Zertifikat-Gültigkeit jedoch nicht?

Dazu werfen wir einen Blick auf den Code, welcher die Gültigkeit des Zertifikats überprüft:

// Flag certificates using too long validity periods.
   if (verify_result->is_issued_by_known_root && HasTooLongValidity(*cert)) {
     verify_result->cert_status |= CERT_STATUS_VALIDITY_TOO_LONG;
     if (rv == OK)
       rv = MapCertStatusToNetError(verify_result->cert_status);
   }

Hier wird geprüft, ob das Zertifikat von einer "öffentlichen" Zertifizierungsstelle stammt und ob die Zertifikatgültigkeit innerhalb des erlaubten Rahmens liegt.

Zum Vergleich der Code, welcher die Prüfung auf Einhaltung des RFC 2818 übernimmt:

if (!cert->VerifyNameMatch(hostname)) {
     verify_result->cert_status |= CERT_STATUS_COMMON_NAME_INVALID;
     rv = MapCertStatusToNetError(verify_result->cert_status);
   }

Hier fehlt die Prüfung is_issued_by_known_root, welche die Auswahl auf "öffentliche" Zertifizierungsstellen einschränkt. Somit gilt die Prüfung für das RFC 2818 generell für alle Zertifikate, die Prüfung der Zertifikatgültigkeit jedoch nur für Zertifikate, die nicht von einer internen Zertifizierungsstelle ausgestellt wurden.

Ist der Microsoft Edge betroffen?

Da viele Unternehmen den Microsoft Edge Browser verwenden, ist es für uns sehr interessant, zu wissen, ob dieser auch betroffen ist. Da der Microsoft Edge Browser nun wie Google Chrome auf dem Chromium Projekt basiert, übernimmt er (weitestgehend) dessen Verhalten. Entsprechend ist er genauso betroffen wie Chrome.

Fazit: Besteht Handlungsbedarf?

Für Internet Explorer Safari, Chrome und Microsoft Edge besteht bei Verwendung einer eigenen internen Zertifizierungsstelle aus rein technischer Sicht kein Handlungsbedarf, da diese bei der Zertifikatprüfung ausgeschlossen werden. Somit können intern weiterhin SSL-Zertifikate verwendet werden, die länger als 398 Tage gültig sind, jedoch nicht länger als 825 Tage.

Es ist allerdings durchaus ratsam, die Ausstellungs- und Außerbetriebnahmeprozesse für SSL-Zertifikate dahingehend zu überprüfen, ob eine solch lange Zertifikatgültigkeit unter Einhaltung des gewünschten Sicherheitsniveaus realisierbar ist.

Weiterführende Links:

Externe Quellen

2 Gedanken zu „Chrome und Safari limitieren SSL Zertifikate auf ein Jahr Gültigkeit“

  1. Pingback: Google Chrome und Microsoft Edge prüfen Sperrstatus von Zertifikaten nicht – Uwe Gradenegger
  2. Pingback: Konfigurieren einer Secure Socket Layer (SSL) Zertifikatvorlage für Web Server – Uwe Gradenegger

Kommentare sind geschlossen.

de_DEDeutsch
en_USEnglish de_DEDeutsch