We have external FeatureServer's that we are adding by URL as content in our Portal instance. Both Portal and the FeatureServer's require 2-way SSL (PKI) connections. We are able to establish the 2-way SSL connections to Portal without issue. We are also able to connect to Portal and the hosted FeatureServer's exactly once, and add layers from those FeatureServer's to the scene, within the context of a new project. Once we save the project and re-open it, the following sequence happens:
--we are challenged for our PKI certificate for Portal as we open the project as expected. This connection appears to succeed.
--we are *not* challenged for our PKI certificate for the FeatureServer layers. Instead we get the exclamation point "broken link" marker next to our layers in the scene. When we try to connect to them, we get an error dialog.
There is a workaround, which is unwieldy:
--First, in ArcGIS Pro, before adding any portal connection/etc, the users need to create and save a blank, dummy project. No services, no portal configuration, nothing. Save this project and don’t ever save over it. Close ArcGIS Pro and restart it.
--Then, the user needs to create the project they’ll actually do their work in. Create the project, and add the PKI-protected portal connection at this point. Once the user establishes a successful connection to the portal and sets it as the active portal, they should locate their services in the catalog, add their services to the map, do whatever they need to do, etc, and save their project.
--Prior to closing the project and Pro, they need to go to the Portals configuration, sign out of the portal, and remove the PKI-protected portal connection completely. Then close Pro.
--The next time they start Pro, the first thing they should do is open the dummy project they created before. While in the project, they need to set up the portal connection again—present their cert, sign in, etc. and set the portal as their active portal connection. Then, in the dummy project, navigate to the catalog and find the PKI-protected FeatureService service. They *should* at this point be able to click on it to drill down to the layers. They will get a cert challenge at this point, which succeeds. After this, they can add it to the map, etc and it will all work. All they need to do is drill into the layers and get past the cert challenge, though.
--At this point, DO NOT SAVE THE DUMMY PROJECT and open up the “real” project they do their work in. The services should work as expected.
--When closing the project they need to go through the same routine of signing out and removing the portal connection, and the next time they start Pro they need to go through the process with the dummy project of adding the portal connection and adding a service builder service, and at least navigating to the service and drilling down into the layers—basically they need to get a cert challenge in the catalog view and they should be good from that point on.
What are we doing wrong? Is an issue in Pro, is there a better workaround, or is there something we are missing?
Thanks in advance for any help,
The problem is with your web server (IIS). Either you have
Hm, we are using a CA-signed cert, although it is our own internal CA. However, we have added the CA cert to all browser keystores and to the Windows keystore, as well as our own personal cert (issued by the same CA), which has the X509v3 Extended Key Usage including TLS Web Client Authentication. We are able to navigate to the FeatureServer with all browsers, which pop up the cert challenge as they should. We also tried using the Add Data->Add Data From Path menu, which works but *only* after successfully establishing a *new* 2-way SSL Portal connection where it gives us the popup for a cert. It will not work if we load an existing project with the 2-way SSL Portal connection already established. So I believe we are doing what we are supposed to, because it will work if only once, but Pro seems to not be doing what I expect on subsequent attempts.
I'm also confused by the image that was posted--it appears to show IIS *not* requiring a cert, but I believe in order to have 2-way SSL it needs to require the cert. I may be missing something there, could you explain more how that works?