chkcert_V1R1M1.py
Certificate Information & Control Tool — Un outil, tous les formatsOne tool, all formats de keystoreCertificate Information & Control Tool — One tool, all keystore formats
Résumé exécutifExecutive Summary
chkcert_V1R1M1.py est un outil CLI Python mono-fichier destiné à l'inspection, l'audit et le reporting de certificats TLS/PKI dans des environnements d'infrastructure variés. Il couvre l'intégralité du spectre des keystores rencontrés en entreprise : IBM MQ/GSKit (.kdb), Java (.jks, .p12, .jceks), formats ouverts (.pem, .der, .p7b, .csr) et le truststore Java cacerts.
Il fonctionne en mode local ou remote SSH/SFTP, génère des rapports HTML et JSON auto-contenus, et est conçu pour être compilé avec Nuitka en binaire standalone ou onefile pour déploiement sans Python sur les serveurs cibles.
Pourquoi cet outil ? Dans les grandes infrastructures, les certificats sont répartis entre des dizaines de keystores hétérogènes, sur des plateformes différentes (Linux, Windows, AIX), gérés par des équipes distinctes. Aucun outil du marché ne couvre l'ensemble de ces formats en ligne de commande, sans agent, sans serveur central. chkcert comble ce manque avec une approche sans installation, sans dépendance sur le serveur cible.
Contexte & enjeuxContext & Challenges
Le problème des cycles courts des Autorités de CertificationThe problem of short CA certificate cycles
Depuis 2020, les grandes AC (DigiCert, Sectigo, GlobalSign, Let's Encrypt) ont progressivement réduit la durée de validité maximale des certificats TLS :
- Avant 2020 : certificats valables jusqu'à 3 ans (1095 jours)
- 2020 : passage à 398 jours maximum (13 mois)
- 2023 : Apple/Mozilla poussent vers 90 jours (Let's Encrypt)
- 2026–2027 : Google Chrome impose 90 jours maximum pour les certificats DV/OV publics. CA/Browser Forum vote en faveur de 47 jours d'ici 2027.
Cette réduction drastique rend le suivi manuel des expirations impossible à l'échelle — un parc de 50 keystores nécessite potentiellement 200+ renouvellements par an si les cycles passent à 47 jours.
L'hétérogénéité des formats : le défi des grandes infrastructuresFormat heterogeneity: the challenge of large infrastructures
Une infrastructure financière ou industrielle typique mêle :
Chaque format nécessite un outil différent. chkcert unifie l'analyse de tous ces formats sous une interface CLI commune et une sortie JSON homogène.
Incidents réels — le coût des certificats expirésReal incidents — the cost of expired certificates
Les expirations de certificats ne sont pas anodines. Voici des incidents documentés qui illustrent l'enjeu :
Microsoft Teams est devenu inaccessible dans le monde entier pendant environ 3 heures. La cause racine était l'expiration d'un certificat TLS utilisé pour l'authentification des services. Des millions de salariés se sont trouvés dans l'incapacité de communiquer, d'accéder aux fichiers partagés ou de rejoindre des réunions. L'incident est survenu un lundi matin, en pleine heure de pointe.
→ Coût estimé : plusieurs millions d'euros en perte de productivité (entreprises utilisant Teams comme outil principal).
Un certificat expiré dans le logiciel de gestion réseau d'Ericsson a provoqué la désactivation simultanée de réseaux 4G chez une douzaine d'opérateurs mondiaux. En Grande-Bretagne, O2 a perdu 32 millions d'abonnés pendant 11 heures. Les systèmes de paiement sans contact, les terminaux de point de vente et les applications de transport en commun ont été paralysés.
→ Coût Ericsson : ~95 millions d'euros en compensation + atteinte massive à la réputation.
Spotify a subi une interruption de service sur son application mobile et web suite à l'expiration d'un certificat TLS sur un composant interne d'authentification. L'incident s'est produit en dehors des heures de bureau, retardant la détection.
→ Perte estimée en abonnements + dommage image en période de forte concurrence (Apple Music, Amazon Music).
L'expiration d'un certificat CA intermédiaire a rompu la chaîne de confiance SSL de LinkedIn, rendant le site inaccessible sur certains navigateurs et clients mobiles. Ce type d'incident illustre que le certificat leaf n'est pas le seul à surveiller — les CA intermédiaires ont également des dates d'expiration.
📌 Ce que chkcert apporte : La simulation de date (--date 2038-12-31) permet de projeter dans le futur et de détecter les expirations avant qu'elles ne surviennent — y compris sur les CA intermédiaires et racines. Les fichiers JSON joints à ce rapport illustrent précisément ce cas : des certificats Sectigo analysés avec date de référence 2038-12-31 révèlent une expiration de 1014 jours.
Métriques clésKey Metrics
| Dimension | Valeur | Détail |
|---|---|---|
| Dépendances tierces obligatoires | 1 | cryptography (paramiko optionnel — mode remote) |
| OS supportés | 4 | Windows, Linux, macOS, AIX (via binaire Nuitka) |
| Compatibilité compilateur | Nuitka | --onefile + --standalone, NUITKA_ONEFILE_PARENT géré |
| Encodage cible | UTF-8 | Avec reconfigure() pour Windows |
| Taille min RSA (défaut) | 2048 bits | Surcharger via constantes_V1R1M1.properties |
| Taille RSA pour les CSR générés | 4096 bits | Surcharger via constantes_V1R1M1.properties |
| Profondeur max chaîne de cert | 20 | _CHAIN_MAX_DEPTH |
| Seuil clé faible/désactivée | ≤ 1048 bits | WEAK_KEY_THRESHOLD (fixe dans le code) |
Plateformes ciblesTarget platforms — Unix & Windows
chkcert est conçu pour fonctionner de manière identique sur toutes les plateformes d'infrastructure rencontrées en entreprise. Le binaire Nuitka onefile supprime toute dépendance à Python sur le serveur cible.
🐧 Linux — Distribution principale🐧 Linux — Primary distribution
Environnement naturel de l'outil. Testé sur RHEL/AlmaLinux, Ubuntu, Debian. Compatible avec les systèmes de fichiers case-sensitive. Supports ANSI natif.
Outils externes : runmqakm (IBM MQ), gsk8capicmd_64 (GSKit), keytool (JDK)
🪟 Windows — Support complet🪟 Windows — Full support
Activation automatique des codes ANSI via GetConsoleMode / SetConsoleMode (ENABLE_VIRTUAL_TERMINAL_PROCESSING). Encodage UTF-8 forcé via reconfigure(). Séparateurs de chemins normalisés.
Compatible PowerShell, cmd.exe, Windows Terminal. Binaire .exe via Nuitka --windows-console-mode=attach
🍎 macOS🍎 macOS
⚙️ AIX / IBM i⚙️ AIX / IBM i
Supporté via le binaire Nuitka compilé sur Linux et copié sur AIX (si compatible ABI). Principal usage : analyse des keystores IBM MQ sur plateformes UNIX propriétaires. Python n'est pas requis sur AIX.
Gestion des outils externes par OSExternal tools management by OS
| Format | Linux/AIX | Windows | macOS |
|---|---|---|---|
| .kdb | runmqakm · gsk8capicmd_64 | runmqakm.exe · gsk8capicmd.exe | gsk8capicmd (GSKit MacOS rare) |
| .jks .p12 | keytool · runmqktool | keytool.exe · runmqktool.exe | keytool (JDK macOS) |
| .pem .der .p7b .csr | aucun — cryptography pure | aucun — cryptography pure | aucun — cryptography pure |
| cacerts | keytool auto-détecté | keytool.exe auto-détecté | keytool auto-détecté |
💡 Principe fondamental : Python et cryptography ne sont jamais requis sur le serveur cible en mode remote. Seul SSH/SFTP est nécessaire. Toute l'analyse s'effectue en local sur la machine de l'opérateur.
ArchitectureArchitecture générale
Le script est mono-fichier et se décompose en 12 couches logiques :
__main__
├─ init couleurs + quiet mode
├─ argparse → args
├─ _ctx.reset_all()
├─ résolution de password (_resolve_password)
├─ construction de files_to_process
│ ├─ --remote → _run_remote_analysis() [SFTP]
│ ├─ --dir → rglob + filtre extensions
│ └─ --file → glob ou chemin direct
└─ for file in files_to_process:
├─ process_one_file()
│ └─ detect_file_type() → _dispatch_file()
│ ├─ process_pem() .cer .pem .crt .arm .der
│ ├─ process_p7b() .p7b
│ ├─ process_kdb() .kdb [runmqakm/gsk]
│ ├─ process_java_keystore() .p12 .pfx .jks .jck .jceks
│ ├─ process_cacerts() cacerts JKS
│ └─ process_csr() .csr
├─ show_chain_summary / show_chain_serial
├─ show_diagnostics_resume()
├─ show_remediation_report() [si --report + mono-fichier]
└─ generate_json_output / generate_html_output [si --output]
Un outil — tous les formats de keystoreOne tool — all keystore formats
C'est la valeur ajoutée centrale de chkcert : une seule commande, quelle que soit la technologie du keystore. L'outil détecte automatiquement le format et appelle l'outil externe approprié ou utilise la librairie Python cryptography directement.
| Extension(s) | Format | Outil requis | Encodage auto | CSRs inclus | Usage typique |
|---|---|---|---|---|---|
| .kdb / .cms | IBM MQ CMS/GSKit | runmqakm · gsk8capicmd_64 | — | Oui | WebSphere, MQ Channel SSL |
| .jks / .jck / .jceks | Java KeyStore | keytool · runmqktool | — | Non | Tomcat, Spring, WAS |
| .p12 / .pfx / .pkcs12 | PKCS#12 | keytool | — | Non | IIS, Exchange, Java |
| .pem / .cer / .crt / .arm | X.509 PEM / DER auto-détecté | aucun | Oui | Non | Nginx, Apache, HAProxy |
| .der | X.509 DER binaire | aucun | Oui | Non | Exports Microsoft, Java |
| .p7b | PKCS#7 bundle | aucun | Oui | Non | Chaînes AC intermédiaires |
| .csr | Certificate Signing Request | aucun | Oui | N/A | Pipeline de renouvellement |
| cacerts (JKS) | Java cacerts truststore | keytool (auto-detect JDK) | — | Non | Audit du truststore JVM |
✅ Auto-détection PEM/DER : _detect_pem_or_der() utilise une heuristique à 4 règles — marqueurs PEM (-----BEGIN), tag ASN.1 0x30, validité UTF-8, fallback binaire — sans se fier uniquement à l'extension fichier. Un fichier .cer peut être PEM ou DER : chkcert le détecte automatiquement.
Fonctions principalesMain functions
| Fonction | Rôle | Retour |
|---|---|---|
| show_cert(cert, ext, alias, count) | Orchestrateur analyse : extraction, expiration, audit algo/clé/self-signed, affichage, actions, registre | None |
| difference_between_dates(expiry, ref) | Calcule durée restante avec référence date simulée (--date) ou now | tuple[str, str, str] |
| _is_self_signed(cert) | Vérification cryptographique RSA/EC/Ed* — plus robuste qu'une comparaison DN | bool |
| check_cert_strength(cert) | Classifie l'algorithme de signature : OK/Weak/Insecure/disabled/Unknown | tuple[str, str] |
| _extract_certificate_info(cert, alias) | Extrait toutes les métadonnées X.509 en CertificateInfo | CertificateInfo |
| _build_csr_cmd(source, alias, dn, size, algo) | Génère la commande de renouvellement CSR adaptée au format | str |
| _resolve_chain(rec, registry, token_map) | Remonte la chaîne jusqu'à la racine (max 20 niveaux) | list[str] |
| generate_json_output(filename) | Sérialise _ctx en JSON horodaté dans json/YYYYMMDD/<ext>/ | str (chemin) |
| generate_html_output(filename) | Rapport HTML auto-contenu avec tables, badges, remédiation, chaînes | str (chemin) |
| _integrity_check() | Contrôle d'intégrité du source — None en mode binaire Nuitka | bytes | None |
| _output_root() | Résout le répertoire de sortie : W/U_FLD_TARGET_ANA_CER ou répertoire du script | str |
| _parse_reference_date(date_arg) | Parse --date : YYYY-MM-DD, +N ou -N jours depuis today | datetime UTC |
| process_one_file(filename, pw, args) | Valide chemin, détecte format, dispatche vers process_*() | None |
Interface CLICLI interface
| Argument | Catégorie | Description |
|---|---|---|
| --file FILE | input | Fichier unique ou glob (*.kdb, **/*.pem) |
| --dir DIR | input | Répertoire — scan récursif rglob |
| --cacerts [FILE] | input | JKS cacerts Java — auto-detect JDK ou chemin explicite |
| --password PASS | auth | Mot de passe du keystore |
| --stashed | auth | Utiliser le fichier .sth (KDB uniquement) |
| --alias PATTERN | filtre | Filtre case-insensitive sur alias/CN/subject/issuer |
| --ext EXT [EXT...] | filtre | Filtre extension avec --dir (keystore, certificate, request) |
| --date DATE | simulation | Date de référence YYYY-MM-DD ou +N/-N jours — visible dans HTML/JSON |
| --chaining MODE | PKI | alias | serial | both — construction et affichage des chaînes |
| --output FORMAT | export | json | html | both |
| --report | export | Rapport de remédiation prioritisé P1/P2/P3 |
| --cmd | export | Inclure les commandes de renouvellement dans --report |
| --remote HOST | remote | Hostname SSH du serveur distant |
| --remote-user USER | remote | Utilisateur SSH |
| --remote-key KEYFILE | remote | Clé privée SSH (recommandé) |
| --remote-port PORT | remote | Port SSH (défaut : 22) |
| --trust-new-host | remote | AutoAddPolicy pour un host key inconnu |
| --quiet | affichage | Supprime la console — conserve JSON/HTML + barre de progression |
| --no-color | affichage | Désactive les codes ANSI (scripts, logs) |
| --showcmd | debug | Affiche les commandes runmqakm/keytool avant exécution |
Sorties généréesGenerated outputs
Structure des répertoires de sortieOutput directory structure
<output_root>/ ← W/U_FLD_TARGET_ANA_CER ou répertoire script html/<YYYYMMDD>/<ext>/ ← rapports HTML par fichier html/<YYYYMMDD>/summary/ ← résumé multi-fichiers HTML json/<YYYYMMDD>/<ext>/ ← exports JSON par fichier json/<YYYYMMDD>/summary/ ← résumé multi-fichiers JSON
Avec --date 2038-12-31, le répertoire prend la date simulée (20381231/) et un badge rouge 📅 ref 2038-12-31 apparaît dans l'en-tête HTML. Le champ reference_date est présent dans tous les JSON.
JSON — schéma complet par fichierJSON — full schema per file
"source_file": "/home/joker/Tools/certificate/new_sectigo/AuthentificationCAEVR36.cer",
"hostname": "check-certificat",
"generated_at": "2026-06-02T14:49:27.628332+00:00",
"reference_date": "2038-12-31", ← date simulée --date
"certificates": [ { label, subject, issuer, serial, key_size, key_algo, ca_flag,
sig_algo, key_usage, eku, san, basic_constraints, matched } ],
"chain_alias": [ { "chain": [...], "tag": "" } ],
"chain_serial": [ { "chain": [...], "tag": "(root)" } ],
"warnings": [],
"errors": [ "❌ Error: Certificate 1 Serial 6d4f... expired 1014 days ago." ],
"action_items": [{
"priority": 1, "severity": "CRITICAL", "category": "EXPIRY",
"action": "Renew the certificate immediately.",
"cmd": "openssl genrsa -out key.pem 4096 ..."
}]
}
JSON Summary — résumé multi-fichiersJSON Summary — multi-file summary
"source": "/home/joker/Tools/certificate/new_sectigo/",
"reference_date": "2038-12-31",
"totals": { "files": 3, "certificates": 3, "errors": 2 },
"files": [
{ "file": "AuthentificationCAEVR36.cer", "status": "ERROR" },
{ "file": "AuthentificationCAOVR36.cer", "status": "ERROR" },
{ "file": "AuthentificationRootR46.cer", "status": "OK" }
]
}
Export JSON & intégration PKI maisonJSON export & in-house PKI integration
📌 Vision à terme : La sortie JSON structurée de chkcert est conçue pour être consommée par une PKI d'entreprise maison — un orchestrateur central qui agrège les résultats de tous les serveurs, déclenche des alertes, pilote les renouvellements et alimente un tableau de bord de conformité.
Pourquoi le JSON chkcert est adapté à l'intégration PKI maisonWhy chkcert JSON is suited for in-house PKI integration
Le schéma JSON est stable, versionné et exhaustif. Chaque certificat expose : label, subject/issuer, numéro de série, algorithme, taille de clé, dates, chaîne de confiance, statut et plan d'action. Le champ reference_date permet de rejouer les analyses avec n'importe quelle date future.
| Usage PKI | Champ JSON utilisé | Exemple |
|---|---|---|
| Déclenchement d'alertes expiration | action_items[].severity = "CRITICAL" | Email/Slack si P1 présent |
| Tableau de bord conformité | totals.errors / totals.warnings | Dashboard Grafana / Kibana |
| Inventaire automatique | certificates[].serial_number | Base de données PKI centrale |
| Déclenchement renouvellement | action_items[].cmd | Pipeline CI/CD automatisé |
| Audit algorithmique | certificates[].signature_algorithm | Détection SHA-1/MD5 à éliminer |
| Simulation d'anticipation | reference_date + errors[] | Prévision des expirations à 6/12 mois |
| Suivi des chaînes de confiance | chain_alias[].chain | Détection des CA intermédiaires expirés |
ArchitectureArchitecture d'intégration suggérée
Cron / Scheduler (quotidien)
└─ chkcert --dir /path/to/keystores --quiet --output json
└─ json/YYYYMMDD/summary/hostname_summary_*.json
└─ Collecteur PKI central (Python / Node / Go)
├─ Parsing JSON chkcert
├─ Base de données inventaire (PostgreSQL / SQLite)
├─ Alertes (Prometheus Alert / PagerDuty / Teams webhook)
├─ Dashboard (Grafana / Kibana)
└─ Déclencheur renouvellement (Ansible / Terraform / script)
⚠️ Limitation actuelle : chkcert produit les JSON mais ne dispose pas encore d'un collecteur central intégré. L'intégration PKI maison nécessite un développement complémentaire côté consommateur du JSON. C'est l'étape V1R2M0 envisagée.
Exemples réels — fichiers jointsReal chkcert_V1R1M1_examples — attached files
Les fichiers JSON joints à ce rapport illustrent chkcert en action sur des certificats réels avec simulation temporelle.
Cas 1 — Certificats Sectigo avec date future 2038-Case 1 — Sectigo certificates with future date 2038-
Commande utilisée : ./chkcert --dir /home/joker/Tools/certificate/new_sectigo/ --date 2038-12-31 --output json --report
Résultat (summary) : 2 erreurs CRITICAL sur 3 fichiers — les certificats CA EV R36 et CA OV R36 de Sectigo seraient expirés depuis 1014 jours à la date de référence 2038-12-31. Seul le Root R46 reste valide.
| Fichier | Certificat | Clé | Algo sig. | Statut à 2038-12-31 |
|---|---|---|---|---|
| AuthentificationCAEVR36.cer | Sectigo Public Server Authentication CA EV R36 | RSA 3072 | sha384WithRSA | ❌ EXPIRÉ +1014 jours |
| AuthentificationCAOVR36.cer | Sectigo Public Server Authentication CA OV R36 | RSA 3072 | sha384WithRSA | ❌ EXPIRÉ +1014 jours |
| AuthentificationRootR46.cer | Sectigo Public Server Authentication Root R46 | RSA 4096 | sha384WithRSA | ✅ OK |
💡 Ce cas illustre l'utilité critique de la vérification des CA intermédiaires — pas seulement des certificats leaf. Un Root valide ne suffit pas si l'intermédiaire est expiré (cas LinkedIn 2021 ci-dessus).
Cas 2 — Certificat WMQ IBM MQ, date future 2038-07Case 2 — IBM MQ WMQ certificate, future date 2038-07
Fichier : test01.cer — Certificat WMQ_HORS_PROD_QMGR_QMU01R (Crédit Agricole Group, PKI privée).
Statut à 2038-07-02 : expiré depuis 4814 jours (~13 ans). Ce certificat RSA 2048 / SHA-256 / clientAuth+serverAuth est ancré dans une PKI privée (CA Credit Agricole Server non trouvée dans le keystore).
| Champ | Valeur |
|---|---|
| CN | WMQ_HORS_PROD_QMGR_QMU01R |
| Émetteur | CN=CA Credit Agricole Server,O=Credit Agricole Group,C=FR |
| Numéro de série | b90d11720203952a40635488 |
| Clé / Algo | RSA 2048 / sha256WithRSA |
| Usage | DigitalSignature, KeyEncipherment, clientAuth, serverAuth |
| SAN DNS | wmq_hors_prod_qmgr_qmu01r |
| Statut à 2038-07-02 | ❌ EXPIRÉ depuis 4814 jours |
| Commande de renouvellement générée | openssl genrsa -out "test01.key" 4096 openssl req -new -key "test01.key" -out "test01.csr" |
Cas 3 — Formats DER et CSR (tests multiformat)Case 3 — DER and CSR formats (multiformat tests)
Tests réels sur comodo_inter.der, globalsign_root.der, comodo_inter.csr, sectigo_inter.csr — tous analysés sans erreur à la date courante 2026-06-02. Illustre la polyvalence des formats : DER binaire (Comodo CA Limited Issuing CA G5 / RSA 3072), Root auto-signé (GMO GlobalSign RSA 4096), CSR en attente de signature (Sectigo / Comodo, RSA 3072, sha256WithRSA).
| Fichier | Type | CN | Clé | Statut |
|---|---|---|---|---|
| comodo_inter.der | CERT DER | Comodo CA Limited Issuing CA G5 | RSA 3072 | ✅ OK |
| globalsign_root.der | CERT DER (root) | GMO GlobalSign nv-sa Root CA G5 | RSA 4096 | ✅ OK (root) |
| comodo_inter.csr | CSR | Comodo CA Limited Issuing CA G5 | RSA 3072 | ✅ Non signé (pending) |
| sectigo_inter.csr | CSR | Sectigo Limited Issuing CA G5 | RSA 3072 | ✅ Non signé (pending) |
Vérifications cryptographiquesCryptographic checks
Classification des algorithmes de signatureSignature algorithm classification
| Algorithme | Statut | Action recommandée |
|---|---|---|
| SHA256 / SHA384 / SHA512 / SHA224 | OK | Aucune |
| SHA3-256 / SHA3-384 / SHA3-512 | OK | Aucune |
| SHA1withRSA | Weak | Planifier migration SHA256 |
| SHA256withDSA (DSA) | disabled | Remplacer par RSA ou EC |
| MD5 | Insecure | Remplacer immédiatement |
| Ed25519 / Ed448 | Unknown | Hash intrinsèque — classification partielle (voir note R5) |
Classification des tailles de clé RSARSA key size classification
| Condition | Statut |
|---|---|
| ≤ 1048 bits | CRITICAL — clé faible |
| < 2048 bits (mais > 1048) | WARNING |
| ≥ 2048 bits | OK |
| EC (ECDSA-SHA384 ou SHA256) | OK — exempté |
| DSA (tout type) | ERROR — désactivé |
Niveaux d'expirationExpiry levels
| Jours restants | Statut | Affichage |
|---|---|---|
| ≤ 0 (expiré) | ❌ CRITICAL | rouge — P1 dans le rapport |
| 1–8 | ❌ Error | rouge — P1 |
| 9–30 | ⚠️ Warning | orange — P2 |
| > 30 | ✅ OK | vert |
Mode RemoteRemote mode SSH/SFTP
Le mode remote (--remote HOST) est implémenté et fonctionnel dans le code (connexion Paramiko SSH, téléchargement SFTP, analyse locale, nettoyage des temporaires). Cependant, aucun test end-to-end en conditions réelles n'a encore été réalisé dans cette version : accès SSH vers un serveur IBM MQ distant, téléchargement d'un .kdb avec son .sth companion, analyse remote cross-platform (Windows vers Linux, Linux vers AIX).
Le mode remote sera validé en priorité dans la version V1R2M0. Les utilisateurs souhaitant l'utiliser dès maintenant sont invités à signaler tout comportement inattendu à licence@jokersoft.com.
ArchitectureArchitecture du mode remote (implémentée)
Principe : Python et cryptography ne sont pas requis sur le serveur distant. Seul SSH/SFTP est nécessaire.
| Scénario | Configuration | Statut test |
|---|---|---|
| Linux → Linux (cas principal) | --remote-key ~/.ssh/id_rsa | Non testé V1R1M1 |
| Windows → Linux | --remote-key %USERPROFILE%\.ssh\id_rsa | Non testé V1R1M1 |
| Linux → AIX / IBM i | --remote-key ~/.ssh/id_ed25519 | Non testé V1R1M1 |
| Windows → Windows (OpenSSH) | OpenSSH activé sur la cible | Non testé V1R1M1 |
| Password auth | --remote-pass | Non testé V1R1M1 |
💡 Le fichier .sth companion des keystores .kdb est automatiquement récupéré via SFTP si présent sur le serveur distant. Le hostname remote alimente _ctx._remote_hostname pour nommer les fichiers JSON/HTML de sortie.
Cycles de renouvellementRenewal cycles & anticipation
Face à la réduction des durées de validité imposée par les AC et les navigateurs, chkcert intègre plusieurs mécanismes d'anticipation :
Simulation temporelle (--date)Time simulation (--date)
L'option --date YYYY-MM-DD (ou +N / -N jours) permet de simuler l'état du parc de certificats à une date future. Exemples pratiques :
./chkcert --dir /opt/mq/ssl/ --date +90 --report # Que sera expiré dans 90 jours ? ./chkcert --dir /opt/mq/ssl/ --date +365 --report # Plan de renouvellement annuel ./chkcert --dir /opt/mq/ssl/ --date 2027-01-01 --output html # Audit au 1er janvier 2027
Génération des commandes de renouvellement (--cmd)Renewal command generation (--cmd)
Avec --report --cmd, chkcert génère les commandes exactes de renouvellement adaptées au format du keystore :
| Format | Commande générée |
|---|---|
| .kdb | runmqakm -certreq -create -db ... -label ... -dn ... -size 4096 -sig_alg sha256 |
| .jks / .p12 | keytool -certreq -keystore ... -alias ... -file out.csr -sigalg SHA256withRSA |
| .pem / .cer | openssl genrsa -out key.pem 4096 && openssl req -new -key key.pem -out csr.pem |
Impact des cycles 47 jours (CA/Browser Forum 2027)47-day cycles impact (CA/Browser Forum 2027)
Si le CA/Browser Forum adopte la durée de 47 jours maximum (vote prévu 2026–2027), un parc de 100 certificats TLS nécessitera ~780 renouvellements par an. Sans automatisation et sans outil de surveillance centralisé, le risque d'expiration accidentelle est proche de 100%.
chkcert + export JSON + PKI maison constitue la base de cette automatisation : détection → alerte → commande de renouvellement générée → pipeline CI/CD.
ObservationsFindings & Recommandations V1R1M1
os.remove(filenameT) ajouté après os.close(_fd) pour les formats KDB — runmqakm refusait d'écrire sur un fichier existant (CTGSK3036W). Corrigé pour cert-extract et certreq-extract.
Validation ajoutée : toute valeur en dessous de 2048 dans MIN_RSA_KEY_SIZE est rejetée avec un warning et ignorée. Le plancher absolu est incontournable même par le fichier de configuration externe.
Les clés W_FLD_TARGET_ANA_CER (Windows) et U_FLD_TARGET_ANA_CER (Unix) sont maintenant chargées depuis constantes_V1R1M1.properties et utilisées par les 4 fonctions de sortie. Fallback silencieux sur le répertoire du script si absent.
Badge 📅 ref YYYY-MM-DD dans l'en-tête HTML. Champ reference_date dans tous les JSON (per-file et summary). Le répertoire de sortie utilise la date simulée comme YYYYMMDD.
check_cert_strength() retourne ('Unknown', 'Unknown') pour Ed25519/Ed448 car signature_hash_algorithm est None pour ces algorithmes (hash intrinsèque). Un statut spécifique 'Modern-EdDSA' est prévu en V1R2M0.
Voir section dédiée ci-dessus. L'implémentation est complète mais les scénarios cross-platform (Linux → AIX, Windows → Linux + KDB/STH) n'ont pas encore été validés en conditions réelles. Prévu V1R2M0.
Prochaines évolutions prévues : (1) validation du mode remote en conditions réelles toutes plateformes, (2) statut EdDSA correct, (3) licence serveur (Option Fort — appel HTTPS api.jokersoft.com), (4) collecteur PKI central consommateur du JSON, (5) support OCSP stapling dans l'analyse.
chkcert_V1R1M1_rapport_technique.html — JokerSoft © 2026
Version V1R1M1 · 5 500+ lignes · 260 KB · check-certificat.com