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)

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.   

• (Java) KeyStore Explorer

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»)

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.

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.

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.

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.

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.

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".

Pour Adobe Acrobat:

Windows Registry Editor Version 5.00

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

"iSize"=dword:00002800

Pour Adobe Acrobat Pro:

Windows Registry Editor Version 5.00

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

"iSize"=dword:00002800