Filtrage par : compliance x effacer
new

CertCentral to issue GeoTrust and RapidSSL DV certificates from new intermediate CA certificates

On May 24, 2022, between 9:00 am and 11:00 am MDT (3:00 pm and 5:00 pm UTC), DigiCert will replace the GeoTrust and RapidSSL intermediate CA (ICA) certificates listed below. We can no longer issue maximum validity (397-day) DV certificates from these intermediates.

Old ICA certificates

  • GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1
  • GeoTrust TLS DV RSA Mixed SHA256 2021 CA-1
  • RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
  • RapidSSL TLS DV RSA Mixed SHA256 2021 CA-1

New ICA certificates

  • GeoTrust Global TLS RSA4096 SHA256 2022 CA1
  • RapidSSL Global TLS RSA4096 SHA256 2022 CA1

See the DigiCert ICA Update KB article.

How does this affect me?

Rolling out new ICA certificates does not affect your existing DV certificates. Active certificates issued from the replaced ICA certificates will remain trusted until they expire.

However, all new certificates, including certificate reissues, will be issued from the new ICA certificates. To ensure ICA certificate replacements go unnoticed, always include the provided ICA certificate with every TLS certificate you install.

No action is required unless you do any of the following:

  • Pin the old versions of the intermediate CA certificates
  • Hard code the acceptance of the old versions of the intermediate CA certificates
  • Operate a trust store that includes the old versions of the intermediate CA certificates

Action required

If you practice pinning, hard code acceptance, or operate a trust store, update your environment as soon as possible. You should stop pinning and hard coding ICA certificates or make the necessary changes to ensure your GeoTrust DV and RapidSSL DV certificates issued from the new ICA certificates are trusted. In other words, make sure they can chain up to their new ICA certificate and trusted root.

See the DigiCert Trusted Root Authority Certificates page to download copies of the new Intermediate CA certificates.

What if I need more time?

If you need more time to update your environment, you can continue to use the old 2020 ICA certificates until they expire. Contact DigiCert Support, and they can set that up for your account. However, after May 31, 2022, RapidSSL DV and GeoTrust DV certificates issued from the 2020 ICA certificates will be truncated to less than one year.

compliance

DigiCert va cesser d'émettre certificats de signature de code en SHA-1

Le mardi 1er décembre 2020 HNR, DigiCert cessera d'émettre des certificats de signature de code SHA-1 et des certificats de signature de code EV SHA-1.

Remarque : Tous les certificats de signature de code/signature de code EV en SHA-1 resteront actifs jusqu'à leur expiration.

Pourquoi ces changements de la part de DigiCert ?

Pour respecter les nouvelles normes en vigueur dans l’industrie, les autorités de certification (AC) doivent effectuer les changements suivants d'ici au 1er janvier 2021 :

  • Cesser d'émettre des certificats de signature de code en SHA-1
  • Cesser d'émettre des certificats racines et des certificats d’AC intermédiaires en SHA-1 pour émettre des certificats d’horodatage et de signature de code utilisant l’algorithme SHA-256.

Reportez-vous à l’Annexe A des Exigences de base pour l’émission et la gestion des certificats de signature de code approuvés publiquement.

En quoi les changements concernant les certificats de signature de code SHA-1 me concernent-ils ?

Si vous devez utiliser des certificats de signature de code en SHA-1, prenez les mesures suivantes, si nécessaire, avant le 1er décembre 2020 :

  • Récupérez vos nouveaux certificats SHA-1
  • Renouvelez vos certificats SHA-1
  • Réémettez et récupérez les certificats SHA-1 dont vous avez besoin

Pour de plus amples informations sur les changements prévus au 1er décembre 2020, consultez notre article de la base de connaissances DigiCert va cesser d'émettre des certificats de signature de code en SHA-1.

Si vous avez d'autres questions, veuillez contacter votre gestionnaire de compte ou notre équipe de support.

compliance

DigiCert cessera de proposer des certificats publics SSL/TLS de 2 ans.

À compter du 27 août 2020, 17:59 MDT (23:59 UTC), DigiCert cessera d'émettre des certificats SSL/TLS publics de 2 ans afin de se préparer aux changements de politique dans l’industrie concernant la validité maximale autorisée pour les certificats SSL/TLS publics.

Après la date limite du 27 août, vous ne pourrez acheter que des certificats TLS/SSL publics d’un an.

Que dois-je faire ?

Pour vous assurer d’obtenir les certificats SSL/TLS publics de 2 ans dont vous avez besoin avant la date limite du 27 août :

  • Faites l’inventaire de tous les certificats de 2 ans dont vous avez besoin, qu’il s'agisse de nouveaux certificats ou de renouvellements.
  • Commandez tous les certificats de 2 ans dont vous avez besoin avant le 13 août.
  • Répondez aux demandes de validation d’organisation et de domaine au plus vite.

Pour découvrir les conséquences de ce changement sur les commandes, réémissions et duplicata de certificats en attente, consultez la page Fin des certificats SSL/TLS DV, OV et EV publics d’une validité de 2 ans.

API de services DigiCert

Les personnes qui utilisent les API Services DigiCert devront mettre à jour leurs workflows d’API pour tenir compte de cette nouvelle durée de validité maximale de 397 jours pour les demandes déposées après la date limite du 27 août. Se reporter à la section API Services.

Après le 27 août 2020

Après le 27 août, vous ne pourrez acheter que des certificats TLS/SSL publics d’un an. Cependant, pour maximiser votre couverture SSL/TLS, commandez vos nouveaux certificats avec un plan pluriannuel DigiCert®. Reportez-vous à la page Plans pluriannuels.

Pourquoi ce changement de la part de DigiCert ?

Le 1er septembre 2020, l'industrie dit adieu aux certificats de 2 ans. À l'avenir, les autorités de certification (AC) ne pourront émettre que des certificats SSL/TLS DV, OV et EV d'une validité maximale de 398 jours (environ 13 mois).

DigiCert mettra en œuvre une validité maximale à 397 jours pour tous les certificats SSL/TLS publics par sécurité, compte tenu des différences de fuseau horaire et afin d'éviter d'émettre un certificat public SSL/TLS d'une durée de validité supérieure à 398 jours.

Consultez notre blog pour en savoir plus sur la transition vers les certificats TLS/SSL publics d’un an. Certificats Public-Trust SSL d’un an : DigiCert à votre service.

new

Plans pluriannuels disponibles dès maintenant

Nous avons le plaisir d'annoncer que les plans pluriannuels sont à présent disponibles dans CertCentral ainsi qu'aux partenaires CertCentral.

Les plans pluriannuels DigiCert® vous permettent de payer un prix unique, réduit, pour une couverture pouvant aller jusqu’à six ans pour vos certificats SSL/TLS. Avec les plans pluriannuels, vous choisissez le certificat SSL/TLS, la durée de couverture que vous souhaitez (jusqu'à six ans) et la validité du certificat. Tant que le plan n’a pas expiré, vous pouvez réémettre votre certificat sans frais chaque fois qu'il atteint la fin de sa période de validité.

La validité maximale d'un certificat SSL/TLS passera de 825 jours à 397 jours le 1er septembre 2020. Lorsque le certificat actif d'un plan pluriannuel est sur le point d’expirer, vous réémettez le certificat pour maintenir votre couverture SSL/TLS.

compliance

Prise en charge des navigateurs pour TLS 1.0 et 1.1

Les quatre principaux navigateurs ont cessé de prendre en charge Transport Layer Security (TLS) 1.0 et 1.1.

Ce que vous devez savoir

Ce changement n'affecte pas vos certificats DigiCert. Vos certificats continuent à fonctionner comme ils l'ont toujours fait.

Ce changement affecte les services et les applications dépendantes du navigateur qui reposent sur TLS 1.0 ou 1.1. Maintenant que les navigateurs ne prendront plus en charge TLS 1.0 et 1.1, tout système dépassé se trouvera dans l’incapacité d’établir des connexions HTTPS.

Ce que vous devez faire

Si ce changement vous concerne et que votre système est compatible avec des versions plus récentes du protocole TLS, passez votre configuration serveur aussi vite que possible à TLS 1.2 ou TLS 1.3.

Si vous ne passez pas à TLS 1.2 ou 1.3, votre serveur Web, système ou agent se trouvera dans l’incapacité d'utiliser HTTPS pour communiquer de manière sécurisée avec le certificat.

Informations sur l’obsolescence de TLS 1.0/1.1 dans les navigateurs

Firefox 78, publié le 30 juin 2020

Safari 13.1, publié le 24 mars 2020

Chrome 84, publié le 21 juillet 2020

Edge v84, publié le 16/07/2020

Ressources utiles

Compte tenu du grand nombre de types de systèmes différents reposant sur le TLS, nous ne pouvons pas couvrir toutes les voies de mise à niveau, mais voici quelques références qui peuvent vous aider :

enhancement

API de services CertCentral : Mise à jour de la documentation des messages d’erreur

Dans la documentation de l’API Services, nous avons mis à jour la page des Erreurs pour y inclure les descriptions des messages d’erreur concernant les points suivants :

  • Émission de certificats DV immédiate
  • Validation de contrôle de domaine (DCV)
  • Contrôles de l’enregistrement de ressources en matière d'autorisation d’autorité de certification (CAA).

Il y a quelques mois cette année, nous avons amélioré les API pour les commandes de certificats DV et les requêtes DCV afin de fournir des messages d’erreur plus détaillés en cas d'échec de la procédure DCV, d'autorisations de fichiers, de consultations DNS ou de contrôles de l’enregistrement de ressources CAA. Désormais, lorsque vous recevez l’un de ces messages d’erreur, consultez la page des Erreurs pour obtenir des informations de dépannage supplémentaires.

Pour plus d’informations :

compliance

Microsoft met fin à la prise en charge des signatures numériques des packages de pilotes en mode noyau de tiers

Le processus de signature des packages de pilotes en mode noyau est en train de changer. À partir de 2021, Microsoft sera le seul fournisseur de signatures de code en mode noyau pour la production. Il vous faudra désormais suivre les instructions mises à jour de Microsoft pour signer tout nouveau package de pilotes en mode noyau. Consultez la page Centre de partenariat pour le matériel Windows.

Que fait DigiCert à ce sujet ?

Dans un premier temps, DigiCert a supprimé l'option de la plate-forme Microsoft Kernel-Mode Code des formulaires de demande de certificat de signature de code : nouveau, réémission et renouvellement.

Désormais, vous ne pouvez plus commander, réémettre ou renouveler un certificat de signature de code pour la plate-forme en mode noyau.

En quoi cela affecte-t-il mon certificat de signature de code en mode noyau existant ?

Vous pouvez continuer à utiliser vos certificats existants pour signer les packages de pilotes en mode noyau jusqu'à ce que la racine à laquelle il est enchaîné arrive à échéance. Les certificats racine à signature croisée de la marque DigiCert expirent en 2021.

Pour obtenir plus d'informations, consultez notre page Suppression progressive de la prise en charge par Microsoft des certificats racine à signature croisée avec des capacités de signature en mode noyau.

compliance

Fin de la prise en charge des navigateurs pour TLS 1.0 et 1.1

En 2020, les quatre principaux navigateurs mettront fin à la prise en charge de la sécurité de Transport Layer Security (TLS) 1.0 et 1.1.

Ce changement n'affecte pas vos certificats DigiCert. Vos certificats continueront à fonctionner comme ils l'ont toujours fait.

Ce que vous devez savoir

Ce changement affecte les services et les applications dépendantes du navigateur qui reposent sur TLS 1.0 ou 1.1. Une fois que les navigateurs ne prendront plus en charge TLS 1.0 ou 1.1, ces systèmes dépassés ne pourront plus établir de connexions HTTPS.

Ce que vous devez faire

Si vous êtes concerné par ce changement, prévoyez d'activer ou de mettre à niveau vers TLS 1.2 ou TLS 1.3 dès maintenant. Prévoyez le temps nécessaire pour régler les problèmes éventuels. Avant de commencer, veillez à identifier tous les systèmes susceptibles d'utiliser TLS 1.0 ou 1.1.

N'oubliez pas de vérifier les serveurs web comme Apache ou Microsoft IIS, .NET Framework, les agents de surveillance des serveurs et les autres applications commerciales qui pourraient y recourir.

Ressources utiles

Compte tenu du grand nombre de types de systèmes différents reposant sur le TLS, nous ne pouvons pas couvrir toutes les voies de mise à niveau disponibles, mais voici quelques références qui peuvent vous aider :

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 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. Ces versions des systèmes d’exploitation d’Apple seront mises à disposition en automne cette année. Cela signifie que vous devez vous préparer dès maintenant.

Nouvelles exigences pour les certificats SSL/TLS privés :

  • Obligation d’utiliser un algorithme de la famille SHA-2 pour la signature. Les certificats SSL/TLS signés SHA-1 ne sont plus approuvés.
  • 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.

Quel est votre rôle ?

Si vous avez besoin des services Apple iOS et macOS trust pour vos certificats SSL/TLS privés, vérifiez que tous les certificats SSL/TLS privés émis après le 1er juillet 2019 répondent à leurs nouvelles exigences. Si vous découvrez des certificats qui ne répondent pas à ces exigences, prenez rapidement les mesures suivantes :

compliance

Prise en charge de la génération de clés de fin de Firefox

Avec la sortie de Firefox 69, Firefox va enfin abandonner la prise en charge de Keygen. Firefox utilise Keygen pour faciliter la génération de la clé publique lors de la génération des certificats de signature de code, client, et SMIME dans leur navigateur.

Remarque : Chrome a déjà abandonné la prise en charge de la génération de clés, alors que Edge et Opera ont toujours refusé cette option.

En quoi cela vous concerne-t-il ?

Suite à l'émission par DigiCert de vos certificats de signature de code, client ou SMIME, nous vous envoyons un courrier électronique avec un lien pour créer et installer votre certificat.

Dès que Firefox 69 sera disponible, vous ne pourrez plus utiliser que deux navigateurs pour générer ces certificats : Internet Explorer et Safari. Si la politique de l'entreprise exige l'utilisation de Firefox, vous pouvez utiliser Firefox ESR ou une copie portable de Firefox.

Pour obtenir plus d'informations, consultez la page Prise en charge de Keygen à désactiver avec Firefox 69.

Conseils et astuces

  • Vous pouvez toujours utiliser Firefox 69 pour l'authentification des clients. Premièrement, générez le certificat SMIME dans IE 11 ou Safari. Ensuite, importez le certificat SMIME dans Firefox.
  • Pour éviter de générer des certificats de signature de code, client ou SMIME dans votre navigateur, générez et soumettez un CSR avec votre commande. DigiCert vous enverra un courrier électronique avec votre certificat en pièce jointe au lieu d'un lien.
new

Nous avons ajouté un nouveau statut, Envoyé par courrier électronique au destinataire, sur les pages Orders (Commandes) et Order Details (Détails de la commande), pour les commandes de signature de code et de certificats client, ce qui permet d'identifier plus facilement à quel stade du processus de délivrance ces commandes se trouvent.

Ce nouveau statut indique que le DigiCert a validé la commande, et que le certificat attend que l'utilisateur/destinataire du courrier électronique le génère dans l'un des navigateurs pris en charge : IE 11, Safari, Firefox 68, et Firefox Portable.

(Dans le menu latéral, cliquez sur Certificates > Orders (Certificats > Commandes). Ensuite, sur la page Orders (Commandes), cliquez sur le numéro de commande pour la commande de certificats de signature de code ou clients.

enhancement

Nous avons mis à jour nos processus de réémission de certificats de signature de code (CS) à validation étendue (EV) et de signature de document (DS), ce qui vous permet de réémettre ces certificats sans révoquer automatiquement le certificat actuel (certificat original ou réémis précédemment).

Remarque : Si vous n'avez pas besoin du certificat actuel (certificat original ou réémis précédemment), vous devrez contacter le service d'assistance afin qu'il puisse le révoquer pour vous.

La prochaine fois que vous réémettrez un certificat EV CS ou DS, vous pourrez conserver le certificat précédemment émis pendant sa période de validité actuelle (ou aussi longtemps que vous en aurez besoin).

compliance

Rappel concernant la conformité aux normes de l’industrie.

Pour les certificats publics et privés, les autorités de certification (AC) n'acceptent pas les abréviations pour les informations suivantes dans vos commandes de certificats ou vos demandes de pré-validation d'organisations :

  • État / Province*
  • Ville ou localité*

*Cette obligation s'applique aux adresses des organisations et des juridictions.

new

Nous avons simplifié la définition du périmètre de validation de votre compte lors de la soumission de vos domaines pour validation (pré-validation ou via des commandes de certificats).

Sur la page Préférences de division, nous avons ajouté deux options de portée de validation de domaine :

  • Soumettre les noms de domaine exacts pour validation
    Avec cette option, les demandes de nouveaux domaines sont soumises pour validation exactement comme ils sont nommés (c'est-à-dire que la demande pour sub.exemple.com est soumise pour validation exactement comme sub.exemple.com). La validation pour le domaine de “niveau supérieur” (par exemple, exemple.com) fonctionne également. Ce comportement est celui par défaut de CertCentral.
  • Restreindre la validation au domaine de base uniquement
    Cette option vous permet de restreindre la validation du domaine au domaine de base (par exemple, exemple.com). Pour les demandes qui incluent de nouveaux sous-domaines (par exemple, sub.exemple.com), nous n'acceptons la validation que pour le domaine de base (par exemple, exemple.com). La validation pour le sous-domaine (par exemple, sub.exemple.com) ne fonctionnera pas.

Pour configurer l'étendue de la validation de domaine pour votre compte, depuis le menu latéral, cliquez sur Settings > Preferences (Paramètres > Préférences). Sur la page Division Preference (Préférence de division), développez le menu Advanced Settings (Paramètres avancés). Dans la section Validation du contrôle de domaine (DCV), sous Domain Validation Scope (Étendue de la validation de domaine),, vous trouverez les nouveaux paramètres.

fix

Nous avons corrigé un bogue qui limitait à 10 le nombre maximum de SANS autorisés lors de la réémission de certificats SSL Wildcard et des commandes de nouveaux certificats.

Désormais, lors de la réémission ou de la commande d'un nouveau certificat SSL Wildcard, vous pouvez ajouter jusqu'à 250 SAN.

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 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 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: Méthodes de validation de contrôle de domaine (Domain Control Validation, DCV).