Si comme nous vous avez de nombreux certificats sur vos systèmes, le ménage peut s’avérer compliqué. En effet, au fur et à mesure des renouvellements, les nouveaux certificats sont installés, les nouvelles autorités également.

Mais les suppressions de certificats sont souvent remises à plus tard. Et l’on se retrouve avec un nombre importants de certificats pour lesquels il est préférable de contrôler la non utilisation avant suppression.

SQL va nous aider ici, avec le service qsys2.certificate_info (cf https://www.ibm.com/docs/en/i/7.6.0?topic=services-certificate-info-table-function) capable de nous donner la liste des certificats et leurs attributs.

qsys2.certificate_info

Permet d’obtenir facilement les principales informations sur les certificats et autorités de certification du magasin *SYSTEM :

La même vue dans DCM :

Et on remarque donc la nécessité du ménage (dans mon cas).

Premièrement, comment faire la distinction entre les certificats et les autorités de certifications ? En utilisant la colonne PRIVATE_KEY_STORAGE_LOCATION.

Autorité de certification

select CERTIFICATE_LABEL,
       VALIDITY_START,
       VALIDITY_END,
       DOMAIN_NAMES,
       SUBJECT_COMMON_NAME,
       SUBJECT_ORGANIZATION,
       ISSUER_COMMON_NAME,
       ISSUER_ORGANIZATION,
       PRIVATE_KEY_STORAGE_LOCATION 
  from table (
      qsys2.certificate_info(certificate_store_password => '*NOPWD')
    )
  where( PRIVATE_KEY_STORAGE_LOCATION <> 'SOFTWARE' or PRIVATE_KEY_STORAGE_LOCATION  is null)

Certificat

select CERTIFICATE_LABEL,
       VALIDITY_START,
       VALIDITY_END,
       DOMAIN_NAMES,
       SUBJECT_COMMON_NAME,
       SUBJECT_ORGANIZATION,
       ISSUER_COMMON_NAME,
       ISSUER_ORGANIZATION,
       PRIVATE_KEY_STORAGE_LOCATION 
  from table (
      qsys2.certificate_info(certificate_store_password => '*NOPWD')
    )
    where PRIVATE_KEY_STORAGE_LOCATION = 'SOFTWARE'

Validité

Le premier élément trivial : quels sont les certificats périmés :

select CERTIFICATE_LABEL,
       VALIDITY_START,
       VALIDITY_END,
       DOMAIN_NAMES,
       SUBJECT_COMMON_NAME,
       SUBJECT_ORGANIZATION,
       ISSUER_COMMON_NAME,
       ISSUER_ORGANIZATION,
       PRIVATE_KEY_STORAGE_LOCATION 
  from table (
      qsys2.certificate_info(certificate_store_password => '*NOPWD')
    )
  where validity_end <= current timestamp
  order by validity_end asc  ;

Lien

Les certificats sont émis (signés) par des autorités de certification, le lien entre les deux est donc un élément indispensable.

Nous pouvons donc maintenant répondre aux questions suivantes :

Pour chaque certificat client/serveur, quel est l’autorité de certification ?

Mais cela génère des doublons :

En effet, nous faisons le lien via le Common Name de l’autorité. Mais celui-ci n’est pas obligatoirement unique, et c’est bien le cas sur les autorités locales créées via les assistants de configuration IBM i.

Pour avoir un identifiant unique, il nous faut utiliser les identifiants de clés, qui elles sont distinctes :

Mais cette information est absente de la fonction table qsys2.certificate_info.

Nous donnerons une solution (pas si simple) lors d’un prochain article dédié.

Malgré tout, ce problème ne concerne « que » les certificats générés depuis une autorité locale, elle même créée via les assistants IBM i, les autorités publiques ayants des noms uniques.

Si l’on prend un certificat acheté via Gandi :

On obtient bien une information unique et exploitable.

Pour chaque autorité, quels sont les certificats émis ?

Par exemple :

Extrait du résultat :

Par extension, quelles sont les autorités inutilisées ?

Produit :

Et le ménage ?

Avec les requêtes précédentes, vous pouvez isoler les certificats et autorités périmés ou les autorités inutilisés (dans notre cas les autorités n’ayant pas généré de certificat). Et vous pouvez donc les supprimer de façon ciblée.

Attention : les autorités et certificats peuvent être utiles et utilisés en dehors des liens vus ici. Ces requêtes permettent donc d’aider à la décision, mais ce n’est pas un automatisme !

Pour aller plus loin

Nous pouvons inclure l’analyse des applications DCM : liens applications/certificats.

Et également utiliser les API RSE pour automatiser la suppression des certificats.

Et rendre nos requêtes récursives pour permettre de suivre une hiérarchie à plus d’un niveau

Voir l’idea soumise pour avoir le lien certificat -> autorité dans la vue qsys2.certificate_info : https://ibm-power-systems.ideas.ibm.com/ideas/IBMI-I-4628