Quand une AC interne sauve une application critique : passage d’un certificat Sectigo à un code signing interne Java

Quand notre certificat Sectigo de signature de code a menacé d'expirer, toute l’application SuperPlan (Java Web Start) risquait l'arrêt total. Voici comment nous avons basculé en urgence sur notre Autorité de Certification interne (AD CS), mis OpenWebStart en confiance et rétabli la signature des JARs — sans interruption de service.

Introduction

Le certificat de code signing Sectigo utilisé pour l’application de scolarité SuperPlan arrivait à expiration le 16 novembre.
Cette application Java Web Start, essentielle pour la gestion de la scolarité, aurait été bloquée du jour au lendemain : sans signature valide, tous les JARs deviennent inacceptables pour Java.

En moins de 24 heures, nous avons :

  1. Émis un nouveau certificat Code Signing via l’autorité de certification interne (AD CS).
  2. Mis à jour le keystore du projet et la chaîne de confiance.
  3. Fait reconnaître l’AC interne par OpenWebStart et par les JVM Java 1.8_452 / OWS 1.12.
  4. Resigné et redéployé les JARs via la CI (Gradle + Jenkins/GitLab).

Résultat : aucune perte d’accès, même en environnement TSE.
Une démonstration concrète de résilience et de souveraineté technique.

Contexte et enjeu

Le client Java Web Start de SuperPlan s’exécute en mode <all-permissions/>.
Dans cette configuration, tous les JARs référencés dans le JNLP doivent être signés par le même certificat, valide et de confiance.
À l’expiration du certificat Sectigo, le lancement aurait affiché des erreurs de type :

« The application’s digital signature has expired and cannot be verified »

et bloqué l’accès à l’ensemble des utilisateurs.

Ne pouvant dépendre d’un renouvellement externe incertain, la solution a été de basculer vers une signature interne basée sur notre infrastructure Microsoft AD CS.

Architecture de confiance

  • AC interne : Autorité de certification d’entreprise (Microsoft AD CS)
    Modèle de certificat : CodeSigning-3Y (validité 3 ans)
  • Keystore projet : PKCS#12 → jks/20251023-code-signing.jks, alias : server
  • OpenWebStart : truststore utilisateur ou centrale (trusted.certs)
  • CI/CD : Gradle + tâche de signature (jarsigner + horodatage Digicert), Jenkins/GitLab CI

1️⃣ Génération et émission du certificat Code Signing interne

# CSR depuis la clé existante (alias server), EKU codeSigning
keytool -certreq -alias server \
  -keystore jks/20251023-code-signing.jks -storepass password -keypass password \
  -file jks/superplan-CodeSigning-3Y.csr \
  -sigalg SHA256withRSA -ext KU=digitalSignature -ext EKU=codeSigning

# Variante DER pour soumission via la MMC (facultatif)
openssl req -in jks/superplan-CodeSigning-3Y.csr -outform DER -out jks/superplan-CodeSigning-3Y.req

# Soumission à l’AC interne via le modèle CodeSigning-3Y
certreq -submit -attrib "CertificateTemplate:CodeSigning-3Y" jks/superplan-CodeSigning-3Y.csr jks/superplan-2025.cer

Vérifications :

  • EKU = Code Signing (1.3.6.1.5.5.7.3.3)
  • KeyUsage = DigitalSignature

2️⃣ Mise à jour du keystore du projet

# Import de la racine interne
keytool -importcert -noprompt -alias RootCA \
  -file jks/rootCA.cer -keystore jks/20251023-code-signing.jks -storepass password

# Import du certificat émis
keytool -importcert -alias server \
  -file jks/superplan-2025.cer \
  -keystore jks/20251023-code-signing.jks -storepass password -keypass password

# Vérification
keytool -list -v -alias server -keystore jks/20251023-code-signing.jks -storepass password

3️⃣ Reconnaissance de l’AC interne dans Java et OpenWebStart

Les JVM ne lisent pas le magasin de certificats Windows.
Il faut donc injecter la racine interne dans les truststores Java et pointer OpenWebStart dessus.

a) Truststore centralisée

Un script PowerShell alimente une truststore centrale C:\script\trusted.certs et configure le deployment.properties utilisateur :

$CertRoot   = 'C:\script\rootCA.cer'
$CentralStore = 'C:\script\trusted.certs'
$AliasRoot   = 'RootCA'
$StorePass   = 'password'

$keytool = 'C:\Program Files\OpenWebStart\jre\bin\keytool.exe'

# Import racine
& $keytool -importcert -noprompt -alias $AliasRoot -file $CertRoot `
  -keystore $CentralStore -storetype JKS -storepass $StorePass

# Configuration OWS
$deploy = "$env:USERPROFILE\.config\icedtea-web\deployment.properties"
"deployment.user.security.trusted.certs=C\:\\script\\trusted.certs" | Out-File -FilePath $deploy -Encoding utf8 -Append
"deployment.user.security.trusted.certs.locked=true" | Out-File -FilePath $deploy -Encoding utf8 -Append

b) Optionnel : import du certificat de signature final

Permet d’éviter le message “New signer prompt” lors du premier lancement :

& $keytool -importcert -noprompt -alias superplan-2025 `
  -file jks/superplan-2025.cer -keystore $CentralStore -storepass $StorePass

4️⃣ Resignature automatisée des JARs dans la CI/CD

Chaque build signe et horodate automatiquement les artefacts via jarsigner.
Le script suivant a été intégré au pipeline :

#!/usr/bin/env bash
set -euo pipefail

TARGET_DIR="${1:-}"
if [[ -z "$TARGET_DIR" || ! -d "$TARGET_DIR" ]]; then
  echo "Usage: $(basename "$0") <directory-containing-jars>" >&2
  exit 1
fi

KEYSTORE_PATH="${JAR_SIGN_KEYSTORE:-$PWD/jks/20251023-code-signing.jks}"
STOREPASS="${JAR_SIGN_STOREPASS:-password}"
ALIAS="${JAR_SIGN_ALIAS:-server}"
TSA_URL="${JAR_SIGN_TSA_URL:-https://timestamp.digicert.com}"

find "$TARGET_DIR" -type f -name '*.jar' -print0 | while IFS= read -r -d '' jar; do
  echo "Signing $jar"
  jarsigner -keystore "$KEYSTORE_PATH" -storepass "$STOREPASS" \
            -sigalg SHA256withRSA -digestalg SHA-256 -tsa "$TSA_URL" \
            "$jar" "$ALIAS"
done
  • Horodatage activé pour garantir la validité post-expiration du certificat.
  • Vérification automatique dans le pipeline : jarsigner -verify -verbose -certs mon.jar

5️⃣ Création et publication du modèle Code Signing dans AD CS

  1. Ouvrir certtmpl.msc
  2. Dupliquer le modèle Code Signing
  3. Nommer par ex. : CodeSigning-3Y
  4. Paramètres clés :
    • Subject Name : Supply in the request
    • Key Usage : Digital Signature
    • EKU : Code Signing uniquement
    • Validity period : 3 ans
    • Security : droits Enroll pour les comptes CI/CD
  5. Publier sur la CA :
    certsrv.msc → Certificate Templates → New → Certificate Template to Issue → CodeSigning-3Y

6️⃣ Enseignement organisationnel : quand la réactivité technique protège la continuité

Au-delà de l’aspect purement technique, cet épisode met en lumière un enseignement organisationnel essentiel pour toute DSI : la capacité à déclencher une action rapide face à un risque identifié.

Dans de nombreuses directions informatiques, la lenteur des processus de validation n’est pas liée à un manque de compétence, mais à une chaîne de décision trop verticale.
Chaque validation successive ajoute un délai, alors que certaines menaces comme l’expiration d’un certificat ou une faille critique exigent une réaction immédiate.

L’enjeu est de rendre la réactivité possible : permettre aux équipes techniques d’agir dans un cadre clair et légitime, dès lors qu’il s’agit de garantir la continuité du service.

Une gouvernance moderne ne s’oppose pas à l’autonomie : elle la rend possible et l’encadre pour mieux protéger la résilience du système d’information.

Résultats obtenus

✅ Aucun arrêt de service — les clients Java continuent de lancer l’application sans incident.
✅ Gestion simplifiée sur les postes TSE via une truststore centralisée.
✅ Sécurité maintenue : EKU stricts, horodatage et signature interne contrôlée.
✅ Souveraineté renforcée — plus de dépendance à Sectigo ou Digicert pour les signatures internes.

Bonnes pratiques

  • Ne jamais mélanger plusieurs certificats de signature dans un même ensemble de JARs.
  • Surveiller la date d’expiration du certificat via script ou supervision.
  • Limiter la portée des AC internes aux environnements maîtrisés.
  • Archiver les keystores et certificats pour traçabilité.

Conclusion

Cette opération a montré qu’on peut reprendre la maîtrise complète du code signing Java tout en évitant une interruption de service.
Grâce à un modèle interne AD CS, un keystore unique et une intégration CI, la confiance Java a été rétablie sans dépendance externe.

Une leçon simple : savoir signer son propre code, c’est garantir la continuité de ses applications critiques.

🔎 SEO

  • Titre SEO : “Comment une autorité interne AD CS peut remplacer un certificat Sectigo Code Signing expiré sous Java /OpenWebStart”
  • Description : “Guide complet pour mettre en place une signature de code Java interne avec AD CS, intégrer la CA dans OpenWebStart et automatiser la resignature via jarsigner.”
  • Mots-clés : Java code signing, OpenWebStart, AD CS, certreq, jarsigner, Sectigo, autorité interne, PKI interne, trusted.certs, TSE, certificat interne.
Étiquettes

Publications similaires