Filtrage par : compliance x effacer
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

Microsoft is sunsetting support for third-party kernel-mode driver package digital signatures

The process for signing your kernel-mode driver packages is changing. Starting in 2021, Microsoft will be the sole provider of production kernel-mode code signatures. You will need to start following Microsoft’s updated instructions to sign any new kernel-mode driver packages going forward. See Partner Center for Windows Hardware.

What is DigiCert doing about this?

As a first step in this sunsetting process, DigiCert has removed the Microsoft Kernel-Mode Code platform option from Code Signing certificate request forms: new, reissue, and renew.

This means going forward, you can no longer order, reissue, or renew a code signing certificate for the kernel-mode platform.

How does this affect my existing kernel-mode Code Signing certificate?

You can continue to use your existing certificates to sign Kernel-Mode driver packages until the cross-signed root it is chained to expires. DigiCert brand cross-signed root certificates expire in 2021.

For more details, see our knowledgeable article, Microsoft sunsetting support for cross-signed root certificates with kernel-mode signing capabilities.

compliance

Nouvelles exigences de conformité d’Apple pour les certificats SSL privés

Apple a récemment annoncé de nouvelles exigences de sécurité pour les certificats SSL/TLS qui entreront en vigueur lors de la mise à disposition des systèmes iOS 13 et macOS 10.15. Ces exigences concernent les certificats publics et privés émis après le 1er juillet 2019.

En ce qui concerne vos certificats SSL/TLS publics DigiCert, aucune action n’est requise de votre part.

En effet, ces certificats répondent déjà à l’ensemble de des exigences de sécurité. Vos certificats SSL/TLS publics ne sont donc pas concernés par ces nouvelles exigences et seront approuvés par les systèmes iOS 13 et macOS 10.15.

Ce qu’il y a de nouveau ?

Apple met en œuvre de nouvelles exigences de sécurité pour tous les certificats SSL/TLS qui, de par leur conception, affectent les certificats SSL/TLS privés. Consultez la page Requirements for trusted certificates in iOS 13 and macOS 10.15 (Exigences applicables aux certificats approuvés dans iOS 13 et macOS 10.15) Les certificats SSL/TLS privés DigiCert répondent à ces exigences s’ils sont émis par des administrateurs de compte conformément aux exigences applicables aux certificats publics.

Vous trouverez ci-dessous une liste des exigences qui pourraient s’appliquer à vos certificats SSL/TLS privés. Fort heureusement, ces versions des systèmes d’exploitation d’Apple seront mises à disposition en automne cette année. Cela signifie que vous avez le temps de vous y préparer.

  • Obligation d’utiliser un algorithme de la famille SHA-2 pour la signature. Les certificats signés SHA-1 ne sont plus approuvés pour SSL/TLS.
  • Obligation de définir une période de validité maximale de 825 jours. Les certificats SSL/TLS d’une validité supérieure à 825 jours ne sont plus approuvés.

Si certains de vos certificats privés ne répondent pas à ces exigences et s’ils doivent être approuvés par les systèmes Apple iOS et macOS, vous devrez faire en sorte que tous les certificats SSL/TLS privé émis après le 1er juillet 2019 soient émis pour la première fois ou réémis avant la mise à disposition des systèmes iOS 13 et macOS 10.15. Consultez la page Réémettre un certificat SSL/TLS.

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

Changement des normes de l’industrie

Depuis le 31 juillet 2019 (19:30 UTC), vous devez utiliser la méthode DCV par démonstration pratique HTTP pour prouver que vous contrôlez les adresses IP figurant sue vos commandes de certificat.

Pour plus d’informations sur la méthode DCV par démonstration pratique HTTP, consultez les instructions suivantes :

Avant, les normes de l’industrie vous autorisaient à utiliser d’autres méthodes DCV pour prouver le contrôle de vos adresses IP. Toutefois, suite au vote SC7, les réglementations relatives à la validation des adresses IP ont changé.

Vote SC7 : Mise à jour des méthodes de validation des adresses IP

Ce vote redéfinit les processus et les procédures autorisés pour valider le contrôle du client quant à l’adresse IP figurant sur le certificat. Les changements apportés par le vote SC7 prennent effet le 31 juillet 2019 (19:30 UTC).

Pour demeurer conforme à cette réglementation, depuis le 31 juillet 2019 (19:30 UTC), DigiCert autorisent ses clients à n’utiliser que la méthode DCV par démonstration pratique HTTP pour valider le contrôle de leurs adresses IP.

Suppression de la prise en charge des adresses IPv6

Depuis le 31 juillet 2019 (19:30 UTC), DigiCert n’émet plus de certificats pour adresses IPv6. En raison des limites de serveur, DigiCert n’est pas en mesure d’accéder aux adresses IPv6 pour vérifier le fichier placé sur le site web du client dans le cadre de la méthode DCV par démonstration pratique HTTP.

enhancement

Nous avons mis à jour les paramètres de fédération SAML dans CertCentral pour empêcher que votre nom de fédération apparaisse sur la liste des IdP des pages SAML Single Sign-On IdP Selection (Sélection de l’IdP pour l’authentification SSO SAML) et SAML certificate requests IdP Selection (Sélection de l’Idp pour les demandes de certificat via SAML).

Désormais, la page « Federation Settings » (Paramètres de fédération) sous les métadonnées de votre IdP, offre l’option Include Federation Name (Inclure le nom de fédération). Si vous ne souhaitez pas que votre nom de fédération apparaisse sur la liste des IdP de la page Sélection de l’IdP,, il vous suffit de désélectionner l’option Add my Federation Name to the list of IdPs (Ajouter le nom de ma fédération à la liste l’IdP).

new

Les certificats TLS/SSL Secure Site Pro sont disponibles dans CertCentral. Avec un certificat Secure Site Pro, le coût de chaque domaine vous est facturé et non pas le coût de base du certificat. Si vous ajoutez un domaine, un seul vous est facturé. Si vous avez besoin de neuf domaines, les neufs domaines vous sont facturés. Vous pouvez protéger jusqu’à 250 domaines avec un seul certificat.

Nous proposons deux types de certificats Secure Site Pro, à savoir, un pour les certificats OV et un pour les certificats EV.

  • Certificats Secure Site Pro SSL
    Procurez-vous le certificat OV adapté à vos besoins. Bénéficiez du chiffrement et de l’authentification pour un domaine, un domaine à caractère générique et tous ses sous-domaines, ou optez pour d’autres noms d’objet (SAN) pour protéger plusieurs domaines et domaines à caractère générique avec un seul certificat.
  • Certificats Secure Site Pro EV SSL
    Procurez-vous le certificat à validation étendue adapté à vos besoins. Bénéficiez du chiffrement et de l’authentification pour protéger un domaine ou optez pour d’autres noms d’objet (SAN) pour protéger plusieurs sites (noms de domaine complets) avec un seul certificat.

Avantages inclus avec chaque certificat Secure Site Pro

Chaque certificat Secure Site Pro inclut – sans coût supplémentaire – un accès prioritaire aux futures fonctions premium intégrées à CertCentral (par ex., le suivi des journaux CT et la gestion des validations).

Autres avantages :

  • Validation prioritaire
  • Support prioritaire
  • Deux sceaux de site sécurisé de haute qualité
  • Recherche de logiciels malveillants
  • Garanties à la pointe de l’industrie

Pour activer les certificats Secure Site Pro pour votre compte CertCentral, prenez contact avec votre gestionnaire de compte ou notre équipe de support.

Pour en savoir plus sur nos certificats Secure Site Pro, consultez la page DigiCert Secure Site Pro (Certificats DigiCert Secure Site Pro).

compliance

Les certificats SSL publics ne sont plus à même de protéger les noms de domaines comportant des traits de soulignement ("_"). Tous les certificats précédemment émis pour des domaines comportant des domaines comportant des traits de soulignement doivent expirer avant cette date.

Remarque : La solution préférée consiste à renommer les autres noms d’hôte (FQDN) qui contiennent des traits de soulignement et de remplacer les certificats. Toutefois, dans les cas où le remplacement du nom est impossible, vous pouvez utiliser des certificats privés et, dans certains cas, un certificat à caractère générique qui protège l’intégralité du domaine.

Pour plus de précisions, consultez la page Retiring Underscores in Domain Names (Révoquer les noms de domaine comportant des traits de soulignement).

compliance

Exigences des normes de l’industrie concernant l’ajout de l’extension « CanSignHttpExchanges » à un certificat SSL/TLS ECC :

  • Enregistrement de ressource CAA pour le domaine, comprenant le paramètres "cansignhttpexchanges=yes"*
  • Paire de clés ECC (Elliptic Curve Cryptography)
  • Extension « CanSignHttpExchanges »
  • Validité maximale de 90 jours*
  • Utilisé seulement pour les échanges HTTP signés

*Remarque : Ces exigences sont entrées en vigueur le 1er mai 2019. L’extension Signed HTTP Exchanges est actuellement en cours de développement. D’autres modifications pourraient être apportées aux exigences à mesure que l’industrie continue d’évoluer.

L’obligation d’une validité maximale de 90 jours ne concerne pas les certificats émis avant le 1er mai 2019. Sachez que la période de validité des certificats réémis sera écourtée à 90 jours à compter de l’heure de réémission. Vous pouvez toutefois continuer de réémettre le certificat pendant toute la période de validité achetée.

Extension CanSignHttpExchanges

Récemment, nous avons intégré un nouveau profil de certificat, HTTP Signed Exchanges, afin de résoudre le problème d’affichage des URL AMP et faire en sorte que votre marque soit correctement spécifiée dans la barre d’adresse. Consultez la page Display better AMP URLs with Signed HTTP Exchanges (Optimiser les URL AMP grâce aux échanges HTTP signés).

Cette nouvelle option de profil vous permet d’inclure l’extension « CanSignHttpExchanges » aux certificats SSL/TLS OV et EV. Une fois activée pour votre compte, l’option Include the CanSignHttpExchanges extension in the certificate (Inclure l’extension CanSignHttpExchanges dans le certificat) apparaît sur les formulaires de vos certificats SSL/TLS OV et EV sous Additional Certificate Options (Options de certificat supplémentaires). Consultez la page Obtenir un certificat Signed HTTP Exchanges.

Pour activer ce profil de certificat pour votre compte, veuillez joindre votre représentant commercial ou contacter votre équipe de support.

compliance

Les AC ne peuvent plus émettre de certificats SSL publics d’une durée de 30 jours pour les noms de domaine comportant des traits de soulignement (noms communs et autres noms d’objet).

Remarque : La solution préférée consiste à renommer les autres noms d’hôte (FQDN) qui contiennent des traits de soulignement et de remplacer les certificats. Toutefois, dans les cas où le remplacement du nom est impossible, vous pouvez utiliser des certificats privés et, dans certains cas, un certificat à caractère générique qui protège l’intégralité du domaine.

Pour plus de précisions, consultez la page Retiring Underscores in Domain Names (Révoquer les noms de domaine comportant des traits de soulignement).

compliance

Dernier jour pour commander des certificats SSL publics d’une durée de 30 jours pour les noms de domaine contenant des traits de soulignement (noms communs et autres noms d’objet) auprès de n’importe quelle AC.

Remarque : La solution préférée consiste à renommer les autres noms d’hôte (FQDN) qui contiennent des traits de soulignement et de remplacer les certificats. Toutefois, dans les cas où le remplacement du nom est impossible, vous pouvez utiliser des certificats privés et, dans certains cas, un certificat à caractère générique qui protège l’intégralité du domaine.

Pour plus de précisions, consultez la page Retiring Underscores in Domain Names (Révoquer les noms de domaine comportant des traits de soulignement).

compliance

Aucune action n’est requise de votre part.

Depuis le 13 février 2019, DigiCert n’émet plus de certificats TLS/SSL ECC (c.-à-d. des certificats avec clés ECDSA) avec paire basée sur la courbe P-384 et sur les fonctions de hachage SHA-2 512 (SHA-512). Cette paire à base de courbes elliptiques et de fonctions de hachage n’est pas conforme à la stratégie du magasin racine de Mozilla.

La stratégie du magasin racine de Mozilla ne prend en charge que les paires utilisant les courbes elliptiques et fonctions de hachage suivantes :

  • P‐256 avec fonctions SHA-256
  • P‐384 avec fonctions SHA-384

Remarque : Vous disposez d’un certificat basé utilisant une paire P-384 et des fonctions de hachage SHA-512 ? Ne vous inquiétez pas, lorsqu’il sera temps de renouveler le certificat, il sera automatiquement émis avec une paire utilisant des courbes elliptiques et des fonctions de hachage prises en charge.

compliance

Les autorités de certification (AC) ont révoqué tous les certificats SSL publics des domaines comportant des traits de soulignement (dans le nom commun et les autres noms d’objet) et dont la période de validité maximale était de 30 jours, fin de journée (heure UTC).

Si vous disposiez d’un certificat SSL d’une période de validité maximale de 31 jours (comprenant tous les certificats valides pendant 1, 2 et 3 ans), arrivé à échéance après le 14 janvier 2019, l’autorité de certification émettrice s’est trouvée dans l’obligation de le révoquer.

Pour plus de précisions, consultez la page Retiring Underscores in Domain Names (Révoquer les noms de domaine comportant des traits de soulignement).

compliance

DigiCert a émis des certificats SSL pour les domaines contenant des traits de soulignement pendant un certain temps.

  • Validité maximale de 30 jours pour les certificats SSL dont les domaines contiennent des traits de soulignement.
  • Le domaine de base ne doit pas comporter de traits de soulignement ("example_domain.com" n’est pas autorisé).
  • Le libellé de domaine situé le plus à gauche ne doit pas comporter de traits de soulignement ("_exemple.domain.com" et "example_domain.exemple.com" ne sont pas autorisés).

Pour plus de précisions, consultez la page Retiring Underscores in Domain Names (Révoquer les noms de domaine comportant des traits de soulignement).

new

Dans le menu supérieur, nous avons intégré deux nouvelles options de contact du support (représentées par des icônes de téléphone et de discussion) vous permettant de contacter le support plus facilement depuis CertCentral (par courrier électronique, discussion ou téléphone).

L’icône du téléphone affiche les options de contact par courrier électronique et par téléphone. L’icône de discussion affiche une fenêtre de discussion vous permettant de démarrer une conservation avec les membres de notre équipe de support dévouée.

enhancement

Nous avons amélioré le menu latéral, afin de vous permettre de mieux voir les options de menu des pages auxquelles vous accédez. Désormais, lorsque vous accédez à une page dans CertCentral, l’option de menu correspondant à cette page sera présentée avec une barre bleue horizontale adjacente.

fix

Nous avons corrigé un bogue affectant la fonction Add Organization (Ajouter une organisation) sur les formulaires de demande de certificat SSL/TLS. Le statut de validation (EV et OV) ne s’affichait pas pour les organisations nouvellement ajoutées et validées au cours du processus de commande du certificat.

Désormais, les nouvelles organisations ajoutées lors de la commande d’un certificat SSL s’afficheront avec le statut Validated (Validée).

Remarque : Le statut de validation de l’organisation concernée n’apparaît pas tant que nous n’avons pas entièrement validée l’organisation.

compliance

Changement concernant la conformité aux normes de l’industrie. Pour les certificats publiquement approuvés, les traits de soulignement ( _ ) ne peuvent plus figurer dans les sous-domaines. Désormais, la norme RFC 5280 s’applique également aux sous-domaines.

Consultez la page Publicly Trusted Certificates – Data Entries that Violate Industry Standards (Certificats approuvés publiquement – Entrées de données non conformes aux normes de l’industrie).

Août 1, 2018

compliance

Un changement des normes de l’industrie a donné lieu à la suppression de deux méthodes de validation du contrôle de domaine (DCV) des exigences de base.

À compter du 1er août 2018, les autorités de certification ne peuvent plus utiliser les méthode de DCV suivantes :

  • 3.2.2.4.1 Validation du demandeur en tant que contact du domaine
    Cette méthode permettait à une AC de valider le contrôle d’un domaine associé à un certificat SSL/TLS en vérifiant si le demandeur est bien contact du domaine directement auprès du bureau d’enregistrement du nom de domaine.
  • 3.2.2.4.5 Document d’autorisation de domaine
    Cette méthode permettait à une AC de valider le contrôle d’un domaine associé à un certificat SSL/TLS en vérifiant auprès de l’autorité si le demandeur est bien habilité à commander un certificat pour le dit domaine tel que mentionné dans un document d’autorisation de domaine .
    Consultez la page Ballot 218: Remove validation methods 1 and 5 (Vote 218 : suppression des méthodes de validation 1 et 5).

Pour en savoir plus sur les méthodes DCV disponibles, consultez la page Domain Control Validation (DCV) Methods (Méthodes de validation du contrôle de domaine [Domain Control Validation, DCV]).

Mai 25, 2018

compliance

Conformité de DigiCert au Règlement général sur la protection des données (RGPD)

Le RGPD est une loi de l’Union européenne sur la protection et la confidentialité des données de toutes les personnes de l’Union européenne. Son principal objectif est de permettre aux citoyens et résidents de l’UE d’exercer un plus grand contrôle sur leur données personnelles et de simplifier l’environnement réglementaire pour les entreprises internationales en unifiant les réglementations au sein de l’UE. Le RGDP est entré en vigueur le 25 mai  2018. « Plus de précisions »

Déclaration de DigiCert

DigiCert s’est engagée à comprendre et à se conformer au RGDP. Nous étions d’ores et déjà en accord avec le RGDP dès son entrée en vigueur le 25 mai 2018. Consultez la page Meeting the General Data Protection Regulation (GDPR) (Se conformer au Règlement général sur la protection des données (RGPD).

compliance

Incidence du RGPD sur la méthode WHOIS de validation du contrôle de domaine (DCV) effectuée par courrier électronique

Le Règlement général de l’Union européenne sur la protection des données (RGPD) est entré en vigueur le 25 mai 2018. Il impose la protection des données des personnes physiques (non pas des personnes morales) résidant dans l’Union européenne.

DigiCert a travaillé en concertation avec l’ICANN (Internet Corporation for Assigned Names and Numbers, ou Société pour l’attribution des noms de domaines et des numéros sur Internet, en français) afin d’assurer la disponibilité des informations WHOIS. L’ICANN a déclaré maintenir l’obligation pour les registres et bureaux d’enregistrement de soumettre des informations au service WHOIS, moyennant certaines adaptations aux objectifs du RGPD. Consultez la page A Note on WHOIS, GDPR and Domain Validation (Observations sur le service WHOIS, le RGPD et la validation des domaines).

Utilisez-vous la méthode WHOIS pour valider le contrôle de votre domaine par courrier électronique ?

Vérifiez auprès de votre bureau d’enregistrement si l’accès des AC aux données WHOIS dans le cadre de la conformité au RGPD s’effectue au moyen d’une adresse électronique anonyme ou d’un formulaire web.

Pour que le processus de validation soit le plus efficace possible, informez votre bureau d’enregistrement que vous souhaitez que vos enregistrements publics ou une adresse électronique anonyme soient utilisés pour vos domaines. Grâce à ces options l’incidence sur vos processus de validation demeurera minimale voire nulle.

Votre bureau d’enregistrement permet-il aux AC d’accéder aux données WHOIS au moyen d’une adresse électronique anonyme ou d’un formulaire web ? Si tel est le cas, nous pouvons envoyer les courriers électroniques DCV aux adresses répertoriées dans l’enregistrement WHOIS.

Votre bureau d’enregistrement masque-t-il ou supprime-t-il les adresses électroniques ? Si tel est le cas, vous devrez utiliser l’une des autres méthodes suivantes pour prouver le contrôle de vos domaines :

  • Adresse électronique construite
  • DNS TXT
  • DNS CNAME
  • Démonstration pratique HTTP

Pour plus d’informations sur les adresses électroniques construites et les autres méthodes DCV disponibles consultez la page Domain Control Validation (DCV) Methods (Méthodes de validation du contrôle de domaine).

Mai 10, 2018

compliance

Les normes de l’industrie autorisent une autorité de certification à émettre un certificat SSL/TLS pour un domaine dont les enregistrements CAA ne contiennent pas de balises de propriété "issue"/"issuewild".

Lorsqu’une AC interroge les enregistrements de ressource CAA d’un domaine et ne trouve pas de balises de propriété "issue" ou "issuewild", l’AC peut interpréter ce cas comme une autorisation d’émission du certificat SSL/TLS pour le domaine en question. Consultez la page Ballot 219: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag (Vote 219 : Rationaliser le traitement des ensembles d’enregistrements CAA sans balise de propriété « issue » ou « issuewild »).

Pour en savoir plus sur le processus de contrôle des enregistrements de ressource CAA, consultez notre page DNS CAA Resource Record Check (Contrôle des enregistrements de ressource DNS CAA).

Avril 1, 2018

compliance

Dans le cadre de l’abandon du protocole TLS 1.0/1.1 dans l’ensemble du secteur et en vue de maintenir notre conformité aux normes PCI, DigiCert a désactivé le protocole TLS 1.0/1.1 le 1er avril 2018. À partir de maintenant, DigiCert ne prend en charge que le protocole TLS 1.2 et les versions ultérieures. Consultez la page Déclassement du protocole TLS 1.0 et 1.1.

Mars 2, 2018

compliance

DigiCert met en œuvre un processus amélioré pour la vérification des unités organisationnelles (UO).

Par exigences de base :

"L’autorité de certification s’engage à mettre en œuvre un processus permettant d’empêcher un attribut d’UO d’inclure un nom, un nom DBA, un nom commercial, une marque commerciale, une adresse, un lieu ou tout autre texte faisant référence à une personne physique ou morale particulière, à moins que l’AC n’ait vérifié ces informations conformément à la Section 11.2…"

Remarque : Le champ de l’UO est un champ facultatif. Il n’est pas obligatoire d’inclure une unité organisationnelle dans une demande de certificat.

compliance

À compter du premier mars 2018, la durée maximale autorisée des certificats SSL/TLS publics de 3 ans réémis (ou dupliqués) est de 825 jours.

Dans le cas d’un certificat OV de 3 ans émis après le 1er mars 2017, n’oubliez pas que pendant la première année du cycle de vie de 3 ans du certificat, tous les certificats réémis ou dupliqués peuvent avoir un cycle de vie plus court que le certificat "original", et ces certificats réémis expireront en premier. Consultez la page
How does this affect my 3-year certificate reissues and duplicate issues? (En quoi cela affecte-t-il les réémissions de mon certificat de 3 ans et les duplicatas ?).

Février 21, 2018

compliance

À compter du 21 février 2018, DigiCert ne propose que des certificats SSL/TLS publics de 1 ou 2 ans en raison d’un changement des normes de l’industrie limitant la durée d’un certificat SSL public à 825 jours (environ 27 mois). Consultez la page February 20, 2018, Last Day for New 3-Year Certificate Orders (Le 20 février 2018 : dernier jour pour commander des certificats d’une durée de 3 ans).

compliance

Ceci vous est présenté à titre indicatif seulement, aucune action n’est requise de votre part.

À compter du premier février 2018, DigiCert enregistre tous les nouveaux certificats SSL/TLS publics émis dans les journaux de transparence des certificats (Certificate Transparency, CT) publics. Cette modification ne concerne pas les certificats OV émis avant le premier février 2018. Sachez que la journalisation CT est obligatoire pour les certificats EV depuis 2015. Consultez la page DigiCert Certificates Will Be Publicly Logged Starting Feb. 1 (DigiCert enregistre les certificats dans les journaux publics à compter du mois de février).

enhancement

Ajout d’une nouvelle fonction "exclude from CT log when ordering a certificate" (Exclure de la journalisation CT lors de la commande de certificat). Lorsque vous activez cette fonction, accessible en cliquant surSettings > Preferences (Paramètres > Préférences), vous autorisez les utilisateurs du compte à exclure les certificats SSL/TLS de la journalisation CT publique par commande individuelle.

Lorsqu’un utilisateur commande un certificat SSL, il a la possibilité de ne pas enregistré le certificat SSL/TLS dans les journaux CT publics. Cette fonction est disponible au moment où un utilisateur commande un nouveau certificat, réémet ou renouvelle un certificat. Consultez la page CertCentral Public SSL/TLS Certificate CT Logging Guide (Guide sur la journalisation CT des certificats SSL/TLS publics dans CertCentral).

enhancement

Ajout d’un nouveau champ (disable_ct) facultatif, permettant de refuser la journalisation CT, aux points de terminaison des API de demande de certificats SSL. Ajout d’un nouveau point de terminaison (ct-status) permettant de refuser la journalisation CT des certificats émis. Consultez la page CertCentral API Public SSL/TLS Certificate Transparency Opt Out Guide (Guide sur l’API d’exclusion des certificats SSL/TLS publics de la journalisation CT).

Octobre 24, 2017

compliance

Changement des normes de l’industrie concernant les contrôles d’enregistrement de ressource CAA. Modification du processus servant à contrôler les chaînes CNAME contenant un maximum de 8 enregistrements CNAME. La recherche ne tient pas compte de la cible parent d’un enregistrement CNAME. Consultez la page DNS CAA Resource Record Check (Contrôle de l’enregistrement de ressource DNS CAA).

Septembre 8, 2017

compliance

Changement des normes de l’industrie relatives à la délivrance des certificats. Processus de délivrance de certificats modifié pour contrôler les enregistrements de ressource DNS CAA. Consultez la page DNS CAA Resource Record Check (Contrôle de l’enregistrement de ressource DNS CAA).

Juillet 28, 2017

compliance

Changement concernant la conformité aux normes de l’industrie ; amélioration des contrôles de violation de la norme RFC 5280 et de son application. Consultez la page Publicly Trusted Certificates – Data Entries that Violate Industry Standards (Certificats approuvés publiquement – Entrées de données non conformes aux normes de l’industrie).

Juillet 21, 2017

compliance

Changement des normes de l’industrie relatives au processus de validation. Les informations de validation (DCV ou organisation) datant de plus de 825 jours doivent être revalidées avant le traitement de toute demande de réémission, de renouvellement ou d’émission de certificat. « Plus de précisions »

Juillet 10, 2017

compliance

Changement des normes de l’industrie ; prise en charge de méthodes supplémentaires pour la validation du contrôle de domaine (DCV). Consulter la page Domain Pre-Validation: Domain Control Validation (DCV) Methods (Prévalidation des domaines : méthodes de validation du contrôle de domaine (Domain Control Validation, DCV).