En lançant ipa-healthcheck --failures-only sur mon primaire FreeIPA (idm.gnali.home, RHEL 10.2, IPA 4.13.1), j’ai obtenu deux résultats ERROR liés au sous-système CA Dogtag :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
  "source": "pki.server.healthcheck.certs.expiration",
  "check": "CASystemCertExpiryCheck",
  "result": "ERROR",
  "kw": {
    "exception": "Request timed out"
  }
},
{
  "source": "pki.server.healthcheck.certs.trustflags",
  "check": "CASystemCertTrustFlagCheck",
  "result": "ERROR",
  "kw": {
    "key": "ocsp_signing",
    "nssdbDir": "/var/lib/pki/pki-tomcat/conf/alias",
    "msg": "Unable to load cert from NSSDB: Request timed out"
  }
}

Le message est inquiétant — expiration de certificats et flags de confiance sont des sujets PKI sensibles. Dans mon cas, la CA était saine. Le healthcheck a simplement manqué de temps pour lire la base NSS.

Ce que signifient réellement ces erreurs

Les deux vérifications inspectent les certificats système stockés dans la base NSS Dogtag à /var/lib/pki/pki-tomcat/conf/alias. Pour cela, ipa-healthcheck appelle la CLI pki (nss-cert-export, nss-cert-show) pour chaque certificat système de la CA : signing, OCSP, audit, subsystem et serveur SSL.

Le mot-clé dans le résultat n’est pas expired ou invalid — c’est Request timed out.

ipa-healthcheck impose un délai par vérification. La valeur par défaut est de 10 secondes, définie dans ipahealthcheck.core.constants et configurable dans /etc/ipahealthcheck/ipahealthcheck.conf.

La vérification d’expiration CA parcourt plusieurs certificats dans une seule exécution du plugin. Si les opérations NSS cumulées dépassent 10 secondes, l’alarme se déclenche et la vérification remonte ERROR avec une exception générique de timeout — même lorsque tous les certificats sont valides.

Pourquoi l’accès NSS est lent

Lorsque pki-tomcat tourne, le processus Java maintient la base softoken NSS ouverte. Un accès concurrent via pki ou certutil peut bloquer sur les verrous PKCS #11.

Sur mon serveur, pki-tomcat était actif et le répertoire NSS était utilisé par le processus Java. Sous contention, les appels pki nss-cert-export étaient lents :

CertificatDurée typique
caSigningCert cert-pki-ca~5 s
ocspSigningCert cert-pki-ca~8–9 s
Server-Cert cert-pki-catimeout à 10 s

Un benchmark manuel a rendu le schéma évident : le premier export de Server-Cert cert-pki-ca après un passage du healthcheck a pris 87 secondes. Les exports suivants se terminaient en environ 1,5 secondes. C’est une contention de verrous classique, pas une corruption.

Parallèlement, une inspection directe montrait que les certificats étaient corrects :

1
2
3
4

certutil -L -d /var/lib/pki/pki-tomcat/conf/alias
pki -d /var/lib/pki/pki-tomcat/conf/alias \
    -f /var/lib/pki/pki-tomcat/conf/password.conf \
    nss-cert-export --format PEM "Server-Cert cert-pki-ca"

Les cinq certificats système de la CA étaient présents avec des dates de validité cohérentes. pki-server status indiquait le sous-système CA comme activé et joignable sur les ports 8080 et 8443.

Confirmation avec le mode debug

Lancer une vérification isolée avec --debug montre où le temps est consommé :

1
2
3
4

ipa-healthcheck \
  --source pki.server.healthcheck.certs.expiration \
  --check CASystemCertExpiryCheck \
  --debug

Dans mon cas, signing et ocsp_signing ont retourné SUCCESS après 5 s et 8,8 s respectivement. Le certificat suivant (sslserver / Server-Cert cert-pki-ca) n’a pas fini avant l’alarme des 10 secondes.

La vérification des flags de confiance a échoué sur le même goulot d’étranglement — chargement de ocsp_signing depuis la NSSDB pendant que tomcat maintenait le verrou.

Correction : augmenter le timeout du healthcheck

Le fichier de configuration par défaut ne contient qu’une section [default] sans timeout explicite. Ajoutez :

1
2
3

# /etc/ipahealthcheck/ipahealthcheck.conf
[default]
timeout = 120

Il n’existe pas d’option --timeout en ligne de commande ; la valeur doit figurer dans le fichier de configuration (ou être passée via --config pointant vers un fichier alternatif).

Après avoir défini timeout = 120, les vérifications de certificats CA ont réussi. L’exécution complète a pris environ 66 secondes — bien en deçà de la nouvelle limite, mais très au-delà des 10 secondes par défaut.

Vérification :

1

ipa-healthcheck --failures-only

En résumé

  • Un ERROR de CASystemCertExpiryCheck ne signifie pas automatiquement qu’un certificat CA expire. Lisez le champ kw. exception: Request timed out pointe vers le délai du healthcheck, pas vers la validité PKIX.
  • La base NSS Dogtag est lente à lire pendant que pki-tomcat tourne. C’est un problème de contention d’outils, pas un signe que la CA est défaillante.
  • Augmenter timeout dans ipahealthcheck.conf est une correction raisonnable sur les serveurs IPA en production, où redémarrer tomcat avant chaque healthcheck n’est pas pratique.

Si vous voyez les mêmes erreurs, vérifiez les certificats manuellement en premier. S’ils sont corrects et les échecs mentionnent des timeouts, vous êtes probablement dans la même situation — pas un incident PKI, juste un healthcheck qui a besoin de plus de temps.