Playbook Ansible : renouveler le certificat aut0-signé d’une Cisco IMC

Depuis un certain temps, nous rencontrons des “problèmes” d’expiration de certificat (auto-signé) de CIMC sur des C220 M4.  Renouveler le certificat auto-signé d’une CIMC est très simple, vous pouvez le faire via la GUI de la CIMC, en CLI ou via le Playbook que nous venons de mettre en place. L’avantage du Playbook est qu’il va récupérer les informations de l’ancien certificat afin de les reporter sur le nouveau certificat, puis il va afficher les informations du nouveau certificat afin de s’assurer que le nouveau certificat a bien une nouvelle date d’expiration, et bien sûr c’est plus rapide et on peut se faire une petite boucle histoire de le faire sur plusieurs CIMC 😉 .

Juste avant Noël, donc on peut légitiment espérer un vrai certificat sous le sapin pour le 25 au matin 🙂
- hosts: localhost
  
  tasks:      
    
    # Read current certificate
    - name: Read Current Certificate
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveDn  inHierarchical="false" dn="sys/cert-mgmt/curr-cert">
          </configResolveDn>
      retries: 10
      delay: 5
      register: current_certif
      until: current_certif is not failed

    - debug:
        msg: "{{ current_certif }}"

    - name: create variables from current_certif
      set_fact:
        var_commonName: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.commonName }}"
        var_countryCode: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.countryCode }}"
        var_organization: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.organization }}"
        var_organizationalUnit: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.organizationalUnit }}"
        var_locality: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.locality }}"
        var_state: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.state }}"
        var_validFrom: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.validFrom }}"
        var_validTo: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.validTo }}"
        var_signatureAlgorithm: "SHA384"
        var_selfSigned: "yes"

    - debug:
        msg: 
          - "{{ var_commonName }}"
          - "{{ var_countryCode }}"
          - "{{ var_organization }}"
          - "{{ var_organizationalUnit }}"
          - "{{ var_locality }}"
          - "{{ var_state }}"
          - "{{ var_validFrom }}"
          - "{{ var_validTo }}"


     # Generate selfSigned Certificate
    - name: Generate selfSigned Certificate
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        timeout: 180
        content: |
            <configConfMo dn="sys/cert-mgmt/gen-csr-req" inHierarchical="false">
            <inConfig>
            <generateCertificateSigningRequest commonName="{{ var_commonName }}" 
              organization="{{ var_organization }}" 
              organizationalUnit="{{ var_organizationalUnit }}" locality="{{ var_locality }}" 
              state="{{ var_state }}" countryCode="United States" 
              dn="sys/cert-mgmt/gen-csr-req" selfSigned="yes"/>
            </inConfig>
            </configConfMo>
      retries: 10
      delay: 5
      register: generate_certif
      until: generate_certif is not failed


    # Read the new certificate
    - name: Read the new certificate
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveDn  inHierarchical="false" dn="sys/cert-mgmt/curr-cert">
          </configResolveDn>
      retries: 30
      delay: 5
      register: new_certif
      until: (new_certif is not failed) and (new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.commonName == var_commonName)

    - debug:
        msg: "{{ new_certif }}"

    - name: create variables for new_certif
      set_fact:
        var_commonName: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.commonName }}"
        var_countryCode: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.countryCode }}"
        var_organization: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.organization }}"
        var_organizationalUnit: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.organizationalUnit }}"
        var_locality: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.locality }}"
        var_state: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.state }}"
        var_validFrom: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.validFrom }}"
        var_validTo: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.validTo }}"

    - debug:
        msg: 
          - "{{ var_commonName }}"
          - "{{ var_countryCode }}"
          - "{{ var_organization }}"
          - "{{ var_organizationalUnit }}"
          - "{{ var_locality }}"
          - "{{ var_state }}"
          - "{{ var_validFrom }}"
          - "{{ var_validTo }}"

Une fois le Playbook passé la CIMC a un nouveau certificat auto-signé avec les anciennes valeurs.

On est reparti pour 5 ans 🙂

Post to Twitter

vROPs : Not receiving data from the Desktop Agent

Nous voilà de retour avec vROps  (vous allez croire qu’on est fan à force), cette fois-ci ce sont des vms de type dekstop qui ne remontaient plus d’infos dans vROps depuis leur Desktop Agent.  Le message d’erreur  dans le dashboard “Horizon Help Desk” était :

Not receiving data from the Desktop Agent

Ne soyons pas médisants on a déjà le protocole qui remonte 🙂

En collaboration avec notre collègue de l’équipe “Poste de Travail” (Christophe Mazzardis) nous avons regardé sur plusieurs vms impactées et avons remarqué que dans la log de l’agent View (C:\ProgramData\VMware\vRealize Operations for Horizon\Desktop Agent\logs\v4v-vrops-rmi-YYYY-MM-DD.log) nous avions l’erreur ci-dessous :

0x00002e70 ERROR    Failed to initialize RMI in the Java client.  java.io.IOException: Invalid keystore format


Vous l’aurez compris le “Invalid keystore format” nous a permis rapidement de faire la liaison avec le fichier “v4pa-truststore.jks” (ce fichier contient le magasin de confiance que l’adaptateur utilise pour authentifier le certificat du broker agent)  situé dans “C:\ProgramData\VMware\vRealize Operations for Horizon\Desktop Agent\conf”. En remplaçant le fichier “v4pa-truststore.jks” par un fichier d’une vm ne posant pas de problème et en relançant le service “v4v_agent” (Vmware vRealize Operations for Horizon Desktop Agent) nous avons pu à nouveau obtenir la remontée des métriques view dans vROps.

On regarde vite fait dans le fichier de log Agent\logs\v4v-vrops-rmi-YYYY-MM-DD.log pour voir si ça se passe bien.

7:14:46 0x00000a68 INFO     Using message server ‘rmi://vROPsIP:3091′.
17:14:46 0x00000a68 INFO     UnregisterDataDumpCallback success: (, , )
17:14:46 0x00000a68 INFO     RegisterDataDumpCallback success: (rmi:// vROPsIP:3091,
539dc7df8b99f2fbddfe841c9332b8dabe1426eee73b449c3b3bfd7fc3d4c1ba, 0500304531153013060355040A130C564D776172652C20496E632E312C302A060355040313237643656E746572204F7065723656E746572204F706573656E746572204F706573656E7B83E986FD33AC301EE104FC25C1DE7435495A………………)
17:14:46 0x00000a68 INFO     Using message server ‘rmi:// vROPsIP:3091’.
17:14:46 0x00000c0c INFO     Using JRE from ‘C:\Program Files\VMware\VMware View\Agent\jre\’.
17:14:47 0x00000c0c INFO     SUCCESSFULLY initialized the Message Logger.
17:14:47 0x00000c0c INFO     Initialized communication manager.
17:14:47 0x00000c0c INFO     Updated the message server URL in the Java client to rmi:// vROPsIP:3091.


Le “SUCCESSFULLY initialized the Message Logger” confirme que tout est ok.

Retournons côté vROps afin de voir si notre vm a bien ses métriques View qui remontent.

Après quelques minutes tout est ok

Maintenant que le problème est résolu, on va essayer de lire le fichier “v4pa-truststore.jks”  (qui causait problème) via “KeyStore Explorer” (le mot de passe du fichier “v4pa-truststore.jks” est contenu dans le fichier “msgclient.properties” (truspass =……..).

Comme nous sommes sur du mot de passe, nous optons pour “le fichier magasin de certificats est corrompu”….on va cliquer sur Ok comme on est joueur
Et en cliquant sur le bouton Détails ?
Nous ne sommes pas plus avancés pour l’instant…..

Maintenant nous allons regarder  ce qu’il y a dans un fichier “v4pa-truststore.jks” sain.

On a bien la liste des certificats 🙂

Retournons côté vROps pour voir si notre vm remonte bien les métriques View.

Nickel

Post to Twitter