FAQ | SwissSign
Une spécialiste de la Poste Suisse pour la sécurité des données

Section générale

Questions fréquemment posées

Questions générales

Tous les clients qui ont obtenu leur solution MPKI avant le 4 août 2022 sont actuellement encore sur l’ancienne CA. Tous les clients de la boutique en ligne utilisent l’ancienne CA. L’ancienne CA utilise le domaine swisssign.net.

Les clients dont la MPKI a été mise en place après le 4 août 2022 utilisent la nouvelle solution SwissSign MPKI. La nouvelle CA utilise le domaine swisssign.ch.

Pour passer à la nouvelle CA de SwissSign, vous n’avez rien à faire. Vous serez automatiquement contacté par SwissSign et guidé dans votre migration vers la nouvelle solution MPKI. Si vous souhaitez passer plus tôt à la nouvelle MPKI de SwissSign, veuillez nous contacter à l’adresse [email protected] en indiquant en objet «Migration MPKI»

Vous trouverez la liste actuelle des pays avec des restrictions d’exportation ici: swisssign.com/fr/support/exportbeschraenkungen

Certificats intermédiaires

Chaque certificat d’utilisateur final SwissSign est signé par un certificat intermédiaire SwissSign. Le certificat intermédiaire est à son tour signé par le certificat Root. Pour qu’un certificat paraisse fiable, il est important que la chaîne complète de certificats figure, par exemple, sur le serveur web. Les systèmes d’exploitation et les applications incluent pratiquement tous le certificat Root, mais le ou les certificats intermédiaires doivent être installés. Soit le certificat final est téléchargé sur swisssign.net (ancienne CA de SwissSign) ou ra.swisssign.ch (nouvelle CA de SwissSign) avec la chaîne complète de certificats, soit le certificat intermédiaire est installé ultérieurement. 

Certificats Root

Chaque certificat d’utilisateur final SwissSign est signé par un certificat intermédiaire SwissSign. Le certificat intermédiaire est à son tour signé par le certificat Root. Pour qu’un certificat paraisse fiable, il est important que la chaîne complète de certificats figure, par exemple, sur le serveur web. Les systèmes d’exploitation et les applications incluent pratiquement tous le certificat Root. Il peut cependant être nécessaire d’installer les certificats Root pour certaines applications particulières. Soit le certificat final est téléchargé sur swisssign.net ou ra.swisssign.ch avec la chaîne complète de certificats, soit le certificat Root est installé ultérieurement. 

Le certificat Root constitue la clé de voûte d’une PKI. L’utilisation d’un certificat Root implique que l’instance utilisateur accepte tous les certificats délivrés par la CA correspondante.

Pour plus d’informations sur l’utilisation de la CA, l’organisation, les fonctions, les méthodes et les processus, veuillez consulter la politique de certification (Certificate Policy – CP) et la déclaration des pratiques de certification (Certification Practice Statement – CPS) de SwissSign: Repository

Listes de révocation

Les certificats révoqués ou retirés sont publiés dans des listes de révocation ou conservés sur un service en ligne (OCSP) qui informe en ligne et en temps réel sur la validité d’un certificat.

L’un des services de validation les plus courants est la vérification de la validité d’un certificat via une liste de révocation de certificats (Certificate Revocation List – CRL) ou via un protocole de statut de certificat en ligne (Online Certificate Status Protocol – OCSP).

Comme dans le monde réel, il est également dangereux dans le monde numérique de perdre une clé ou de ne plus disposer d’une clé valable, par exemple à la suite du départ d’un collaborateur. C’est pourquoi il est régulièrement signalé que des clés/certificats doivent être révoqués afin d’éviter tout dommage. SwissSign – comme toute CA – publie ces clés/certificats dans ce que l’on appelle des «Certificate Revocation Lists» (CRL).

La CRL (liste de révocation ou liste de révocation de certificats) contient tous les numéros de série des certificats qui ont été invalidés avant l’expiration de leur durée de vie. Pour vérifier le statut de certificats, la liste est chargée à partir d’une URL publique et le numéro de série du certificat à vérifier est recherché dans cette liste: S’il figure dans la liste, le certificat est révoqué, sinon il est valide.

Les certificats révoqués ou invalidés restent inscrits dans la CRL même après la date d’expiration indiquée dans le certificat. Ceci est dû au fait qu’il est important de savoir quand un certificat a été révoqué pour la validation de la signature.

Les CRL sont généralement mises à jour à intervalles réguliers. Comme pour les certificats, la durée de vie des CRL est définie dans la CRL elle-même. Cette durée de vie est nettement plus longue que ne pourrait le suggérer la fréquence d’émission (au moins 2 fois par jour). Cela permet également de couvrir le risque de «défaut majeur». Les CRL peuvent être mises en cache localement et permettent de consulter hors ligne le statut d’un certificat. Ce faisant, le lien entre le titulaire du certificat et la Relying Party n’est pas révélé au CSP. Cependant, le degré d’imprécision de la consultation du statut d’un certificat est alors relativement élevé.

Le service de validation OCSP (Online Certificate Status Protocol), qui fonctionne en ligne, constitue une alternative plus précise. Il fournit des informations en temps réel sur la validité d’un certificat. Pour utiliser un OCSP, il est important que la CA soit très performante. La CA de SwissSign garantit cette haute performance et n’utilise également pour l’OCSP que son propre logiciel, développé en Suisse. Les vérifications de statut en ligne sont généralement utilisées lorsqu’il est important de vérifier la validité du certificat à un moment précis – p. ex. pour les transferts financiers.

 

Tous nos certificats CA Root et intermédiaires, ainsi que les listes de révocation (CRL) émises, peuvent être téléchargés sous le lien suivant: https://www.swisssign.com/fr/support/ca-prod.html.

Selon le CP/CPS, le fichier de liste de révocation de certificats (CRL) doit être mis à jour au moins toutes les 24 heures. Dans la pratique, SwissSign les met à jour plus fréquemment, et ce, sur une base horaire.

En principe, un fichier CRL est valable dix jours, c’est pourquoi il comporte la mention «Prochaine mise à jour ...» (date de création+dix jours). Cela est conditionné par la réglementation en cas de force majeure: dans ce cas, en cas de défaillance des systèmes, le fichier de liste de révocation devrait être à nouveau mis à jour au plus tard après dix jours.

Questions sur la délivrance, l’installation et le dépannage

Mon système d’exploitation ou mon application me signale des erreurs, et/ou je ne sais pas comment installer correctement le certificat.

SwissSign répertorie les problèmes connus et leurs solutions dans les FAQ et les documentations. Malheureusement, nous ne pouvons pas fournir d’assistance directe à ce sujet. La compétence principale de SwissSign AG est la création de certificats standardisés et fiables. Comme nous ne développons ni applications ni systèmes d’exploitation chez SwissSign, nous préférons nous abstenir de fournir une assistance pour les applications et les systèmes d’exploitation.

Toutefois, l’un de nos partenaires pourra peut-être vous aider avec son application: Partenaires SwissSign

Les certificats Root de SwissSign sont installés dans les navigateurs les plus courants. Mettez à jour votre navigateur avec la dernière version et installez les derniers certificats Root depuis la page de mise à jour de Windows. 

Vous trouverez des informations sur la compatibilité et la diffusion des certificats Root de SwissSign ici: Compatibilité | SwissSign

SwissSign vous permet de générer votre propre paire de clés – clé privée et clé publique – pour toutes les offres. La longueur minimale de la clé doit être de 2048 bits.

Il est également possible que votre serveur web n’envoie pas la chaîne de certificats complète aux clients. Pour résoudre ce problème, utilisez la fonction «SSLCertificateChainFile» dans la configuration d’Apache.

Avec les certificats SwissSign SSL, vous acquérez des licences de serveur illimitées. Contrairement à la plupart des autres certificats SSL, vous pouvez utiliser votre SwissSign SSL de manière illimitée.

Certificats avec clé privée (.p12, PKCS#12)*

*Cette méthode ne peut pas être utilisée pour les certificats SSL! 

Les formats .p12 ou PKCS#12 contiennent un certificat public et la clé privée (protégée par un mot de passe). Les fichiers .p12 ou PKCS#12 sont utilisés, par exemple, pour être installés dans des programmes de messagerie, des systèmes d’exploitation et des serveurs web.

Pour les serveurs web, la chaîne de certificats complète doit être installée. La CA qui délivre le certificat se fie généralement à une CA de niveau supérieur, qui se fie à son tour, par exemple, au certificat Root de SwissSign. Seul le certificat de la CA Root de SwissSign est reconnu par tous les navigateurs. Veuillez donc télécharger les certificats des CA intermédiaires sur la page de téléchargement et les installer également. Cela ne concerne que les personnes qui installent un serveur web et non les utilisateurs finaux.

Certificats sans clé privée

  • .cer: codé en DER ou BASE64
  • .crt: codé en DER ou BASE64
  • .pem: Certificat codé en Base64, entouré des mentions «-----BEGIN CERTIFICATE-----» et «-----END CERTIFICATE-----»
  • .p7b (chaîne de certificats): Certificats au format ASCII codé en Base64 (p. ex. pour les systèmes d’exploitation Windows, Java Tomcat)
  • .p7c (chaîne de certificats): Structure de données signée PKCS#7 sans contenu de données, comprenant uniquement le(s) certificat(s), y compris la chaîne de certificats complète (p. ex. pour les systèmes d’exploitation Windows, Java Tomcat)
  • .pem (chaîne de certificats): Certificat codé en Base64, y compris la chaîne de certificats complète (p. ex. pour Apache et les plateformes similaires)

Le format .pfx est équivalent au format .p12. Téléchargez le format .p12 et renommez l’extension du fichier en .pfx.

Si vous oubliez ou perdez le mot de passe de la clé privée, SwissSign ne peut malheureusement pas vous aider. Il est impossible de récupérer ou de réinitialiser le mot de passe. Il ne vous reste malheureusement pas d’autre choix que de demander un nouveau certificat et de bien conserver votre mot de passe.

  • Créez une CSR – une demande de certificat – sur le système Synology, ce qui crée également la paire de clés sur le serveur Synology.

  • Une fois le certificat délivré, téléchargez-le sur swisssign.net au format .pem. Tous les autres formats peuvent provoquer des messages d’erreur tels que: «L’encodage du fichier doit être enregistré en UTF-8».

  • Téléchargez également le certificat intermédiaire (type G22) depuis la page de téléchargement 

  • Vous pouvez maintenant charger sur le serveur Synology les fichiers «clé privée» (générés localement), ainsi que le certificat au format .pem et le certificat intermédiaire au format .perm.

Il existe deux raisons principales à cela:

  • Lors de la mise en place d’un cryptage SSL ou également dans les systèmes de messagerie électronique, il a été oublié d’installer un certificat intermédiaire. Voir la FAQ «Mon certificat ne fonctionne pas sur mon système d’exploitation ou mon navigateur, bien que SwissSign le prenne en charge».

  • Le client exploite dans son proxy ce que l’on appelle une «inspection SSL». Cette fonctionnalité brise la connexion cryptée et vérifie que la communication ne comporte pas de contenu non autorisé, voire de logiciels malveillants lors du téléchargement. L’inspection SSL fonctionne généralement avec des certificats propres non fiables. Ainsi, non seulement les sites avec des certificats SwissSign sont concernés, mais aussi d’autres sites. Pour y remédier, il suffit de reconfigurer le site en question dans le proxy.

Souvent, ces problèmes ne sont pas dus à des certificats Root manquants ou erronés dans les systèmes d’exploitation ou les navigateurs, mais au fait que l’installation d’un certificat intermédiaire a été oubliée lors de la configuration d’un cryptage SSL ou encore de systèmes de messagerie.

Les certificats sont classés de façon hiérarchique: Le certificat proprement dit se fie à un certificat intermédiaire, qui se fie éventuellement à un autre certificat intermédiaire, etc. Et enfin, les certificats intermédiaires se fient à leur tour aux certificats Root répertoriés dans les navigateurs et les systèmes d’exploitation. Comme les navigateurs et les systèmes d’exploitation ne contiennent que les certificats Racine, la chaîne de confiance est rompue en l’absence de certificats intermédiaires.

Dans l’environnement Windows, ces problèmes sont plus rares, car Microsoft Windows ou les navigateurs Windows tentent de mettre en cache les certificats intermédiaires dès qu’une page a été consultée une fois, p. ex. avec l’installation correcte d’un certificat SwissSign. Cette mise en cache est ensuite automatiquement utilisée si le certificat intermédiaire n’a pas été installé correctement, et l’utilisateur ne se rend alors pas compte de l’«erreur».

Sous Linux, en revanche, ce manque de configuration se remarque immédiatement. Pour y remédier, il suffit de télécharger la chaîne de certificats complète et de l’installer, avec les certificats intermédiaires:

Instructions pour l’ancienne CA (swisssign.net):

  • Pour ce faire, ouvrez le lien que vous avez reçu lors de la délivrance du certificat afin de télécharger les certificats. Vous pouvez également rechercher votre certificat sur swisssign.net et cliquer sur le bouton «Télécharger».
  • Dans les formats de téléchargement proposés, choisissez le fichier avec l’extension .p7c ou .pem (chaîne de certificats complète). Tous les autres téléchargements – y compris le fichier .p12 – ne contiennent pas les certificats intermédiaires.

Instructions pour la nouvelle CA (ra.swisssign.ch):

  • Pour ce faire, ouvrez le lien que vous avez reçu lors de la délivrance du certificat afin de télécharger les certificats. Vous pouvez également rechercher votre certificat sur ra.swisssign.ch, menu «Commandes et certificats».
  • Vous avez alors la possibilité de télécharger le certificat:
    • Au format PEM ou base64
    • Directement au format DER
    • En tant que chaîne de certificats (format PKCS#7)

Exploitation et assistance

Avant qu’un certificat SSL puisse être délivré, une paire de clés et une requête technique de certificat (Certificate Signing Request – CSR) doivent être créées.   

Il existe différents outils pour convertir un format. Par exemple, le visualiseur de certificats de Windows permet d’enregistrer un certificat dans les formats suivants:

  • Directement au format binaire (DER – «Distinguished Encoding Rules»)
  • Au format de fichier texte encodé (Base64 ou PEM – «Privacy Enhanced Mail»)
  • Au format PKCS#7 (p7b ou CMS – «Cryptographic Message Syntax»)

Modification et prolongation de certificats

Conformément à la réglementation, SwissSign est tenu de revalider régulièrement les attributs actifs du certificat. Si une différence est constatée entre les attributs du certificat et le registre officiel, SwissSign est tenue d'adapter ces données dans le certificat. 

De son côté, le titulaire du certificat est tenu d'annoncer spontanément à SwissSign tous les changements d'adresse ou de nom d'organisation dans un délai de trois jours ouvrables. Il a en outre l'obligation de révoquer les certificats délivrés de manière erronée dans un délai de 120 heures.

La révocation est le processus qui rend un certificat invalide ou le bloque. Les certificats révoqués figurent sur des listes de révocation appelées Certificate Revocation Lists (CRL).

Si un certificat de cryptage est révoqué, il est très important que vous conserviez tout de même la clé privée correspondante. Elle vous sera indispensable pour décrypter les données que vous avez codées avec cet ancien certificat ou ce certificat révoqué.

Si un certificat de signature est révoqué, vous pouvez détruire la clé privée, car vous ne pourrez plus l’utiliser pour une signature numérique valable.

Raisons qui peuvent entraîner la révocation ou la nullité d’un certificat:

  •  L’utilisateur a oublié le mot de passe de sa clé privée.
  •  La clé est corrompue.
  •  Les indications fournies dans le certificat ne sont plus valables (par exemple, l’adresse e-mail ou le fait que vous ne fassiez plus partie de l’organisation).

Les certificats SwissSign peuvent être révoqués de différentes manières:

Pour les clients de la boutique en ligne et les clients qui utilisent l’ancienne MPKI:

  1. Révocation en ligne: possible si vous avez demandé le certificat via un compte utilisateur technique sur swisssign.net. 

  2. Révocation en ligne: vous pouvez révoquer des certificats en ligne sur swisssign.net si vous possédez encore la clé privée ou le code nécessaire à cet effet. Vous avez reçu le code dans l’e-mail d’approbation de ce certificat. Veuillez consulter la page swisssign.net et entrer dans le champ de recherche «Licence» votre numéro de licence pour le certificat que vous avez reçu lors de votre achat. Le certificat est affiché. Vous pouvez maintenant révoquer le certificat avec le code de révocation de l’e-mail d’approbation en cliquant sur le bouton «Révoquer». 

  3. Révocation hors ligne: Vous pouvez également demander à SwissSign de procéder à la révocation. Pour cela, le formulaire de révocation hors ligne est à votre disposition. Veuillez noter que ce service est payant.

Pour les clients qui utilisent la nouvelle solution CA/MPKI de SwissSign

  1. Révocation en ligne: Si vous avez demandé votre certificat sur ra.swisssign,ch, vous pouvez le révoquer directement dans la MPKI. Veuillez suivre la procédure décrite dans le manuel des opérateurs RA.

  2. Révocation hors ligne: Vous pouvez également demander à SwissSign de procéder à la révocation. Pour cela, le formulaire de révocation hors ligne est à votre disposition. Veuillez noter que ce service est payant.

Les deux.

Il n’est pas possible de révoquer provisoirement ou temporairement un certificat (ce que l’on appelle aussi une suspension).

Certificats SSL et e-mail: Oui, ils sont supprimés de la CRL après leur expiration.

Certificats de signature: Non, ils sont conservés dans la CRL même après leur expiration, afin de garantir également la vérification ultérieure d’une signature. 

Non, d’un point de vue technique, le certificat doit être délivré de nouveau en cas de modification du contenu.

Oui, vous recevrez une notification par e-mail 30 jours avant l'expiration de votre certificat SwissSign.

Vous aurez besoin de la clé privée correspondante pour les décrypter. Assurez-vous que votre ancien certificat de cryptage est toujours importé dans votre navigateur. Il s’agit de la seule façon de décrypter les données qui ont été cryptées avec votre ancien certificat.

Si le certificat ne figure plus dans votre navigateur, connectez-vous à votre profil SwissSign et téléchargez-le à nouveau. Pour ce faire, vous aurez besoin du mot de passe à 16 caractères que vous avez saisi lors de la création du certificat.

Il n’est en principe pas possible de prolonger un certificat. Lorsqu’un certificat est délivré, une durée fixe lui est attribuée. Vous devez donc demander un nouveau certificat après l’expiration. Nous devons alors vérifier si le contenu du certificat souhaité est toujours valable.

Questions générales sur les certificats numériques

Dans le monde électronique, la notion de fiabilité revêt une nouvelle dimension. Les utilisateurs doivent être en mesure d’identifier clairement le partenaire de communication.

Un certificat numérique ou électronique (Certificate) est une attestation électronique qui associe une clé de vérification de signature au nom d’une personne, d’une organisation ou d’un serveur. Autrement dit: Un certificat est une «carte d’identité électronique» non modifiable que l’utilisateur peut utiliser pour l’identification et/ou le cryptage sur Internet.

Identification: Les certificats sont utilisés:

  •  Pour identifier l’émetteur d’informations
  •  Pour identifier le serveur auquel un utilisateur se connecte
  •  Pour identifier l’utilisateur qui se connecte à un serveur

Cryptage: Les certificats numériques contiennent la clé publique du titulaire du certificat. Celle-ci peut être utilisée par son interlocuteur pour crypter un e-mail ou un document envoyé par Internet.

Les certificats jouent également un rôle important dans les transactions web sécurisées telles que https (certificats SSL)

Il existe différents types de certificats numériques. L’ensemble minimal contient les éléments suivants:

  • La clé publique du titulaire du certificat (personne, ordinateur/machine ou organisation)

  • Informations sur le titulaire du certificat

  • Informations sur l’émetteur du certificat, c’est-à-dire la CA ou l’organisation qui a délivré le certificat.

  • Signature numérique de ce certificat par l’émetteur.

  • Date de livraison et d’expiration du certificat

  • Numéro de série du certificat

  • Les certificats de SwissSign contiennent en outre des informations sur le CP et le CPS.

L’utilisation de certificats vous garantit sécurité, protection des données et fiabilité. Les certificats sont utilisés dans différentes applications. Par exemple, pour les messageries électroniques sécurisées, l’e-business, l’e-gouvernement, l’e-santé, etc. 

Pour en savoir plus, consultez notre page web dédiée à nos partenaires de solution.

La clé publique est une méthode cryptographique asymétrique qui utilise une paire de clés. Cette paire de clés cryptographiques se compose d’une clé publique et d’une clé privée. Les données cryptées avec l’une de ces clés ne peuvent être décryptées qu’avec l’autre clé. Cette méthode cryptographique peut alors être utilisée aussi bien pour le cryptage que pour les signatures techniques.

Dans le cas du cryptage, les données sont cryptées pour le destinataire avec la clé publique (Public Key, clé dans le certificat) et ne peuvent plus être décryptées qu’avec la clé privée (Private Key) correspondante.

Dans le cas de la signature technique, les données sont cryptées pour le destinataire à l’aide de la clé privée de l’émetteur et peuvent ensuite être vérifiées par le destinataire à l’aide de la clé publique.

La clé publique est accessible au public via le certificat. Cette clé est utilisée pour crypter des données ou pour confirmer la signature numérique du signataire (identification). Les données cryptées avec la clé publique ne peuvent être décryptées qu’avec la clé privée correspondante.

La clé privée n’est connue que du titulaire du certificat et ne doit être accessible qu’à lui. Elle est utilisée pour le décryptage des données et la création d’une signature numérique.

Le certificat contient une entrée «Key Usage». Ce champ définit l’utilisation prévue pour le certificat. Les entrées possibles pour la Key Usage sont: Signature numérique, Non-Repudiation/Content-Commitment (non-répudiation/engagement sur le contenu), Key Agreement (accord sur la clé), cryptage et/ou cryptage des données.

Chaque certificat numérique passe par le cycle de vie suivant:

  • Demande de certificat: Un utilisateur demande un certificat.

  • Vérification de la demande: L’autorité d’enregistrement (Registration Authority – RA) vérifie l’identité de l’utilisateur/demandeur.

  • Génération/délivrance du certificat: L’autorité de certification (Certificate Authority – CA) délivre le certificat. Ce certificat contient des informations sur le titulaire, l’émetteur, l’utilisation autorisée et sa durée de vie (valable du et valable jusqu’au).

  • Révocation/invalidation: Le certificat est révoqué ou invalidé avant son expiration.

  • Fin de la durée de vie du certificat: La durée de vie du certificat a expiré.

  • Renouvellement du certificat, aussi appelé «certificate renewal» ou «rekey».

La confiance est le principe fondamental de tout modèle de sécurité. C’est également le cas pour l’infrastructure à clés publiques (Public Key Infrastructure – PKI). Pour pouvoir travailler avec des certificats, vous devez avoir confiance dans la CA qui a délivré le certificat.

Les PKI sont toujours organisées de manière hiérarchique. Le niveau supérieur de la hiérarchie (Root ou racine) doit être expressément inscrit comme étant digne de confiance, de sorte que le contenu du certificat Root correspondant (certificat racine) soit digne de confiance.

Les certificats Root de SwissSign sont reconnus comme étant dignes de confiance, c’est-à-dire qu’ils sont inscrits, entre autres, dans les Root Trust Stores suivants: Microsoft, Mozilla (NSS) et Apple OS X. Vous trouverez ci-joint la diffusion des certificats Root de SwissSign.

L’utilisateur final de ces applications verra donc les certificats SwissSign comme étant dignes de confiance. Ainsi, dès que le certificat Root d’une PKI est classé comme digne de confiance, chaque sous-certificat de cette souche hiérarchique peut être vérifié en toute sécurité.

Faire confiance à une CA comme SwissSign signifie en outre faire confiance aux différents processus appartenant à la PKI, comme l’enregistrement des utilisateurs ou la validation des certificats (CRL, OCSP). La Certificate Policy et les Certification Practice Statements (CP/CPS) apportent de la transparence dans les processus et aident à renforcer la confiance. Vous établissez ainsi votre confiance dans la CA de SwissSign en lisant les CP/CPS correspondantes. SwissSign est par ailleurs un fournisseur de services de certification (Certification Service Provider – CSP) qualifié au regard du droit suisse, qui satisfait aux exigences de la loi fédérale suisse sur la signature électronique (SCSE). La SCSE répond quant à elle aux normes internationales les plus strictes dans ce domaine.

Enfin, importez également les certificats Root de SwissSign correspondants dans vos programmes afin d’établir la relation de confiance.

Une infrastructure à clés publiques (Public Key Infrastructure – PKI) est une infrastructure/un environnement dans lequel diverses applications et fonctions sont exécutées à l’aide de clés cryptographiques (publiques et privées) et de certificats. Ces applications vont des contrôles d’accès aux applications de messagerie sécurisées, en passant par différents types d’informations signées numériquement en relation avec la CA ou la RA.

Une autorité de certification (Certificate Authority – CA) est un fournisseur de services de certification ou un organisme de certification – aussi appelé «tiers de confiance» (Trusted Third Party). On parle parfois aussi de fournisseur de services de certification (Certification Service Provider – CSP).

SwissSign est une CA – une autorité qui confirme des données de personnes, d’organisations ou de machines dans le cadre d’un environnement électronique et qui délivre des certificats numériques à cette fin.

Une autorité d’enregistrement (Registration Authority – RA) est un service de SwissSign qui consiste à vérifier l’identité et, si nécessaire, les attributs de chaque demandeur de certificat avant que la CA ne génère le certificat correspondant ou n’attribue les données permettant d’activer l’utilisation de la clé de signature.

La politique de certification (Certificate Policy – CP) est un document du fournisseur de services de certification (CSP) qui décrit les règles applicables à un type de certificat («ce qui doit être accompli»). Elle englobe l’ensemble des règles qui prescrivent l’applicabilité d’un certificat à un groupe particulier de personnes et/ou à une classe d’applications spécifiques présentant des exigences de sécurité communes. Elle permet aux tiers d’analyser la fiabilité.

La déclaration des pratiques de certification (Certificate Practice Statement – CPS) fournit des informations sur les pratiques de certification, c’est-à-dire sur la manière dont les exigences sont mises en œuvre.

La CP et la CPS constituent la base légale régissant la relation entre les titulaires de certificats et SwissSign.

Vous trouverez ces documents dans le SwissSign Repository.

Les éditeurs de navigateurs, de systèmes d’exploitation, de clients de messagerie et d’autres logiciels qui évaluent les certificats doivent tenir à jour un programme dans lequel ils administrent les CSP qu’ils recommandent à leurs clients comme étant des CSP de confiance (programme Rootstore).

La gestion de son propre programme Rootstore est complexe. Elle consiste à gérer les documents d’exigences et les CSP enregistrés. C’est pourquoi le CA Browser Forum se charge de la gestion des documents d’exigences minimales. Ce comité réunit les gestionnaires de programmes Rootstore (éditeurs de logiciels) et les CSP, qui élaborent et gèrent ensemble les documents d’exigences.

Aujourd’hui, de plus en plus de programmes Rootstore sont basés sur les «Baseline Requirements» du CA Browser Forum. www.cabforum.org

La procédure de sécurité «Certificate Transparency» (CT) vise à identifier les organismes de certification qui ne remplissent pas leurs fonctions correctement et à les exclure des communications sécurisées sur Internet. Promue par Google Chrome, cette procédure est une pierre angulaire de la sécurité sur Internet, dans la mesure où elle permet de garantir la fiabilité des communications.

L’idée sous-jacente est la suivante: Tous les certificats utilisés pour les communications Internet sécurisées doivent être enregistrés dans un système de journaux protégé par des moyens cryptographiques et gérés par au moins 3 serveurs de journaux centraux répartis dans le monde entier. Les modifications apportées après coup, les enregistrements suspects et non autorisés, les faux certificats, les ajouts ou autres manipulations d’un certificat enregistré une fois sont ainsi exclus ou sont immédiatement détectés par chaque navigateur.

SwissSign appuie pleinement le principe de Certificate Transparency avec ses certificats SSL.

Dans la CP/CPS correspondante de l’émetteur, vous pouvez lire avec quelle qualité le titulaire du certificat (expéditeur) a été identifié par l’émetteur. Ainsi, l’authenticité de l’expéditeur est assurée par une signature valide et digne de confiance. Une méfiance de bon aloi est toutefois de mise vis-à-vis des expéditeurs inconnus, surtout si l’éditeur de la signature est lui aussi inconnu.

Les e-mails sont cryptés avec la clé publique (Public Key) du destinataire et décryptés avec la clé privée (Private Key) du destinataire. La signature est effectuée avec le certificat.

  • Il peut arriver qu’un certificat ou le mot de passe de la clé privée soit perdu. Les e-mails cryptés avec ce certificat ne peuvent alors plus jamais être lus par qui que ce soit.

  • Il arrive aussi que des certificats soient renouvelés, mais que l’on oublie d’installer aussi l’ancien certificat qui a expiré. Tous les anciens e-mails conservés ne peuvent alors plus être lus. Accès après l’expiration du certificat

  • Un collaborateur quitte l’entreprise ou est absent pendant une période prolongée. Ses e-mails ne peuvent plus être lus par quelqu’un d’autre.

  • Un virus ou un cheval de Troie est envoyé avec un e-mail crypté. Aucun programme antivirus n’est en mesure d’analyser un e-mail crypté, le virus ou le cheval de Troie peut donc s’infiltrer en toute impunité. Ainsi, le cryptage peut même présenter un risque de sécurité dans ce cas.

Le certificat SSL avec ses clés asymétriques n’est utilisé que pour l’identification univoque et sécurisée du serveur, à des fins d’authentification mutuelle. Dans les applications traditionnelles, le certificat est également utilisé pour le cryptage.

La délivrance de certificats est régie par la norme RFC 5280. La norme la plus récente stipule que le nom de l’expéditeur doit figurer dans le Subject Distinguished Name et dans le Subject Alternative Name (SAN). La plupart des applications de messagerie présentes sur le marché accordent une attention particulière à ce dernier. Le placement de l’adresse e-mail dans l’attribut emailAddress du Subject distinguished Name est obsolète et n’est plus utilisé par SwissSign.

RFC signifie «Request for Comments» (demande de commentaires). Les RFC sont une série de documents techniques et organisationnels de l’éditeur RFC qui sont généralement et internationalement acceptés comme normes internet. Le système RFC a été lancé dès 1969.

Pour plus d’informations, voir www.rfc-editor.org.

Questions sur les certificats SSL

La Certification Authority Authorization (CAA) est une norme internet publiée en 2013 sous la référence RFC 6844.

Les noms de domaine sont répertoriés, à la manière d’un grand annuaire téléphonique, dans un registre de noms répartis dans le monde entier, appelé Domain Name Service ou DNS en abrégé. Une page web avec un nom accrocheur, comme www.swisssign.com est convertie par ce service en une adresse internet, telle que «46.175.9.80», et est ainsi accessible pour différents services internet, par exemple un navigateur. Outre cette conversion, le Domain Name Service permet de fournir diverses informations supplémentaires, telles que le nom et l’adresse du propriétaire d’un site web.

Grâce à la norme CAA, d’autres informations sont désormais enregistrées pour ces domaines: Il est enregistré quelle autorité de certification peut délivrer un certificat pour le domaine mentionné. Si aucun organisme de certification n’est enregistré, n’importe qui peut délivrer un certificat, mais dans le cas contraire, un organisme de certification ne peut pas délivrer de certificat pour le domaine si son nom n’y est pas mentionné.

La CAA est une procédure qui permet au propriétaire du domaine de déterminer quelle CA peut délivrer des certificats pour son domaine.  Pour ce faire, un enregistrement CAA, appelé «CAA record», est enregistré dans le DNS. Depuis septembre 2017, SwissSign vérifie tous les domaines avant de délivrer des certificats pour voir s’ils présentent une restriction dans leur CAA record. Les domaines soumis à une restriction d’accepter des certificats d’organismes de certification autres que SwissSign ne sont pas acceptés dans le certificat. La demande de certificat est alors rejetée. Si aucune restriction n’a été placée ou que le CAA record autorise SwissSign, le certificat est approuvé.

Le configurateur CAA vous aide à trouver le réglage exact pour votre site web.

Voici quelques exemples en fonction de la technologie DNS utilisée:

Autorisation pour SwissSign de délivrer des certificats

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue "swisssign.com"

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 20 0005697373756573776973737369676E2E636F6D

Autorisation pour SwissSign de délivrer des certificats non-Wildcard

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue "swisssign.com"

example.com.     IN       CAA      0 issuewild ";"

 Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 20 0005697373756573776973737369676E2E636F6D

example.com.     IN       TYPE257  \# 12 0009697373756577696C643B

Autorisation pour SwissSign de délivrer des certificats Wildcard

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue ";"

example.com.     IN       CAA      0 issuewild "swisssign.com"

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 8 000569737375653B

example.com.     IN       TYPE257  \# 24 0009697373756577696C6473776973737369676E2E636F6D

Malheureusement non, puisque vous n’êtes pas propriétaire du domaine dyndns.ch ou dyndns.org comme indiqué sur www.whois.ch et que DynDNS ne procède pas à des validations de domaine, il sera difficile d’obtenir une confirmation du propriétaire qui soit également vérifiable.

Oui, c’est possible. Pour obtenir un certificat SSL Gold EV, les associations doivent aussi fournir un numéro de registre.

En Suisse, les associations peuvent, à l’instar des entreprises, demander un numéro d’identification d’entreprise (IDE). Celui-ci ne doit pas être confondu avec le numéro de TVA intracommunautaire de l’UE (EU-UID). Les associations dont le chiffre d’affaires annuel est inférieur à CHF 150 000.– sont certes exonérées de la TVA, mais elles peuvent obtenir un numéro d’identification d’entreprise sur demande. Cet IDE doit être inscrit sur le certificat en guise de numéro de registre.

Les associations allemandes sont inscrites au registre des associations en tant qu’associations enregistrées et peuvent utiliser ce numéro.

SwissSign peut consulter les IDE suisses. Pour autant que vous n’ayez pas limité la visibilité de votre IDE, les données de votre association suffisent. Dans le cas contraire, veuillez nous fournir une confirmation IDE. Les associations étrangères sont priées de joindre un extrait de registre à titre de confirmation.

Le numéro d’identification des entreprises (IDE) remplace l’ancien numéro d’entreprise dans le registre du commerce.

L’Office fédéral de la statistique (OFS) attribue à chaque entreprise exerçant une activité économique en Suisse un numéro d’identification d’entreprise (IDE) unique et global. Celui-ci permet aux entreprises de s’identifier avec un seul et même numéro dans tous leurs échanges avec les autorités.

Depuis lors, les certificats SwissSign SSL Gold EV font référence à l’IDE.

Il existe trois types de certificats SSL:

  • Domaine unique: Utilisable uniquement pour un site web spécifique. Exemple: mywebsite.com.
  • Multidomaine: Utilisable pour plusieurs sites web/domaines. Exemple: mywebsite.com, yourwebsite.com, hiswebsite.ch.
  • Wildcard: Utilisable pour tout site web avec un nom de domaine défini. Exemple: db.mywebsite.com, mail.mywebsite.com, sap.mywebsite.com, etc.

Les certificats multidomaines sont souvent appelés UCC/SAN (Unified Communication Certificates/Subject Alternative Name), car ils sont prédestinés à être utilisés avec Exchange dans un environnement Microsoft. Dans le champ SAN du certificat, les certificats multidomaines et Wildcard comportent une entrée qui fait référence aux autres domaines ou à la Wildcard.

Les certificats multidomaines ou Wildcard sont très souvent utilisés en raison de leur prix attractif. Des copies du même certificat SwissSign peuvent être utilisées librement sur différents serveurs. Il est donc possible de sécuriser un environnement d’entreprise complet avec un même certificat Wildcard. Cela dit, les possibilités offertes par un certificat Wildcard sont certes très pratiques, mais peuvent aussi s’avérer risquées dans les grandes structures d’entreprise: Si une clé privée de ce certificat est compromise sur l’un des nombreux serveurs et qu’elle permet à un sitew eb frauduleux de se présenter en ligne avec votre nom de domaine en tant que «man-in-the-middle», cela risque de passer inaperçu et de causer des dommages importants. D’autant plus que ce site frauduleux est alors parfaitement protégé par un certificat de l’entreprise. C’est pourquoi les certificats Wildcard ne peuvent pas non plus être proposés avec la norme EV.

Les certificats multidomaines n’ont pas ce problème.

Mais en raison du grand nombre d’entrées SAN, le risque que le certificat multidomaine doive être remplacé prématurément est accru: Souvent, parmi les domaines, il y en a aussi qui ne vous appartiennent pas et pour lesquels une procuration a dû être établie lors de la délivrance. Si un domaine disparaît, le certificat n’est plus valable et tous les certificats multidomaines utilisés doivent être remplacés.

Comme pour toute décision, les avantages, les dangers et les risques doivent être évalués. Dans les petits environnements aisément maîtrisables ou pour une utilisation dans des environnements Microsoft UCC, il y a certainement de bonnes raisons d’utiliser ces certificats. Pour une utilisation spécifique dans un environnement Microsoft Exchange, veuillez consulter notre FAQ séparée «UCC/SAN – Wildcard ou multidomaine pour Microsoft Exchange»?

Non, cela n’est pas autorisé par la RFC 2818.

Nous vous recommandons donc d’acheter deux certificats SSL Wildcard : un pour *.mydomain.com et un pour *.sub2.mydomain.com. Il n’est pas non plus possible de spécifier différents Alternative Names (SAN) avec les certificats SSL Wildcard de SwissSign.

Die alte CA-Plattform bietet die Möglichkeit, neben der Wildcard-Domain (z.B. «*.swisssign.com») auch die «Base Domain» (z.B. «swisssign.com») aufzunehmen. Die neue CA-Plattform bietet diese Möglichkeit auch, gehen Sie dazu während eines Beantragungs-Vorgangs für ein Wildcard-Zertifikate wie folgt vor:

  • Klicken Sie unter dem Absatz «DNS» den Button «+Element hinzufügen»
  • Geben Sie im Feld «DNS1*» den Wildcard-Eintrag ein, also z.B. «*.swisssign.com»
  • Geben Sie im Feld «DNS2*» den Base-Domain-Eintrag ein, also z.B. «swisssign.com»
  • Fahren Sie wie üblich mit dem Ausstellungsprozess fort.

Questions sur les certificats e-mail

En principe, il est possible d’acheter un certificat e-mail pour un compte d’équipe. Cependant, cela reste un certificat personnel et nécessite la désignation d’un responsable de clé.

Les règles du CP et du CPS s’appliquent ici. Ces règles sont les suivantes:

  • Si le certificat a été acheté en tant que certificat Gold, la désignation "pseudo:" doit être utilisée à la place du prénom et du nom (certificat pseudonyme). Exemple: pseudo: Sales Team

  • Pour les certificats Silver, qui ne sont validés que par e-mail, n’importe quelle adresse e-mail peut être certifiée, à condition qu’il soit vérifié que cette adresse e-mail existe.

Le cryptage de l’e-mail est effectué à l’aide du certificat du destinataire. Il est donc nécessaire que l’expéditeur obtienne le certificat du destinataire. Cela peut se faire manuellement ou en utilisant une passerelle de messagerie sécurisée (Secure Mail Gateway) qui collecte les certificats des e-mails entrants.

Les e-mails sont cryptés avec la clé publique (Public Key) du destinataire et décryptés avec la clé privée (Private Key) du destinataire. La signature est effectuée avec le certificat.

  • Il peut arriver qu’un certificat ou le mot de passe de la clé privée soit perdu. Les e-mails cryptés avec ce certificat ne peuvent alors plus jamais être lus par qui que ce soit.

  • Il arrive aussi que des certificats soient renouvelés, mais que l’on oublie d’installer aussi l’ancien certificat qui a expiré. Tous les anciens e-mails conservés ne peuvent alors plus être lus. Accès après l’expiration du certificat

  • Un collaborateur quitte l’entreprise ou est absent pendant une période prolongée. Ses e-mails ne peuvent plus être lus par quelqu’un d’autre.

  • Un virus ou un cheval de Troie est envoyé avec un e-mail crypté. Aucun programme antivirus n’est en mesure d’analyser un e-mail crypté, le virus ou le cheval de Troie peut donc s’infiltrer en toute impunité. Ainsi, le cryptage peut même présenter un risque de sécurité dans ce cas.

La signature numérique d’un e-mail signé est envoyée en tant que pièce jointe. Cette pièce jointe est automatiquement vérifiée par le programme de messagerie du destinataire. Cependant, la plupart des fournisseurs de webmail, tels que Gmail ou Hotmail, affichent la signature uniquement en tant que pièce jointe avec le nom de fichier smime.p7s, sans procéder à une vérification de la signature.

Le client de messagerie considère que l’émetteur du certificat n’est pas fiable. Cela peut être corrigé en désignant l’émetteur comme étant digne de confiance. En général, les éditeurs de ces programmes se chargent de cette tâche via leurs programmes Rootstore.

En désignant l’émetteur SwissSign comme Root de confiance. Cela signifie que vous répondez par Oui à la question «Souhaitez-vous faire confiance à l’éditeur?». Si vous utilisez un PC d’entreprise, nous vous prions de vous adresser à votre service d’assistance informatique.

Très souvent, nos clients ont besoin d’un certificat pour s’authentifier (se connecter) sur un site web.

Le certificat Pro S/MIME Email ID Gold avec authentification est prévu pour une telle authentification de client TLS-WWW. Il peut également être utilisé pour le cryptage et la signature d’e-mails.

Questions sur le Managed PKI Service de SwissSign

Veuillez suivre les indications données sur la page web suivante: Managed PKI Service | SwissSign

Pour accéder à votre nouvelle MPKI, vous avez besoin d’un identifiant SwissID avec l’autorisation à deux facteurs correspondante.

Veuillez noter que vous devez impérativement utiliser pour cet identifiant l’adresse e-mail que vous avez renseignée dans les documents de commande de votre MPKI.

Vous trouverez sur cette page des instructions étape par étape sur la création de votre SwissID. 

Assurez-vous d’avoir effectué l’onboarding sur le SwissID comme indiqué dans les étapes ici.

Assurez-vous que le SwissID a été enregistré avec la même adresse e-mail que celle renseignée dans les documents contractuels sous la rubrique «Opérateurs RA».

Le cas échéant, votre identification a été transmise à notre back-office pour une vérification manuelle. Vous recevrez un e-mail dès que le processus d’identification aura été effectué avec succès.

Oui, c’est possible. Envoyez-nous le contrat scanné et, si nécessaire, signé, ainsi que les documents de demande complets à l’adresse [email protected]

Vous pouvez également nous envoyer votre commande par courrier postal comme auparavant:

SwissSign AG
Sales & Partner Management
Sägereistrasse 25
8152 Glattbrugg Suisse

SwissSign vous confirmera la réception de votre commande par e-mail.

L’envoi du document «Contrat et commande Managed PKI Services» est considéré comme une commande ferme d’un service payant. La durée du contrat et la période de facturation commencent à courir à la date de la commande.

La période de prestation d’une Managed PKI est toujours d’un an et est reconduite automatiquement pour un an si le contrat n’est pas résilié. En cas de résiliation du contrat, les certificats encore actifs sont retirés (révoqués) à la date de résiliation.

Spécifications des domaines

Les domaines SSL ou e-mail sont spécifiés sans être associés à un type de certificat particulier. Cela signifie que vous pouvez par la suite émettre n’importe quel certificat SSL que vous avez commandé pour tous les domaines SSL mentionnés. De même, les certificats E-Mail ID commandés peuvent être émis pour tous les domaines de messagerie mentionnés.

Autorisation d’accès au domaine

Vous prouvez votre droit d’accès en publiant une Random value (secrète) (dans le DNS), que vous obtenez via l’accès MPKI.

Publication de certificats

SwissSign tient à jour sur www.swisssign.net et directory.swisssign.ch un répertoire général de tous les certificats E-Mail ID publiés (LDAP). Ce répertoire est public et comparable à un annuaire téléphonique. Cela est particulièrement intéressant pour une communication par e-mail cryptée, dans la mesure où votre interlocuteur peut utiliser votre clé publique contenue dans le certificat pour crypter les messages qu’il vous adresse.

Le répertoire public peut également être intégré directement dans les programmes de messagerie électronique par la saisie de paramètres, afin d’effectuer le cryptage dans les programmes de messagerie électronique par récupération automatique des certificats.

Si vous ne souhaitez pas que vos certificats figurent dans le répertoire, sélectionnez la case d’option «Je ne souhaite pas que mes certificats soient publiés». Vous pouvez également faire modifier ce paramètre ultérieurement moyennant des frais de CHF 150.– ou € 135.–.

Pour l’ancienne CA, les paramètres LDAP sont les suivants:

  • Répertoire: directory.swisssign.net.
  • Base de recherche: ‹o=SwissSign,c=CH›.

Pour la nouvelle CA, les paramètres LDAP sont les suivants:

  • Répertoire: directory.swisssign.ch.
  • Base de recherche: ‹o=SwissSign AG,c=CH›.

Certificats SSL DV Silver

Les certificats de niveau DV/Silver sont indiqués comme ayant une validation de domaine. Seule l’adresse e-mail ou du serveur web est inscrite dans le certificat. Ils peuvent également contenir le nom de l’organisation. Le cryptage et la signature sont possibles pour les certificats e-mail, mais pas l’authentification. Les certificats de niveau DV sont inclus dans les produits MPKI DV, OV et EV.


Certificats OV SSL Gold

Les certificats de niveau OV/Gold sont indiqués comme ayant une validation d’organisation ou une validation de personne. Le certificat comporte une entrée d’organisation et, pour les certificats e-mail (S/MIME), une entrée de personne. Les certificats de niveau OV sont inclus dans les produits MPKI OV et EV.


Certificats EV SSL Gold

Vous pouvez également émettre des certificats EV SSL Gold pour votre entreprise dans le cadre de la Managed PKI. Ceux-ci sont validés de manière approfondie par l’organisation. Les certificats de niveau EV sont inclus dans le produit MPKI EV.

Veuillez noter que les certificats avec inscription d’organisation doivent toujours faire l’objet d’une commande/déclaration d’acceptation distincte.

Problèmes de connexion à votre service SwissSign Managed PKI

Pour accéder à votre MPKI, votre SwissID doit être élevée à un niveau de confiance supérieur. Pour savoir comment procéder, cliquez sur le lien suivant, qui vous aidera à vérifier votre identité étape par étape :

https://www.swisssign.com/fr/support/dokumentationen/ra-operator-onboarding.html

La création d'un compte SwissID ne prend que quelques minutes. Il est important qu'en tant qu'opérateur MPKI, vous utilisiez toujours l'adresse e-mail qui a été enregistrée dans la commande MPKI dans la section "Opérateurs RA". Ensuite, veuillez suivre les instructions étape par étape sous le lien suivant :

https://www.swisssign.com/fr/support/dokumentationen/ra-operator-onboarding.html

Si vous ne pouvez soudainement plus vous connecter à votre MPKI en tant qu'opérateur MPKI, cela peut être lié au fait que la dernière vérification de votre identité a eu lieu il y a plus d'un an et qu'une ré-identification est donc nécessaire. Veuillez noter que vous n'avez pas besoin de créer un nouveau compte SwissID et que vous pouvez commencer à vous identifier directement sur l'application SwissID. Commencez directement au chapitre 2 des instructions étape par étape en cliquant sur le lien suivant :

https://www.swisssign.com/fr/support/dokumentationen/ra-operator-onboarding.html

Questions sur l’obtention d’un certificat dans la boutique en ligne

Les délais indiqués s’appliquent à partir de la réception des documents de demande et ne peuvent être respectés que si tous les documents ont été entièrement et correctement établis.

Délai de délivrance pour les certificats SSL

  • DV SSL Silver (domaine unique et Wildcard): quelques minutes
  • OV SSL Gold (domaine unique, multidomaine et Wildcard): jusqu’à 2 jours ouvrables
  • EV SSL Gold EV (domaine unique et multidomaine): 5 à 10 jours ouvrables

Délai de délivrance pour les certificats S/MIME Email ID

  • Personal S/MIME E-Mail ID Silver: quelques minutes

Si vous souhaitez à l’avenir obtenir vos certificats plus rapidement en cas de besoin, nous vous recommandons nos services MPKI.
 

Après avoir acheté vos certificats dans la boutique en ligne swisssign.com, veuillez suivre la procédure suivante pour les obtenir:

  • Connectez-vous à votre compte utilisateur.

  • Cliquez sur «Certificats» et lancez l’activation du certificat souhaité en cliquant sur «Émettre» après l'entrée correspondante.

  • Vous accédez maintenant à la demande technique de votre certificat. Suivez à cet effet les instructions du processus de demande.

  • Une fois votre demande vérifiée et acceptée, vous recevrez un e-mail contenant le lien pour télécharger votre certificat.

  1. Connectez-vous à votre compte utilisateur de la boutique en ligne sur swisssign.com.

  2. Dans l’onglet «Certificats», ouvrez l’entrée souhaitée.

  3. Les codes s’affichent. Cliquez sur «Partager» pour copier le lien correspondant.

  4. Partagez le lien avec l’autre personne.

  5. L’autre personne peut maintenant utiliser ce lien pour procéder directement à la demande technique du certificat. Elle n’a pas besoin d’un compte sur la boutique pour cela.

Vous pouvez saisir les anciens codes de licence sur la page web d’enrôlement: portal.shop.swisssign.com/enrollment

Les standards de sécurité élevés appliqués dans le commerce de certificats exigent que vous obteniez à nouveau les signatures des personnes autorisées en cas de nouvelle demande de certificat et que vous nous les fassiez parvenir avec les copies correspondantes des cartes d’identité/passeports.

Pour simplifier le processus en cas d’achat multiple de certificats, vous pouvez demander aux responsables de votre organisation de vous donner procuration: Formulaire de procuration (PDF, 106 KB). Veuillez mentionner cette procuration lors de chaque commande ou en joindre une copie.

Vous avez régulièrement besoin de certificats? Dans ce cas, notre service de certificats Managed PKI vous permet de bénéficier de rabais sur le volume intéressants.

Veuillez contacter notre service clientèle.

  1. Connectez-vous à swisssign.com.

  2. Recherchez la demande correspondante dans votre compte.

  3. Réimprimez le formulaire.

Pour révoquer votre certificat de notre boutique en ligne, vous avez besoin du lien de révocation figurant dans l’e-mail de délivrance correspondant.

Questions sur le service d’horodatage (Time Stamping Service)

Le service d’horodatage (Time Stamping Service, TSA) est le service d’une CA qui délivre une attestation, munie de la date, de l’heure et d’une signature de la CA, indiquant que certaines données numériques ont existé à un moment donné. Le service d’horodatage SwissSign est conforme à la législation suisse (SCSE).

Les horodatages numériques servent principalement à l’archivage de documents ou à l’identification de documents commerciaux tels que des contrats. En outre, la législation suisse stipule qu’une signature qualifiée n’est équivalente à une signature manuscrite que si elle est accompagnée d’un horodatage «qualifié». Les horodatages SwissSign peuvent être utilisés pour des solutions de workflow et d’archivage. Bien que chaque signature électronique contienne déjà une indication de temps (heure locale du système), il peut s’avérer utile d’associer une heure certifiée par un tiers aux données et aux documents. Il est ainsi possible de prouver à tout moment, de manière simple et transparente, que l’enregistrement correspondant a existé à un moment donné et qu’il n’a pas été modifié depuis le moment exact où il a été horodaté (intégrité).

Utilisation: par exemple, pour des solutions visant à mettre en œuvre des exigences légales comme l’Olico, des règles de conformité comme SOX et Bâle II ou encore des chartes de qualité spécifiques à un secteur comme des BPF.

D’un point de vue technique, l’horodatage est une signature du fournisseur qui contient une indication temporelle fiable. La génération de cet horodatage est effectuée par la Time Stamping Authority (TSA) conformément à la norme RFC 3161. Le protocole RFC 3161 définit que la demande contient la valeur de hachage et que celle-ci est ensuite signée par la TSA. Cela garantit que le service TSA n’a pas connaissance du contenu des documents horodatés.

Pour en savoir plus, cliquez ici.

Ceci est dû à l’adaptation du service d’horodatage aux nouvelles exigences de sécurité et à l’augmentation de quelques octets de la taille de la réponse au programme Adobe. Dans sa configuration normale, Adobe n’est pas préparé à cela. Adobe conseille donc d’augmenter l’iSize dans le registre.

Le correctif suivant pour Adobe Reader DC sert d’exemple. À cette fin, enregistrez le texte suivant en tant que fichier «fix_adobe.reg» et double-cliquez pour effectuer la modification dans le registre. Il est recommandé de sauvegarder le registre au préalable. N’oubliez pas que le fichier de registre est toujours spécifique à la version d’Adobe et que le texte doit donc être modifié le cas échéant. Par exemple, la partie en bas qui est désignée ci-dessous par "Adobe Reader" peut aussi être "Adobe Acrobat".

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\Security\cASPKI\cAdobe_TSPProvider]

"iSize"=dword:00002800