Filtern nach: compliance x Löschen
compliance

Browser support ending for TLS 1.0 and 1.1

In 2020, the four major browsers are ending support for Transport Layer Security (TLS) 1.0 and 1.1.

This change doesn't affect your DigiCert certificates. Your certificates will continue to work as they always have.

What you need to know

This change affects browser-dependent services and applications relying on TLS 1.0 or 1.1. Once browser support for TLS 1.0 or 1.1 ends, these out-of-date systems will be unable to make HTTPS connections.

What you need to do

If you are affected by this change, plan to enable or upgrade to TLS 1.2 or TLS 1.3 now. Give yourself lead time to deal with any problems. Before you start, make sure to identify all systems that might use TLS 1.0 or 1.1.

Remember to check web servers like Apache or Microsoft IIS, .NET Framework, server monitoring agents, and other commerce applications that might use it.

Helpful resources

With so many different types of systems relying on TLS, we can't cover all available upgrade paths, but here are a few references that may help:

compliance

Die neuen Compliance-Anforderungen für Private SSL-Zertifikate von Apple

Apple kündigte kürzlich einige neue Sicherheitsanforderungen für SSL/TLS-Zertifikate an, die mit der Veröffentlichung von iOS 13 und macOS 10.15 in Kraft treten werden. Diese Anforderungen betreffen öffentliche und private Zertifikate, die nach dem 1. Juli 2019 ausgestellt wurden.

Für Ihre öffentlichen DigiCert-SSL-/TLS-Zertifikate ist keine Aktion erforderlich.

Die öffentlichen DigiCert-SSL-/TLS-Zertifikate erfüllen bereits alle diese Sicherheitsanforderungen. Ihre öffentlichen SSL-/TLS-Zertifikate sind nicht davon betroffen bleiben auch in iOS 13 und macOS 10.15 vertrauenswürdig.

Was ist neu?

Apple implementiert zusätzliche Sicherheitsanforderungen für alle SSL-/TLS-Zertifikate, die sich gemäß Design auf private SSL-/TLS-Zertifikate auswirken. Siehe Anforderungen an vertrauenswürdige Zertifikate in iOS 13 und macOS 10.15. Private DigiCert-SSL/TLS-Zertifikate erfüllen diese Anforderungen, wenn sie von Kontoadministratoren gemäß den öffentlichen Zertifikatsanforderungen ausgestellt wurden.

Wir haben unten eine Liste der Anforderungen die Auswirkungen auf Ihre privaten SSL-/TLS-Zertifikate haben können. Glücklicherweise ist die Freigabe dieser Versionen von Apple OS für den Herbst dieses Jahres geplant. So haben Sie Zeit, sich vorzubereiten.

  • Muss einen Algorithmus aus der SHA-2-Familie im Signatur-Algorithmus verwenden. SHA-1-signierte Zertifikate sind nicht mehr vertrauenswürdig für SSL/TLS.
  • Muss eine Laufzeit von maximal 825 Tagen haben. SSL/TLS-Zertifikate mit einer Laufzeit von mehr als 825 Tagen nicht mehr vertrauenswürdig.

Falls Sie private Zertifikate besitzen, die diese Anforderungen nicht erfüllen und für Apple iOS und macOS vertrauenswürdig sein müssen, müssen Sie sicherstellen, dass alle privaten SSL/TLS-Zertifikate, die nach dem 1. Juli 2019 ausgestellt wurden, entweder ursprünglich oder neu ausgestellt wurden vor der allgemeinen Verfügbarkeit von iOS 13 und macOS 10.15. Siehe Neuausstellung eines SSL/TLS-Zertifikats.

compliance

Firefox ending key generation support

With the release of Firefox 69, Firefox will finally drop support for Keygen. Firefox uses Keygen to facilitate generating key material for submitting the public key when generating Code Signing, Client, and SMIME certificates in their browser.

Note: Chrome already dropped support for key generation, and Edge and Opera never supported it.

How does this affect you?

After DigiCert issues your Code Signing, Client, or SMIME certificates, we send you an email with a link to create and install your certificate.

Once Firefox 69 is released, you can only use two browsers to generate these certificates: Internet Explorer and Safari. If company policy requires the use of Firefox, you can use Firefox ESR or a portable copy of Firefox.

For more information, see Keygen support to be dropped with Firefox 69.

Tips and tricks

  • You can still use Firefox 69 for client authentication. First, generate the SMIME certificate in IE 11 or Safari. Then, import the SMIME certificate to Firefox.
  • To bypass generating Code Signing, Client, or SMIME certificates in your browser, generate and submit a CSR with your order. Instead of a link, DigiCert will send you an email with your certificate attached.
new

We added a new status, Emailed to Recipient, to the Orders and Order Details pages, for Code Signing and Client certificate orders, making it easier to identify where these orders are in the issuance process.

This new status indicates the DigiCert has validated the order, and the certificate is waiting for the user/email recipient to generate it in one of the supported browsers: IE 11, Safari, Firefox 68, and portable Firefox.

(In the sidebar menu, click Certificates > Orders. Then, on the Orders page, click the order number for the Code Signing or Client certificate order.)

enhancement

We updated our Extended Validation (EV) Code Signing (CS) and Document Signing (DS) certificate reissue processes, enabling you to reissue these certificates without automatically revoking the current certificate (original or previously reissued certificate).

Note: If you don't need the current certificate (original or previously reissued certificate), you'll need to contact support so they can revoke it for you.

Now, the next time you reissue an EV CS or DS certificate, you can keep the previously issued certificate active to its current validity period (or for as long as you need it).

compliance

Industry standards compliance reminder

For public and private certificates, Certificate Authorities (CAs) don't accept abbreviations for these parts of an address in your certificate orders or organization pre-validation requests:

  • State or Province*
  • City or Locality*

*This applies to organization and jurisdiction addresses.

new

We made it easier to define the domain validation scope for your account when submitting your domains for validation (pre-validation or via certificate orders).

On the Division Preferences page, we added two domain validation scope options:

  • Submit exact domain names for validation
    With this option, requests for new domains are submitted for validation exactly as named (i.e., request for sub.example.com is submitted for validation exactly as sub.example.com). Validation for the “higher level” domain (e.g., example.com) also works. This is the default behavior for CertCentral.
  • Restrict validation to base domain only
    This option allows you to restrict domain validation to the base domain (e.g., example.com). For request that include new subdomains (e.g., sub.example.com), we only accept domain validation for the base domain (e.g., example.com). Validation for the subdomain (e.g., sub.example.com) won’t work.

To configure the domain validation scope for your account, in the sidebar menu, click Settings > Preferences. On the Division Preference page, expand Advanced Settings. In the Domain Control Validation (DCV) section, under Domain Validation Scope, you'll see the new settings.

fix

We fixed a bug where we were limiting the maximum allowed number of SANS to 10 on Wildcard SSL certificate reissue and new certificate orders.

Now, when reissuing or ordering a new Wildcard SSL certificate, you can add up to 250 SANs.

compliance

Änderung der Branchenstandards

Ab dem 31. Juli 2019 (19:30 Uhr UTC) müssen Sie die DCV-Methode HTTP-Praxisbeispiel zum Nachweis der Kontrolle über IP-Adressen auf Ihren Zertifikatsaufträgen verwenden.

Weitere Informationen zur DCV-Methode HTTP-Praxisbeispiel:

Bisher pflegten Branchenstandards andere DCV-Methoden zum Nachweis der Kontrolle über Ihre IP-Adresse zuzulassen. Mit der Abstimmung SC7 wurden jedoch die Vorschriften für die Validierung der IP-Adresse geändert.

Abstimmung SC7: Validierungsmethoden zur Aktualisierung der IP-Adresse

Dieser Abstimmung definiert die zulässigen Prozesse und Verfahren für die Validierung der Kundenkontrolle über eine in einem Zertifikat gelistete IP-Adresse neu. Die Compliance-Änderungen gemäß Abstimmung SC7 treten am 31 Juli 2019 (19:30 Uhr UTC) in Kraft.

Um nach dem 31. Juli 31 2019 (19:30 Uhr UTC) mit den Vorschriften konform zu bleiben, gestattet DigiCert seinen Kunden nur noch die DCV-Methode HTTP-Praxisbeispiel zum Validieren ihrer IP-Adressen.

Beenden des Supports für IPv6

Seit dem 31. Juli 2019 (19:30 UTC) hat DigiCert den Support von Zertifikaten für IPv6-Adressen eingestellt. Aufgrund von Serverbeschränkungen ist DigiCert nicht in der Lage, eine IPv6-Adresse zu erreichen, um die Datei zu prüfen, die auf der Website de Kunden für die DCV-Methode HTTP-Praxisbeispiel liegt.

enhancement

Wir haben die CertCentral-SAML-Verbundeinstellungen aktualisiert, sodass Sie die Möglichkeit haben, die Anzeige Ihres Verbundnamens in der Liste der IdPs auf den Seiten IdP-Auswahl für SAML-SSO und IdP-Auswahl für SAML-Zertifikatsanträge zu unterdrücken.

Auf der Seite der Verbundeinstellungen unter Ihren IDP-Metadaten haben wir nun die Option Verbundnamen einbeziehen hinzugefügt. Falls Sie Ihren Verbundnamen aus der Liste der IdPs auf der Seite IdP-Auswahl entfernen möchten, deaktivieren Sie einfach die Option Fügen Sie meinen Verbundnamen zur Liste der IdPs hinzu.

new

Secure Site Pro TLS/SSL-Zertifikate sind in CertCentral verfügbar. Bei Secure Site Pro zahlen Sie pro Domäne; keine Zertifikatsbasiskosten. Fügen Sie eine Domäne hinzu, zahlen Sie für eine. Benötigen Sie neun Domänen, Zahlen Sie für neun. Schützen Sie bis zu 250 Domänen mit einem Zertifikat.

Wir bieten zwei Arten Secure Site Pro-Zertifikate an, eine für OV-Zertifikate und eine für EV-Zertifikate.

  • Secure Site Pro SSL
    Das OV-Zertifikat, das zu Ihren Anforderungen passt. Bietet Verschlüsselung und Authentifizierung für eine Domäne, einen Wildcard-Domäne und alle zugehörigen Unterdomänen, oder Sie verwenden SANs (Subject Alternative Names), um mehrere Domänen und Wildcard-Domänen mit nur einem Zertifikat zu schützen.
  • Secure Site Pro EV SSL
    Das EV-Zertifikat, das zu Ihren Anforderungen passt. Bietet Verschlüsselung und Authentifizierung zum Schutz einer Domäne oder Sie verwenden SANs (Subject Alternative Names), um mehrere Websites (vollqualifizierte Domänennamen) mit einem Zertifikat zu schützen.

Vorteile jedes Secure Site Pro-Zertifikats

Jedes Secure Site Pro-Zertifikat umfasst – ohne Extrakosten – sofortigen Zugriff auf zukünftige Premium Feature-Ergänzungen für CertCentral (z. B. die CT-Protokollüberwachung und Validierungsmanagement).

Weitere Vorteile sind:

  • Validierung mit Priorität
  • Support mit Priorität
  • Zwei Premium-Standortsiegel
  • Malware-Prüfung
  • Branchenführende Garantien

Um Secure Site Pro-Zertifikate für Ihr CertCentral-Konto zu aktivieren, wenden Sie sich an Ihren Kundenbetreuer oder unser Supportteam.

Weitere Informationen über unsere Secure Site Pro-Zertifikate: DigiCert Secure Site Pro.

compliance

Öffentliche SSL-Zertifikate können Domänennamen mit Unterstrichen ("_") nicht mehr schützen. Alle bereits ausgestellten Zertifikate mit Unterstrichen in Domänennamen müssen vor diesem Datum ablaufen.

Hinweis: Die bevorzugte Lösung für Unterstriche ist die Umbenennung der Hosts (FQDNs), welche Unterstriche enthalten, und das Ersetzen der Zertifikate. In Fällen jedoch, in denen das Umbenennen nicht möglich ist, können Sie private Zertifikate und in einigen Fällen ein Wildcard-Zertifikat benutzen, um die gesamte Domäne zu schützen.

Weitere Details: Beseitigen von Unterstrichen in Domänennamen.

compliance

Anforderungen der Branchenstandards an die Aufnahme der Erweiterung CanSignHttpExchanges in ein ECC-SSL/TLS-Zertifikat:

  • CAA-Ressourceneintrag für die Domäne, die den "cansignhttpexchanges=yes"-Parameter einbezieht*
  • ECC-Schlüsselpaar (Elliptic Curve Cryptography)
  • CanSignHttpExchanges-Erweiterung
  • Maximale Laufzeit 90 Tage*
  • Nur für Signed HTTP Exchange

* Hinweis: Diese Anforderungen gilt ab 1. Mai 2019. Die Erweiterung Signed HTTP Exchange befindet sich in Entwicklung. Im Rahmen der weiteren Entwicklung können sich die Anforderungen noch ändern.

Die Anforderung einer Maximallaufzeit von 90 Tagen für das Zertifikat hat keinen Einfluss auf vor dem 1. Mai 2019 ausgestellte Zertifikate. Bei Zertifikaten, die erneut ausgestellt werden, wird die Laufzeit auf 90 Tage ab dem Zeitpunkt der Neuausstellung gekürzt. Sie können das Zertifikat jedoch weiterhin für die volle bezahlte Laufzeit neuausstellen.

CanSignHttpExchanges-Erweiterung

Vor kurzem fügten wir eine neues Zertifikatsprofil HTTP Signed Exchanges hinzu, um dem AMP-URL-Anzeigeproblem zu begegnen, durch das Ihre Marke nicht in der Adresszeile angezeigt wird. Bessere AMP-URLs mit Signed HTTP Exchange

Dieses neue Profil ermöglicht Ihnen, die CanSignHttpExchanges-Erweiterung in OV- und EV-SSL/TLS-Zertifikate einzubeziehen. Sobald es für Ihr Konto aktiviert ist, wird die Option Einbeziehen der CanSignHttpExchanges-Erweiterung in das Zertifikat auf Ihren OV- und EV-SSL/TLS-Antragsformularen unter Zusätzliche Zertifikatsoptionen angezeigt. Siehe So erhalten Sie Ihr Signed HTTP Exchange-Zertifikat.

Um dieses Zertifikatsprofil für Ihr Konto zu aktivieren, wenden Sie sich an Ihren Kundenbetreuer oder unser Supportteam.

compliance

Zertifizierungsstellen (CAs) stellen keine öffentlichen 30-Tage-SSL-Zertifikate mit Unterstrichen in Domänennamen (allgemeinen Namen und SANs) mehr aus.

Hinweis: Die bevorzugte Lösung für Unterstriche ist die Umbenennung der Hosts (FQDNs), welche Unterstriche enthalten, und das Ersetzen der Zertifikate. In Fällen jedoch, in denen das Umbenennen nicht möglich ist, können Sie private Zertifikate und in einigen Fällen ein Wildcard-Zertifikat benutzen, um die gesamte Domäne zu schützen.

Weitere Details: Beseitigen von Unterstrichen in Domänennamen.

compliance

Letzter Tag für die Bestellung 30-tägiger öffentlicher SSL-Zertifikate mit Unterstrichen in Domänennamen (allgemeine Namen und SANs) bei einer beliebigen CA.

Hinweis: Die bevorzugte Lösung für Unterstriche ist die Umbenennung der Hosts (FQDNs), welche Unterstriche enthalten, und das Ersetzen der Zertifikate. In Fällen jedoch, in denen das Umbenennen nicht möglich ist, können Sie private Zertifikate und in einigen Fällen ein Wildcard-Zertifikat benutzen, um die gesamte Domäne zu schützen.

Weitere Details: Beseitigen von Unterstrichen in Domänennamen.

compliance

Sie brauchen nichts zu tun.

Ab 13. Februar 2019 stellt DigiCert keine ECC TLS/SSL-Zertifikate (d. h. Zertifikate mit ECDSA-Schlüsseln) mit dem Curve-Hash-Paar P-384 mit SHA-2 512 (SHA-512) mehr aus. Dieses Curve-Hash-Paar ist mit der Stammspeicherrichtlinie von Mozilla nicht kompatibel.

Stammspeicherrichtlinie von Mozilla unterstützt nur diese Curve-Hash-Paare:

  • P‐256 mit SHA-256
  • P‐384 mit SHA-384

Hinweis: Sie haben ein Zertifikat mit einem P-384 mit SHA-512 Curve-Hash-Paar? Keine Sorge! Sobald das Zertifikat verlängert wird, wird es automatisch mithilfe eines unterstützten Curve-Hash-Paars ausgestellt.

compliance

Die Zertifizierungsstellen (Certificate Authorities, CAs) widerriefen bis zum Tagesende (UTC) alle öffentlichen SSL-Zertifikate mit Unterstrichen (im allgemeinen Namen und in den SANs) mit einer Höchstlaufzeit von mehr als 30 Tagen.

Falls Sie ein SSL-Zertifikat mit Gesamtlaufzeit von mehr als 30 Tagen hatten (schließt alle 1-Jahres-, 2-Jahres- und 3-Jahres-Zertifikate ein), das nach dem 14. Januar 2019 abgelaufen ist, musste die ausstellende Zertifizierungsstelle Ihr Zertifikat widerrufen.

Weitere Details: Beseitigen von Unterstrichen in Domänennamen.

compliance

DigiCert begann für begrenzte Zeit, öffentliche SSL-Zertifikate mit Unterstrichen auszustellen.

  • Die maximale Laufzeit für öffentliche SSL-Zertifikate mit Unterstrichen in Domänennamen betrug 30 Tage.
  • Unterstriche in Basisdomänen sind unzulässig ("example_domain.com" ist nicht erlaubt).
  • Unterstriche sind im äußersten linken Domänen-Label unzulässig ("_example.domain.com" und "example_domain.example.com" sind nicht erlaubt).

Weitere Details: Beseitigen von Unterstrichen in Domänennamen.

new

Im obersten Menü haben wir zwei neue Kontakt-Support-Optionen (Symbole für Telefon und Chat) hinzugefügt, um es innerhalb von CertCentral zu vereinfachen, sich an den Support zu wenden (per E-Mail, Chat oder Telefon).

Das Telefonsymbol bietet Ihnen E-Mail- und Telefonoptionen. Das Chat-Symbol bietet Ihnen ein Chat-Fenster, um mit einem unserer speziell geschulten Supportmitarbeiter zu chatten.

enhancement

Wir verbesserten das Menü der Seitenleiste, sodass Sie leichter die Menüoptionen für die Seiten sehen können, die Sie besuchen. Wenn sie jetzt auf eine Seite in CertCentral gehen, sehen Sie neben der Option für diese Seite einen horizontalen blauen Balken.

fix

Wir beseitigten einen Fehler der Funktion Organisation hinzufügen auf SSL/TLS-Zertifikatsantragsformularen, durch den der Validierungsstatus (EV- und OV-validiert) für neue Organisationen, die im Rahmen des Zertifikatsauftrags hinzugefügt und validiert wurden, nicht angezeigt wurde.

Das haben wir nun geändert.

Hinweis: Der Validierungsstatus einer Organisation wird erst angezeigt, wenn wir die Organisation vollständig validiert haben.

compliance

Änderung der Branchenstandards-Compliance Bei öffentlich vertrauenswürdigen Zertifikaten dürfen Unterstriche ( _ ) nicht mehr in Unterdomänen verwendet werden. RFC 5280 wird nun auch für Unterdomänen durchgesetzt.

Siehe Öffentlich vertrauenswürdige Zertifikate – Dateneinträge, die gegen Branchenstandards verstoßen.

August 1, 2018

compliance

Die Branchenstandards wurden geändert und zwei DCV-Methoden wurden aus den Mindestanforderungen (Baseline Requirements, BRs) entfernt.

Ab dem 1. August 2018 dürfen Zertifizierungsstellen die folgenden DCV-Methoden nicht mehr verwenden:

  • 3.2.2.4.1 Validierung des Antragsteller als Domänenkontakt
    Bei dieser Methode konnte eine CA die Kontrolle des Zertifikatsantragstellers über eine Domäne auf einem SSL/TLS-Auftrag validieren, indem sie bestätigte, dass der Antragsteller der Domänenkontakt direkt mit der Domänennamen-Registrierungsstelle ist.
  • 3.2.2.4.5 Domänenautorisierungsdokument
    Bei dieser Methode konnte eine CA die Kontrolle des Zertifikatsantragstellers über eine Domäne auf einem SSL/TLS-Auftrag validieren anhand der Bestätigung der Berechtigung des Antragstellers, ein Zertifikat für die betreffende Domäne zu bestellen, wie in einem Domänenautorisierungsdokument festgehalten.
    Siehe Abstimmung 218: Entfernen der Validierungsmethoden 1 und 5

Weitere Informationen über die verfügbaren DCV-Methoden finden Sie unter DCV-Methoden (Domain Control Validation).

Mai 25, 2018

compliance

DigiCert-Compliance mit der DSGVO

Die Datenschutz-Grundverordnung (DSGVO) ist ein Gesetz der Europäischen Union zum Schutz von Daten und Privatsphäre für alle Personen innerhalb der EU. Das primäre Ziel ist es, den Bürgern und Bewohnern der EU mehr Kontrolle über Ihre personenbezogenen Daten zu geben und durch die Vereinheitlichung der Vorschriften innerhalb der EU das regulatorische Umfeld für internationale Geschäfte zu vereinfachen. Die DSGVO trat am 25. Mai 2018 in Kraft. Weitere Details »

Die DigiCert-Erklärung

DigiCert versteht und befolgt die Anforderungen der DSGVO. Wir waren bereits in Übereinstimmung mit der DSGVO, als sie am 25. Mai 2018 in Kraft trat. Siehe Einhaltung der Datenschutz-Grundverordnung (DSGVO).

compliance

Auswirkungen der DSGVO auf WHOIS-basierte E-Mail-DCV (Domain Control Validation)

Die Datenschutz-Grundverordnung (DSGVO) der Europäischen Union trat am 25. Mai 2018 in Kraft. Die DSGVO verlangt Datenschutz für natürliche Personen (nicht juristische Personen), die ihren Wohnsitz innerhalb der Europäischen Union (EU) haben.

DigiCert arbeitete mit ICANN, um die WHOIS-Daten verfügbar zu halten. ICANN kündigte an, dass es weiterhin Registrierungen und Registrierungsstellen benötigen wird, um mit ein paar Änderungen zur Einhaltung der DSGVO Informationen an WHOIS zu übermitteln. Siehe Anmerkungen zu WHOIS, DSGVO und Domänenvalidierung.

Verwenden Sie WHOIS-basierte E-Mail-Domänenvalidierung?

Prüfen Sie, ob Ihre Domänenregistrierung eine anonymisierte E-Mail oder ein Internetformular als Möglichkeit für Zertifizierungsstellen verwendet, DSGVO-konform auf WHOIS-Daten zuzugreifen.

Um den Validierungsprozess möglichst effizient zu halten, fordern Sie Ihre Registrierung auf, entweder weiterhin vollständig veröffentlichte Einträge oder eine anonymisierte E-Mail-Adresse für Ihre Domänen zu verwenden. Mit diesen Optionen wird sichergestellt, dass es minimale bis keine Auswirkungen auf unsere Validierungsprozesse hat.

Verwendet Ihre Registrierung eine anonymisierte E-Mail oder ein Internetformular als Möglichkeit für Zertifizierungsstellen auf WHOIS-Daten zuzugreifen? Falls ja, können wir die DCV-E-Mail an die Adressen senden, die in Ihrem WHOIS-Eintrag aufgelistet sind.

Maskiert oder entfernt Ihre Registrierungsstelle E-Mail-Adressen? Falls dem so ist, müssen Sie eine der anderen Methoden zum Nachweis der Kontrolle über Ihre Domänen verwenden:

  • Konstruierte E-Mail-Adressen
  • DNS TXT
  • DNS CNAME
  • HTTP-Praxisbeispiel

Weitere Informationen über konstruierte E-Mail-Adressen und alternative DCV-Methoden finden Sie unter DCV-Methoden (Validierung der Domänenkontrolle).

Mai 10, 2018

compliance

Die Branchenstandards erlauben es einer Zertifizierungsstelle (CA), ein TLS-SSL-Zertifikat für eine Domäne auszustellen, die nur CAA-Einträge ohne "issue"-/"issuewild"-Eigenschaften-Tags hat.

Falls eine CA die CAA RRs einer Domäne abfragt und nur Dateneinträge ohne "issue"- oder "issuewild"-Eigenschaften-Tags findet, kann sie dies als Erlaubnis interpretieren, ein SSL/TLS-Zertifikat für diese Domäne auszustellen. Siehe Abstimmung 219: Klärung von CAA Record Sets ohne "issue"/"issuewild"-Eigenschafts-Tag.

Weitere Informationen über die CAA-RR-Prüfung finden Sie auf unserer Seite DNS CAA Resource Record Check.

April 1, 2018

compliance

Im Rahmen des branchenweiten Wechsels weg von TLS 1.0/1.1 und um unsere PCI-Compliance zu wahren, deaktivierte DigiCert TLS 1.0/1.1 am 1. April 2018. In der Folge unterstützt DigiCert nur noch TLS 1.2 und höher. Siehe Das Aus für TLS 1.0 und 1.1.

März 2, 2018

compliance

DigiCert implementiert eine verbesserte Überprüfung der Organisationseinheiten (OU).

Nach grundlegenden Anforderungen:

"Die CA WIRD einen Prozess implementieren, der verhindert, dass ein OU-Attribut einen Namen, einen DBA-Namen, einen Handelsnamen, eine Marke, eine Adresse, einen Standort oder anderen Text enthält, der sich auf eine bestimmte natürliche oder juristische Person bezieht, sofern die CA diese Information nicht in Übereinstimmung mit Abschnitt 11.2 ... geprüft hat."

Hinweis: Das OU-Feld ist ein optionales Feld. Es ist nicht erforderlich, eine Organisationseinheit in einen Zertifikatsantrag aufzunehmen.

compliance

Ab dem 1. März 2018 beträgt die maximale Laufzeit für erneut (oder als Duplikat) ausgestellte öffentliche 3-Jahres-SSL/TLS-Zertifikate 825 Tage.

Bei einem 3-Jahres-OV-Zertifikat, das am 1. März 2017 ausgestellt wurde, bedenken Sie, dass alle während des ersten Jahres der Laufzeit erneut ausgestellten oder duplizierten Zertifikate eine kürzere Laufzeit als das "Originalzertifikat" haben und deshalb zuerst ablaufen werden. Siehe
Wie wirkt sich das auf meine 3-Jahres-Zertifikatneuausstellungen und -duplikate aus?.

Februar 21, 2018

compliance

Ab 21. Februar 2018 bietet DigiCert aufgrund von Änderungen der Branchenstandards, die die maximale Laufzeit eines öffentlichen SSL-Zertifikats auf 825 Tage (ca. 27 Monate) begrenzen, nur noch 1- und 2-jährige öffentliche SSL-/TLS-Zertifikate an. Siehe 20. Februar 2018, letzter Tag für neue 3-Jahres-Aufträge von Zertifikaten.

compliance

Dies dient nur Informationszwecken. Es ist keine Aktion erforderlich.

Ab 1. Februar 2018 veröffentlicht DigiCert alle neu ausgestellten öffentlichen SSL-/TLS-Zertifikate in öffentlichen CT-Protokollen. OV-Zertifikate, die vor dem 1. Februar 2018 ausgestellt wurden sind davon nicht betroffen. Beachten Sie, dass die CT-Protokollierung für EV-Zertifikate bereits seit 2015 verlangt wird. Siehe DigiCert-Zertifikate werden ab 1. Febr. öffentlich protokolliert.

enhancement

Neue Funktion "Ausschluss von der CT-Protokollierung bei der Bestellung eines Zertifikats" zu CertCentral hinzugefügt. Wenn Sie diese Funktion aktivieren (Einstellungen > Voreinstellungen), können Kontobenutzer öffentliche SSL-/TLS-Zertifikate von der Protokollierung in öffentlichen CT-Protokollen auf Auftragsbasis ausnehmen.

Bei der Bestellung eines SSL-Zertifikats haben die Benutzer die Option, das SSL/TLS-Zertifikat nicht in öffentlichen CT-Protokollen zu protokollieren. Diese Funktion ist verfügbar, wenn ein Benutzer ein neues Zertifikat beantragt, ein Zertifikat neuausstellen oder verlängern lässt. Siehe CertCentral-CT-Protokollierungsanleitung für öffentliche SSL/TLS-Zertifikate.

enhancement

Es wurde ein neues CT-Protokollierungsfeld (disable_ct) hinzugefügt zu den SSL-Zertifikatsantrags-API-Endpunkten hinzugefügt. Außerdem wurde ein neuer Endpunkt „Ausgestelltes Zertifikat von CT-Protokollierung ausnehmen“ (CT-Status) hinzugefügt. Siehe CertCentral-API-Anleitung zum Ausnehmen öffentlicher SSL/TLS-Zertifikate von der CT-Protokollierung.

Oktober 24, 2017

compliance

Änderungen der Branchenstandards für Prüfungen von CAA-Ressourcen-Einträgen. Änderung der Prüfung von CNAME-Ketten mit 8 oder weniger CNAME-Einträgen, wobei die Suche nicht das übergeordnete Ziel eines CNAME-Eintrags umfasst. Siehe DNS-CAA-Dateneintragsprüfung

September 8, 2017

compliance

Änderungen der Branchenstandards bei der Ausstellung von Zertifikaten. Bei der Zertifikatsausstellung werden nun DNS-CAA-Dateneinträge überprüft. Siehe DNS-CAA-Dateneintragsprüfung

Juli 28, 2017

compliance

Compliance-Änderungen der Branchenstandards; verbesserte RFC 5280-Prüfung von Verletzungen und -Zwangsmaßnahmen. Siehe Öffentlich vertrauenswürdige Zertifikate – Dateneinträge, die gegen Branchenstandards verstoßen

Juli 21, 2017

compliance

Änderung der Validierung in den Branchenstandards Validierungsinformationen (DCV oder Organisation), die älter als 825 Tage sind, müssen neu validiert werden, bevor ein Zertifikat neu ausgestellt, verlängert oder ausgestellt werden kann. Weitere Details »

Juli 10, 2017

compliance

Compliance-Änderungen der Branchenstandards; erweiterte Unterstützung für zusätzliche DCV-Methoden. Siehe Domänenvorabvalidierung: DCV-Methoden (Domain Control Validation).