Vous pouvez approuver vous-même les certificats SSL Silver et Personal ID Silver en activant le lien qui figure dans l’e-mail reçu. Cet e-mail est parfois envoyé avant que le compte e-mail requis ait été créé.

Vous pouvez faire partir cet e-mail en procédant comme suit:
a) Connectez-vous à votre compte sur swisssign.net et cliquez sur le bouton de commande «Rechercher». 
b) Si vous n’avez pas de compte sur swisssign.net: dans le champ de recherche, entrez le numéro de licence concerné pour la demande de certificat et activez le bouton de commande «Rechercher».

La demande de certificat s’affichera dans les deux cas dans un tableau de résultats. A côté de votre entrée, vous trouverez le bouton de commande «Attributs». Cliquez sur ce bouton. A la page suivante, vous pouvez de nouveau envoyer le «E-mail de confirmation de propriété» via un bouton de commande dans la section «Approbation».

Vous pouvez aussi faire déposer vos documents pour une demande de certificat par courier. Dans ce cas, merci d’utiliser l’adresse suivante:SwissSign Group AG, Kundendienst, Sägereistrasse 25, CH-8152 Glattbrugg.

Les standards de sécurité élevés pour l’émission de certificats exigent que vous obteniez à nouveau les signatures des personnes autorisées lorsque vous faites une nouvelle demande de certificat et que vous nous la fassiez parvenir avec la copie de leur carte d’identité/passeport.

Pour simplifier la procédure en cas d’achat de plusieurs certificats, vous pouvez vous faire mandater par le responsable de votre organisation: Procuration (PDF, 106 KB). Merci de signaler l’existence de cette procuration à chaque commande ou d’en joindre une copie.

A partir d’un volume de commande de CHF 1000 et en cas d’achat multiple, il est recommandé de conclure un contrat de Managed PKI Services.

Une validation électronique est transmise par e-mail à l’adresse désirée pour les certificats SSL Silver et Personal Silver ID. Cet e-mail n’arrive nulle part si vous créez par exemple votre compte e-mail après avoir envoyé une demande.

Vous avez créé un compte sur swisssign.net? Dans ce cas, procédez comme suit:

• Connectez-vous à swisssign.net.
• Cherchez la demande de certificat désirée. Si vous n’entrez aucun paramètre dans le champ de recherche et que vous cliquez sur «Rechercher», tous vos certificats et demandes de certificat s’afficheront.
• À côté de la demande de certificat désirée, sélectionnez «Attributs».
• Une nouvelle fenêtre avec le paragraphe «Approbation» s‘ouvre.
• Sélectionnez «Envoyer un e-mail de confirmation de propriété».
• L’e-mail de validation vous sera renvoyé.

Vous n’avez pas créé de compte sur swisssign.net? Dans ce cas, procédez comme suit:

• Connectez-vous à votre compte d’utilisateur pour la boutique en ligne sur swisssign.com et allez sous vos licences.
• Sélectionnez la licence désirée puis cliquez sur «Activer le code».
• Étant donné que vous avez déjà transformé la licence en demande de certificat, le message d’erreur suivant s’affiche: «Un certificat a déjà été demandé».
• Sous le message d’erreur, sélectionnez le lien «Rechercher les demandes déjà envoyées». Vous serez alors dirigé sur swisssign.net.
• Une nouvelle fenêtre de recherche affichant votre demande de certificat en cours s‘ouvre.
• À côté de la demande de certificat désirée, sélectionnez «Attributs».
• Une nouvelle fenêtre avec le paragraphe «Approbation» s‘ouvre.
• Sélectionnez «Envoyer un e-mail de confirmation de propriété».
• L’e-mail de validation vous sera renvoyé.

Vous avez créé un compte sur swisssign.net? Dans ce cas, procédez comme suit:

• Connectez-vous à swisssign.net.
• Cherchez la demande de certificat désirée. Si vous n’entrez aucun paramètre dans le champ de recherche et que vous cliquez sur «Rechercher», tous vos certificats et demandes de certificat s’afficheront.
• À côté de la demande de certificat désirée, sélectionnez «Attributs».
• Une nouvelle fenêtre avec le paragraphe «Approbation» s‘ouvre.
• Cliquez sur le lien à côté de «Document d‘enregistrement».
• Le formulaire de demande va à nouveau s’afficher.

Vous n’avez pas créé de compte sur swisssign.net? Dans ce cas, procédez comme suit:

• Connectez-vous à votre compte d’utilisateur pour la boutique en ligne sur swisssign.com et allez sous vos licences.
• Sélectionnez la licence désirée puis cliquez sur «Activer le code».
• Étant donné que vous avez déjà transformé la licence en demande de certificat, le message d’erreur suivant s’affiche: «Un certificat a déjà été demandé».
• Sous le message d’erreur, sélectionnez le lien «Rechercher les demandes déjà envoyées». Vous serez alors dirigé sur swisssign.net.
• À côté de la demande de certificat désirée, sélectionnez «Attributs».
• Une nouvelle fenêtre avec le paragraphe «Approbation» s‘ouvre.
• Cliquez sur le lien à côté de «Document d‘enregistrement».
• Le formulaire de demande va à nouveau s’afficher.

Les délais commencent à courir à partir de la réception des documents de la demande et ne peuvent être respectés que si ces documents ont été intégralement et correctement remplis.

Vitesse d’émission des certificats SSL

• SSL Silver: de quelques secondes à quelques minutes
• SSL Silver Wildcard: de quelques secondes à quelques minutes
• SSL Gold / SSL Gold Multi-Domain (UCC/SAN): jusqu’à 2 jours ouvrables
• SSL Gold Wildcard: jusqu’à 2 jours ouvrables
• SSL Gold EV / SSL Gold EV Multi-Domain (UCC/SAN): de 5 à 10 jours ouvrables

Vitesse d’émission pour les certificats de personnes

• Personal Silver ID: de quelques secondes à quelques minutes
• Personal Gold ID: jusqu’à 2 jours ouvrables
• Gold ID pour les collaborateurs: jusqu’à 2 jours ouvrables

Vitesse d’émission pour les certificats d’organisation

• Certificat d’organisation sur Smartcard/USB: de 5 à 10 jours ouvrables (excepté la livraison de matériel en dehors de la Suisse)
• Certificat d’organisation pour HSM: de 5 à 10 jours ouvrables

Compte tenu de la réglementation applicable en Suisse, SwissSign ne peut malheureusement pas émettre de certificats pour les pays suivants:

• Algérie
• Biélorussie
• Côte d’Ivoire
• Cuba
• Equateur
• Erythrée
• Guinée
• Guinée-Bissau
• Irak
• Liban
• Liberia
• Libye
• Myanmar (Birmanie)
• République centrafricaine
• République démocratique du Congo
• République islamique d’Iran
• République populaire démocratique de Corée (Corée du Nord)
• Somalie
• Soudan
• Syrie
• Yémen
• Zimbabwe

L’émission de certificats est ici – si possible – empêchée. Les demandes ou émissions de certificats pour ces pays peuvent toutefois être retirées a posteriori.

Avant qu’un certificat SSL puisse être émis, une demande de certficat – Certificate Service Request (CSR) – doit être déposée à cette fin. La CSR est automatiquement générée* dans la boutique en ligne www.swisssign.com ou peut, si la demande de certificat a déjà été établi par un autre biais, être transférée vers le format PKCS#10 durant la procédure de commande. L’autorité de certification ne certifie dans ce cas que le certificat déjà établi ailleurs. S’il n’y a pas de fichier de format PKCS#10, la boutique en ligne déclenche le processus CRS et transfère la paire de certificats vers le format standard PKCS#12. C’est la raison pour laquelle le fichier a l’extension .p12. Il est possible de générer soi-même des bi-clés pour toutes les offres.

Plusieurs champs sont remplis pendant l’établissement de l’offre: l’organisation (O), l’unité de l’organisation (OU), le pays (C), l’Etat/la région/le département/le canton (S), la localité (L) et le nom usuel (CN). En fonction du type de certificat, le nom usuel (CN) contient soit l’inscription du nom de domaine, p. ex. domaine.com, soit, pour les certificats de personne, l’adresse e-mail de la personne, p. ex. foo@gmail.com. 

Si le certificat comporte une entrée d'organisation, vous pouvez facultativement définir une entrée OU. Veuillez noter que certains attributs peuvent être ignorés selon le type de certificat.

*Veuillez noter que cette procédure n'est plus autorisée pour les certificats SSL.

Dans le compte utilisateur technique sur www.swisssign.net – Rubrique «Mes certificats», dernière colonne à droite –, vous pouvez choisir sous «Niveau de sécurité» entre «Privé» et «Accessible publiquement». Cette option de sélection concerne la partie publique de votre certificat et définit sa visibilité pour les tiers:

• Privé: avec cette option, votre certificat ne peut pas être trouvé. Le certificat et le sujet ne sont donc pas mentionnés dans le répertoire LDAP de SwissSign. Votre certificat n’est pas publié non plus à la rubrique «Cherchez des ID» sur swisssign.net. L’option «Privé» est l’option sélectionnée par défaut.
• Accessible publiquement: avec cette option, la partie publique du certificat – sujet et clé publique – est publiée et peut être téléchargée par tout un chacun. Cette option est particulièrement utile si vous utilisez votre certificat pour crypter des messages. Vos partenaires de communication ont ainsi accès à votre clé publique dont ils ont besoin pour coder les messages qu’ils vous envoient.

Ce paramétrage n’a pas grande importance pour les certificats de serveurs, car le statut du certificat peut être vérifié par CRL ou OCSP (les liens figurent dans le certificat) – indépendamment du niveau de sécurité sélectionné.

Les certificats bloqués ou révoqués sont publiés dans des listes de révocation ou centralisés dans un service en ligne (OCSP) qui vérifie la validité des certificats en ligne et en temps réel. Les listes de révocation sont régulièrement actualisées et sont accessibles via les URL suivants:

Télécharger des listes de révocation (CRL) 

• SSL Gold EV, SSL Gold EV Multidomain
• SSL Gold, SSL Gold Multidomain, SSL Gold Wildcard, CodeSigning
• Personal Gold ID avec/sans saisie d'organisation
• Personal Silver ID
• Certificat d'organisation

Tous les certificats SwissSign sont signés par un certificat intermédiaire SwissSign. Les certificats intermédiaires sont à leur tour signés par un certificat racine. Pour qu’un certificat apparaisse comme étant de confiance, il est important que la chaîne complète soit respectée p. ex. sur le serveur web. Le certificat racine est déjà installé sur pratiquement tous les systèmes d’exploitation et applications. Pour certaines applications, il peut toutefois être nécessaire d’installer les certificats racine. Vous pouvez télécharger le certificat final sur swisssign.net avec toute la chaîne de confiance ou installer le certificat racine ultérieurement.

Téléchargez le certificat suivant pour ce produit:

• SSL Silver, SSL Silver Wildcard, Personal Silver ID: Silver_G2.pem
• SSL Silver, SSL Silver Wildcard, Personal Silver ID: Silver_G2.der
• SSL EV Gold, SSL EV Gold Wildcard, SSL Gold, SSL Gold Multidomain, SSL Gold Wildcard, Personal ID Gold, CodeSigning: Gold_G2.pem
• SSL EV Gold, SSL EV Gold Wildcard, SSL Gold, SSL Gold Multidomain, SSL Gold Wildcard, Personal ID Gold, CodeSigning: Gold_G2.der
• Certificat d'organisation: Platinum_G2.pem
• Certificat d'organisation: Platinum_G2.der

Tous les certificats SwissSign sont signés par un certificat intermédiaire SwissSign. Les certificats intermédiaires sont pour leur part signés par un certificat racine. Pour qu’un certificat apparaisse comme étant de confiance, il est important que la chaîne complète soit respectée p. ex. sur le serveur web. Le certificat racine est déjà installé sur pratiquement tous les systèmes d’exploitation et applications mais le certificat intermédiaire doit être installé. Vous pouvez télécharger le certificat final sur swisssign.net avec toute la chaîne de confiance ou l’installer ultérieurement.

Télécharger des certificats interméediaires

• SSL Silver, SSL Silver Wildcard: Server_Silver_G22_2014.pem
• SSL Silver, SSL Silver Wildcard: Server_Silver_G22_2014.der
• Personal ID Silver: Personal_Silver_G22_2014.pem
• Personal ID Silver: Personal_Silver_G22_2014.der
• SSL Gold EV, SSL Gold EV Multi-Domain: EV_Gold_G22_2014.pem
• SSL Gold EV, SSL Gold EV Multi-Domain: EV_Gold_G22_2014.der
• Personal Gold ID avec/sans saisie d'organisation: Personal_Gold_G22_2014.pem
• Personal Gold ID avec/sans saisie d'organisation: Personal_Gold_G22_2014.der
• Certificat  d'organisation HSM: Personal_Platinum_G22_2014.pem
• Certificat d'organisation HSM: Personal_Platinum_G22_2014.der
• SSL Gold, SSL Gold Wildcard, SSL Gold Multi-Domain, CodeSigning: Server_Gold_G22_2014.pem
• SSL Gold, SSL Gold Wildcard, SSL Gold Multi-Domain, CodeSigning: Server_Gold_G22_2014.der

Dans les attaques de type «Man-in-the-Middle», l’attaquant utilise une copie de votre site web qu’il protège avec un faux certificat. Il manipule les routeurs et dévie le flux de données de votre site sur le sien. En général, l’agresseur ne fait que lire les informations puis les redirige directement vers votre site. Ce mécanisme est souvent utilisé par les services secrets.

Vous pouvez protéger votre site web contre les attaques «Man-in-the-Middle»: l’épinglage de votre certificat garantit en effet que l’appelant ne peut consulter le site web que s’il a trouvé le certificat installé à l’origine.

Instructions pour l’épinglage de certificat (PDF en anglais, 98 KB)

Mon système d’exploitation ou mon application m’indique une erreur resp. je ne sais pas comment installer correctement le certificat.

SwissSign mentionne dans les FAQs et les documentations es problèmes connus et leurs solutions. Nous ne pouvons malheureusement pas vous fournir de soutien direct dans ce domaine. La compétence-clé de SwissSign SA est d’établir des certificats standardisés fiables. Compte tenu du fait que SwissSign ne développe pas d’application ni de système d’exploitation, elle se démarque de l’assistance relative à ces deux domaines.

Mais l’un de nos partenaires pourra sans doute vous aider: Partenaires SwissSign

Après avoir acheté vos certificats dans la boutique en ligne swisssign.com, procédez comme suit pour les recevoir:

• Connectez-vous à votre compte utilisateur.
• Sélectionnez «Mes licences» et lancez l’activation du certificat désiré en cliquant sur «Activer le code».
• Il vous faut maintenant faire la demande technique de votre certificat. Veuillez suivre les instructions fournies.
• Dès que votre demande aura été examinée et acceptée, vous recevrez un courriel avec le lien vous permettant de télécharger votre certificat.

Instruction Comment demander la licence de certificat sur swisssign.net? (Instruction en anglais, PDF, 1 MB)

• Connectez-vous à votre compte utilisateur dans la boutique en ligne sur swisssign.com et allez sous vos bon d’achat de certificats.
• Sélectionnez le lbon d’achat de certificat désirée puis cliquez sur «Envoyer un lien d’activation» afin de faire suivre le bon d’achat de certificat à quelqu’un d’autre. Un courriel au/à la destinataire de la bon d’achat de certificat va être préparé en interaction avec vos entrées et pourra ensuite être envoyé.
• Le/La destinataire reçoit peu après un courriel contenant le message personnel ainsi qu’un lien qui lui permettra d’émettre aussitôt le certificat sur swisssign.net.

SwissSign permet de créer soi-même sa bi-clé (privée et publique) pour toutes les offres. La longueur des clés est de 2048 bits. Les clés générées par SwissSign ont également une longueur de 2048 bits.

En vertu des conditions générales en vigueur, les clients ou partenaires n’ont en principe droit à aucun remboursement ou crédit. Si tel est le cas, il s’agit donc toujours d’une concession de la part de SwissSign.

Nous faisons actuellement les gestes commerciaux suivants:

• Tous les clients ont le choix, dans un délai de 30 jours à partir de l’émission des certificats, entre le remboursement et un crédit à hauteur du montant du certificat reçu et révoqué.
• Au bout de 30 jours, le client reçoit, en cas de révocation, un crédit équivalent à la durée résiduelle du certificat concerné.
• L’obligation de garantie de SwissSign portant sur les conseils et l’émission de certificats n’est bien sûr pas concernée.

Les certificats racine de SwissSign sont installés dans les navigateurs les plus courants. Téléchargez la dernière version de votre navigateur et installez les certificats racine les plus récents à partir de la page Windows-Update. Diffusion des certificats racine de SwissSign

Il est également possible que votre serveur web n’envoie pas la totalité de la chaîne de certificats aux clients. Vous pouvez résoudre ce problème avec la fonction «SSLCertificateChainFile» dans la configuration Apache.

Les certificats SwissSign SSL autorisent un nombre illimité de licences de serveurs. Contrairement à la plupart des autres certificats SSL, vous pouvez donc installer votre certificat SSL SwissSign sur autant de serveurs physiques que vous le désirez.

Avec les certificats SSL Silver, SwissSign contrôle les domaines indiqués dans la demande de certificat. Ce contrôle est appelé «Proof of Possession». Durant la procédure, l’auteur de la demande de certificat peut choisir qui reçoit les courriels concernant la preuve de l’appartenance du domaine. Vous pouvez cliquer au choix sur l’un des boutons suivants:

• admin@domaineindiqué
• administrator@domaineindiqué
• hostmaster@domaineindiqué
• postmaster@domaineindiqué
• webmaster@domaineindiqué

Le courriel de «Proof of Possession» est envoyé à l’adresse e-mail sélectionnée. Dès que le lien contenu dans ce courriel est activé, le certificat est établi.

Vous recevez le courriel suivant:
 

Cher opérateur,

L’émission CRL automatique de la CA 'Silver Personal G3' a échoué. Merci d’utiliser le lien suivant pour le faire manuellement: https://swisssign.net/cgi-bin/auth/ca?_crl=do&;selected=Silver Personal G3

Meilleures salutations,

Contrôle du certificat

Veuillez ne pas tenir compte de ce message, nous allons examiner le problème et le corriger dès que possible.

Les certificats intermédiaires permettent de maintenir la «chaîne de confiance» du certificat e-mail que vous acheté chez nous jusqu’au certificat racine de confiance de SwissSign.

Avez-vous fait établir la clé privée et publique de votre certificat par SwissSign? Dans ce cas, vous trouverez votre certificat e-mail ainsi que le certificat intermédiaire pour le certificat racine dans le fichier .p12 que vous pouvez télécharger sur swisssign.net.

Vous avez vous-même créé la clé et entré une CSR lors de votre inscription? Veillez dans ce cas à ce que toute la chaîne de certificats soit bien installée. Lors du téléchargement sur swisssign.net, nous vous proposons plusieurs formats à cet effet. Ceux qui possèdent la chaîne complète de certificats sont accompagnés de l’extension «p7c», «pem».

Nos clients ont très souvent besoin d’un certificat pour s’authentifier (login) sur un site Internet.

Pour ce type d’authentification TLS-WWW-Client, vous avez besoin du certificat Personal ID Gold (avec ou sans inscription d’entreprise) qui peut également être utilisé pour crypter et signer les e-mails. Il n’est pas possible de s’authentifier avec un certificat Personal ID Silver.

Certificats de personnes

Grâce à une petite astuce, vous pouvez faire en sorte que votre visiteur établisse une connexion sécurisée avec votre site Web: paramétrez le fichier .htaccess afin que tous les appels http non sécurisés soient redirigés vers des appels https. Le paramétrage est le suivant:

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

La première ligne active le Rewrite-Engine (moteur de réécriture). La première ligne active le Rewrite-Engine (moteur de réécriture). La deuxième ligne stipule que s’il ne s’agit pas du port https 443 «sécurisé» la demande (troisième ligne) est transmise à la page https via une redirection 301.

L’extension des noms de fichiers indique le type de fichier dont il s’agit. Vous pouvez télécharger sur swisssign.net les types de fichiers suivants avec des contenus différents:

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

Cette procédure ne s'applique pas aux certificats SSL.

(IMAGE: swisssign_faq_ZertifikateMitPrivatemSchlüssel.png)

Les formats .p12- ou PKCS#12 contiennent un certificat officiel ainsi que 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 e-mail, des systèmes d’exploitation et des serveurs Web.

Pour les serveurs Web, il faut installer toute la chaîne des certificats. L’autorité de certification qui émet le certificat fait typiquement confiance à une AC supérieure qui fait pour sa part confiance au certificat racine de SwissSign. Seul le certificat de l’autorité de certification racine de SwissSign est reconnu par tous les navigateurs. Veuillez par conséquent télécharger les certificats des AC intermédiaires de https://www.swisssign.com/de/ca-prod puis les installer également. Cela ne concerne que les personnes qui installent un serveur Web et non les utilisateurs finaux.

Certificats sans clé privée

(IMAGE: swisssign_faq_ZertifikateOhnePrivatenSchlüssel.png)

• .cer: codé DER ou BASE64
• .crt: codé DER ou BASE64
• .pem: certificat codé Base64 encadré par «-----BEGIN CERTIFICATE-----» et «-----END CERTIFICATE-----»
• .p7b (chaîne de certificats) : certificats au format ASCII codé Base64 (par ex. pour Windows OS, Java Tomcat)
• .p7c (chaîne de certificats): structure de données signée PKCS#7 sans contenu de données, uniquement le(s) certificat(s), à l’inclusion de toute la chaîne de certificats (par exemple pour Windows OS, Java Tomcat)
• .pem (chaîne de certificats): certificat codé Base64, à l’inclusion de la chaîne de certificats complète (par exemple pour Apache et les plates-formes similaires)

L’autorité d’enregistrement (AE), un service de SwissSign, contrôle l’identité et si nécessaire les attributs de toute personne qui demande un certificat avant que l’autorité de certification (AC) n’émette le certificat ou n’attribue les données qui permettent d’activer l’utilisation de la clé de signature.

Le format .pfx correspond au format .p12. Téléchargez le format .p12 et renommez-le.

Si vous oubliez ou perdez le mot de passe de la clé privée, SwissSign ne peut malheureusement pas vous aider. Le mot de passe ne peut pas être décrypté ou réinitialisé. Vous n’avez pas d’autre solution que de demander un nouveau certificat et de conserver votre mot de passe en lieu sûr.

• Vous devez d’abord créer un CSR (Certificate Signing Request) dans le système Synology (une demande de certificat). Cela signifie que la bi-clé a en même temps été créée sur le serveur Synology.
• Une fois le certificat émis, téléchargez-le au format .pem sur swisssign.net. Tous les autres formats risquent d’entraîner un message d’erreur comme p. ex.: «Le codage du fichier doit être enregistré en UTF-8.»
• Enregistrez également le certificat intermédiaire (type G22) à partir de la page de téléchargement.
• Vous pouvez maintenant télécharger les fichiers «clé privée» (générée localement) et le certificat en format .pem ainsi que le certificat intermédiaire en format .pem sur le serveur Synology.

• Installation sous Linux pour le certificat d’organisation sur smartcard
• Installation sous Mac pour le certificat d’organisation sur smartcard
• Installation sous Windows pour le certificat d’organisation sur smartcard

Après une exportation au format CSV, les trémas ne s‘affichent pas correctement, par exemple dans les résultats d’une recherche sur la plateforme swisssign.net.

Excel n’ouvre pas le fichier en tant que fichier codé en UTF-8. Conséquence: les trémas ne s’affichent pas correctement dans Excel. Pour éviter ce problème, nous vous recommandons de procéder comme suit:

1. Enregistrez le fichier exporté au format CSV localement comme fichier CSV
2. Ouvrez Excel et, sous l’onglet «Données», sélectionnez le point «A partir du texte»
3. Sélectionnez le fichier CSV sauvegardé
4. Dans la première fenêtre de l’assistant d’importation, entrez UTF-8 comme origine du fichier

Grâce à cette procédure, les trémas s’affichent correctement dans Excel.

Si vous avez reçu votre certificat SSL SHA-1 et votre certificat Code Signing par l’intermédiaire d’un revendeur, celui-ci a reçu un code correspondant. Adressez-vous à lui à ce sujet.

Vous trouverez ici les instructions pour signer les documents pdf.

Non, les certificats révoqués – annulés – continuent à figurer sur la Certificate Revocation List (CRL) après la date d’échéance indiquée sur le certificat, car il est important, pour la validation de la signature, de savoir si le certificat était encore valable à la date de la signature.

SwissSign gère un répertoire LDAP sous directory.swisssign.net. La base de recherche est la suivante: ‹o=SwissSign,c=CH›.

Pour pouvoir trouver votre certificat dans le répertoire LDAP, il est important que le paramétrage de sécurité sélectionné soit «verifiable publiquement» ou «accessible publiquement».

Plusieurs outils sont disponibles pour passer d’un format à un autre. www.openssl.org est l’un des plus connus:

• pour convertir un certificat du format PEM au format DER: openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER
• pour convertir un certificat du format DER au format PEM: openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM

Prenez contact, en votre qualité de client-e d’une solution de Managed PKI de SwissSign, avec l‘autorité d’enregistrement (AE) de votre entreprise. Si vous avez acheté votre certificat dans la boutique en ligne swisssign.com ou auprès de l’un des partenaires de notre boutique, merci de nous envoyer un courriel avec signature numérique à helpdesk@swisssign.com.

Les e-mails sont cryptés à l’aide du certificat du destinataire. C‘est la raison pour laquelle il est indispensable que l’expéditeur obtienne le certificat du destinataire. Cela peut se faire manuellement ou dans le cadre d’une passerelle de messagerie sécurisée qui collecte les certificats des e-mails entrants.

Le certificat d’organisation sur carte à puce/clé USB est basé sur la SuisseID. Les logiciels et pilotes correspondants sont les suivants:

• Documentation technique Windows
• Documentation technique Mac (Linux)

Vous trouverez ensuite sous Unix le module PKCS#11 sous «/usr/local/lib/libcvP11.so».

Si le courriel est signé sous Unix avec PKCS#11, ACS ACR38T USB Reader et la carte à puce ATOS de Siemens (composants SuisseID), (longueur de clé: 2048 Bit), la performance est d’une signature par seconde.

Oui. Les certificats qualifiés de SwissSign satisfont aux exigences de l’ordonnance du Département fédéral des finances sur les données et informations électroniques (OeIDI) et de l’ordonnance concernant la tenue et la conservation des livres de comptes (Olico). Cela permet de signer par exemple des factures individuelles conformes à la TVA. Pour la signature de factures en masse conformes à la TVA, nous vous recommandons toutefois d’utiliser notre certificat d’organisation.

Les principaux navigateurs prennent tous en charge l’agrafage OCSP d’origine:

• Apache/nginx
• Microsoft IIS

Nous vous invitons vivement à actualiser votre système ou à le remplacer de sorte à pouvoir utiliser également les certificats SHA-2, car les nouvelles dispositions du forum CA/navigateur stipulent que les autorités de certification ne pourront encore émettre des certificats SHA-1 que peu de temps.

SwissSign propose à ses gros clients qui possèdent plusieurs certificats d’émettre pour une période transitoire des certificats d’une durée de plusieurs mois. Ce service est offert sur la base d’un projet. Pour pouvoir établir une offre, nous avons besoin d’une liste exacte des types de certificats que vous possédez et de leur nombre.

Nous offrons en outre en principe le retrait et le remboursement de certificats SHA-2 dans le cas où ils ne peuvent pas être utilisés.

Si vous utilisez des certificats SSL SHA-2, il est possible que vos clients qui possèdent des systèmes d’exploitation ou des navigateurs plus anciens ne puissent plus ouvrir les pages Internet. C’est par exemple le cas de tous les clients qui utilisent encore Windows XP avec le Service Pack 2 et n’ont pas installé le Service Pack 3.

Les nouveaux systèmes Windows prennent tous les SHA-2 en charge. SwissSign ne fournit toutefois que des certificats soumis à une norme. Nous ne pouvons malheureusement pas vous dire si SHA-2 est pris en charge par tous les fabricants dans toutes les versions. Il existe un trop grand nombre de systèmes et de versions sur le marché. Nous vous prions de vous adresser au fabricant ou à la société qui vous a vendu votre système informatique.

Nous avons reçu les informations suivantes que nous vous transmettons sans aucune garantie:

• Les serveurs web basés sur le système Java prennent SHA-2 en charge, à condition que la version de Java soit la version SDK 1.4.2 ou une version supérieure.
• Les serveurs basés sur le système Apache doivent être équipés de la version 2.x ou d’une version supérieure. Pour pouvoir générer des clés, votre ordinateur doit être équipé au minimum d’Open SSL 1.1.x.
• Le matériel plus ancien, comme par exemple les systèmes de point de vente, risque d’avoir également des problèmes avec SHA-2. Nous vous recommandons de vous informer en temps utile auprès du fabricant pour savoir si ces systèmes peuvent supporter une version actuelle des logiciels.
   

Les fabricants de systèmes d’exploitation et de logiciels ont indiqué dans le détail les versions qui prennent en charge SHA-2 (sans garantie):

Systèmes d’exploitation

• Windows à partir de la version XP SP3
• Windows Phone à partir de la version 7
• Windows Server à partir de la version 2003 SP2, y compris les correctifs
• Android à partir de la version 2.3
• Apple OS X à partir de la version 10.5
• Apple iOS à partir de la version 3.0
• Blackberry à partir de la version 5.0

Systèmes de serveur

• Apache à partir de la version 2.0.63 avec OpenSSL 0.9.80; version supérieure recommandée en raison de la faille de sécurité heartbleed.
• JAVA à partir de la version 1.4.2
• Mozilla NSS à partir de la version 3.8
• Oracle Weblogic à partir de la version 10.3.1
• Serveur IBM Domino: prise en charge à partir de la version 9.0.1 FP2
• Citrix: cf. liste
• Serveur IBM à partir de la version 8.5

Navigateurs

• Internet Explorer à partir de la version 6, avec système d’exploitation Windows à partir de la version XP SP3
• Mozilla à partir de la version 1.4
• Firefox à partir de la version 1.5
• Chrome à partir de la version 26
• Netscape à partir de la version 7.1
• Opera à partir de la version 9.0
• Safari à partir de la version 3

Applications e-mail

• Outlook 2003/2007 avec Windows XP SP3 ne peut pas vérifier ni envoyer de courriel signé SHA-2.
• Outlook 2007 et les versions supérieurs prennent SHA-2 en charge.
• Mozilla Thunderbird 24 avec Windows XP SP3 peut vérifier les courriels signés SHA-2. De manière générale, il y a eu des problèmes avec SHA-1 concernant l’envoi de courriels signés.
• IBM Notes 9, IBM Notes prend en principe également SHA-2 en charge mais présente des problèmes avec la vérification des e-mails signés.

Deux raisons peuvent en principe être à l’origine de ce problème:

• L’installation d’un certificat intermédiaire a été oubliée lors de l’élaboration du codage SSL ou dans les systèmes d’e-mails. Cf. FAQ «Mon certificat ne fonctionne pas sur mon système d’exploitation ou sur mon navigateur malgré le fait que SwissSign les prenne en charge».
• Le client exploite dans son Proxy ce que l’on appelle une «SSL Inspection». Cette fonction force la liaison cryptée et contrôle si la communication affiche un contenu non autorisé ou si des malware ont été téléchargés. SSL Inspection travaille en général avec ses propres certificats non approuvés. D’autres pages que les pages contenant des certificats SwissSign sont donc concernées. Le problème est en général résolu en configurant la page concernée dans le proxy.

Chrome version 42 qualifie toutes les connexions SSL qui sont encore basées sur l’algorithme SHA-1 de peu sûres et les accompagnent d’une croix rouge ou d’un point d’interrogation dans le navigateur. La connexion n’est pas encore bloquée.

Veuillez remplacer votre certificat SSL par un certificat basé sur un algorithme SHA-2. SwissSign a proposé à vos clients un programme d’échange entre octobre 2014 et janvier 2015. Nous avons prolongé les coupons non utilisés jusqu’à fin novembre 2015.

Seuls sont concernés les certificats SSL EV émis à partir du 1er janvier 2015. La barre d’adresse verte, que l’on appelle «green bar», ne figure pas dans le navigateur Google-Chrome à partir de la version 41. Chrome n’affiche en vert que le https assorti d’un cadenas vert. Mais les informations sur le certificat confirment l’identité de l’organisation qui exploite le site Web mais indiquent également qu’il n’existe pas de registre public.

Non, il n’existe pas de certificat maître. La seule possibilité est d’émettre un certificat à une «adresse e-mail neutre», p. ex. info@xxx.

Annoncez-vous au support.

Souvent, ce type de problème n’est pas dû aux certificats racine absents ou défectueux dans les systèmes d’exploitation ou les navigateurs mais au fait qu’aucun certificat intermédiaire n’a été installé lors du cryptage SSL ou dans les systèmes e-mail.

Les certificats sont classés par ordre hiérarchique: le certificat proprement dit repose sur un certificat intermédiaire de confiance qui repose éventuellement à son tour sur un autre certificat intermédiaire etc. Au bout de la chaîne, les certificats intermédiaires reposent à leur tour sur les certificats racine listés dans les navigateurs et les systèmes d’exploitation qui ne contiennent que les certificats racine. Sans certificat intermédiaire, la chaîne de confiance est donc interrompue.

Ces problèmes se produisent rarement dans un environnement Windows, car Microsoft Windows resp. les navigateurs Windows essaient de mémoriser temporairement les certificats intermédiaires dès qu’une page a par exemple été consultée avec l’installation correcte d’un certificat SwissSign. Ce stockage temporaire est ensuite automatiquement utilisé lorsque le certificat intermédiaire n’a pas été correctement installé et l’utilisateur ne se rend même pas compte de «l’erreur».

Avec Linux par contre, la configuration incorrecte saute aux yeux. Cette situation peut être corrigée en téléchargeant l’ensemble de la chaîne de certificats et en installant la chaîne à l’inclusion des certificats intermédiaires:

• Pour ce faire, ouvrez le lien que vous avez reçu lors de l’établissement des certificats afin de les télécharger. Vous pouvez sinon aller chercher votre certificat sur swisssign.net puis cliquer sur le bouton «Télécharger».
• Parmi les formats proposés, choisissez le fichier qui se termine par .p7c ou .pem (chaîne entière des certificats). Aucun des autres fichiers – à l’inclusion du fichier .p12 – ne contient de certificat intermédiaire.

Oui, c’est possible. Dans la directive Comment demander ma licence de certificat sur www.swisssign.net? (PDF) en anglais, vous trouverez en page 7 un modèle de courriel de confirmation avec le lien requis pour télécharger le certificat.

En vertu de la CP/CPS, les listes de révocation des certificats (CRL) doivent être actualisées au minimum toutes les 24 heures.  Dans la pratique, SwissSign les actualise plus souvent, à savoir toutes les heures.

Un fichier CRL est en principe valable 10 jours, raison pour laquelle il contient la remarque «prochaine actualisation ...» (≤ dix jours). Cette procédure est due à la réglementation applicable en cas de force majeure qui stipule que le fichier doit être réactualisé au bout de 10 jours au maximum si un système est tombé en panne.

La signature numérique d’un courriel signé est envoyée sous la forme d’une annexe automatiquement contrôlée par le programme e-mail du destinataire. La plupart des fournisseurs de Webmail comme par exemple Gmail, Windows Live Hotmail ou Yahoo! n’affichent toutefois la signature qu’en tant qu’annexe avec le nom de fichier smime.p7s sans la vérifier.

L’e-mail client ne reconnaît pas l’émetteur du certificat comme une source fiable. Vous pouvez y remédier en désignant l’émetteur comme fiable. Ce sont habituellement les fabricants de ces programmes qui s’en chargent au moyen de leurs programmes Root Store.

En inscrivant l’émetteur SwissSign comme une source fiable, ce qui veut dire répondre par oui à la question «Voulez-vous faire confiance à l’émetteur?». Si vous utilisez un PC d’entreprise, nous vous remercions de bien vouloir vous adresser à votre support informatique.

Adobe Acrobat (PDF) n’a pas accès par défaut aux certificats fiables dans Windows Certificate Manager et ne peut donc pas vérifier la validité du certificat utilisé. Pour y remédier, procédez comme suit dans Adobe Acrobat:

Sélectionnez «Modifier – Paramètres – Sécurité – Paramètres avancés». Allez sous la carte de registre Windows-Integration et activez les trois cases. Si un contrôle est effectué la fois suivante, un certificat valable devrait s’afficher.

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). Les CRL sont publiées par l’autorité de certification (CA) sur la base des CP/CPS concernées.

Si un certificat de chiffrement est révoqué, il est très important que vous conserviez 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.

D’un point de vue technique, le certificat doit être réémis si son contenu est modifié, ce qui entraîne des frais. Dans la structure actuelle des prix, les frais sont facturés pour chaque sujet valable, à condition que le nombre de certificats émis reste raisonnable.

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 (p. ex. 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 trois manières différentes:

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. Veulliez visitez la page swisssign.net et entrez dans le champs „Licence“ votre numéro de licence pour le certificat que vous avez reçu au moment de l'achat directement sans login. Le certificat est affiché. Vous pouvez maintenant révoquer le certificat avec le code de révocation de l'e-mail d'approbation par presser le bouton «Revoke».
3. Révocation hors ligne: le formulaire de révocation hors ligne (PDF, 57 KB) est à votre disposition.

Oui, vous recevrez un e-mail 30 jours puis 10 jours avant l’expiration de votre certificat SwissSign.

Les deux.

Depuis le 1er avril 2015, les autorités de certification ne peuvent plus émettre de certificats d’une durée de 5 ans. Si le client utilise encore après cette date des certificats acquis auparavant, nous sommes tenus de retirer cette licence. Les clients concernés peuvent se faire rembourser leur certificat ou recevoir un certificat de 3 ans ainsi qu’un bon pour l’achat d’un autre certificat. Merci de contacter notre équipe de support technique à ce sujet.

Avec la suspension, la validité d’un certificat peut être provisoirement/temporairement suspendue.

SwissSign ne propose pas de blocage provisoire de certificats, car les certificats bloqués sont inscrits sur une liste de révocation (CRL) de laquelle il faut ensuite les retirer. Dans ce cas, on n’arrive par la suite pas à retrouver la période durant laquelle le certificat a été suspendu. La loi interdit en outre le blocage provisoire des certificats qualifiés.

Vous avez besoin à cet effet de la clé privée correspondante pour pouvoir déchiffrer les données. Assurez-vous que votre ancien certificat de cryptage est encore importé dans votre navigateur. C’est la seule possibilité de déchiffrer des données codées au moyen de votre ancien certificat.

Si le certificat n’existe plus dans votre navigateur, allez dans votre profil SwissSign et téléchargez à nouveau votre certificat. Vous avez besoin à cet effet du mot de passe à 16 caractères que vous avez entré lors de l’établissement du certificat.

Il n’est en principe pas possible de prolonger un certificat. Vous devez malheureusement en acheter et demander un autre. Si vous avez beaucoup de certificats, nous vous recommandons la solution des Managed PKI pour lesquels vous ne devez fournir les documents et autorisations de signature qu’une seule fois.

En cas de prolongation d’un certificat Gold, vous devez malheureusement fournir aussi tous les documents requis pour une demande de certificat signée. N’oubliez pas d’obtenir la signature du propriétaire du domaine ainsi qu’une copie de la carte d’identité/du passeport de tous les signataires. Il n’est plus nécessaire de joindre un extrait du registre du commerce.

Lors de l’établissement d’un certificat, une période de validité fixe lui est attribuée. C’est la raison pour laquelle il faut demander un nouveau certificat lorsque le certificat concerné est arrivé à expiration. Nous devons alors examiner si le contenu du certificat désiré est encore valable. Afin d’éviter le renouvellement annuel, nous vous recommandons d’acheter des certificats qui durent plusieurs années.

SwissSign utilise un processus extrêmement sûr pour générer les bi-clés. La base est un générateur aléatoire qui comprend de nombreux événements aléatoires qui ne risquent donc pas de se reproduire. On utilise ici des informations d’état du processus actuelles et aléatoires, différents horodateurs, des numéros de processus etc. Ce processus aléatoire très complexe est réalisé pour chaque clé. Il est par conséquent unique.

L’utilisation de certificats vous garantit la sécurité, la protection des données et la confiance. Les certificats sont utilisés pour différentes applications, p. ex. pour les e-mails sécurisés, le e-business, le eGovernment, la eHealth etc.  

Vous en apprendrez plus sous Solutions

La clé publique est une procédure cryptographique asymétrique basée sur l’utilisation d’une bi-clé. Cette paire de clés cryptées est composée d’une clé publique et d’une clé privée. Les données qui ont été cryptées avec l’une de ces clés ne peuvent être déverrouillées qu’avec l’autre clé. Cette méthode cryptographique peut être utilisée aussi bien pour le cryptage que pour les signatures techniques.

En cas de chiffrement, les données pour le destinataire sont cryptées au moyen de la clé publique (Public Key, clé dans le certificat) et ne peuvent être décodées qu’avec la clé privée correspondante.

En cas de signature technique, les données pour le destinataire sont cryptées au moyen de la clé privée de l’expéditeur et peuvent être consultées par le destinataire à l’aide de la clé publique.

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

La clé privée/Private Key n’est connue que du propriétaire du certificat resp. il est le seul à y avoir accès. Elle est utilisée pour décoder les données et pour établir une signature numérique.

Das Zertifikat enthält einen Eintrag «Key Usage». Dieses Feld definiert die Verwendung für das Zertifikat. Mögliche Einträge für die Key Usage sind: Digitale Signatur, Non-Repudiation (Nicht-Zurückweisung), Key Agreement (Schlüsselvereinbarung), Verschlüsselung und/oder Datenverschlüsselung.

Le terme «Dual Keying» est souvent utilisé dans le contexte des e-mails sécurisés. Si vous disposez d’une application bien développée, vous pouvez coder et signer des e-mails. Il vous suffit d’importer un certificat SwissSign dans votre application e-mail et vous pouvez démarrer.

Dual Keying utilise deux paires de clés (certificats):

• Une paire pour le codage. Faites impérativement un backup de la clé privée du certificat de chiffrement. En cas de perte, vous risquez sinon de ne plus pouvoir lire vos données cryptées. Vous pouvez sauvegarder votre backup dans la banque de données en ligne de SwissSign. En cas de perte, il vous suffit de vous connecter à votre profil SwissSign et de télécharger à nouveau le certificat. Vous pouvez bien sûr aussi sauvegarder votre backup sur CD/clé USB.
• Une paire pour la signature numérique. Vous n’avez pas besoin de faire de backup de la clé privée du certificat de signature. La perte de la clé ne pose dans ce cas pas de problème. Il suffit d’en créer une autre. 

Les signatures numériques offrent la base requise pour identifier le signataire d’un document électronique et protéger l’intégrité des données qu’il contient. La signature numérique permet de montrer de façon fiable de qui viennent les données numériques – par exemple un e-mail ou un document – (authenticité) et la modification ultérieure du document est immédiatement identifiée (intégrité).

Vous pouvez utiliser une clé privée pour signer vos documents de façon numérique (p. ex. e-mails, PDFs). Dans la mesure où votre certificat est valable à la date de la signature, une signature numérique valable est créée. Cette signature peut être vérifiée par tous ceux qui possèdent votre clé publique et qui ont ainsi la preuve que c’est bien vous qui avez signé le document.

Un certificat racine est un certificat signé par une CA (autorité de certification). Pour pouvoir utiliser un certificat racine, vous devez d’abord faire confiance à l’autorité de certification correspondante. L’utilisation d’un certificat racine implique que l’instance utilisatrice accepte tous les certificats émis par l’autorité de certification concernée.

Pour de plus amples informations sur l’utilisation de la CA, sur l’organisation, les fonctions, les méthodes et les processus, veuillez consulter la politique de Certification (CP)/la Déclaration des Pratiques de Certification (CPS) de SwissSign: Repository

La confiance est le principe de base de tout modèle de sécurité. C’est également le cas de l’infrastructure à clés publiques gérée (ICP). Pour pouvoir vraiment travailler avec des certificats, vous devez faire confiance à l’autorité de certification qui a émis le certificat.

Les ICP sont toujours organisées de manière hiérarchique. Le niveau le plus élevé (Root) doit expressément être considéré comme fiable de sorte à pouvoir faire confiance au contenu du certificat racine correspondant.

Les certificats racine de SwissSign sont identifiés comme fiables, c’est-à-dire qu’ils figurent entre autres dans les magasins de certificat racine de confiance suivants: Microsoft, Mozilla (NSS) et Apple OS X. Diffusion des certificats racine de Swisssign

C’est pourquoi les certificats SwissSign sont indiqués comme fiables à l’utilisateur final de ces applications. Dès que le certificat racine d’une ICP est identifié comme fiable, tous les sous-certificats qui en découlent peuvent également être considérés comme sûrs.

Faire confiance à une autorité de certification comme SwissSign signifie également faire confiance aux différents processus en lien avec l’ICP, comme par exemple l’enregistrement de l’utilisateur ou la validation du certificat (CRL, OCSP). Les Certificate Policy et Certification Practice Statements (CP/CPS) offrent la transparence concernant les processus et aident à consolider la confiance. Le fait de lire les CP/CPS concernées vous permet de faire confiance à l’autorité de certification SwissSign. SwissSign est de plus un prestataire de service de certification (CSP) qualifié en droit suisse qui répond aux exigences de la loi fédérale sur la signature électronique (SCSE). La SCSE correspond quant à elle aux standards internationaux les plus stricts dans ce domaine.

Importez enfin aussi les certificats racine SwissSign dans vos programmes pour instaurer un climat de confiance.

Une autorité de certification (CA) est un prestataire de service de certification ou un service de certification – un «Trusted Third Party». On parle parfois aussi de Certification Service Provider (CSP).

SwissSign est une autorité de certification – un service qui confirme les données de personnes, d’organisations ou de machines dans un environnement électronique et émet des certificats numériques à cet effet.

L’autorité d’enregistrement (AE)/Registration Authority (RA) est un service de SwissSign destiné à vérifier l’identité et si nécessaire les attributs de la personne qui demande un certificat avant que l’autorité de certification émette le certificat correspondant ou affecte les données en vue de l’activation de l’utilisation de la clé de signature.

Les CAOs ou RAOs sont des «opérateurs» (personnes) avec des fonctions et obligations spécifiques pour l’ autorité de certification ou l’autorité d’enregistrement.

Une infrastructure à clés publiques (ICP) est une infrastructure ou un environnement dans lequel différentes applications et fonctions sont exécutées avec des clés cryptographiques (publiques et privées) et des certificats. Ces applications vont des contrôles d’accès et des applications e-mails sécurisées jusqu’à différentes sortes d’informations signées de manière numérique en lien avec l’autorité de certification ou l’autorité d’enregistrement.

La politique de certification/Certificate Policy (CP) est un document du fournisseur de services de certification (CSP) qui décrit les différents acteurs d’une infrastructure à clés publiques gérée (PKI) ainsi que leurs rôles et obligations. Elle comprend toutes les règles qui prévoient l’applicabilité d’un certificat pour un cercle de personnes donné et/ou une classe d’applications spéciales avec des exigences de sécurité communes. Les tiers l’utilisent pour analyser la fiabilité des certificats.

Les certificats SwissSign correspondent tous aux certificats standard X.509 pour lesquels un champ spécifique peut être créé avec un lien qui renvoie à la CP/CPS correspondante. Chaque partie peut ainsi s’informer sur le niveau de confiance d’un certificat.

CPS signifie Déclaration des pratiques de Certification/Certificate Practice Statement (CPS), c’est-à-dire des déclarations et des directives effectivement mises en oeuvre par SwissSign pour l’émission de certificats. La CPS définit les équipements, la politique et les procédures utilisés par le fournisseur de services de certification en accord avec la politique de certification choisie. Les CPS correspondent aux standards internationaux basés sur le RFC 3647.

La CP et la CPS constituent la base légale qui régit les rapports entre les propriétaires de certificats et SwissSign.

SwissSign CP/CPS (Repository)

Microsoft a annoncé en novembre 2013 que les Code Signing certificats et les certificats SSL avec SHA-1 ne seraient plus acceptés comme certificats approuvés dès janvier 2016.

SHA-2 est composé de plusieurs algorithmes de hachage cryptographiques créés par le National Institute of Standards and Technology (NIST) destinés à remplacer l’algorithme de hachage SHA-1 considéré comme moins efficace.

Google a lui aussi annoncé ces derniers jours qu’à partir de janvier 2015 probablement, tous les sites Web protégés par des certificats encore valables après le 1er janvier 2016 et basés sur l’algorithme SHA-1 seraient affichés comme peu sûrs dans toutes les versions du navigateur Google Chrome.

Dans le monde électronique, le terme de fiabilité revêt une nouvelle dimension. Les utilisateurs doivent pouvoir identifier clairement leurs partenaires de communication.

Un certificat numérique ou électronique (Certificate) est une attestation électronique qui fait le lien entre une clé de vérification de signature et le nom d’une personne, d’une organisation ou d’un serveur. En d’autres termes: un certificat est une «carte d’identité électronique» que l’on ne peut pas modifier et dont l’utilisateur peut se servir pour identifier et/ou crypter des données sur Internet.

Identification: les certificats sont utilisés pour,

•  identifier l’expéditeur des informations.
•  identifier le serveur sur lequel un utilisateur se connecte.
•  identifier l’utilisateur qui se connecte sur un serveur.

Chiffrement: les certificats numériques contiennent la clé publique du propriétaire du certificat. Celui-ci peut être utilisé par son vis-à-vis pour crypter un e-mail ou un document à envoyer par Internet.

Les certificats jouent eux aussi un rôle important dans les transactions web sécurisées comme https (certificats SSL).

Il existe plusieurs types de certificats numériques. Le set minimal contient les éléments suivants:

• La clé publique du titulaire du certificat (personne, ordinateur/machine ou organisation)
• Des informations sur le titulaire du certificat
• Des informations sur l’éditeur du certificat, c’est-à-dire l’autorité de certification, ou sur l’organisation qui a fourni le certificat
• La signature numérique de ce certificat par l’éditeur
• La date de délivrance ou d’échéance du certificat
• Le numéro de série du certificat
• Les certificats de SwissSign contiennent également des indications sur la CP/CPS

SwissSign utilise un processus extrêmement sûr pour générer les bi-clés. La base est un générateur aléatoire qui comprend de nombreux événements aléatoires qui ne risquent donc pas de se reproduire. On utilise ici des informations d’état du processus actuelles et aléatoires, différents horodateurs, des numéros de processus etc. Ce processus aléatoire très complexe est réalisé pour chaque clé. Il est par conséquent unique.

Les fabricants de navigateurs, de systèmes d’exploitation, d’e-mail clients et autres logiciels qui évaluent des certificats doivent posséder et mettre à jour des programmes dans lesquels ils gèrent les CSP qu’ils recommandent à leurs clients comme des CSP de confiance (programme de listes de certificats racine).

La maintenance des programmes de listes de certificats racine prend beaucoup de temps. Elle comprend la mise à jour des documents des exigences et des CSP admis. C’est la raison pour laquelle c’est le forum CA/navigateur qui se charge de cette tâche. Les personnes chargées de la maintenance des programmes de listes de certificats racine (fabricants de logiciels) et les CSP sont représentés au sein de ce groupe et ils élaborent et mettent à jour ensemble les documents des exigences.

De plus en plus de programmes de listes de certificats racine sont actuellement basés sur les «Baseline Requirements» du forum CA/navigateur. www.cabforum.org

Le certificat contient la clé publique (Public Key). Si p. ex. Alice désire vous envoyer un e-mail confidentiel et souhaite utiliser à cet effet la procédure «Public Key», elle a besoin de votre clé publique. L’une des tâches d’une CA (autorité de certification) est de rendre également les Public Keys accessibles publiquement.

SwissSign vous offre trois niveaux de confidentialité. Dans le compte utilisateur technique sur www.swisssign.net (Recherchez le certificat et appuyez sur "attributs"), vous pouvez choisir sous «Niveau de sécurité» entre «Privé», «vérifiable publiquement» et «accessible publiquement». Cette option concerne la partie publique de votre certificat. Si vous n'avez pas créé un compte sur swisssign.net, vous pouvez directement rechercher votre certificat avec le code de licence acheté à l'achat et faire la sélection via "Attributes".

Vous définissez ainsi vous-même la visibilité de vos certificats pour les tiers.

Lisez à ce sujet le document Informations sur l'importance juridique des certificats SwissSign en anglais (PDF, 273 KB).

Tous les certificats numériques affichent le cycle de vie suivant:

• Demande de certificat: un utilisateur demande un certificat.
• Examen de la demande: l’autorité d’enregistrement (Registration Authority RA) vérifie l’identité de l’utilisateur/de l’auteur de la demande.
• Génération/Etablissement des certificats: l’autorité de certification (Certificate Authority CA) émet le certificat. Ce certificat contient des données sur le titulaire, l’éditeur, l’utilisation autorisée et sa durée de vie (valable du et valable jusqu’au).
• Suspension: le certificat est momentanément bloqué. Ce n’est pas le cas chez SwissSign.
• Révocation/Nullité: le certificat est révoqué ou déclaré nul avant son échéance.
• Echéance du certificat: la durée de vie du certificat est terminée.
• Renouvellement du certificat: renouvellement du certificat.

L’autorité d’horodatage (TSA) est le service d’une autorité de certification qui délivre une attestation portant la date, l’heure et une signature et en vertu de laquelle des données numériques déterminées ont existé à une certaine date. Le service d’horodatage de SwissSign répond à la législation suisse (SCSE).

VA est l’abréviation de services de validation. L’un des services de validation les plus courants consiste à vérifier la validité d’un certificat au moyen de ce que l’on appelle une liste de révocation (CRL) ou d’un OCSP (Online Certificate Status Protocol).

Dans le monde numérique comme dans le monde physique, il est dangereux de perdre une clé ou qu’une clé ne soit plus valable, p. ex. lorsqu’un collaborateur quitte l’entreprise. C’est la raison pour laquelle des clés/certificats sont continuellement signalés et doivent être bloqués afin d’éviter des dommages. SwissSign inscrit – comme toutes les autorités de certification – ces clés/certificats dans des «Certificate Revocation Lists» (CRL).

Les CRL (listes de révocation ou de blocage des certificats) contiennent tous les numéros de série des certificats invalidés avant l’échéance de leur durée de vie. Lors de l’examen du statut d’un certificat, la liste est téléchargée à partir d’un URL public et le numéro du certificat concerné est recherché dans cette liste. S’il y figure, le certificat est bloqué. S’il n’y figure pas, il est valable.

Les certificats révoqués resp. invalidés restent sur la CRL après la date d’échéance indiquée dans le certificat. Cela s’explique par le fait qu’il est important de connaître, pour la validation de la signature, la date à laquelle un certificat a été révoqué.

Les CRL sont en général actualisées à intervalles réguliers. Comme pour les certificats, la durée de vie figure dans les CRL. Cette durée est nettement plus longue que la fréquence d’émission (au moins deux fois par jour) peut le laisser supposer. Les cas de «force majeure» sont ainsi également couverts. Les CRL peuvent être stockées temporairement de manière locale et permettent de consulter le statut d’un certificat hors ligne. La connexion entre le titulaire du certificat et la Relying Party (partie qui se fie au certificat) n’est pas divulguée au CSP. Mais cette manière de procéder entraîne une grande inexactitude concernant la consultation du statut d’un certificat.

Il existe une autre possibilité: le service de validation en ligne OCSP (Online Certificate Status Protocol). Ce service renseigne sur la validité d’un certificat en temps réel. Le recours au protocole OCSP requiert une performance élevée de la CA. La CA de SwissSign garantit la performance désirée et n’utilise à cet effet que ses propres logiciels créés en Suisse. L’examen du statut en ligne est habituellement effectué lorsque le contrôle du certificat à une date précise est important, p. ex. pour les transferts financiers.

• Le message n’a pas été modifié après avoir été envoyé.
• En fonction de la CP/CPS associée au certificat signé, vous pouvez être certains que l’expéditeur est bien celui qu’il prétend être.

Google Chrome est basé sur le modèle du «Certificate Transparency» (CT). Cette procédure de sécurité CT est destinée à identifier les services de certification défaillants et à les exclure des communications Internet sécurisées. La procédure adoptée par Google Chrome est un pilier important des communications Internet fiables.

Idée de base de la CT: tous les certificats utilisés pour des communications Internet sécurisées doivent être enregistrés dans un système log protégé de manière cryptographique et être gérés par au moins 3 serveurs log centraux répartis dans le monde entier. Les modifications ultérieures, les enregistrements bizarres et illicites, les faux certificats, les adjonctions ou autres manipulations d’un certificat déjà enregistré seraient ainsi exclus ou détectés sur-le-champ par n’importe quel navigateur.

Avec ses certificats EV, SwissSign soutient totalement la transparence des certificats. Tous les utilisateurs de certificats EV peuvent, avec l’activation de l’agrafage OCSP, justifier les entrées log des certificats SwissSign, ce qui entraîne l’apparition d’un cadenas vert dans le navigateur Chrome. SwissSign soutient ainsi, avec plusieurs services de certification européens, une transparence des certificats paneuropéenne (Certificate Transparency Log).

Vous pouvez vérifier dans la CP/CPS correspondante de l’éditeur la qualité avec laquelle il a identifié le titulaire du certificat (expéditeur). L’authenticité de l’expéditeur est ainsi garantie par une signature valable et fiable. Il est toutefois conseillé de faire preuve d’une saine méfiance lorsque vous ne connaissez pas l’éditeur, en particulier si vous ne connaissez pas non plus l’éditeur de la signature. 

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

• Les certificats resp. le mot de passe de la clé privée peuvent être perdus. Les e-mails chiffrés avec ce certificat ne pourront dans ce cas plus jamais être lus et ne pourront plus l’être par personne.
• Vous avez renouvelé vos certificats mais vous avez oublié de réinstaller l’ancien certificat échu. Vous ne pourrez plus lire les anciens e-mails que vous avez conservés.
• Un collaborateur quitte l’entreprise ou est absent pendant une longue durée. Ses e-mails ne pourront plus être lus par personne.
• Vous recevez un e-mail crypté qui contient un virus ou un cheval de Troie. Aucun antivirus ne peut accéder aux e-mails cryptés. Le virus ou le cheval de Troie peut donc s’infiltrer en toute impunité. Dans ce cas, le cryptage peut représenter un risque pour la sécurité.

Le terme de «certificat qualifié» est apparu en Europe durant une campagne menée dans l’Union européenne pour introduire un standard uniforme pour les systèmes ICP. Il n’existe pas de définition formelle de ce terme mais les certificats qualifiés désignent habituellement un certificat émis sur la base des prescriptions nationales légales. La Suisse possède sa propre loi sur la signature numérique: la loi fédérale sur les services de certification dans le domaine de la signature électronique du 19 décembre 2003 (SCSE), RS 943.03. Au sein de l’UE, la norme applicable est la norme ETSI TS 101 456 et aux USA et au Canada, la norme ANSI X9.79.

http + Secure Socket Layer SSL = https

https est le standard conçu pour le transfert crypté des données entre le navigateur et le serveur web – pour des transactions Internet sécurisées. Il repose sur des certificats X.509 et utilise une procédure de chiffrement asymétrique. Il nécessite des calculs mathématiques très compliqués et alourdit considérablement la charge du processeur. En revanche, les clés transmises ne peuvent pas être interceptées par un attaquant.

Voici comment se déroule une connexion HTTPS: le serveur web envoie au navigateur son certificat numérique signé par une CA (certificat du serveur web). Ce certificat contient d’une part la clé publique du serveur web et identifie d’autre part ledit serveur. Le navigateur contrôle son authenticité à l’aide du certificat CA installé, car il se fie aux certificats de serveurs web qui ont une signature valable. Le navigateur génère ensuite une clé symétrique secrète qui ne sera utilisée que pour cette session SSL. Il la crypte avec la clé publique du serveur web puis l’envoie audit serveur. D’autres données peuvent dès lors être codées avec la clé de la session. Un cryptage symétrique des données peut maintenant démarrer avec la clé de la session que possèdent les deux parties («secret session key»). Cette procédure est beaucoup plus simple et n’alourdit que très peu la charge du processus.

Rôle de la CA (autorité de certification): elle garantit la transmission non falsifiée de la clé publique et l’authenticité du serveur web. Le certificat de la CA est installé dans tous les navigateurs où il est affiché comme «Autorité de certification racine de confiance». Si le certificat n’est pas installé, l’utilisateur recevra un message d’erreur à l’ouverture du site web. Le serveur web génère également une bi-clé dont la partie publique est transmise à la CA. La CA contrôle les indications de l’exploitant du serveur et signe la clé. Le certificat du serveur web ainsi généré garantit l’authenticité du serveur et représente pour les utilisateurs la certitude qu’ils sont connectés au bon serveur.

Pour Outlook Web Access (OWA), vous avez besoin d’un certificat SSL installé sur un serveur OWA. En fonction du niveau de confiance désiré, vous pouvez opter pour un certificat individuel Silver, Gold ou Gold EV.

Le Trustcenter certificateur de SwissSign doit répondre à des exigences très élevées pour que les certificats soient considérés comme suffisamment sécurisés. L’un des aspects essentiels de la sécurité est la longueur de la clé qui est régulièrement adaptée sur la base des progrès réalisés en informatique et en cryptologie.

Depuis 2010, les standards industriels recommandent d’utiliser une longueur de clé de 2048 bits pour les clés asymétriques. Les clés symétriques peuvent être échangées avec ces clés asymétriques qui permettent de chiffrer des contenus de manière symétrique.

Les certificats SSL avec leurs clés asymétriques ne sont utilisés que pour l’identification claire et sécurisée du serveur, pour l’authentification mutuelle et la mise en place d’un canal sécurisé pour l’échange de clés symétriques. Pour des raisons de performance, l’échange de données lui-même n’est effectué qu’avec les clés symétriques échangées. Tous les certificats SSL de SwissSign admettent la longueur maximale des clés symétriques qui est aujourd’hui habituellement de 256 bits.

Mit den Technologien der integrierten Kommunikation und Zusammenarbeit (Unified Communications & Collaboration, UCC) bietet Microsoft eine effiziente und einfache Möglichkeit der Kommunikation über verschiedene Anwendungen hinweg an. Einheitliche Schnittstellen erweitern die Kompatibilität zwischen den Office Produkten und ermöglichen den reibungslosen und sicheren Austausch von Daten auf elektronischem Weg.

Zentrales Element von UCC ist Microsoft® Exchange™. Zu den UCC Anwendungen gehören aber auch Outlook Web  Access (OWA), ActiveSync, Outlook Anywhere, Autodiscover, POP3, IMAP4, Unified Messaging, Office Communications, Office Enterprise, Office SharePoint und Office SharePoint Designer. Die Vereinfachung der Kommunikationswege stellt aber auch spezielle Anforderungen an die Sicherheit. So muss der Datenaustausch innerhalb der UCC Server gesichert werden.

Le certificat est émis sur la base de la norme RFC 5280. La nouvelle norme prévoit l’entrée de l’adresse e-mail aussi bien dans le «Subject Distinguished Name» (nom de sujet distinct) que dans le «Subject Alternative Name» (multi-domaines) (SAN). La plupart des applications mail analysent surtout l’entrée dans le champ SAN. Le fait de placer l’adresse e-mail dans l’attribut «emailAddress» du Subject Distinguished Name est obsolète et n’est plus utilisé par SwissSign.

SCSE est l’abréviation de la Loi fédérale sur les services de certification dans le domaine de la signature électronique du 19 décembre 2003, SCSE RS 943.03.

Le bilan et le compte de résultat doivent être archivés physiquement et signés à la main. S’ils sont archivés électroniquement, il faut conserver les originaux.

Les livres, les pièces comptables, la correspondance commerciale et les inventaires (le grand livre ainsi que les comptes et le journal, les livres auxiliaires, en particulier la comptabilité salariale, la comptabilité des débiteurs et des créditeurs, les stocks de marchandises / les prestations non facturées) peuvent être archivés électroniquement.

Les systèmes d’enregistrement requis pour le modèle de CT, que l‘on appelle les «Certificate Logs», n’étaient proposés jusque-là que par des fournisseurs américains (Google, DigiCert). C’est pourquoi les acteurs D-TRUST, SwissSign et Izenpe ont décidé en juillet 2014, afin de gérer leur propre Certificate Log, que le modèle de CT doit s’appuyer sur une infrastructure log totalement autonome.

L’un des principaux objectifs de l‘initiative des trois Trust-Centers est que la ligne d’adresse du navigateur qui apparaît en vert (green bar) et qui indique aux utilisateurs Internet que la connexion est fiable reflète à l’avenir également les intérêts de tous les fournisseurs représentés dans le forum international CA/navigateur.

Car si seul le modèle de CT américain (Google) devait s’imposer, on peut craindre que certains certificats perdent le label reconnu de la barre verte à validation étendue (Extended Validation) malgré les standards de sécurité élevés sur lesquels ils sont basés.

Il vous appartient en principe de décider quel est le certificat indiqué dans tel ou tel but (p. ex. archivage ou facturation) et qui réponde en même temps aux exigences légales et à vos prescriptions internes.

SwissSign ne peut malheureusement que vous donner des informations générales à ce sujet et n’est pas autorisée à émettre des recommandations finales. La situation légale est par exemple différente d’un canton à l’autre et dépend également du fait que le droit international s’applique ou non et qu’il existe des prescriptions internes des autorités ou des entreprises.

La procédure à suivre pour signer votre code dépend de la plateforme. Chaque fabricant fournit des instructions à cet effet:

• Microsoft «Authenticode»: nos certificats peuvent être utilisés. Avec le nouveau Windows SDK, le code signature peut également être utilisé sur la plateforme Windows. Voici un exemple d’appel typique sous Windows pour l’outil de signature:
  signtool sign /tr http://tsa.swisssign.net /a /f <fichier-P12> /p <mot de passe pour le fichier-P12> myprogram.exe
• osslsigncode 1.5.1, qui est utilisé aussi pour Cross-Compiling Windows sous Linux, prend également en charge le RFC 3161 avec l’option -ts. Cf. aussi le site web de osslsigncode
• Java JAR Signer: nos certificats peuvent être utilisés.
• Android: nos certificats peuvent être utilisés.
• Apple iOS / OS X: Apple accepte depuis peu uniquement ses propres certificats, ce qui signifie qu’aucun certificat de fournisseurs tiers comme SwissSign ne peut être utilisé pour le code signature.

RFC est l’abréviation de «Request for Comments». Les RFC sont toute une série de documents techniques et d’organisation de l’éditeur RFC qui sont acceptés de manière générale et au niveau international comme standards Internet. Le système RFC a été instauré en 1969.

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

La mise en place d’une infrastructure log paneuropéenne autonome a pris fin à l’automne de l’année dernière et a été soumise à Google pour validation. Google n’a pas encore donné son feu vert. SwissSign travaille pour l’instant à l’enregistrement des certificats SSL EV dans les deux CT-logs Google. Dès que le log paneuropéen aura été validé, tous les certificats SwissSign obtiendront la validation de 3 CT-logs: deux CT-logs Google plus le log paneuropéen. Selon Google, c’est la condition pour que les certificats continuent à s’afficher avec une barre verte à partir de l’été. Jusque-là, l’enregistrement dans un seul log suffit.

Malheureusement, le calendrier de Google Chrome change régulièrement et les dates communiquées au départ ne sont pas respectées. Cela montre qu’un changement de système de ce genre prend du temps.

SwissSign enregistre tous les certificats EV dans les deux «Certificate Transparency Logs» de Google ainsi que dans le «Certificate Transparency Log» paneuropéen. Vérifiez que l’agrafage OCSP est bien activé. Depuis 2016, l’agrafage OCSP est obligatoire dans les navigateurs Chrome et Firefox.

Les Logs CT complètent le système de sécurité SSL et en augmentent la fiabilité mais ne les remplacent pas.

(IMAGE: swisssign_faq_CT-Logos.png)

Lien pour télécharger les certificats intermédiaires

Certification Authority Authorization (CAA) est un standard Internet publié en 2013 sous le nom RFC 6844.

Les noms de domaine figurent, à l’instar d’un grand annuaire téléphonique, dans un registre de noms diffusé dans le monde entier, le «Domain Name Service» ou DNS en abrégé. Ce service traduit le nom d’un site Internet comme www.swisssign.com en adresse Internet, p.ex. «46.175.9.80», ce qui permet à différents services Internet, comme un navigateur, de l’atteindre. Le Domain Name Service permet en outre d’échanger différentes informations supplémentaires telles que le nom et l’adresse du propriétaire du site.

Grâce au standard CAA, il est désormais possible d’ajouter des enregistrements spécifiant quelles autorités de certification peuvent émettre un certificat pour le domaine mentionné. Si aucune autorité de certification n’est enregistrée, n’importe quelle autorité peut émettre un certificat; par contre, une autorité de certification ne peut émettre aucun certificat pour le domaine si son nom n’y est pas mentionné.

Pourquoi ce règlement?

Ces dernières années, il y a eu de plus en plus d’«attaques de l’homme du milieu», un comportement auquel ont aussi recours les services de renseignements du monde entier. Ces derniers prient, en vue d’espionner les accès à un site Internet crypté, une autorité de certification amie ou complaisante d’émettre un certificat similaire pour ce site Internet. L’attaquant recrée le site Internet avec ce «faux» certificat et détourne d’abord le trafic de données vers le faux site Internet en manipulant le routeur. Il y décrypte et transmet ensuite directement la communication au site Internet original. Le site Internet attaqué et ses visiteurs ne se doutent en général de rien.

Un enregistrement CAA peut réduire le risque si l’on enregistre délibérément les autorités de certification à qui ont fait confiance. Depuis septembre 2017, toutes les autorités de certification admises dans les navigateurs sont contraintes par le CA/Browser Forum, une association de fabricants de navigateurs et d’autorités de certification, de contrôler l’enregistrement CAA avant d’émettre des certificats.

CAA est un processus par lequel le propriétaire du domaine peut déterminer quelle AC est autorisée à délivrer des certificats pour son domaine. Un enregistrement appelé CAA est entré dans le DNS. Depuis septembre 2017, SwissSign vérifie tous les domaines avant de délivrer des certificats afin de déterminer si vous avez une restriction dans votre dossier CAA. Les domaines qui ont été restreints pour accepter des certificats d'autorités de certification autres que SwissSign ne sont pas autorisés dans le certificat. La demande de certificat est rejetée. Si aucune restriction n'a été effectuée ou que l'enregistrement CAA nomme SwissSign comme CA, le certificat sera autorisé.

Le configurateur CAA vous accompagne dans la définition des paramètres exacts pour votre site web.

Voici quelques exemples selon la technologie DNS utilisée:

Autorisation pour SwissSign de delivrer 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 delivrer des certificats (pas joker)

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 delivrer des certificats (seulement joker)

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

Les certificats SSL de SwissSign vous permettent d’acquérir un nombre de licences illimité. Vous pouvez par conséquent installer votre certificat Swisssign sur autant de serveurs physiques que vous le souhaitez.

Malheureusement pas, car d’après www.whois.ch, vous n’êtes pas propriétaire des domaines dyndns.ch ou dyndns.org. Etant donné que DynDNS n’effectue pas de validation de domaine, il va être difficile d’obtenir une confirmation du propriétaire qui puisse également être vérifiée.

Pour acquérir un certificat SSL Gold EV, les associations doivent elles aussi indiquer un numéro de registre.

En Suisse, les associations peuvent, comme les entreprises, demander un numéro d’identification d’entreprise (IDE) qu’il ne faut pas confondre avec l’identifiant TVA de l’UE (IDE-UE). Si les associations dont le chiffre d’affaires annuel est inférieur à CHF 150'000 sont libérées de la TVA, elles peuvent toutefois demander un IDE qu’il conviendra d’inscrire dans le certificat en tant que numéro de registre

Les associations allemandes sont inscrites dans le registre des associations comme associations enregistrées et peuvent utiliser ce numéro.

Le SwissSign Fulfillment peut consulter les IDE suisses. Si vous n’avez pas restreint la visibilité de votre IDE, les données de votre association suffisent. Vous pouvez sinon nous fournir une confirmation IDE. Les associations étrangères voudront bien joindre un extrait du registre pour la confirmation.

Le numéro d’identification d’entreprise (IDE) remplace l’ancien numéro d’entreprise inscrit au registre du commerce.

Depuis janvier 2011, l’Office fédéral de la statistique (OFS) a commencé à attribuer à chaque entreprise active en Suisse un numéro d’identification unique, à caractère universel (IDE). Cela permet aux entreprises de s’identifier auprès de toutes les autorités avec un seul et même numéro.

L’ancien numéro du registre du commerce à 11 chiffres (CH-123.4.567.890-1) a été remplacé le 1er janvier 2014. Depuis cette date, le numéro valable est l’IDE.

Et depuis cette date, les certificats SwissSign SSL Gold EV font référence à l’IDE.

Les certificats SSL traditionnels sont uniquement destinés à sécuriser des domaines ou sous-domaines individuels. Dans le cas d’UCC, il faudrait par exemple acheter et installer un certificat différent pour chaque serveur, ce qui serait très fastidieux.

Le certificat UCC/SAN comporte, en tant que certificat SSL spécial, une extension qui permet plusieurs «Subject Alternative Names» (SAN). Ces SAN peuvent se composer de préfixes (sous-domaines) et de noms d’hôtes. Le certificat UCC/SAN permet ainsi de sécuriser plusieurs SAN avec un seul certificat. La communication entre plusieurs serveurs est ainsi cryptée avec un seul certificat UCC/SAN. La complexité de la configuration du serveur est ainsi considérablement simplifiée.

Lorsque vous installez un environnement UCC/SAN sous MS Exchange, la question se pose toujours de savoir si un certificat Wildcard (plus avantageux) suffit ou s’il vaut mieux avoir recours à un certificat Multi-Domain (plus onéreux). Il existait auparavant des certificats UCC/SAN spéciaux qui autorisaient aussi des noms de domaines internes comme p. ex. autodiscover etc. voire même des adresses IP internes. Ceux-ci ne sont aujourd’hui plus admis par le forum CA/navigateur.

De manière générale, nous recommandons des certificats Multi-Domain pour les environnements UCC/SAN pour Microsoft. A partir de la version Microsoft Exchange 2010, il est possible d’utiliser également des certificats Wildcard. Ces certificats sont également indiqués dans Microsoft Technet. Il n’est par contre pas possible d’utiliser des certificats Wildcard pour les versions inférieures à 2007 ou en combinaison avec d’anciens téléphones mobiles comme Windows Mobile 5.0.

Vous trouverez ici tout ce dont il faut tenir compte lors de l’utilisation de certificats Wildcard. Concernant Lync 2013, Microsoft fournit des informations ici et concernant la Wildcard, ici.

Il existe trois types de certificats SSL:

• Single-Domain: utilisable pour un seul site web. Exemple: monsiteweb.com.
• Multi-Domain: utilisable pour plusieurs sites web/domaines. Exemple: monsiteweb.com, votresiteweb.com, sonsiteweb.ch.
• Wildcard: utilisable pour tous les sites web qui ont un nom de domaine spécifié. Exemple: db.monsiteweb.com, mail.monsiteweb.com, sap.monsiteweb.com etc.

Les certificats Multi-Domain sont également souvent appelés UCC/SAN (Unified Communication Certificates/Subject Alternative Name), car ils conviennent parfaitement à un environnement Lync ou Microsoft Exchange. Le champ SAN du certificat contient pour les certificats Multi-Domain et Wildcard une entrée qui signale les autres domaines ou la Wildcard.

Les certificats Multi-Domain ou les certificats Wildcard sont très souvent utilisés en raison de leur prix avantageux. Des copies du même certificat SwissSign peuvent être utilisées sur autant de serveurs que désiré, ce qui permet le cas échéant de sécuriser l’environnement complet d’une entreprise avec un certificat Wildcard. Si les certificats Wildcard sont d’un côté très pratiques, ils peuvent en même temps se révéler très risqués pour les grandes entreprise: si la clé privée du certificat est compromise et qu’un site frauduleux de type man-in-the-middle devait être créé avec son nom de domaine, cela se remarquerait à peine et le dommage occasionné serait énorme, d’autant que ce site serait parfaitement protégé avec le certificat de l’entreprise. C’est pourquoi les certificats Wildcard ne peuvent pas être proposés avec le standard EV.

Les certificats Multi-Domain ne présentent pas ce problème. Ils peuvent par contre présenter un problème de performance s’ils contiennent une longue liste de noms de domaines. Pour pouvoir communiquer de manière sécurisée, les serveurs doivent changer de certificat et plus le certificat est long, plus le nombre de bytes à transférer est important. La performance ne sera pas affectée si le nombre de domaines s’élève à 20 mais s’il est de 50, 100 ou 200, le système risque d’être ralenti.

Un grand nombre d’entrées SAN augmente le risque de devoir changer prématurément de certificat Multi-Domain: les noms de domaines comprennent en effet souvent des domaines qui n’appartiennent pas au propriétaire du certificat et le propriétaire du site doit en autoriser l’utilisation au moyen d’une procuration. Si le domaine ne peut plus être utilisé, le certificat n’est plus valable et il faut renouveler l’ensemble des certificats Multi-Domain.

Il s’est passé la même chose avec le bug heartbleed détecté uniquement sur les systèmes OpenSSL de la nouvelle génération. Il a fallu renouveler tous les certificats. Les certificats Multi-Domain ou Wildcard utilisés ont dû être changés même sur les systèmes qui n’étaient pas affectés par le bug Heartbleed. Tout changement de certificat entraîne une altération du fonctionnement et une mise hors service momentanée du site web. A l’échéance d’un certificat, celui-ci doit également être renouvelé sur tous les systèmes.

Il convient, comme pour toute décision, de peser le pour et le contre. Dans les petits environnements qu’il est possible de contrôler convenablement ou pour toute utilisation avec Microsoft UCC, il existe certainement de bonnes raisons pour utiliser ces certificats. Si vous désirez savoir quel certificat utiliser dans un environnement Microsoft Exchange, veuillez lire aussi nos FAQ spécifiques «UCC/SAN – certificats Wildcard ou Multi-Domain pour Microsoft Exchange?»

Non, le RFC 2818 ne le permet malheureusement pas:

«La concordance est effectuée en utilisant les règles de congruence spécifiées par le RFC 2459. Si plus d’une identité d’un type donné figure sur le certificat (p. ex. plus d’un nom nomdNS, une concordance avec n’importe lequel d’entre eux est considérée comme acceptable.) Les noms peuvent contenir le caractère Wildcard * considéré comme concordant avec n’importe quel composant ou partie de composant de nom de domaine unique. P. ex. *.a.com correspond à foo.a.com mais pas à bar.foo.a.com. f*.com correspond à foo.com mais pas à bar.com».

Nous vous recommandons par conséquent d’acheter deux certificats SSL Wildcard: un pour *.mondomaine.com et un pour *.sub2.mondomaine.com. Avec les certificats SSL Wildcard de SwissSign, vous ne pouvez pas non plus indiquer de noms multiples (SAN).

Pour chaque adresse e-mail. En tant que personne, vous pouvez demander plusieurs certificats, ayant chacun différentes adresses e-mail.

Certification Authority Authorization (CAA) est un standard Internet publié en 2013 sous le nom RFC 6844.

Les noms de domaine figurent, à l’instar d’un grand annuaire téléphonique, dans un registre de noms diffusé dans le monde entier, le «Domain Name Service» ou DNS en abrégé. Ce service traduit le nom d’un site Internet comme www.swisssign.com en adresse Internet, p.ex. «46.175.9.80», ce qui permet à différents services Internet, comme un navigateur, de l’atteindre. Le Domain Name Service permet en outre d’échanger différentes informations supplémentaires telles que le nom et l’adresse du propriétaire du site.

Grâce au standard CAA, il est désormais possible d’ajouter des enregistrements spécifiant quelles autorités de certification peuvent émettre un certificat pour le domaine mentionné. Si aucune autorité de certification n’est enregistrée, n’importe quelle autorité peut émettre un certificat; par contre, une autorité de certification ne peut émettre aucun certificat pour le domaine si son nom n’y est pas mentionné.

Pourquoi ce règlement?

Ces dernières années, il y a eu de plus en plus d’«attaques de l’homme du milieu», un comportement auquel ont aussi recours les services de renseignements du monde entier. Ces derniers prient, en vue d’espionner les accès à un site Internet crypté, une autorité de certification amie ou complaisante d’émettre un certificat similaire pour ce site Internet. L’attaquant recrée le site Internet avec ce «faux» certificat et détourne d’abord le trafic de données vers le faux site Internet en manipulant le routeur. Il y décrypte et transmet ensuite directement la communication au site Internet original. Le site Internet attaqué et ses visiteurs ne se doutent en général de rien.

Un enregistrement CAA peut réduire le risque si l’on enregistre délibérément les autorités de certification à qui ont fait confiance. Depuis septembre 2017, toutes les autorités de certification admises dans les navigateurs sont contraintes par le CA/Browser Forum, une association de fabricants de navigateurs et d’autorités de certification, de contrôler l’enregistrement CAA avant d’émettre des certificats.

Pour un compte de groupe, vous pouvez en principe demander un certificat Personal ID Gold ou Silver. Ces certificats sont toutefois également des certificats personnels et demandent donc un-e responsable de la clé.

Veuillez suivre les règles de la CP/CPS comme suit:

• Si vous avez acheté un certificat en tant que certificat Gold dans une boutique en ligne et que ce certificat a été directement approuvé par SwissSign, veuillez saisir votre pseudo à la place de vos noms et prénoms. Exemple: pseudo: équipe de vente
• Pour les certificat Silver qui ne sont validés que par courriel, toutes les adresses e-mail peuvent être certifiées dans la mesure où leur existence a été contrôlée.

CAA est un processus par lequel le propriétaire du domaine peut déterminer quelle AC est autorisée à délivrer des certificats pour son domaine. Un enregistrement appelé CAA est entré dans le DNS. Depuis septembre 2017, SwissSign vérifie tous les domaines avant de délivrer des certificats afin de déterminer si vous avez une restriction dans votre dossier CAA. Les domaines qui ont été restreints pour accepter des certificats d'autorités de certification autres que SwissSign ne sont pas autorisés dans le certificat. La demande de certificat est rejetée. Si aucune restriction n'a été effectuée ou que l'enregistrement CAA nomme SwissSign comme CA, le certificat sera autorisé.

Le configurateur CAA vous accompagne dans la définition des paramètres exacts pour votre site web.

Voici quelques exemples selon la technologie DNS utilisée:

Autorisation pour SwissSign de delivrer 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 delivrer des certificats (pas joker)

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 delivrer des certificats (seulement joker)

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

En l’état actuel de nos connaissances, MS Outlook Webmail (OWA) ne prend aucun certificat e-mail en charge. 

Dans la mesure où l’inscription de l’entreprise est incluse dans un certificat, l’entreprise doit avoir donné son accord à cet effet. La procédure d’enregistrement garantit que seuls peuvent être émis des certificats avec inscription de l’entreprise avec laquelle l’entreprise concernée est d’accord.

Adresse e-mail générale

Si des applications partenaires sont connectées à la plateforme Managed PKI de SwissSign au moyen d’une interface automatique (CMC oder RFC 2797) afin de recevoir des certificats, ces applications sont assorties d’un certificat d’accès non personnel.

SwissSign a besoin d’une adresse e-mail pour vous notifier par exemple l’expiration prochaine de votre certificat. Il est recommandé d’utiliser à cette fin une adresse e-mail générale, comme p. ex. celle du département informatique, car la durée de vie de ces certificats est relativement longue (3 à 5 ans).

Commande par voie électronique

L’envoi du document «Contrat et commande de Managed PKI Services» est considéré comme une commande ferme assortie d’une obligation de paiement. La période de facturation annuelle commence à la fin du mois suivant après le début du contrat, sauf accord contraire

La commande peut être transmise par courriel sous forme numérique sans signature électronique qualifiée. Vous recevrez une copie de votre commande dans notre confirmation de commande électronique. Cette étape constitue la conclusion légale du contrat. Seul le contrat d’établissement des Managed PKI Services (services d’ICP gérés) doit porter la signature manuelle ou la signature électronique qualifiée de tous les signataires.

Commande pour plusieurs années

La durée des prestations des services d’ICP gérés est toujours d’une année. Si le contrat n’est pas résilié, elle est ensuite automatiquement prolongée pour une année supplémentaire. Il est toutefois possible de demander des certificats Managed PKI portant sur plusieurs années. Si le contrat est résilié, les certificats sont dans ce cas tout simplement retirés (révoqués).

Indication du compte sur swisssign.net

Vous ne devez indiquer le nom du compte sur la plateforme swisssign.net que si vous êtes déjà client-e de SwissSign et que vous souhaitez par exemple passer une commande supplémentaire. Le compte de la plateforme swisssign.net Managed PKI est totalement indépendant de la boutique en ligne swisssign.com. C’est la raison pour laquelle vous devez utiliser des noms de compte et des mots de passe différents.

Rabais

Les rabais augmentent avec les quantités commandées et sont indiqués avec précision dans le calcul du montant total de la commande.

Transfert de certificats

Si vous avez déjà commandé des certificats dans la boutique en ligne, nous pouvons très bien les transférer dans votre nouveau compte de services d’IPC gérés. Merci de bien vouloir nous l’indiquer dans la case «Remarques générales» à la dernière page du formulaire de commande.

Informations de domaines

Il n’y a pas de corrélation entre les noms de domaines SSL ou e-mail et les types de certificats demandés, ce qui signifie que vous pouvez émettre ultérieurement n’importe quel certificat SSL commandé pour tous les domaines SSL mentionnés. De même, les certificats e-mail commandés peuvent être émis pour tous les noms de domaine mentionnés.

Registre de domaines

Des services comme www.whois.org, www.denic.ch, www.whois.org, www.denic.de etc. vous indiquent à qui appartiennent les domaines. Vous pouvez ainsi prouver que vous êtes le propriétaire du/des domaine(s) concerné(s).

Droit d‘accès au(x) domaine(s)

Vous prouvez votre autorisation d'accès en publiant une valeur aléatoire (secrète) (dans le DNS ou sous forme de fichier TXT sur le serveur web) que vous obtenez via l'accès MPKI. Pour plus d’informations à ce sujet, consultez le chapitre 9 du manuel d'utilisation Managed PKI.

Durées techniques et contractuelles

Un certificat est valable pendant un certain temps (durée technique). Dans les services d’ICP gérés, la période de validité est indépendante de la période contractuelle commerciale (période de prestations). Il est par conséquent possible d’émettre également pendant leur période de validité des certificats dont la validité est bien plus longue que la période de prestations. Le contrat est quant à lui conclu pour une durée illimitée et peut être résilié avec un préavis de trois mois pour la fin de la durée de prestations annuelle.

Révocation et réémission

La révocation d’un certificat (retrait) suivi de sa réémission (p. ex. en cas de changement de collaborateur) ne représente l’acquisition que d’un seul certificat.

Révocation – Fin de contrat

A la fin du contrat, les certificats encore valables sont retirés – soit par vous-même soit par notre service de support. Merci de nous contacter à cet effet: contracts@swisssign.com ou +41 848 77 66 55.

SwissSign publie sur www.swisssign.net une liste générale de tous les certificats émis (LDAP). Cette liste est publique et comparable à un annuaire. Cela prend tout son sens notamment pour les communications e-mail cryptées afin que votre partenaire de communication puisse crypter les messages qu’il vous adresse avec la clé publique qui se trouve dans votre certificat.

La liste publique peut également être directement intégrée dans les programmes e-mail grâce à un paramétrage permettant le cryptage dans les programmes e-mail via la récupération automatisée des certificats.

Si vous ne souhaitez pas que vos certificats figurent dans la liste, cliquez sur «Je ne souhaite pas publier mes certificats.». Vous pouvez également faire modifier ce réglage par la suite moyennant une taxe de CHF/EURO/USD 250. Ce paramètre ne s’appliquera toutefois pas rétroactivement aux certificats déjà émis.

Certificat Silver

Les certificats de niveau Silver sont affichés comme contenant une validation de domaine. Ils contiennent uniquement l’adresse e-mail ou l’adresse du serveur Web. Mais ils peuvent aussi comprendre le nom de l’organisation. Avec les certificats e-mail, il est possible de crypter et signer les courriels mais pas de s’authentifier.

Certificat Gold

Les certificats de niveau Gold sont affichés comme contenant une validation d’organisation ou de personne. Sur le certificat figure l’inscription de l’organisation et sur les certificats e-mail (S/MIME) l’inscription de la personne. Dans les certificats e-mail, le cryptage, la signature et l’authentification sont donc possibles.

Certificats SSL Gold EV

Dans le cadre des services d’ICP gérés, vous pouvez également émettre des certificats SSL Gold EV pour votre entreprise. Ces certificats contiennent une validation d’organisation et affichent une barre verte dans votre navigateur.

Inscription de filiales indépendantes

Vous pouvez également émettre par exemple des certificats pour des filiales. Veuillez noter que pour les certificats Gold avec inscription de l’entreprise, il faut toujours joindre une procuration pour pouvoir utiliser le nom de l’organisation dans le certificat. A cet effet, toutes les organisations doivent remplir et signer le contrat d’établissement des services d’ICP gérés (avec à chaque fois les mêmes personnes responsables de l’accès).

Le certificat pour le responsable d’accès est valable trois ans.

Un QWAC ne peut être émis que si les clés ont été créées sur un HSM correspondant qualifié. La norme minimale FIPS-140-2 niveau 3 est nécessaire à cet effet. Vous confirmez en signant la demande de certificat ou l'acceptation de la politique RA de Managed PKI que vous assurez la génération de clés de cette manière.

Vous pouvez ajouter le numéro de série si le titulaire du certificat est inscrit dans un registre national personnel et si les données personnelles du certificat ne sont pas uniques. Dans les pays scandinaves en particulier, le numéro d'identification personnel est très répandu.

Pour les besoins de l'autorisation, les applications utilisent le nom d'utilisateur principal. Normalement, vous devez entrer votre adresse e-mail. L'adresse e-mail apparaît dans le champ SAN du certificat.

Le format n’est pas défini dans la loi. En règle générale, les formats utilisés sont le format PDF, PDF/A (signature intégrée au document) ou TIFF (signature dans un dossier séparé => fingerprint).

Le certificat indique le nom de l’organisation et cas échéant des précisions comme par exemple la filiale ou le département concerné, le pays du siège de l’organisation. Il peut également fournir des indications sur la commune ou le canton. Le nom de la personne qui fait la demande ne figure pas dans le certificat.

Les indications sur votre organisation doivent en principe être fournies telles qu’elles sont inscrites dans le registre IDE (IDE est l’abréviation du numéro d’identification des entreprises suisse unique). Ce registre comprend toutes les entreprises resp. organisations inscrites sises en Suisse, mais n’est pas limité à ces dernières. Toutes les données figurant ci-dessous ne sont pas des champs obligatoires et nous recommandons de se limiter aux champs obligatoires.
 

• Common Name (Champ obligatoire)

Même inscription qu’à «Organization» (cf. ci-dessous)
 

• Name of the organisation (Champ obligatoire)

Nom de l’organisation selon l’inscription au registre IDE, p.ex. «SwissSign SA». Dans la demande de signature de certificat (CSR) technique, cette valeur doit être inscrite dans l’attribut «Common Name» (CN) que dans l’attribut «Organisation» (O).
 

• Country (Champ obligatoire)

Code pays ISO-3166-alpha-2, habituellement «CH» pour la Suisse
 

• Organisations-Identifier (Champ obligatoire)

Préfixe «NTRCH» suivi du numéro IDE de l’organisation. L’IDE présente la structure suivante:
CHE-ZZZ.ZZZ.ZZZ («Z» remplace un chiffre de 1 à 9)

Exemple: «NTRCH-CHE-109.357.012»

Dans la CSR technique, cette valeur doit être inscrite dans l’attribut «organizationIdentifier».
 

• Organisation details, part 1 (Champ non obligatoire)

Éventuelles indications sur l’unité organisationnelle*

* Seul peut figurer ici le nom d’un département de la société, p.ex. «Finances» ou «Informatique», qui ne peut pas créer une confusion avec une autre organisation ou marque.
 

• Organisation details, part 2 (Champ non obligatoire)

Cf. ci-dessus
 

• StateOrPrivince (Champ non obligatoire)

Canton selon l’inscription, p.ex. «Zoug»
 

• City (Champ non obligatoire)

Commune selon l’inscription, p.ex. «Baar»

Un Hardware Security Module (HSM) – module cryptographique – est un élément matériel qui permet de générer, sauvegarder et utiliser des clés secrètes et de les protéger contre tout accès non autorisé.

Etant donné qu’Adobe Reader accepte le certificat d’organisation SwissSign, il peut être utilisé partout dans le monde pour prouver clairement l’intégrité d’un document et son origine.

Avec le certificat d’organisation, les organisations montrent à leurs partenaires de communication qu’un document PDF n’a pas été modifié après sa signature et apportent la preuve qu’il provient bien d’elle.

Pour révoquer votre certificat d’organisation sur carte à puce (pas HSM), veuillez aller sur la page: https://postsuisseid.ch/de/support/revozierung

La procédure de révocation est la même que pour une SuisseID sur carte à puce. Vous avez besoin à cet effet du code PUK/PIN qui vous a été remis avec votre carte à puce. Si vous ne l’avez plus, merci de vous adresser à notre support technique.

En raison de l'adaptation du service TSA aux nouvelles exigences d'eIDAS et de ZertES, la signature résultante pour le client Adobe a plusieurs octets de plus qu'auparavant. Adobe n'est pas prêt à gérer cela. Par conséquent Adobe donne l'indice pour augmenter la taille de la valeur iSize dans le Registre. Pour cela, consultez l'exemple de correction suivant pour Adobe Acrobat DC. Nous vous recommandons d'enregistrer le fichier de registre correctement avant toute modification. Remarque: le fichier de registre est spécifique à Adobe Version et doit être modifié de manière appropriée.

Copiez et enregistrez le texte ci-dessous comme «fix_adobe.reg» et double-cliquez pour appliquer le correctif:

Éditeur du Registre Windows Version 5.00

[HKEY_CURRENT_USER \ Software \ Adobe \ Acrobat Reader \ DC \ Sécurité \ cASPKI \ cAdobe_TSPProvider]

"ISize" = dword: 00002800

Les horodateurs numériques servent principalement à archiver des documents en temps et en heure ou à définir des documents commerciaux comme par exemple des contrats. Les horodateurs SwissSign peuvent être utilisés en tant que partie du workflow et solutions d’archivage. Bien que chaque signature électronique comprenne déjà l’indication du temps (temps de système local), il peut être utile de relier un temps certifié par une source externe aux données et aux documents. Cette manière de procéder permet de prouver à tout instant de manière simple et transparente l’existence de la série de données concernée à une date déterminée et le fait qu’elle n’a pas été modifiée depuis (intégrité).

Utilisation: par exemple pour les solutions de mise en oeuvre des exigences légales comme Olico, les règles de conformité comme SOX, Bâle II ou les cadres spécifiques à la qualité comme GMP.

Du point de vue technique, l’horodatage est une signature de l’autorité de certification qui contient une référence de temps fiable. Cet horodatage est effectué par l’autorité d’horodatage (TSA) selon la RFC 3161. Le protocole RFC 3161 stipule que la demande contient la valeur hash et que celle-ci est ensuite signée par la TSA. Cela permet de garantir que le service TSA ne peut rien savoir sur le contenu des documents horodatés.

Il existent deux possibilités:

• Vous pouvez installer votre propre service d’horodatage avec un HSM (Hardware Security Module) approprié ou avec un appareil similaire. Nous pouvons vous recommander à cet effet des solutions de partenaires adéquates. Cette solution peut ensuite être utilisée avec un certificat d’horodatage.
• Vous pouvez également utiliser pour les signatures en masse le service d’horodatage de SwissSign via l’interface RFC 3161.  

Pour pouvoir utiliser ce service, vous avez besoin d’un certificat numérique. Avec ce certificat, vous pouvez signer un document pdf et le munir de l’horodateur de Swisssign. Après l’avoir signé, vous vérifiez l’horodateur dans le document en cliquant sur la signature puis en sélectionnant «Propriétés de la signature» et «Date/heure».

Le service d’horodatage peut également être adapté à vos désirs sur demande. Contactez-nous.