How to resolve certificate errors encountered after an upgrade of the ELM

How to resolve certificate errors encountered after an upgrade of the ELM

book

Article ID: CTX339978

calendar_today

Updated On:

Description

Unable to create layers after an upgrade, One of the below errors is seen.

  • "The issuing certificate does not have a usable private key"
  • "Certificate doesn't contain private key"

Resolution

The below steps will delete the two certificates associated with Offload Compositing(OC). The certificates will be automatically recreated.

NOTE: Run these commands from the hypervisor console or an SSH connection to the ELM, as root. If using Azure, "sudo" may be required before the command

 
  1. JwtCertificate
    1. Gather the JwtCeritifcate Hash
      1. Execute, certmgr -list -c -m My | grep -C 3 JwtCertificate
    2. Delete the current JwtCertificate
      1. Execute, certmgr -del -c -m My <UniqueHashHere>
        1. <UniqueHashHere> is the hash from the list command without <>
    3. Verify nothing is reported back, then go to the next step
      1. Execute, certmgr -list -c -m My | grep -C 3 JwtCertificate
        1. If the certificate is still visible verify there are no additional or missing characters, spacing or letter casing discrepancies, then reattempt the above steps
        2. Contact Support for assistance if the data is still present
    4. Regenerate the certificate
      1. Execute, systemctl restart maservice
    5. Verify the certificate has a current timestamp, date
      1. certmgr -list -c -m My | grep -C 3 JwtCertificate
  2. DefaultRootCertificate
    1. Gather the DefaultRootCeritifcate Hash
      1. Execute, certmgr -list -c -m Root | grep -C 3 CN=DefaultRootCertificate
    2. Delete the current DefaultRootCertificate
      1. Execute, certmgr -del -c -m Root <UniqueHashHere>
        1. <UniqueHashHere> is the hash from the list command without <>
    3. Verify nothing is reported back, then go to the next step
      1. Execute, certmgr -list -c -m Root | grep -C 3 CN=DefaultRootCertificate
        1. If the certificate is still visible verify there are no additional or missing characters, spacing or letter casing discrepancies, then reattempt the above steps
        2. Contact Support for assistance if the data is still present
    4. Regenerate the certificate
      1. Execute, systemctl restart maservice
    5. Verify the certificate has a current timestamp, date
      1. certmgr -list -c -m Root | grep -C 3 CN=DefaultRootCertificate
After completing the above steps reattempt the task(s) that had failed.

Problem Cause

The cause is currently unknown. We expect the certificates to be present or recreated as need, after an upgrade.