Maximo Open Forum

 View Only

 SSL cert not working for *.home.masdomain

  • Maximo Application Suite
Andrew Meuse's profile image
Andrew Meuse posted 08-21-2025 10:14

After renewing the ssl cert on a 9.0 MAS\manage instance the *.masdomain and*.manage.masdomain work fine but *.home.masdomain is still using the old cert. Any ideas why this may be the case? Have done the standard, clear cache, use another browser, etc and checked the details of the cert to make sure I didn't type 'hom' instead of 'home' when requesting. Its all coming up with green checks in MAS and the Routes in OpenShift look good. 

https://maximo.home.demo01.apps.masdemo01.domain.com/maximo - gives me the old cert.
https://maximo.manage.demo01.apps.masdemo01.domain.com/maximo - works fine.

Any ideas what it may be?

Thanks,

Andy

Brett Coleman's profile image
Brett Coleman

What do your DNS entries look like on your certificate object/issuer? Do you have specific applications mentioned in them?

I recently discovered it's best practice to use a wildcard certificate for the entire cluster/domain. The configuration should look something like this:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
    name: cert
    namespace: cert-manager
spec:
    dnsNames:
        - *.masdemo01.domain.com
    secretName: cert-ssl
    issuerRef:
        name: ssl-issuer
Andrew Meuse's profile image
Andrew Meuse

I don't know how to get the info that you displayed. Maybe I am just not using the correct output on - oc get secret. Should the SANs on my cert correspond with spec: dnsNames? 

I have 1 cert with 3 wildcard SANs.

*.masdomain
*.manage.masdomain
*.home.masdomain

Brett Coleman's profile image
Brett Coleman

Instead of specifying individual SANs, just use the wildcard DNS entry for the entire domain. This provides a security blanket across the entire cluster and all the applications within it, rather than just covering specific parts of the deployment.

For example, if you later deploy services like Health, MVI, etc., you won’t need to update the certificate with additional SANs.

Of course, I’m not sure what your internal security policies are, how your certificates are currently configured, or which operators you're using in your OpenShift environment. So it’s hard to give a precise fix, but starting with just a wildcard cert is a good first step to try.

Andrew Meuse's profile image
Andrew Meuse

I don't think a single wildcard cert would work. It only covers the first level subdomain as far as I know. So a wildcard cert for -

*.masdomain

Would be good for
manage.masdomain
home.masdomain

But not

*.manage.masdomain
*.home.masdomain

My configuration is straight out of https://www.ibm.com/docs/en/masv-and-l/cd?topic=management-manual-certificate so I am only updating 2 secrets. 

Arif Ali's profile image
Arif Ali

Andy, the single wildcard works when we fetch certificates automatically. You are using manual certificates method, where a single wildcard without SAN would not work.

For your issue at hand, have you tried manually updating the .home.masdomain route with renewed certificate? (I assume you already re-ran the Ansible role to manually update the renewed certificate on all of your routes and the *.home.masdomain probably got missed by Ansible for some reasons). 

I suspect you'd be better off creating a support case with IBM.

Andrew Meuse's profile image
Andrew Meuse

Hi Arif,

I didn't know there was an Ansible role to run, I just manually replaced the secrets. I didn't realize you could edit the Route and change the secret there and it was coming up Green so I didn't look. That did the trick.