CA Service Management

Good afternoon, Community
We have SDM suite 14.1 and in this case you have to log in to Unified Self Service (USS),
I want to see the pending tickets or requests and the following scenarios are given:  In Mozilla Firefox: the page is displayed correctly. In Internet Explorer: The page is not displayed correctly. In Google Chrome: The page is not displayed correctly.

Mozilla Firefox:

Google Chrome:

Another user on another PC logged in with the same user:  In Internet Explorer: the page is displayed correctly. In Google Chrome: Not all the information is displayed on the page. In Mozilla Firefox: He doesn´t have it.  Why does this scenario happen and how can it be solved? Thank you very much in advance.

Regards

Carlos Ramirez

In Spanish:

Buenas tardes Comunidad,

Se tiene la suite 14.1 de SDM y en este caso se tiene que cuando inicio sesión en Unified Self Service (USS), quiero ver los tickets o solicitudes pendientes y se dan los siguientes escenarios:

En Mozilla Firefox: Si se muestra la página correctamente.

En Internet Explorer: No se muestra la página correctamente.
En Google Chrome: No se muestra la página correctamente.

Otro usuario en otra PC logueado con el mismo usuario:

carlosgrv 

What patch level is your SDM and USS installs?

I obtained this information from SDM

---------- server.HIS
[Wed Jan 27 03:42:06 2016] - PTF Wizard created this history file.
[Wed Jan 27 03:43:23 2016] - PTF Wizard installed RO86155 (USRD)
[Wed Jan 27 03:46:13 2016] - PTF Wizard installed RO86157 (USRD)
[Wed Jan 27 03:47:28 2016] - PTF Wizard installed RO86160 (USRD)
[Wed Jun 21 13:50:00 2017] - PTF Wizard installed T52Y630 (USRD)
[Fri Jul 07 13:32:21 2017] - PTF Wizard installed T5U3500 (USRD)

Carlos,

If you open your browser console on the 2 browsers where its not working, it might show some errors about mixed content or something similar that's forcing your browsers not to show the content.

I see that the USS URL is on HTTPS.  In USS -> Settings -> Datasources -> Service Catalog,  the Catalog URL there is that HTTP or HTTPS?

_R

Thanks for answering my doubt. Yes, some errors appear in debug mode.

With respect about de URL, we use https. I did the homework and here it is the evidence:

Thanks for the help you can give me back.

Regards,

Carlos Ramirez

carlosgrv 

What errors are you seeing in IE and Chrome via the Web browser console?

Here are the errors I get from the browsers:

Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID

Uncaught TypeError: Cannot set property 'innerHTML' of null at myrequest-catalog:3211

Failed to load resource: the server responded with a status of 404 (Not Found)

SCRIPT5007: No se puede establecer la propiedad 'innerHTML' de referencia nula o sin definir

Thank you.

So basically both certificates are being deemed invalid by your browser to start with. that's why the behavior.

Do this. Close all browsers.

1) go to Catalog SSL URL first. I think you'll get a cert warning, accept it and go to Catalog home page

2) now got to USS URL.  you'll get another cert warning. accept it. 

Now you should see Catalog content properly in USS

This is happening because the browser is making sure the certs are accepted as valid exceptions

If these are vendor issued certs, then make sure you are accessing the URLs for USS and Catalog using the correct server names for which the certs were given  (example:  https://realservername.company.com  is not same as  https://realservername )

_R

Good day Raghu,

Thanks for the answer, i did what u told in Chrome navigator and the results are:

1. I got in first to the SC web page first and logged in succesfully.

2. Then I went to USS web page and logged in and go fine but when is loading the information, the page ask me again for authentication of SC in order to load embedded SC ticket's information

So, the navigator still asking for corrects certificates and updated.

Why the error continues??

Regards,

Carlos Ramirez 

Basically both server names are different and are considered as invalid certificates until you accept the certificate exception manually against both URLs first.

Then only you can access them properly.

_R

carlosgrv 

Did you have a chance to try the solution proposed by Raghu.Rudraraju ?

If so, did it resolve the issue?

No, it didn´t work out Paul. Because the second site (USS) is still asking for the credentials of the first one (SC) and the certificates are updated.

Regards

Carlos Ramirez

carlosgrv 

As Raghu.Rudraraju indicated, since both server names are different, they are considered as invalid certificates until you accept the certificate exception manually against both URLs first

Please manually accept the certificate exception for each URL and see if the issue persists