SUPPORT

HOT UPDATE

Modifikation der Abbildung von SSL-Zertifikaten in Chrome

Fulda, den 15.10.2018

Nachdem nun über 75% der Internetseiten SSL-Zertifikate nutzen, wurden für die neue Chrome Version 68 interessante Änderungen in der Anzeige dieser Verschlüsselung umgesetzt. Anstatt nur das Vorhandensein von SSL-Zertifikaten abzubilden, wird nun ausnahmslos vor jeder unverschlüsselten Seite gewarnt.

Zuvor wurde in Google Chrome nur vor denjenigen HTTP-Seiten gewarnt, die Passwort- oder Bezahlungsinformationen verarbeiten. Nun werden alle unverschlüsselten Webseiten in Chrome mit einem grauen „Nicht Sicher“ in der Adresszeile gekennzeichnet. Somit sollten voraussichtlich noch einige Seitenbesitzer die Verschlüsselung ihrer Webseite in Gang setzen.

Für die zukünftige Chrome Version 69 wurden weitere Neuerungen angekündigt. So soll das zuvor grün abgebildete „Sicher“ bei verschlüsselten Seiten, welches erst 2016 hinzugefügt wurde, wieder verschwinden. Grund hierfür könnte die Tatsache sein, dass Verschlüsselung mittlerweile als allgemeiner Standard gilt und Negativ-Warnungen deutlich effektiver wirken als eine positive Darstellung der sicheren Seiten.

DigiCert: Optimierungsmarathon geht in die nächste Runde

DigiCert hat in den vergangenen Wochen weitere Verbesserungen und Neuheiten in Angriff genommen. Unter anderem wurde der Prozess der Validierung von Domänen angepasst und ist seit 8. August auf dem aktuellem Stand. Zudem wurde die Umstellung auf DigiCert weiter vorangebracht, indem nun keine validierungsbezogenen Mails mehr von @symantec.com-E-Mail-Adressen, sondern von DigiCert-Adressen verschickt werden. 
Außerdem ändert sich die Code-Signing PKI-Hierarchie noch im Verlaufe des Jahres. Dies geschieht zum Zwecke Aktualisierung des Sortiments an Code-Signing-Zertifikaten und des Einbaus der ehemaligen Website-Sicherheitsinfrastruktur. Jegliche neue Code-Signing-Zertifikate sollen bis zum 31. Oktober ausgestellt werden. Bestehende Code-Signing-Zertifikate, deren Sicherheitsstatus oder Laufzeit bleiben von diesen Änderungen unbeeinflusst.



Certum: Nachzügler in der Validierungsanpassung

Ab dem 01. August 2018 wird auch Certum seine Validierungsmöglichkeiten an den Beschluss des CA/Browser Forums anpassen. Das bedeutet konkret, dass es mit Eintreten dieses Datums nicht mehr möglich sein wird, die Domain über den Whois-Kontakt zu validieren.
Somit verbleiben noch drei Möglichkeiten der Validierung bei Certum:

1. Beweis der Domain-Inhaberschaft mithilfe der Administratoren-E-Mail-Adresse:
• admin@,
• administrator@,
• hostmaster@,
• postmaster@ oder
• webmaster@.

2. Beweis der Domain-Inhaberschaft durch Hochladen einer „HTML“-Datei auf den Server. Der Inhalt wird von Certum bestimmt.

3. Beweis der Domain-Inhaberschaft durch Erstellen eines Texteintrags im DNS. Der Text wird von Certum vorgegeben.

GlobalSign: Temporärer Ausfall von Zertifikats-Managementdiensten

Fulda, den 17.07.2018

GlobalSign wird am 29. Juli 2018 zwischen 21:00 und 23:00 Uhr wichtige Wartungsarbeiten durchführen. Damit einhergeht eine kurzweilige Blockade der Zertifikats-Managementfunktionen, d. h. der Kauf, die Erneuerung und Neuausstellung von Zertifikaten wird während der Durchführung dieser Updates nicht möglich sein.

WICHTIG: Timestamping, Site Seal- und OCSP- Dienste sind von diesen temporären Arbeiten nicht betroffen und können wie gewohnt in Anspruch genommen werden.

GlobalSign: Anpassung der Domainvalidierung

Fulda, den 17.07.2018

Ab dem 1. August 2018 werden die zulässigen Methoden der Domainvalidierung geändert. Mit Eintreten dieses Datums dürfen die Validierungsmethoden 1 und 5 nicht mehr in Anspruch genommen werden. Die gestrichenen Validierungsmethoden nutzten die WHOIS-Daten, welches nicht mehr zur Prüfung herangezogen werden dürfen. Auch GlobalSign passt nun die Validierungsmethoden an und lässt ab August ausschließlich Methoden zu, die HTTP- und DNS-basiert sind.

Folgen hat das vor allem für die Ausstellung von organisationsvalidierten SSL-Zertifikaten, die häufig über Methode 1 validiert wurden. Für alle Neuausstellungen dieser Zertifikate muss die Domain zwangsläufig ein weiteres Mal geprüft werden. Für diese Prüfung werden von GlobalSign dann E-Mail, HTTP oder DNS Validierungsmöglichkeiten genutzt.

WICHTIG: Weder bei bestehenden OV SSL Zertifikaten, noch bei EV SSL Zertifikaten besteht aktuell Handlungsbedarf. Die neuen Bedingungen betreffen lediglich auslaufende OV SSL Zertifikate. 

Neue Anforderung an die Domainvalidierung

Fulda, den 05.07.2018 

Nach dem Beschluss des CA/Browser Forums, soll die Domainvalidierung nicht mehr über eine Prüfung des WHOIS erfolgen. Folgende Validierungsmöglichkeiten werden somit von der Liste an Methoden der Domainvalidierung entfernt.

Möglichkeit 1 Validierung durch eine Überprüfung der Übereinstimmung des Antragstellers (Domain-Kontakt) mit dem WHOIS-Datensatz.

Möglichkeit 5 Domain-Autorisierungsdokument.

Weitere Änderungen, die sich durch die Ballot 218 ergeben, sind die Abänderung des AATL-Überprüfungsverfahrens sowie die Abklärung des ePKI/MSSL-Überprüfungsprozesses. Zweck der Änderungen war der Versuch den Prüfprozess auf das Eigentum und die Kontrolle des Antragstellers zu fokussieren. Bei den meisten Validierungsmöglichkeiten war es der Fall, dass tatsächlich Eigentum und Kontrolle untersucht wurden, bei Validierungsmethode 1 und 5 jedoch nicht, weshalb diese entfernt werden sollten.

Schon ab dem 01. März 2018 durfte die WHOIS-Methode nicht mehr für die Verifizierung von OV/EV MSSL verwendet werden. Ab dem 01. August 2018 soll nun die Validierung ausschließlich mithilfe von technischen Domainvalidierungsverfahren erfolgen. Alle ausstehenden OV/EV-MSSL-Domänen, in denen die WHOIS-Methode verwendet wurde, müssen neu validiert werden. 

Google: Strengere SSL-Zertifikatsprüfung durch Chrome 68

Fulda, den 05.07.2018 

Die neue Google Richtlinie „Certificate Transparency“, die ab 01. Juli 2018 mit der Browser-Version Chrome 68 umgesetzt wurde, bringt einige Veränderungen für die Verwendung von SSL-Zertifikaten mit sich. Die Richtlinie, die aufgrund eines vermeintlichen Zusammenhangs von SSL-Zertifikaten und der Seriosität von Websites verfasst wurde, beinhaltet, dass alle SSL-Zertifikate, die nach dem 30. April 2018 ausgestellt wurden mit Googles Bestimmungen (Chromium CT-Richtlinie) Konform gehen müssen. Anderenfalls kann dies zu einer schlechteren Einstufung durch Google und Fehlermeldungen beim Seitenaufruf führen.

Zwei Möglichkeiten der Prüfung von Zertifikaten sind die Pre-Certificate-Methode, bei der Informationen im Zertifikat enthalten sind oder OCSP-Stapling, wo CT-Log-Informationen durch die Antwort eines OCSP Servers bereitgestellt werden. Bei der zweiten Methode sind spezielle Server-Einstellungen erforderlich. Hierzu haben wir eine Anleitung unterfolgendem Link für Sie bereitgestellt. Um Ihre Webseite zu testen können Sie diese mithilfe von Chrome Canary öffnen, wenn keine Fehlermeldung angezeigt wird, besteht kein Änderungsbedarf, wenn doch sind weitere Anpassungen notwendig.

Comodo: Verzögerungen bei der Ausstellung und Austausch von SSL-Zertifikaten

Fulda, den 21.06.2018

Wegen einer internen Umstrukturierung kommt es derzeit bei der Ausstellung von S/MIME-, SSL-und Code-Signing-Zertifiakaten eventuell zu Verzögerungen. Dies kann unter Umständen bis zu 5 Werktagen dauern. Ab nächster Woche sollte der Service wieder wie gewohnt weiterlaufen.

SwissSign: Änderungen im Domänenprüfverfahren

Fulda, den 21.06.2018

Um die Anforderungen des CA/Browser Forum zu erfüllen, wird SwissSign zum 30. Juni 2018 bei sämtlichen SSL-Zertifikatsanträgen die automatische Domänenvalidierung aktivieren. Um Ihren Zugriff auf die Domänen zu prüfen, muss das von unserem System generierte Zufallswert/Geheimnis (weiter unten als <random value> referenziert) an einer der drei folgenden Stellen auf der Webseite Ihrer Domain hinterlegt werden:
 
  • TXT Check*
In einer Textdatei unter dem Pfad:
<domain>/.well-known/pki-validation/swisssign-check.txt 
Der Inhalt der Text-Datei muss wie folgt formatiert sein: <random value>

 
  • HTML META TAG Check*
Als <meta> Tag einer HTML Datei unter dem Pfad:
<domain>/.well-known/pki-validation/swisssign-check.htm
Der Inhalt des Meta Tags muss wie folgt formatiert sein: <meta name="swisssign-check" content="<random value>" />

 
  • DNS Eintrag
Als TXT Eintrag im DNS der Domäne:
Der Inhalt muss wie folgt formatiert sein: "swisssign-check=<random value>"


*Bitte beachten Sie, dass für diese Verfahren keine Weiterleitungen erlaubt sind.
 

Die spitzen Klammern <> beim <random value> dienen nur zur Illustration und müssen weggelassen werden.


Mit dem Release 4.12 (26.05.2018) wurde das Managed PKI Tool zur Domänenverifikation weiterentwickelt. MPKI Kunden sehen dort ab sofort alle freigeschalteten Domänen und deren Validierungsstatus.


Im Rahmen der beschriebenen automatischen Verfahren prüft das System 30 Tage lang, ob der Zufallswert an einer der drei oben erwähnten Stellen hinterlegt wurde. Sobald eine der drei Prüfungen erfolgreich ist, wird die Domäne automatisch freigeschaltet. Für noch nicht validierte Domänen kann die Validierung vom Kunden direkt ausgelöst werden. SwissSign wird im Juni 2018 für alle noch ausstehenden Domänen die Validierung anstossen. Kunden können dann die generierten Zufallswerte via CSV Datei exportieren und hinterlegen.


Für Sie als SwissSign Managed PKI-Kunde gibt es folgende Änderungen zu berücksichtigen:
 
Erstmalige Prüfung
Neue Domänen können nur noch mit einem der oben beschriebenen Verfahren eingetragen werden. Bereits eingetragene Domänen müssen bis zum 30. Juli 2018 mit einem der oben beschriebenen Verfahren validiert werden. Domänen, die bis zum 31. Juli 2018 nicht gemäss obigen Angaben validiert wurden, müssen aus regulatorischen Gründen per 1. August 2018 von SwissSign aus dem entsprechenden MPKI Setup entfernt werden. Ausgenommen von dieser Regelung sind nur Kunden, welche ausschliesslich S/MIME Zertifikate beziehen.

 
Wiederkehrende Prüfungen
Bitte beachten Sie, dass die automatische Domänenvalidierung beim Einsatz von EV SSL Zertifikaten jeweils nach 13 Monaten und bei Domänen- und Organisationsvalidierten SSL Zertifikaten jeweils nach 24 Monate wiederholt werden muss.

Workaround zum Firefox-Bug

Fulda, den 11.04.2018

Wie wir bereits berichteten gibt es bei der neuesten Version vom Mozilla Firefox einen Bug, der es nicht möglich macht über den Browser bestellte E-Mail-Zertifikate von Comodo abzuholen.

Da die Abholung der Comodo E-Mail-Zertifikate im Firefox bis zur Version 58.0.2 möglich ist, empfehlen wir Ihnen als temporäre Lösung eine älter Version vom Firefox zu nutzen.

Diesen können Sie unter folgenden Links runterladen:

Übersicht aller Plattformen (inklusive Checksums) zum Download:
http://releases.mozilla.org/pub/firefox/releases/58.0.2/

Direkte Downloads in deutscher Sprache

Linux 32-Bit
http://releases.mozilla.org/pub/firefox/releases/58.0.2/linux-i686/de/firefox-58.0.2.tar.bz2

Linux 64-Bit
http://releases.mozilla.org/pub/firefox/releases/58.0.2/linux-x86_64/de/firefox-58.0.2.tar.bz2

Mac (EME-free)
http://releases.mozilla.org/pub/firefox/releases/58.0.2/mac-EME-free/de/Firefox%2058.0.2.dmg
http://releases.mozilla.org/pub/firefox/releases/58.0.2/mac-EME-free/de/Firefox%2058.0.2.dmg.asc

Mac
http://releases.mozilla.org/pub/firefox/releases/58.0.2/mac/de/Firefox%2058.0.2.dmg

Windows 32-Bit (EME-free)
http://releases.mozilla.org/pub/firefox/releases/58.0.2/win32-EME-free/de/Firefox%20Setup%2058.0.2.exe
http://releases.mozilla.org/pub/firefox/releases/58.0.2/win32-EME-free/de/Firefox%20Setup%2058.0.2.exe.asc

Windows 32-Bit
http://releases.mozilla.org/pub/firefox/releases/58.0.2/win32/de/Firefox%20Installer.exe
http://releases.mozilla.org/pub/firefox/releases/58.0.2/win32/de/Firefox%20Setup%2058.0.2.exe

Windows 64-Bit (EME-free)
http://releases.mozilla.org/pub/firefox/releases/58.0.2/win64-EME-free/de/Firefox%20Setup%2058.0.2.exe
http://releases.mozilla.org/pub/firefox/releases/58.0.2/win64-EME-free/de/Firefox%20Setup%2058.0.2.exe.asc

Windows 64-Bit
http://releases.mozilla.org/pub/firefox/releases/58.0.2/win64/de/Firefox%20Setup%2058.0.2.exe

INFO bzgl. "EME-Free"
Encrypted Media Extension (JavaScript-Schnittstelle) dient dazu DRM-geschützte Inhalte abzuspielen.


Tipp:

Nach der Neu-Installation des Browsers stehen in der Regel alle alten Zertifikate noch im Repository des Browsers zur Verfügung.


Hinweis:

Der Browser sollte dann zügig dafür genutzt werden, die neuen Zertifikate zu beziehen. Bei einem Neustart des Browsers könnte direkt die Update-Funktion versuchen den Browser auf die neueste (nicht mehr funktionierende) Version zu aktualisieren.

Alternativ kann man mit folgenden Schritten die Update-Funktion deaktivieren. Nach der Erfolgreichen Installation der Zertifikate sollte die Update-Funktion aber wieder aktiviert werden!

  • Geben Sie in die Adresszeile von Firefox about:config ein und drücken Sie „Enter“.
  • Suchen Sie die Einträge app.update.auto, browser.search.update, app.update.enabled, extensions.update.enabled und extensions.update.notifyuser.
  • Hinter diesen Einträgen sollte in der Spalte „Wert“ die Eigenschaft „true“ stehen.
  • Klicken Sie mit rechts auf die jeweilige Zeile und wählen Sie „Umschalten“ aus. Daraufhin springt der Wert auf „false“ und ist deaktiviert.


Chrome-Browser verlangt ab April 2018 CT-Protokolle für alle vertrauenswürdigen SSL-Zertifikate

Reminder: Certificate Transparancy (CT)

Fulda, den 03.04.2018

Comodo möchte Ihre Organisation weiterhin bestmöglich absichern und informiert über die neuesten Anforderungen des Google Chrome-Browsers:

Im April 2018 beginnt der Chrome-Browser von Google damit, alle öffentlich vertrauenswürdigen Serverzertifikate in öffentlichen CT-Protokollen zu protokollieren. Dies betrifft alle domainvalidierten(DV), organisationsvalidierten (OV) und erweitert validierten (EV) SSL-Zertifikate, die seit Januar 2015 in den CT-Logs enthalten sind.

Was ist Certificate Transparancy (Zertifikattransparenz)?: CT ist ein System von öffentlichen "Logs", die verwendet werden, um eine nur anhängige Liste aller öffentlich ausgestellten Zertifikate zu führen. Diese Protokolle können verwendet werden, um falsch ausgestellte Zertifikate zu erkennen. Außerdem können Benutzer die Zertifikatausgabe für ihre eigenen Eigenschaften überwachen, die sie möglicherweise nicht kennen oder nicht autorisiert haben. Browser können Daten innerhalb der Zertifikate verwenden, die die protokollierten Zertifikate "beweisen" und sicherstellen, dass sie vertrauenswürdig sind. Somit ist es wesentlich einfacher, falsch ausgestellte SSL-Zertifikate zu erkennen.

Comodo erfüllt diese Anforderungen und generiert automatisch die erforderlichen Zeitstempel für signierte SSL-Zertifikate und fügt diese den ausgestellten Zertifikaten hinzu, so dass Google Chrome sicher sein kann, dass die Zertifikate korrekt ausgestellt wurden.

Diese Information haben wir von Support@noSpamComodoCA.com.

Für Rückfragen steht Ihnen unser Support-Team unter der Telefonnummer +49 661 480 276 10 gern zur Verfügung.


Wichtige Informationen zu E-Mail Zertifikaten von Comodo

Bug bei Mozilla Firefox

Fulda, den 26.03.2018

Nach Rücksprache mit Comodo, möchten wir Sie über einen Bug im Mozilla Firefox informieren.
Dieser Bug hat zur Folge, dass bei der Abholung Ihrer E-Mail-Zertifikate immer die Fehlermeldung ausgegeben wird, das Kennwort sei nicht korrekt.

Um Ihr E-Mail Zertifikat dennoch zu sichern, empfehlen wir Ihnen daher temporär, für diesen Zertifikatsprozess den Internet Explorer zu nutzen.
Beachten Sie bitte, dass alle Ihnen zugesendeten Links von Comodo ausschließlich im Internet Explorer geöffnet werden sollten.

Absender dieser E-Mails ist noreply_support@noSpamcomodo.com.

Für Rückfragen steht Ihnen unser Support-Team gerne unter der Telefonnummer +49 661 480 276 10 zur Verfügung.


Entzug der Vertrauenswürdigkeit für SSL/TLS-Zertifikate der Symantec-Gruppe

Prüfen Sie, ob Ihr SSL-Zertifikat getauscht werden muss!

Fulda, den 28.02.2018

In den kommenden Versionen von Google Chrome werden ab März oder September bestimmte SSL-Zertifikate von Symantec, Thawte und GeoTrust als nicht vertrauenswürdig angezeigt. Wir haben bereits berichtet!

Chrome-Nutzer sehen dann "Nicht sicher" in der Adressleiste, wenn sie eine Website aufrufen, die ein nicht vertrauenswürdiges SSL-Zertifikat verwendet.

Ob auch Ihr Symantec, Thawte oder GeoTrust SSL-Zertifikate ausgetauscht werden muss, können Sie auch selbst prüfen! Klicken Sie auf "PRÜFEN" um zum SSL Checker zu gelangen:

SSL-CHECKER
Prüfen Sie hier ob Ihr Symantec, Thawte, GeoTrust oder RapidSSL SSL-Zertifikat betroffen ist.
PRÜFEN

Ende der Ausstellung von SSL-Zertifikaten mit dreijähriger Laufzeit

Ab 01.03.2018 keine 3 Jahres SSL-Zertifikate mehr

Fulda, 31.01.2018

Wie bereits in unserem HOT Update berichtet hat das CA/B-Forum die Mindestanforderungen an die Ausstellung von SSL-Zertifikaten angepasst. Zum 1. März 2018 wird die maximale Gültigkeitsdauer von allen SSL-Zertifikaten auf 825 Tage (27 Monate) beschränkt.

Daher wird thawte schon ab dem 20. Februar 2018 keine SSL-Zertifikate mit dreijähriger Gültigkeitsdauer mehr ausstellen. Ab dem 01. März 2018 werden Comodo und Certum auch keine SSL-Zertifikate mit dreijähriger Gültigkeitsdauer mehr ausstellen.

Wichtiger Hinweis: Diese Änderung betrifft alle Zertifizierungsstellen.

Bereits ausgegebene Zertifikate, die drei Jahre oder länger gelten, behalten Ihre Gültigkeitsdauer. In diesem Fall sind keine Maßnahmen Ihrerseits erforderlich.

Wenn Sie Ihr SSL-Zertifikat mit dreijähriger Gültigkeitsdauer nach dem 20. Februar 2018 (thawte) bzw. nach dem 01. März 2018 bei Comodo oder Certum austauschen müssen, erhalten Sie ein Ersatzzertifikat, dass für die verbleibende Laufzeit des ursprünglichen Zertifikats bzw. für maximal 825 Tage gültig ist.    

Validierungsguidelines für DigiCert-Zertifikate (gilt auch für Symantec, thawte und GeoTrust)

Fulda, 31.01.2018

Bei der Validierung der Zertifikate setzt DigiCert die Richtlinien des CA/Browser Forums (CAB Forum) und die Browser Root-Store-Richtlinien um. Die Einhaltung dieser Richtlinien hilft, Kunden zu schützen und eine gesunde Beziehung zu den Betreibern von Rootstores zu gewährleisten.

Die Validierung der DV-SSL-Zertifikate erfolgt über die Domainüberprüfung und der OV- und EV-SSL-Zertifikaten über Identitäts- und Domainüberprüfung.

1. Identitätsüberprüfung

DigiCert verifiziert die Identität anhand von Abfragen aus öffentlichen Datenbanken. Diese Identitätsüberprüfung ist gekoppelt an eine Autoritätsüberprüfung. DigiCert verifiziert die Autorität während eines Telefonats an eine vorher verifizierte Nummer, falls verfügbar können aber auch E-Mails, Textnachrichten und andere Kommunikationsmittel genutzt werden.


Ein Versäumnis der Durchführung eines der beiden erforderlichen Verifizierungsschritte führt dazu, dass die CA gegen die Root-Store-Richtlinien des Browsers verstößt, selbst wenn andere Schritte äußerst gewissenhaft durchgeführt wurden. Ein Verstoß gegen eine Root-Store-Richtlinie ist ein Grund für die Entfernung aus den Root-Stores.

2. Domainüberprüfung

Die Domainüberprüfung ist unabhängig vom Zertifikatstyp eine kritische Komponente und wird für alle Zertifikate gemäß Abschnitt 3.2.2.2.4. der CAB Forum Baseline Requirements (BRs) gefordert.

Durch die Domainüberprüfung bestätigt der Zertifikatsinhaber die Inhaberschaft oder die Kontrolle über einen Domainnamen.

Bei OV- und EV-Zertifikaten zeigt dieser entscheidende Schritt die Verbindung zwischen der Organisation und der Domain.

Die Base Requirements erlauben es CAs, eine von zehn Methoden zur Überprüfung der Domänenkontrolle zu nutzen.
DigiCert unterstützt derzeit die Verifikation durch folgende Methoden:

  • Versendung einer Bestätigungs-E-Mail an den WHOIS E-Mail-Kontakt
  • Telefonische Validierung mit dem WHOIS Telefonkontakt
  • Versendung einer Bestätigungs-E-Mail an eine generische E-Mail-Adresse die innerhalb der zu zertifizierenden Domain liegt
  • dateibasierte Authentifizierung (Upload einer Datei in ein durch DigiCert vorgegebenes Verzeichnis)
  • DNS-Verifizierung (Zufallswerte in TXT-, CNAME- und CAA-Datensätzen)

Symantec: Probleme bei der Ausstellung und Austausch von SSL-Zertifikaten

Fulda, den 15.01.2018

Die Probleme, die nach der Übernahme der Symantec-Gruppe (Symantec, thawte, GeoTrust, RapidSSL) durch DigiCert aufgetreten sind, konnten bisher noch nicht gelöst werden.

Leider kommt es immer noch zu massiven Verzögerungen bei der Ausstellung von SSL-Zertifikaten. Zudem sind seit einigen Wochen weitere Probleme bei der Validierung und dem Versand von Bestätigungsemails hinzugekommen. Weiterhin möchten wir darauf hinweisen, dass manchmal Bestellungen storniert werden, wenn die Bestätigung des Auftrages nicht innerhalb kürzester Zeit erfolgt ist. Leider erhalten wir zu diesen Bestellungen auch kein Statusupdate, sodass wir auf Ihre Mithilfe angewiesen sind.

Für diese Unannehmlichkeiten möchten wir uns stellvertretend entschuldigen und bitten um Ihr Verständnis.

Symantec: Änderungen bei Code-Signing-Zertifikaten

 

 


Verzögerungen bei der Ausstellung von Zertifikaten der Symantec-Gruppe

Fulda, den 22.12.2017

  Aufgrund der Übernahme des Geschäftsbereichs Certificate Authority der Symantec-Gruppe (Symantec, GeoTrust, RapidSSL, thawte) durch DigiCert kann es aktuell zu Verzögerungen bei der Ausstellung von Zertifikaten der Symantec-Gruppe kommen.

Für diese Unannehmlichkeiten möchten wir uns stellvertretend entschuldigen und bitten um Ihr Verständnis.

Eine Übersicht über die Symantec-Austausch-Termine finden Sie hier.    

Falsche Darstellung der (EV)-Zertifikate von der Symantec-Gruppe

Fulda, den 12.12.2017

Bei Symantec-, Thawte- und GeoTrust Extended Validation (EV)-Zertifikaten, die Ende 2017 von DigiCert (SHA-256-Full Chain) ausgestellt wurden, wird die grüne Adressleiste in Google Chrome nicht angezeigt. Dies ist auf einen Fehler in Chrome zurückzuführen. Weitere Informationen: Chrome Bug.

Dieser Fehler wurde bereits gemeldet und Google arbeitet an der Fehlerbehebung. Um fehlerhafte Anzeigen in der Adressleiste bei Google Chrome zu vermeiden hat Symantec die Option SHA-256-Full Chain deaktiviert. Sobald diese Funktion wieder aktiviert ist, kann Ihr Zertifikat mit SHA-256-Full Chain erneut ausgestellt werden.

Wichtige Updates bei GlobalSign am 16. Dezember bis 10 Uhr

Fulda, den 11.12.2017

GlobalSign führt am 16. Dezember wichtige Updates an seiner Datenbank durch. In diesem Zeitraum sind alle GlobalSign-Systeme betroffen:

UTC: 3.00 - 9.00 Uhr, 16. Dez

MEZ: 4.00 - 10.00 Uhr, 16. Dez


Alle Funktionen des Zertifikatsmanagement (z.B. bestellen,wiederausstellen und erneuern) über das GlobalSign Certificate Center(GCC) oder APIs werden nicht verfügbar sein. In dem Zeitraum werden keine Zertifikate ausgestellt.

Bitte beachten Sie: Zeitstempel und OCSP Dienste sind möglicherweise in dem Zeitraum kurzfristig betroffen (30 Sekunden für OCSP und 2 Minuten TSA Unterbrechung). Site Seals werden als statisches Bild angezeigt, die Zertifikatsdetails auf Klick werden kurzzeitig nicht verfügbar sein.

Wir möchten uns schon jetzt für die Unannehmlichkeiten entschuldigen.


DigiCert übernimmt Symantecs PKI-Geschäft

Wichtige Informationen rund um die Umstellung auf die neue Infrastruktur

Fulda, den 04.12.2017

Wie bereits in unserem Hot Update berichtet, hat Google einen zeitkritischen Plan bezüglich der von Symantec ausgestellten SSL/TLS-Serverzertifikate veröffentlicht und bestätigt sämtlichen SSL/TLS-Zertifikaten der Symantec-Gruppe (Symantec, thawte, GeoTrust und RapidSSL) innerhalb einer Frist bis zum 15. März 2018 das Vertrauen zu entziehen. Zudem hat Google Chrome erklärt, dass alle Symantec-Zertifikate ab dem 1. Dezember 2017 von einer neuen Infrastruktur ausgestellt werden müssen.
Daraufhin hat DigiCert Symantecs Website Security und das damit verbundene PKI-Geschäft übernommen. Nach der Übernahme werden alle Produkte von Symantec, thawte, GeoTrust und RapidSSL weiterhin zu gleichen Kontitionen angeboten.

Zum 01. Dezember 2017 wurde Symantec, thawte, GeoTrust und RapidSSL auf die neue DigiCert PKI-Infrastruktur migriert. Das bedeutet, dass ab sofort alle neuen SSL/TLS-Zertifikate und die bestehenden Aufträge nur noch über die neue DigiCert Infrastruktur ausgestellt, ausgetauscht und durch DigiCert validiert werden.

Aufgrund der Übernahme des Geschäftsbereichs Certificate Authority der Symantec-Gruppe (Symantec, GeoTrust, RapidSSL, Thawte) durch DigiCert kann es aktuell zu Verzögerungen bei der Ausstellung von Zertifikaten der Symantec-Gruppe kommen. Wir arbeiten derzeit akribisch an einer Problemlösung. Für diese Unannehmlichkeiten möchten wir uns stellvertretend entschuldigen und bitten um Ihr Verständnis.


Wenn Sie ein SSL/TLS-Zertifikate der Symantec-Gruppe im Einsatz haben ergibt sich für Sie der  folgende Zeitplan:

  Bis zum 15. März 2018

•    SSL/TLS-Zertifikate, die vor dem 01. Juni 2016 ausgestellt wurden, können ab sofort bis zum 15. März 2018 durch die neue SubPKI von DigiCert ausgetauscht werden. Ab dem 15. März 2018 werden SSL/TLS-Zertifikate, die noch über die alte PKI-Infrastruktur von Symantec ausgestellt und nicht ausgetauscht wurden, in Google Chrome als nicht vertrauenswürdig eingestuft!


Bis zum 13. September 2018

•    SSL/TLS-Zertifikate, die vor dem 01. Dezember 2017 ausgestellt wurden und nach dem 13. September 2018 auslaufen, können ab sofort bis spätestens zum 13. September 2018 durch die neue SubPKI von DigiCert ausgetauscht werden. Ab dem 13. September 2018 werden die SSL/TLS-Zertifikate, die noch über die alte PKI-Infrastruktur von Symantec ausgestellt wurden, in Google Chrome als nicht vertrauenswürdig eingestuft!


Was Sie jetzt tun können?

Wenn Sie ein SSL/TLS-Zertifikat der Symantec-Gruppe im Einsatz haben, müssen Sie Ihre SSL/TLS-Zertifikate spätestens bis zum erwähnten Datum austauschen. Um Verzögerungen zu vermeiden empfehlen wir Ihnen den Austauschprozess nicht sofort zu initiieren sondern diesen auf Januar zu verschieben.


Um den Austausch für Sie so unkompliziert wie möglich zu gestalten haben wir unter

www.psw-group.de/ssl-zertifikate/austausch-psw-group/

eine Austausch-Website erstellt.

Für den Austausch benötigen Sie Ihre Ordernummer (die Order-Nummer entnehmen Sie bitte Ihrer Rechnung oder Auftragsbestätigung) sowie ein neu generiertes CSR.
Wenn Sie ein Apache-Server oder Plesk im Einsatz haben können Sie das bestehende CSR wiederverwenden.

Für weitere Informationen steht Ihnen unser Support-Team unter der Telefonnummer +49 661 480 276 10 gerne zur Verfügung.


Folgende Fehlermeldung kann vereinzelt bei der Nutzung des Chrome Browser jetzt schon auftreten. In diesem Fall tauschen Sie Ihr SSL/TLS-Zertifikat bitte zeitnah um.

The certificate used to load www.domain.de uses an SSL certificate that will be distrusted in an upcoming release of Chrome. Once distrusted, users will be prevented from loading this resource. See g.co/chrome/symantecpkicerts for more information.


Austausch-Termine für alle SSL/TLS-Zertifikate der Symantec-Gruppe

Entzug der Vertrauenswürdigkeit für SSL/TLS-Zertifikate der Symantec-Gruppe ab dem 15. März 2018


Aufgrund der Änderung der Akzeptanzkriterien für die von der Symantec-Gruppe ausgestellten SSL/TLS-Zertifikate durch Google hat Symantec nun einen Austausch-Zeitplan für alle SSL/TLS-Zertifikate veröffentlicht:

Ab dem 01. Dezember 2017 werden alle Symantec-, GeoTrust-, Thawte- und RapidSSL-SSL/TLS-Zertifikate durch die neue PKI-Infrastruktur, die von einer SubCA betrieben wird, validiert und ausgestellt. Da DigiCert die Zertifikatssparte von Symantec erworben hat, wird die neue SubCA von  DigiCert betrieben. Trotz der Übernahme werden die Brands Symantec, Thawte, GeoTrust und RapidSSL weiterhin angeboten. 


Symantec-Zeitplan:
1. Phase:
SSL/TLS-Zertifikate, die vor dem 01.Juni 2016 ausgestellt wurden und vor dem 13. September 2018 auslaufen, können ab sofort bis spätestens zum 15. März 2018 ausgetauscht werden. Ab 15. März 2018 werden SSL/TLS-Zertifikate, die nicht ausgestellt wurden, in Google Chrome als nicht vertrauenswürdig eingestuft.

2. Phase:
SSL/TLS-Zertifikate, die vor dem 01.Juni 2016 ausgestellt wurden und nach dem 13. September 2018 auslaufen, müssen ab 01. Dezember 2017 bis spätestens zum 15. März 2018 durch die neue SubCA ausgetauscht werden. Ab 15. März 2018 werden SSL/TLS-Zertifikate, die noch über die aktuelle PKI-Infrastruktur von Symantec ausgestellt wurden, in Google Chrome als nicht vertrauenswürdig eingestuft.

3. Phase:
SSL/TLS-Zertifikate, die vor dem 01.Dezember 2017 ausgestellt wurden und nach dem 13. September 2018 auslaufen müssen ab dem 01. Dezember 2017 bis spätestens zum 13. September 2018, durch die neue SubCA ausgetauscht werden. Ab dem 13. September 2018 werden die SSL/TLS-Zertifikate, die noch über die aktuelle PKI-Infrastruktur von Symantec ausgestellt wurden, in Google Chrome als nicht vertrauenswürdig eingestuft.

Sollten Sie eine größere Anzahl an SSL/TLS-Zertifikaten austauschen müssen, möchten wir Sie bitten, vor dem Austausch unseren Support zu kontaktieren. Dadurch können wir Ihren Austausch besser koordinieren und längere Wartezeiten vermeiden.
 
Für weitere Informationen steht Ihnen unser Support-Team unter der Telefonnummer +49 661 480 276 10 gern zur Verfügung.

Wichtige Änderungen bei SSL/TLS-Zertifikaten der Symantec-Gruppe

Entzug der Vertrauenswürdigkeit für SSL/TLS-Zertifikate der Symantec-Gruppe ab dem 15. März 2018


Bestimmt haben Sie schon davon gehört, dass Symantec und Google seit Monaten im Gespräch über neue Akzeptanzrichtlinien für die von der Symantec-Gruppe ausgestellten SSL/TLS-Zertifikate sind, um Googles ursprünglichen Vorschlag aus März 2017 zu adressieren, alle von der Symantec-Gruppe ausgestellten SSL/TLS-Zertifikate ab 8. August 2017 als nicht vertrauenswürdig einzustufen.

Daher hat Symantec am 18. Juli 2017 seinen Kunden als proaktive Maßnahme empfohlen, alle vor dem 01. Juni 2016 ausgestellten SSL/TLS-Zertifikate von Symantec, GeoTrust, Thawte und RapidSSL auszutauschen, da diese ab dem 08. August 2017 zu fehlerhaften und nicht vertrauenswürdigen Darstellungen im Google Chrome Browser führen könnten.

Da viele Zertifikatsinhaber nicht über die Kapazitäten verfügen, alle Ihre Zertifikate in dieser kurzen Zeit zu tauschen, hat Google eine Fristverlängerung für den Umtausch eingeräumt.

Am 27. Juli 2017 hat Google einen neuen Zeitplan veröffentlicht, um dessen Vertrauen in SSL/TLS-Zertifikate der Symantec-Gruppe langsam zu verbessern.

Das neue offizielle Datum für die Abstufung von SSL/TLS-Zertifikaten der Symantec-Gruppe ist der 15. März 2018 (Termin für die Veröffentlichung von Chrome 66). Durch die Fristverlängerung von August 2017 auf März 2018 können viele SSL/TLS-Zertifikate, die vor dem 1. Juli 2016 ausgestellt wurden, ganz normal über die neue Symantec-PKI-Infrastruktur verlängert werden. SSL/TLS-Zertifikate, die über die neue Frist hinaus gültig sind, sollten dennoch ausgetauscht werden.

Folgende neue Termine ergeben sich für Symantec:
Bis zum 01. Dezember 2017 muss Symantec eine neue PKI-Infrastruktur, die von einer SubCA verwaltet werden soll, implementieren. Hierdurch erhält jedes Symantec-, GeoTrust-, Thawte- und RapidSSL-SSL/TLS-Zertifikat, das unter dieser neuen Infrastruktur ausgestellt oder verlängert wird, die volle Browser-Akzeptanz in Google Chrome - einschließlich der Akzeptanz der Erweitert Validierten Zertifikate und dessen maximalen Gültigkeitszeiträumen (27 Monate). Dies ist eine positive Entwicklung für viele Kunden, da Googles erster Vorschlag eine Komprimierung der Gültigkeitsräume von EV-SSL/TLS-Zertifikaten auf 9 Monate vorsah.

Ab dem 01. Februar 2018 müssen alle Validierungstätigkeiten ausschließlich durch die neue SubCA ausgeführt werden.

Ab 15. März 2018, Datum der Veröffentlichung von Chrome 66 Beta, wird Google alle vor dem 1. Juli 2016 durch die Symantec-Gruppe ausgestellten SSL/TLS-Zertifikate als nicht vertrauenswürdig einstufen.

Ab 13. September 2018 Chrome Version 70 wird Google alle SSL/TLS-Zertifikate der Symantec-Gruppe, die noch über die aktuelle PKI-Infrastruktur ausgestellt wurden, als nicht vertrauenswürdig einstufen. Für weitere Informationen steht Ihnen unser Support-Team unter der Telefonnummer +49 661 480 276 10 gern zur Verfügung.

Timeline Symantec:





Detaillierte Informationen finden Sie auch unter: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B1-25%5D



Änderung des Domain-Validierungsprozesses

Comodo ändert den Prozess zum 20.07.2017


Durch die Einführung eines standardisierten Domain-Validierungsprozesses seitens des CA/Browser-Forum ändert Comodo zum 20. Juli 2017 den DCV-Prozess für alle SSL/TLS-Zertifikate.


Derzeit bietet Comodo folgende Validierungsmethoden für DCV an:

  • E-Mail - Bestätigungsemail an einen administrativen Kontakt aus dem WHOIS oder eine E-Mail-Adresse aus der Standardliste von fünf Adressen @ der Domain erhalten.
  • HTTP (S) - Textdatei mit bestimmten Inhalten im Root-Verzeichnis ablegen z.B. http (s): //fully.qualified.name/filename.txt.
  • DNS CNAME - CNAME-Eintrag erstellen z.B. randomvalue.fully.qualified.name CNAME randomvalue2.comodoca.com.).

Diese drei Methoden werden auch nach dem 20. Juli noch angeboten, jedoch werden einige der technischen Details wie Speicherort und Inhalt der Textdatei oder die Form des DNS-Eintrages geändert.


E-Mail
Der E-Mail-DCV-Prozess bleibt weitgehend unverändert. Die einzige signifikante Änderung ist, dass Bestätigungsemail nur noch 30 Tage gültig sind.
Es sind keine API-Änderungen erforderlich.



HTTP (S)
Der Dateiname, das Dateiverzeichnis und der Dateispeicherort ändern sich alle.
Der Dateiname bleibt gleich - der MD5-Hashwert des CSRs, wird nun in Großbuchstaben geschrieben.
Der Dateiinhalt ändert sich - SHA1-Hash-Wertes wird durch einen SHA-256-Hash-Wert ersetzt.
Der Dateispeicherort ändert sich - anstatt des Root-Verzeichnisses, nutzen Sie nun folgenden Pfad
Http (s): //fully.qualified.name/.well-known/pki-validation/ <dateiname.txt>
Der Zugriff auf diese Datei erfolgt von der gleichen IP-Adresse und mit dem gleichen User-Agent wie bisher.

DNS CNAME
  • Der Eintrag bleibt ein CNAME-Datensatz.
  • Der Datensatz besteht aus den MD5-Hashwert, der über das CSR gebildet wird. Ein Unterstrich ('_') muss vorangestellt werden.
  • Der Datensatz besteht aus den SHA-256 Hashwert der über das CSR gebildet wird, aufgeteilt in zwei 32-stellige Einträge.

Beispiel für einen neuen DCV-CNAME-Datensatz:
_c7fbc2039e400c8ef74129ec7db1842c.fully.qualified.name CNAME c9c863405fe7675a3988b97664ea6baf.442019e4e52fa335f406f7c5f26cf14f.comodoca.com.


Wiederverwendung von CSRs
Diejenigen Kunden, die für die Verlängerung das gleiche CSR verwenden, haben einige zusätzliche Änderungen zu machen.


Die gleichen DCV-Werte können nicht für mehr als ein Zertifikat verwendet werden. So muss bei einer Verlängerung mit dem exakt gleichen CSR, ein zusätzlicher "eindeutiger Code" hinzugefügt werden.
Dieser Code wird von Ihnen als zufälliger, alphanumerischer Wert von 20 Zeichen oder weniger erzeugt. Es sollte im API-Aufruf zusammen mit dem CSR gesendet und in DNS oder die Textdatei eingegeben werden.

Änderung der CA / B Forum Baseline Requirements

Ab 01.03.2018 keine 3 Jahres SSL-Zertifikate

Nach einem Beschluss des CA-Browserforums erfolgt ab dem 01. März 2018 keine Ausstellung von 3-jährigen SSL-Zertifikate mehr! Ab diesem Zeitpunkt dürfen die Domain- und Organisationsprüfungen nicht länger als 825 Tage (27 Monate) vor der Zertifikatsausgabe erfolgt sein.
20. April 2017 
Seit dem 20. April 2017 bietet GlobalSign (inkl. AlphaSSL) deshalb keine 3-jährigen SSL-Zertifikate an, damit nach dem 01. März 2018 keine SSL-Zertifikate mit einer Laufzeit von 36 bzw. 39 Monaten mehr im Umlauf sind 

31. Mai 2017 
Bis zum 31. Mai 2017 können Sie Ihr 3-jähriges SSL-Zertifikat bestellen, ohne dass Sie Laufzeitverluste im Falle eines Austausches erleiden 



01. Januar 2018 
Ab dem 01. Januar 2018 bietet SwissSign keine SSL-Zertifikate mit einer Laufzeit von 3 Jahren mehr an 


28. Februar 2018 
Bis 28. Februar 2018 können Sie SSL-Zertifikate mit einer Laufzeit von 39 Monaten bestellen (außer bei GlobalSign und SwissSign). Sollten Sie aber einen Austausch durchführen müssen, erhalten Sie die nachfolgend aufgeführten Restlaufzeiten (eine Erstattung ist nicht vorgesehen): 
  • Austausch im Mai 2017 max. 37 Monate Restlaufzeit
  • Austausch im Juni 2017 max. 36 Monate Restlaufzeit
  • Austausch im Juli 2017 max. 35 Monate Restlaufzeit
  • Austausch im August 2017 max. 34 Monate Restlaufzeit 
  • Austausch im September 2017 max. 33 Monate Restlaufzeit 
  • Austausch im Oktober 2017 max. 32 Monate Restlaufzeit 
  • Austausch im November 2017 max. 31 Monate Restlaufzeit 
  • Austausch im Dezember 2017 max. 30 Monate Restlaufzeit 
  • Austausch im Januar 2018 max. 29 Monate Restlaufzeit 
  • Austausch im Februar 2018 max. 28 Monate Restlaufzeit
  • Austausch im März 2018     max. 27 Monate Restlaufzeit
 

01. März 2018
Ab dem 01. März 2018 werden nur noch SSL-Zertifikat mit einer maximalen Laufzeit von 27 Monaten ausgestellt.


GlobalSign stellt keine 3-Jahres-SSL-Zertifikate mehr aus

Ab dem 20. April werden keine 3-Jahres-SSL-Zertifikate mehr ausgestellt

Das CA/B-Forum hat die Mindestanforderungen an die Ausstellung von SSL-Zertifikaten angepasst. Zum 1. März 2018 wird die maximale Gültigkeitsdauer von allen SSL-Zertifikaten auf 825 Tage (27 Monate) beschränkt.

Durch die Änderung der kürzlich veröffentlichten Anforderungen aus dem CA / B-Forum hat auch GlobalSign seine SSL-Zertifikatspolitik aktualisiert, um 2 wichtige Anforderungen zu erfüllen.

1. Zum 1. März 2018 wird die maximale Gültigkeitsdauer von allen SSL-Zertifikaten auf 825 Tage (27 Monate) beschränkt.

Daher wird GlobalSign schon ab dem 20. April 2017 keine 3-Jahres-Zertifikate mehr ausstellen um nach dem 1. März 2018 keine validen 3-Jahres-Zertifikate im Umlauf zu haben. GlobalSign hat das Datum zur Abkündigung von 3-Jahres-Zertifikaten etwas früher bestimmt, um abgeschnittene Zertifikat-Gültigkeitszeiträume zu vermeiden.

2. Die Domain- und Organisationsprüfung darf nicht länger als 825 Tage (27 Monate) vor der Neuausgabe des Zertifikats erfolgt sein. (zuvor betrug dieser Zeitraum 39 Monate).


Bitte beachten Sie
: Es gibt keine Auswirkung auf Neubestellungen. Die Änderungen ergeben sich, wenn SSL-Zertifikate ausgetauscht oder neue SANs hinzugefügt oder gelöscht werden, da die Domain- und Organisationsinformationen nicht älter als 27 Monate sein dürfen.

Folgende Änderungen ergeben sich für Zertifikatsaustausche:

Abkündigung von 3-Jahres domainvalidierten SSL-Zertifikaten
GlobalSign stellt keine Domainvalidierte 3-Jahres-SSL-Zertifikate mehr aus (einschließlich DomainSSL und AlphaSSL), um folgende mögliche Szenarien zu vermeiden:

Szenario 1:
Ein Kunde tauscht nach dem 01. März 2018 sein SSL-Zertifikat mit einer verbleibenden Gültigkeitsdauer von mehr als 27 Monaten aus.
Ergebnis:

Das SSL-Zertifikat muss auf 27 Monate gekürzt werden, da dies die maximal zulässige Gültigkeitsdauer ist. Um den Verlust des Gültigkeitszeitraums für den Kunden zu vermeiden, stellt GlobalSign schon ab dem 20. April 2017 keine 3-Jahres-SSL-Zertifikate mehr aus.

Szenario 2:
Nach dem 20. April 2017 versucht ein Kunde nach 27 Monaten ein 3-Jahres-Zertifikat auszutauschen:
Ergebnis:
Da die Domainprüfung innerhalb der letzten 27 Monate durchgeführt worden sein muss, wird der Versuch ein Domainvalidiertes-SSL-Zertifikat auszutauschen abgelehnt.

Dies bedeutet, dass jegliche Versuche nach dem 20. April 2017 ein 3-Jahres-Domainvalidiertes SSL-Zertifikate auszutauschen abgelehnt werden müssen, da die Domainprüfung vor mehr als 27 Monaten durchgeführt wurde.


Abkündigung von 3-Jahres organisationsvalidierten SSL-Zertifikate
GlobalSign wird organisationsvalidierte 3-Jahres-SSL-Zertifikate ablehnen, um das folgende Szenario zu vermeiden:

Szenario 1:

Ein Kunde tauscht nach dem 01. März 2018 sein Zertifikat mit einer verbleibenden Gültigkeitsdauer von mehr als 27 Monaten aus.

Ergebnis:
Das Zertifikat muss auf 27 Monate gekürzt werden, da dies die maximal zulässige Gültigkeitsdauer ist. Um den Verlust des Gültigkeitszeitraums für den Kunden zu vermeiden, stellt GlobalSign ab dem 20. April 2017 keine 3-Jahres-SSL-Zertifikate mehr aus, um dieses Thema im Jahr 2018 zu vermeiden.

Keine Austausche für organisationsvalidierte SSL-Zertifikate
Um die Anforderungen des CA / B-Forum einhalten zu können, deaktiviert GlobalSign vorübergehend die Möglichkeit organisationsvalidierte SSL-Zertifikate auszutauschen.
Wir hoffen, in den nächsten Monaten hierfür eine Lösung von GlobalSign zu erhalten.
Bei Fragen wenden Sie sich bitte an unseren Support.


Wichtige Änderungen bei der Domainvalidierung

Die Symantec-Gruppe ändert ihre Validierungsrichtlinien zum 15. März 2017

Das CA-Browser-Forum führt einen standardisierten Domain-Validierungsprozess ein. Aus diesem Grund ändern Symantec, Thawte und GeoTrust zum 15. März 2017 ihre Validierungsrichtlinien für alle SSL/TLS-Zertifikate.

Nachfolgend haben wir Ihnen die wichtigsten Änderungen, die für alle DV-SSL Zertifikate und Encryption Everywhere Zertifikate gelten zusammengestellt:

Datei-basierte Authentifizierung – Bei dieser Option laden Sie eine Datei, die Ihnen von der CA vorgegeben wird, in ein bestimmtes Verzeichnis auf Ihrem Server hoch, um den Zugriff auf die Domäne zu bestätigen.
  • Dateiformat ändert sich von .HTML auf .TXT
  • Der generierte String umfasst statt 32 jetzt 64 Zeichen
  • Der URL-Pfad ändert sich von http oder https <root.tld>/<random Dateiname>.html in http oder https <root.tld>/.well-known/pki-validation/fileauth.txt
  • Der Zeitstempel „File Auth Time Stamp“ ändert sich von “Time of order submission +/- 24 hours” in “Order date minus 7 days”
  • Der „Shared Key“ Erstellungsprozess ändert sich von “HMAC with SHA1” in “HMAC with SHA2”
  • Order, Reissue and Revoke APIs ändern sich von code “returned in response” in “removed from response”

DNS-basierte Authentifizierung – Bei dieser Option erstellen Sie einen DNS-Eintrag. Dieser wird Ihnen von der CA vorgegeben, um den Zugriff auf die Domäne zu bestätigen.
  • Dateityp ändert sich von CNAME in TXT
  • Der generierte String umfasst jetzt 64 statt 32 Zeichen
  • DNS-Eintrag ändert sich von "<random string>.domain.com" in "random string in TXT-Datei"

WHOIS-basierte Authentifizierung
- Bei dieser Option erhalten Sie von der CA eine Bestätigungs-E-Mail, an die im WHOIS hinterlegte E-Mail-Adresse.
  • Der generierte String umfasst jetzt 24 Zeichen
  • Der Link in der Bestätigungs-E-Mail ist nur 30 Tage valid

Alle Kunden, die anstehende DV-Bestellungen haben und versuchen noch nach 30 Tagen auf den Link zu klicken, erhalten folgende Fehlermeldung:
Abgelaufene PIN
"Leider ist die übermittelte PIN abgelaufen. Bitte versenden Sie die E-Mail erneut zu, um den neuen Link zu erhalten. Wir entschuldigen uns für eventuelle Unannehmlichkeiten. Bitte wenden Sie sich an den GeoTrust Support."
Um den Fehler zu beheben, können Kunden sich durch den PSW GROUP-Support die Bestätigungs-E-Mail erneut zusenden lassen.


Folgende Änderungen ergeben sich für alle OV und EV-Zertifikate:
  • Symantec akzeptiert keine Professional Opinion Letters (POL) mehr um die Domaininhaberschaft zu bestätigen
  • Die Bestätigung der Domaininhaberschaft wird von DV-Zertifikaten adaptiert

Änderungen bezüglich der telefonischen Validierung:

Für die telefonische Validierung des Zertifikatsinhabers ist ein Eintrag in einem der folgenden öffentlichen Telefonregister unabdingbar:

Deutschland
  • www.upik.de           
  • www.firmenwissen.de        
  • www.dasoertliche.de        
  • www.telefonbuch.de       
  • www.gelbe-seiten.de       
  • de.kompass.com       
  • www.teleauskunft.de       
  • www.1818.com       
  • www.11880.com       
  • home.meinestadt.de       

Österreich
  • www.upik.de           
  • www.firmenwissen.de       
  • www.firmenwissen.de       
  • auskunft.at           
  • www.herold.at           
  • www.telefonabc.at       

Schweiz
  • www.upik.de           
  • www.firmenwissen.de       
  • ch.kompass.com       
  • tel.search.ch           
  • yellow.local.ch           
  • www.1818.com       
 
Organisationen mit Sitz außerhalb des deutschsprachigen Raums benötigen einen Eintrag bei Dun & Bradstreet (D&B) bzw. dem lokalen Äquivalent. Weitere Änderungen entnehmen Sie bitte den jeweiligen Validierungsguidelines in unseren Produbeschreibungen.

Weitere Informationen zu den Änderungen von Symantec finden Sie hier.

Für weitere Informationen steht Ihnen unser Support-Team unter der Telefonnummer +49 661 480 276 10 gern zur Verfügung.

Wichtige Änderungen bei Code-Signing-Zertifikaten

Neue Branchenanforderungen ab 1. Februar 2017


Wir möchten Sie über neue Branchenanforderungen informieren, die am 8. Dezember 2016 vom Certificate Authority Security Council (CASC) für Code-Signing-Zertifikate verabschiedet wurden und am 1. Februar 2017 in Kraft traten.

Die neuen Richtlinien gelten für alle Zertifizierungsstellen und sorgen für höhere Sicherheit in der Praxis und minimieren das Risiko von Angriffen auf Code-Signing-Zertifikate. Jede Zertifizierungsstelle muss die Mindestanforderungen erfüllen, kann aber darüberhinaus eigene Verfahrensweisen definieren.

Alle ab dem 01. Februar ausgestellten Code-Signing-Zertifikate müssen auf einem externen Gerät gespeichert werden. Zu keinem Zeitpunkt sollte der Private Schlüssel in einen Web-Browser gesichert werden.
Zur Zeit verkauft nur GlobalSign Code-Signing-Zertifikate, die bereits auf einem SafeNet Token gespeichert sind, so dass Sie sich nicht mehr um den Erwerb der entsprechenden Hardware kümmern müssen.  Nachfolgend stellen wir Ihnen die Verfahrensweisen vor, die Symantec eingeführt hat um das Risiko der Falschausgabe zu reduzieren:

 

  • Strengere und standardisierte Identitätsprüfung, um den Antragsteller zu authentifizieren
  • Prüfung aller Code-Signing-Aufträge auf Listen von verdächtigen oder bekannten Herausgebern von Malware
  • Prüfung aller Code-Signing-Aufträge, die zuvor von Symantec widerrufen wurden, in denen die Zertifikate verwendet wurden, um verdächtigen Code zu unterzeichnen.


Zudem hat Symantec ein "Certificate Problem Reporting" -System sowohl für Symantec- als auch Thawte Code-Signing-Zertifikate eingeführt, die es Dritten z.B. Softwareanbietern ermöglicht, Probleme in Bezug auf komprimierte Schlüssel, Missbrauch von Zertifikaten und möglichen Betrug zu melden. Nach der neuen Richtlinien wird Symantec, sobald eine Meldung eingeht, das betreffende Code-Signing-Zertifikat innerhalb von achtundvierzig Stunden widerrufen oder den Antragsteller darauf aufmerksam machen, dass eine Untersuchung eingeleitet wurde.

 

Angesichts der potenziellen Schwachstelle, die im Hinblick auf die ungesicherte Speicherung privater Schlüssel entsteht, wird ein strengeres Schlüssel-Management empfohlen.

Nachfolgend stellen wir Ihnen die Empfehlung von Symantec vor, wie der private Schlüssel zu speichern ist:

  1. Ein „Trusted Platform Module“ (TPM): generiert und sichert ein Schlüsselpaar und hat die Möglichkeit die Sicherheit des Privaten Schlüsseln von den Teilnehmer durch eine TPM-Schlüssel Bescheinigung zu dokumentieren.
  2. Ein Hardware-Krypto-Modul: zertifiziert als konform zu FIPS 140 Level 2, Common Criteria EAL 4+, oder gleichwertig. 


Wenn keine der beiden obigen Optionen möglich sind, kann alternativ eine Art von Hardware-Speicher-Token mit der Größe einer SD-Karte oder USB-Token (nicht unbedingt zertifiziert als konform zu FIPS 140 Level 2 or Common Criteria EAL 4+) gewählt werden. Im diesen Fall sollten Sie unbedingt sicherstellen, dass der Token getrennt von dem Gerät aufbewahrt wird, mit dem Sie die Code-Signierung durchführen.



 


Widerruf von SSL-Zertifikaten ab 01.10.2016

Verfahrensweise für SSL-Zertifikate mit internen Domain-Namen und reservierten IP-Adressen

Im Juli 2012 hat das CA / Browser Forum die Entscheidung getroffen, dass SSL-Zertifikate mit reservierten IP-Adressen und internen Namen ab 1. November 2015 nicht mehr ausgestellt werden dürfen. Alle noch aktiven Zertifikate müssen daher bis zum 31. Oktober 2016 widerrufen werden.


Comodo kündigt an:

Ab 1. Oktober 2016 werden durch Comodo alle noch nicht abgelaufenen SSL-TLS-Zertifikate widerrufen, die als Subject Alternative Name (SAN) oder Common Name eine reservierte IP-Adresse oder einen internen Servername enthalten.

Wenn Sie immer noch interne Namen verwenden, empfehlen wir Ihnen dringend den Server für die Verwendung von öffentlichen Domainnamen zu konfigurieren.
Bei weiteren Fragen erreichen Sie uns telefonisch unter 0661 480 276 10 oder per E-Mail unter support[at]psw.net.
NACH OBEN
Zertifizierer