Un certificat serveur sert à la sécurisation des échanges d’informations entre un utilisateur et un système informatique, ou entre deux systèmes informatiques dans le domaine de la santé.

Un certificat peut aussi être associé à une machine ou un système informatique, c’est le cas d’un certificat serveur qui permet d’assurer l’identification du serveur, mais aussi la reconnaissance (par la signature de l'ASIP Santé) et la sécurisation (cryptographie) des échanges d’informations.

Il existe deux types de certificats serveurs :

o        Un certificat serveur, dit « certificat SSL », qui permet la sécurisation d’une voie d’échange avec un correspondant, par exemple une liaison https sur SSL avec un serveur, ceci pendant la durée de la connexion; la sécurisation consiste en l’authentification réciproque du serveur vis-à-vis des utilisateurs (ou d'autres serveurs), ainsi que la confidentialité et l'intégrité des données échangées. Ce certificat contient le nom du domaine du serveur (DNS), permettant d’établir une connexion avec lui ;

o        Un certificat serveur, dit « certificat S/MIME », qui permet la sécurisation des objets échangés, avant ou au moment de l’échange, par exemple par un outil de messagerie mettant en oeuvre le protocole S/MIME; la sécurisation consiste en la signature de l’objet par le serveur, garantissant ainsi l’identité de ce serveur et l’intégrité du contenu de l’objet, et éventuellement en un chiffrement du contenu pour en assurer la confidentialité. Ce certificat contient l’adresse e-mail du serveur, permettant de lui expédier des objets.

L’usage des certificats serveurs répond à un niveau de service rendu par l'ASIP qui est spécifié dans un document appelé Politique de Certification classe 4.

Télécharger : Politique de Certification classe 4

Procédure de demande administrative : VOIR SUR LE SITE ESANTE : http://esante.gouv.fr/espace-cps/guide/procedure-d-obtention-d-un-certificat-serveur-applicatif-phase-administrative

Le responsable d'établissement ou l’un des administrateurs désignés par le responsable de l’organisme demandeur sur le formulaire de demande, réalise les opérations suivantes :

1) Génération de la bi-clé RSA

Le demandeur est responsable de la génération d’une bi-clé RSA (clé privée et clé publique) et de sa protection (la longueur de la clé à générer et à certifier est de 1.024 bits).

2) Génération de la Requête de Certificat Serveur (CSR ou PKCS#10)

Votre requête que l’on nomme CSR ou PKCS#10 est l'élément nécessaire à la fabrication du Certificat Serveur. Elle est générée sur la machine qui sert de serveur.

Elle doit contenir les informations suivantes :

• Le "DistinguishedName" (DN) du serveur doit être composé des éléments suivants et dans cet ordre (c’est l’exemple du dialogue avec un serveur de type Apache de génération de CSR) :
• Le "Country" : Le pays qui a pour valeur un code pays à 2 lettres fixé à "FR" pour la France.
• L' "Organization" (O) qui a pour valeur "GIP-CPS"

·         La "Locality" (L) qui est le département de localisation de la structure. Exemple L=Paris (75).

Remarque : il est important de respecter l’orthographe précise de "Locality" de la carte (du responsable de la structure du ou des administrateur(s)), telle qu’elle apparaît dans l’annuaire CPS (majuscules, minuscules, accentuation, tirets, …).

• L' "organizationalUnitName" (OU) qui est l'identification nationale de structure dans laquelle le serveur est déclaré. Exemple : ou=318003000900013 ;

Remarques : l'attribut "OU" du "DN" des certificats serveur de l'ASIP Santé suit la codification suivante (// étant le signe de concaténation) :

• 0 // numéro ADELI/Rang,
• 1 // numéro FINESS,
• 2 // numéro SIREN,
• 3 // numéro SIRET.

L’"OU" correspond à un OU de carte (celle du responsable et du ou des administrateurs désignés). Ce numéro est accessible de plusieurs façons dans l’annuaire CPS de l'ASIP Santé (il doit en effet correspondre à une structure effective consultable par son département et son identifiant structure).

• le "CommonName" (CN) qui est le nom de domaine pleinement qualifié (FQDN) du serveur qui va être sécurisé. Il est de la forme xxx.yyy où xxxest le nom d'hôte du serveur et yyy est le nom de domaine ;    
  (Exemple : CN=annuaire.asipsante.fr, (annuaire est le nom d'hôte et asipsante.fr est le nom de domaine) ;

·         Optionnellement, l’extension "subjectAltName", présente uniquement dans une demande de certificat de type S/MIME, et qui spécifie l'adresse email du serveur

• SSL (authentification/confidentialité)
• S/Mime (signature/chiffrement)

3) Envoi de la CSR au Serveur d'Inscription par l’administrateur

Suivant les cas précédents la procédure de demande de certificat est la suivante :

A) Si l’administrateur utilise l'outil Cleo de l'ASIP Santé (de génération de CSR), l'envoi du CSR/PKCS#10 est automatiquement effectué à l'opérateur de certification.

B) Si l’administrateur dispose d’un outil de messagerie sécurisé CPS (signature par le demandeur et chiffrement), il peut adresser directement le CSR/PKCS#10 généré sur son serveur en respectant le standard S/MIME à l’adresse suivante : inscription@certif.gip-cps.fr

C) Dans les autres cas, le demandeur génère sa bi-clé et le PKCS#10 sur son serveur puis le transmet à l'ASIP Santé sur support ou par mail à l’adresse suivante : certificat.classe4@gip-cps.fr

La réponse est donnée par l’Autorité de Certification dans les 2 jours ouvrés qui suivent la réception de la requête.

4) Génération et restitution du certificat par l’Autorité de Certification

Le message contenant le CSR est accepté par l’Opérateur de Certification de l'ASIP Santé, si les conditions suivantes sont remplies :

1. Le message peut être déchiffré par le serveur d’Autorité d’Enregistrement (AE) ;
2. La CSR est signée avec le certificat public CPS de classe 3, c'est-à-dire avec l’une des cartes de la famille CPS (désignée dans les annexes B à C) ;
3. La signature du message est valide : contrôle cryptographique, contrôle du chemin de certification et de non-révocation ;
4. Le signataire détient les habilitations suffisantes : droits d'administration du serveur ou du domaine Internet ;
5. La preuve de possession de la clé privée est faite ;
6. La structure de la CSR est conforme ;
7. La structure est référencée dans l'annuaire (C=fr, O=gip-cps, L=département, OU=idnatstruct) ;
8. Le type de certificat demandé (SSL ou S/MIME) doit être cohérent avec le contenu de l'extension subAltName.
9. La cohérence du DN est établie, les cas possibles :

• Il existe dans l’annuaire CPS un autre DN composé d’un CN identique : rejet de la demande ;
• Le DN est absent de l’annuaire CPS : la demande est une demande initiale ;
• Le DN est présent dans l’annuaire CPS : il s’agit d’un renouvellement (révocation implicite de l’ancien certificat) ;