An insecure item from ArcGIS Portal's Server URL is being loaded

[MichaelSchoelen]

Long story short: An item from our portal server is skipping around the portal URL, and loading as its own resource. This is causing a problem because the server does not have its own certificate. It should be bundled up with the portal resources.

Note: https://internal.gis.bisnet.com is on https://server01.ina.bisnet.com

We have ArcGIS Enterprise deployed. Everything is secure, however when a hosted feature service is loaded in a new web map, the site is flagged as insecure.

In Google Chrome Developer tools, I loaded the site to understand what insecure resource was being loaded.

• It notes that my portal site (https://internal.gis.bisnet.com --example) IS secure.
• However, it is also showing the name of the server that portal is on (https://server01.ina.bisnet.com) as an INSECURE resource. This is interesting, because everything should be coming through the portal URL (internal.gis.bisnet.com).

I took a look at the Google Chrome sources list, to determine what resource was loading from server01 (skipping around portal).

• It might be an item from our Webadaptor (called team)
• It appears to be something under the "self" properties

How do I modify my settings so this resource travels through portal, and does not appear as its own resource?

[RandallWilliams]

I'm unsure I completely understand. A few questions:

Are Portal and Server installed on separate machines?

How many web adaptors are you using, and where are they located? There should be two, one for Portal and one for Server.

Portal is on server01.ina.bisnet.com, correct?

If you're installed on two separate machines, then that puts ArcGIS Server on internal.ina.bisnet.com, is that correct?

The response to the call to the SELF resource would be coming from the Portal.

[MichaelSchoelen]

Our portal website is: https://internal.gis.bisnet.com/team

Portal and Server are installed on separate machines.

• Portal is installed on https://server01.ina.bisnet.com
  • It has a web adaptor installed on the same machine (team)
• Server is installed on https://server02.ina.bisnet.com
  • • It does not have a web adaptor installed

"The response to the call to the SELF resource would be coming from the Portal." -- That is correct.

[RandallWilliams]

Ok, got it. Does that mean that https://internal.gis.bisnet.com/team is a DNS alias that points to your web adaptor?

If that's the case, that would imply that the CN issued for your cert is also internal.gis.bisnet.com. Is that correct?

If those are correct, I'd address this issue by adding updating your cert to include server01.ina.bisnet.com in the cert's SAN (Subject Alternative Name). I think that you're getting that error because the browser doesn't believe that the cert that's presented matches the hostname you're reaching. Setting the SAN would help correct that.

[MichaelSchoelen]

Yep!  https://internal.gis.bisnet.com/team is the DNS alias that points to our web adaptor.

And we have a wildcard cert from a CA for *.gis.bisnet.com

Is there guidance on how to set the SAN? I've read this, but we are using an already-signed certificate. 

I hoped we could set that somewhere in the SSL certificate properties in Portal Admin Directory?

[PhilipMcNeilly]

Have you set the webcontextURL for portal to point at the DNS Alias?  If not,  this could be why the requests are being sent to the portal machine name, and as a result, resulting in a certificate error, rather than being sent via the DNS Alias.

Use a reverse proxy server with Portal for ArcGIS—Portal for ArcGIS (10.6) | ArcGIS Enterprise 

[RandallWilliams]

Philip's response above is going to be the best bet. I totally forgot about that setting. Updating the SAN would also have worked, but Philip's is the 'proper' fix.

[MichaelSchoelen · Accepted solution]

So I'm not sure if this was the Web Context URL or simply the name of the web adaptor being incorrect, but the solution was to go to the portaladmin page on portal, navigate to the web adaptor properties, add "/edit" to the end of the URL, and update the name of the web adaptor from the server name to the domain name used by portal. That resolved all of the issues! 

Thank you! Your comments put me on the right track.