x
    SUPPORT

HOT UPDATE

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