Where do I verify the SSL settings with Enterprise config

[BugPie]

I'm having trouble migrating a print service from 10.3.1 to 10.6.1. The big changes are that we are in azure and that we now have a portal in the mix. So the security is brand new to me and I'm stuck getting a print service to work. During my troubleshooting I came across an admin page that is showing a self signed cert is assigned to Portal. This stands out to me as possibly being an issue. 

I do not see SSL warning anywhere and we can access our site and port with https. 

From the portaladmin/security/sslcertifiactes/portal

I see there is a Self signed. Is this not what I should see? Where can I validate my SSL is setup correctly?

[JonathanQuinn]

And I imagine you can reach all services from the desktop you're running the tool from? If so, there's something the ExportWebMapTask or ConvertWebMapToMapDocument tools can't handle within the JSON that's getting sent in. I'd slowly start pulling out complexity within the webmap_as_json, (graphic layers, symbolization, etc), until you can determine the cause of the problem. I don't think there's any other way to go about it. Are you services public?

[BugPie]

Correct, I can reach all the services from my desktop and other machines within the network. My WAB app is able to print just fine. No, my services are not public, they should only be reachable by users with Active Directory user creds. I'd be willing to make one public if someone is able to help me troubleshoot....? I know a long shot.

Anyways, Its so strange to me! Everything seems to have access to the map services except for the GP tool. But only when the json is produced by the my application. When the json is prodcued form another applicaiton like a WAB template there are no issues. --> which by this point all signs are pointing to the app itself. I'm not a developer by any means so this is a major issue for me. This is literally the last piece of the puzzle before we move Enterprise into Production. Damn. I guess a good way to look at it is that it's a super simple custom print service. We are filling in text elements and putting definition query on two layers. Everything else gets printed into the template and viola! but only with 10.3.1 I guess. 

What's changed? New Server Machine, New AGS version, Portal (with Portal Security). I guess I'll just keep pushing buttons until something works. Has to be within one of these arenas I would think? Seems simple enough: why can't GP service access map service. 

Well then. I guess we can cross off SSL getting into the way. ok, check that off the list. And moving on, I guess we can count out a failure from the Server/Print GP service as well.  

Thank you for your insights Jonathan and Bill. 

[BugPie · Accepted solution]

Anyone following or involved in this thread, I am happy to report a solution. In the end it was not related to SSL settings and Jonathan is correct with the explanation of self signed ok in this configuration. I'm not sure it's logged as an official bug, but I can sure as heck tell you that this is not behavior I woudl expect. 

My 10.6.1 print service was being denied access to the map service because of the Definition Query that we are including in our print request. Really simply, this definition query is restricting any features who's ID are not in the single ID query. This ends up being a single point and a few radius rings in my scenario. 

Once we were able to pull the print code apart enough to find the query was failing. I sent this and the print web map documentation to support. They almost instantly responded with the solution.  "Does this map service contain dynamic layers? To check, look in ArcGIS Server Manager and go to the Map Service > Capabilities under Dynamic Workspaces and see if the checkbox next to "Allow per request modification of layer order and symbology" is selected. Unless you are using this ability, this should not be checked. Server Manager may require a restart for this change to take effect."

My answer was no, there are no dynamic layers. So I unchecked this box and VIOLA! it works. amazing. So default check box on position at 10.6.1 will not play nice with definition query in the print request. At 10.3.1 it was fine. Further digging with ESRI relieved  "This is kind of an odd bug/resurface and initially started in 10.2 and reoccurred in 10.5. It seems to be pretty complex and I am not 100% positive of why enabling/disabling dynamic layers would interfere with layerDefinitions especially since Dynamic layers only increase the amount of interaction that users are able to have with the maps."

Hope this helps someone out there, I lost almost 3 weeks working on this a few hours a day.