Latest Contributions by EdgarIparraguirre

‎01-28-2020

It might be related at the AGS Admin URI configured in Portal, it might still be pointing to the internal server name

‎03-24-2019

Jonathan, I suppose I have not expressed myself clearly. The system – which I was referring to – was working perfectly and configured with valid certificates, including the corresponding CA’s. Also everything operating through Web Adaptors (IIS). Due to a coupled of changes which rendered Portal inaccesible for us. So we decided to uninstall Portal – loosing federation was not relevant as it concerned a play-ground machine. After installing Portal again, we recreated the AGE federation with no issue, except for the issue regarding Data Store. Before we federated AGE we took care of loading the Portal Server certificate & root CA’s – as for replacing the self-signed certificate. In essence, all the individual components were configured with valid certificates prior federation. Being that all involved certificates were valid, I still do not see a) why the issue can be related to untrusted certificates, and b) it only suffices to select HOSTING_SERVER to solve the issue. As a final remark, that the issue has only be seen by Esri Inc when related to untrusted certificates, it does not mean that it cannot due to different causes. Regards, Edgar.

‎03-21-2019

Yes, it has also solved my issue and I agree this is bug. Also (in my case) I am quite sure it has nothing to do with certificates validity. In my case, I had remove the federation an Portal, then installed Portal. The federation went fine with no issue, but I got the issue with DS. Prio to removing Portal and the federation, all certificates were valid and still are - so I suppose there is more than one cause triggering the issue ... Funny, I had the same issue on a Ubuntu 16.04 enviroment (mine is Windows). Comparing to another installations, we corrected the server type .... and everything went then right. Obviously, we had concluded then "odd thing, it must be one-off" and forgot about how we solved ... until I got the same issue today.

‎12-20-2018

Jonathan, We are not saying that always happen, as we have had upgrades and new installations that went smoothly – so the issue does not always come-up. Or even cause by the same issue, they just show similar symptoms. On one case one of my colleagues recursed to configuring SchUseStrongCrypto (but did not work for us) Regarding our last experience, we were baffled that we could not succeed loading a valid certificate. Did it happened on my machine? Definitely. Could happen on other machines? Possibly but not necessarily. ProcMon was used on my machine because it seemed to us not a wise thing to do on a customer’s almost-in-production machine. A question (just looking for differences): the certificate you imported, was on a “regular filesystem”? Like not encrypted, standard MS-paths? I ask because due to company policies all our drives are encrypted, and the certificate was sitting on a VeraCrypt driver. By the way, last week I have submitted the ticket to Esri Support NL and they forwarded it to Esri Inc. Edgar.

‎12-19-2018

To be honest, I believe we are talking about different issues. In our case, we have tried on browsers like Edge, Internet Explorer, Firefox, Otter, Opera, Chrome, SeaMonkey. With all of them we had the same issue, SeaMonkey and alikes do know nothing about Internet Zones or use it. ProcMon capture also shows clearly that Portal starts KeyTools inside a CMD box with a wrong pointer to the pfx file (i.e. containing the drive letter followed by a “:”). I do not see why or at which stage the Internet Explorer would interfere with parameters passed (Q:\....pfx) to the Portal browser process. Of course, it could the JavaScript code running on the browser which is creating the wrong path – but then this is Esri stuff an not browser related.

‎12-16-2018

We have had many ocasions where the issue has happened, specially when there is ArcGIS Data Store configured. The root of the issue is mostly related at the dsconnection.lst files with content not identifiable by the GPPublishingToolEX. The solution which has helped us (most of the times), is to remove all registered databases (will not affect any already published object), then to create new sde-connections (at the same version as AGS), and register the databases with the new connection. Essentially what happens is that GPPublishingEx fails in process of (re)creating the service's json under config-store, while parsing dsconnections.lst. My guess that the way de connection strings (lines in dsconnection.lst) has changed a lot through AGS versions, and that the parsing procedure inside GPPublishingEx is not that smart at detecting those changes.

‎12-15-2018

Just forgot to mention a simple step: run the latter keytools command in a CMD box as Adminitrator

‎12-15-2018

Portal 10.6.1 fails to load CA-signed Server certificates (portaladmin) After configuring a Portal 10.6.1 machine from scratch, we have tried to load a CA-signed Server certificate through /portaladmin but it fails but there are not any error message to found anywhere. The web interface just plainly returns without an error. Bias ProcMon we have founded that the loading process is started as: "C:\Program Files\ArcGIS\Portal\framework\runtime\jre\bin\keytool.exe" -importkeystore -noprompt -destalias esrinl.com -destkeystore "C:\Program Files\ArcGIS\Portal\etc\ssl\portal.ks" -deststorepass portal.secret -srckeystore C:\Users\SVC-PO~1\AppData\Local\Temp\3f197469-451d-43a8-a642-af05d4b496c234558828440621475899837007361998\Q:EWI__Crypto__Certificatesesrinl.com.p12 -srcstoretype PKCS12 -srcstorepass ******** -srcalias *.esrinl.com -destkeypass ******** -deststoretype JKS -J-Duser.language=en Looking closely, the p12 container is temporarily store under $env:TEMP ... having in its name "Q:" ... and obviously this not possible, as ProcMon states: <event> <ProcessIndex>785</ProcessIndex> <Time_of_Day>09:08:22.7509261</Time_of_Day> <Process_Name>keytool.exe</Process_Name> <PID>42652</PID> <Operation>QueryDirectory</Operation> <Path>C:\Users\svc-portal\AppData\Local\Temp\6c8dcf85-ca76-44b4-bcd0-cc64e17cc657678222220559960898291853642410002\Q:EWI__Crypto__Certificatesesrinl.com.p12</Path> <Result>NAME INVALID</Result> <Detail>Filter: Q:EWI__Crypto__Certificatesesrinl.com.p12</Detail> </event> Our solution? Just use a line like: "C:\Program Files\ArcGIS\Portal\framework\runtime\jre\bin\keytool.exe" -importkeystore -noprompt -destalias esrinl.com -destkeystore "C:\Program Files\ArcGIS\Portal\etc\ssl\portal.ks" -deststorepass ******** -srckeystore Q:\EWI\__Crypto__\Certificates\esrinl.com.p12 -srcstoretype PKCS12 -srcstorepass ******** -srcalias "*.esrinl.com" -destkeypass portal.secret -deststoretype JKS And the value of "-srcalias" is the CommonName (CN) of the certificate. Edgar.

Online Status	Offline
Date Last Visited	‎11-11-2020 02:23 AM

My Ideas

Latest Contributions by EdgarIparraguirre

Re: Hosting server grayed out unable to select Hosting server

Re: Hosting server grayed out unable to select Hosting server

Re: Hosting server grayed out unable to select Hosting server

Re: Portal 10.6.1 fails to load CA-signed Server certificates (portaladmin)

Re: Portal 10.6.1 fails to load CA-signed Server certificates (portaladmin)

Re: Unable to publish map service with data in enterprise database using Server 10.4

Re: Portal 10.6.1 fails to load CA-signed Server certificates (portaladmin)

Portal 10.6.1 fails to load CA-signed Server certificates (portaladmin)

Re: Unable to publish map service with data in ent...