Certificats, habilitations et cycle de vie

L’API ne se contente pas de vérifier qu’un identifiant de certificat existe. Le certificat doit être disponible pour l’organisation et l’utilisateur appelant doit être autorisé à l’utiliser.

Préparer le certificat

Pour le cachet, choisissez un certificat de personne morale et le niveau de confiance approprié. Enterprise+ Cloud et les certificats de signature de personne physique ont des usages distincts. Un certificat qualifié et un dispositif qualifié de création ne se déduisent pas d’un nom de format dans une requête.

Les règles d’identification, de délivrance et d’utilisation sont définies dans les politiques et CGU de certification. L’ouverture commerciale d’un abonnement n’émet pas automatiquement un certificat : le parcours de délivrance doit être achevé.

Conditions techniques d’utilisation

Condition	Conséquence
Même organisation	Le compte appelant doit appartenir à l’organisation du certificat
Habilitation explicite	Un utilisateur de la même organisation n’est pas automatiquement autorisé
Certificat émis et exploitable	Les données de certificat et la clé associée doivent être disponibles
Validité utilisable	Un certificat expiré est refusé pour de nouvelles opérations
Absence de désactivation ou destruction de clé	Une clé désactivée ou détruite ne permet plus de créer un cachet
Abonnement Click&Cert actif	Condition d’accès aux routes métier de l’API

La gestion des utilisateurs autorisés s’effectue par les fonctions d’administration habilitées. Ne construisez pas une intégration cliente sur les routes internes d’administration des certificats ou des abonnements.

Consulter le certificat public

GET /api/clickncert/certificates/{certificate_uid} renvoie certificate_data, qui contient les données publiques du certificat. La route contrôle l’accès au certificat et impose un UID au format attendu. Elle n’exporte pas la clé privée.

curl --fail-with-body --silent --show-error \
  --user 'UTILISATEUR_API' \
  --header 'Accept: application/json' \
  'https://my.datasure.net/api/clickncert/certificates/UID_CERTIFICAT'

Remplacez UID_CERTIFICAT par l’UUID réel. Référence certificat.

Renouvellement et révocation

Anticipez le renouvellement avant la fin de validité. Un nouveau certificat peut nécessiter un nouvel UID et de nouvelles habilitations ; ne figez pas ces valeurs dans le code applicatif. Testez la bascule et conservez le certificat historique avec les documents qu’il a cachetés.

En cas de soupçon de compromission ou d’usage non autorisé, suivez la procédure de révocation et prévenez le support. Distinguez la désactivation d’un accès ou d’une clé dans l’application et le statut de révocation du certificat dans l’infrastructure de confiance.

La fin de validité interdit la création de nouveaux cachets avec ce certificat. La validation des cachets déjà produits relève d’une analyse historique avec les preuves de date et de révocation disponibles ; voir Validation.