Autosigné ou confiance

Intégrité cryptographique vs confiance d'identité : certificat autosigné, chaîne PKI, validation PDF et considérations de sécurité.

Publié le 9 sept. 2026 · Mis à jour le 24 sept. 2026 · 3 min de lecture

Comprendre l’avertissement du lecteur

Ouvrez les propriétés de la signature pour examiner le certificat et l’intégrité du document. Un problème de confiance dans l’émetteur et une modification du document sont deux résultats différents. Ne désactivez pas les contrôles de sécurité pour supprimer l’avertissement. La page Démo explique le périmètre du test.

TL;DR

  • La signature PAdES prouve l'intégrité du PDF (bytes non altérés) et lie le digest à une clé privée.
  • Le certificat X.509 porte la clé publique et une identité déclarée. Autosigné ≠ insecure cryptographiquement ; = pas de chaîne de confiance publique.
  • Sandbox Khatm : certificat de test autosigné. Production : PKI / HSM / prestataire du projet. Khatm n'est pas un PSCo/TSP qualifié.

Deux propriétés distinctes se confondent souvent à la validation : (1) le document a-t-il changé après signature ? (2) l'identité affichée est-elle ancrée dans une autorité de confiance connue du validateur ?

Modèle d'architecture

Application cliente / SaaS
Workflow Khatm (envoi, champs, PAdES, preuves)
Couche confiance (certificat + clé privée)
Autosigné (sandbox)  |  CA / TSP / HSM (prod)
Validateur PDF (Adobe, etc.)

Séparation workflow (Khatm) et couche confiance (PKI / HSM / TSP).

PDF bytes → ByteRange → digest (SHA-256)
                 ↓
         CMS/PKCS#7 Signature
                 ↓
         SignerCert (X.509)
                 ↓
    trust path? ──no──→ integrity OK, identity UNTRUSTED
                 │
                yes
                 ↓
         trust anchor known → identity TRUSTED

Chaîne de validation côté lecteur PDF (abstrait)

Garanties cryptographiques

Quel que soit l'émetteur du certificat, une signature PAdES valide établit :

  • Intégrité : toute modification du ByteRange signé invalide la signature.
  • Authenticité cryptographique : le digest a été signé avec la clé privée correspondant à la clé publique du certificat embarqué.
  • Non-répudiation technique (au sens crypto) : possession de la clé privée au moment de la signature, pas reconnaissance légale automatique.

Ces garanties ne dépendent pas du statut « trusté » du certificat dans Adobe. Elles dépendent de la vérification crypto du CMS et du digest.

Comparaison

PropriétéAutosigné (test)Émis par CA / TSP (prod)
Intégrité PDF (digest)OuiOui
Issuer == SubjectOuiNon (Issuer = CA)
Chaîne jusqu'à trust anchor publicNonOui si l'AC est dans le magasin
UI Adobe typiqueSignature valide, identité non vérifiéeSignature + identité OK
UsageSandbox, CI, démo UX/PAdESDéploiement client, LTV, conformité projet
Contrôle de la clé privéeEnvironnement de testHSM / KMS / TSP selon architecture

Certificat autosigné

Issuer et Subject sont identiques. Aucune CA intermédiaire. Utile pour valider le pipeline PAdES sans dépendre d'une PKI.

openssl req -x509 -newkey rsa:2048 -sha256 -days 365 \
  -keyout test-signer.key -out test-signer.crt \
  -subj "/CN=Khatm Test Signer/O=Sandbox"

# Issuer == Subject → self-signed
openssl x509 -in test-signer.crt -noout -issuer -subject

Exemple conceptuel : certificat de test (ne pas utiliser en production)

Certificat de confiance

Le certificat est émis par une CA (entreprise, locale ou TSP). La clé privée reste sous contrôle d'un HSM, d'un KMS ou du prestataire. En production, Khatm se branche projet par projet sur cette couche. Khatm n'émet pas de certificats de confiance publics et n'est pas un prestataire de confiance qualifié.

  1. Définir le niveau de preuve requis (pays, métier, eIDAS / cadre local).
  2. Choisir l'émetteur (PKI client, TSP, dispositif qualifié).
  3. Protéger la clé privée (HSM/KMS, rotation, audit).
  4. Valider le chemin de confiance dans les lecteurs cibles (Adobe trust store, politiques entreprise).

Considérations de sécurité

  • Ne jamais réutiliser un certificat/clé de sandbox en production.
  • Séparer les environnements : clés de test hors du périmètre prod ; secrets hors du dépôt Git.
  • Protéger la clé privée signataire (HSM/KMS, accès moindre privilège, journalisation des opérations de signature).
  • Un avis « identité non vérifiée » dans Adobe n'implique pas une signature crypto invalide ; ne pas le confondre avec une altération du PDF.
  • Pour B-T / B-LT : horodatage RFC 3161 et données de validation (OCSP/CRL) selon le profil PAdES cible.
  • Revocation : prévoir la politique OCSP/CRL si la durée de vie du document dépasse celle du certificat.

Informations générales, sans valeur de conseil juridique. Vérifiez les exigences applicables à votre opération.

Un certificat autosigné est-il cryptographiquement faible ?

Non par nature. RSA/ECDSA + SHA-256 restent valides. Ce qui manque, c'est le chemin de confiance public jusqu'à une ancre connue du validateur.

Pourquoi Adobe affiche-t-il « identité non vérifiée » sur la démo ?

Parce que la chaîne ne remonte pas à une CA du magasin de confiance. L'intégrité du digest peut néanmoins être valide.

Khatm fournit-il un certificat de confiance public ?

Non. Le sandbox utilise un certificat de test autosigné. En production, on connecte la PKI, le HSM ou le TSP choisi avec le client.

La signature sur khatm.io est-elle qualifiée ?

Non. Le sandbox valide le workflow technique. Khatm ne délivre pas de signature qualifiée ni de reconnaissance réglementaire.