Now what? Now when I start ArcMap or ArcCatalog 10.6 on my Windows 10 PC, I get multiple messages of "This page requires a secure connection which includes server authentication. The Certificate issuer for this site is untrusted or unknown. Do you wish to proceed?" Did I change something in IE on this machine to access my new installation of Portal on a LAN without a domain or cert. authority that causes this error in Desktop? Where do I find this in the Desktop docs?
It's when I start up Desktop 10.6. With ArcMap I have to bybass the error four times. https://www.dropbox.com/s/9zi40u4zzt243ph/arcSecurityError.jpg?dl=0
I don't have Portal linked to Desktop or ArcGIS Pro. Haven't I seen this before, and it's ArcMap picking up the security settings in Internet Explorer?
Yeah, I did it do myself when I was trying out Portal. I have Portal running on one of my field office LANs with a domain and was able to get a cert from my own CA. But on my home office LAN, have no domain or CA, so I was trying to cheat by using the portal url https://hostname:7443/arcgis Works for browser access but it is "unsupported" by ESRI, and I guess this is one of the reasons why. I think I will have to remove this portal link with ArcGIS Administrator. Dropbox - portalerror.PNG
Esri software will complain about certificates just like a browser would... until you configure it to trust the certificate. If Firefox is your browser of choice, it stores certificates differently than Chrome and IE, so even if you configured Firefox to trust the certificate, I don't think that will get rid of the certificate error for ArcMap.
Can you check the certificate that comes up and see if the CN of it is set to the shortname, (nsmap), or the FQDN, (like nsmap.domain.com). It could be a combination of a certificate mismatch problem, (the CN is nsmap.domain.com, but you're reaching it through nsmap), as well as it being untrusted if it's a self-signed certificate.
If the certificate CN is set to nsmap.domain.com, update the URL in ArcGIS Administrator to be https://nsmap.domain.com:7443/arcgis. If that doesn't fix it, install the self-signed certificate as a trusted root CA.
That's not really my problem today, but I can give a little more background.
In my field office, the LAN has a domain and a CA, so I finally got a cert working with Portal and Server and the Web Adapter, and got the Server federated with the Portal. Users can access Portal through a https url and are able to link Desktop and Pro to the Portal.
But the problem I am having today is back at my home office. On this LAN I don't have a domain, and I don't have a CA.
I have read up on self-signed certs, and can't figure out what they are good for. ESRI docs on Portal https://enterprise.arcgis.com/en/web-adaptor/10.3/install/iis/enable-https-on-your-web-server-portal-.htm say that with a self-signed cert I will not be able to get Portal federated with Server, or get GISPro to use my local Portal.
But Portal is working real well for my customers in my home office when I just give them the url with port 7443 added, and tell them to add an exception to their browsers. I'm just using Portal here to deliver some specialized image services of mine to my users that are not using ArcGIS Desktop. The users are very pleased. Someday I'll add a domain and CA to this LAN.
Today's problem is the server authentication error I'm getting when I start up ArcMap or ArcCatalog from my PC on this home office LAN. In my third post of this string, I thought I had it figured out. I still had a connection to the Portal without a certificate in my ArcGIS Administrator settings. Well, now I have removed that portal connection. Dropbox - noportal.PNG But why am I still getting four server authentication errors when I start up ArcMap? Where else is that bad Portal connection persisting?
You're getting those errors because a request is made to a resource that uses a certificate that your machine doesn't trust.
If you hit the View Certificate button:
Then look at the CN of the certificate:
That will give you an indication of the URL request being made. In the case above, I'm trying to connect to a Server over 6443, and since the Server uses a self-signed certificate, I get the prompt.
If you install any certificate into your trusted root store, then you shouldn't see any more issues.
Thanks for the help. I just tried that procedure four times, and while it appears to successfully import and install a certificate, I still get two security challenges at startup of ArcMap and Catalog, and I still can't add a ESRI basemap.
Now that's weird. I'm getting a certificate error from Windows when I try to add a base map from ESRI. Dropbox - Clipboard01.jpg
That was a strange one. I had to do a screen share with Cody at ESRI support to figure this out. Initially, he thought it was because my license server is on this LAN without a domain so the certificate is not getting relayed properly. But I said I have been running license server for years this way, and that this PC is the only one on this LAN that is having this problem. What we eventually figured out was I had to go from the security alert at Desktop start up to view certificate > install certificate > then don't take the defaults but manually install it for the machine in the trusted store. I think this was the first or second choice in the pull down. Had to repeat this for the second security alert.
But the windows security warning when trying to access an ESRI basemap persisted.
We had to shutdown Desktop, go to GIS Administrator > Advanced > Manage Portal Connections > highlight http:\\www.arcgis.com and manually Connect. After that base maps started working again in Desktop.
I don't know how all the certificates that normally come with Desktop installation got flushed. Maybe it was a step I tried when trying to make Portal run better for me in this deficient LAN.
Hi Paul,
I'm unsure I understand your question.
Are you connecting to Portal via ArcGIS Desktop?
Is this a new issue - did it happen before?
Are you using a CA issued certificate?
Has the certificate expired, or was it issued against a hostname that differs from the FQDN you're requesting?
Do you see similar errors in your browser when you browse to the Portal?
While it's only speculation, the only thing I can think of client side that may have changed would be if you'd previously trusted the certificate you're using, then removed that cert from your local store. You'd know if you did that though.