nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Install Portal without SSL

JoeHershman

I am installing Portal internal to a domain. Because it is all internal there is no need for SSL.

I am finding it almost (if not completely) impossible to configure Portal without SSL. Within Portal itself on the security page I have unchecked the 'Allow access to the portal through HTTPS only.'

The issue seems to really be with WebAdapter. When I go to register the Portal with Web Adapter I give it the address:

http://mymachine:7080 (instead of 7443). This works for doing the registration, however, when it registers the Portal it still gives it the Url: https://mymachine/arcgis/home. What I want is the Url to be: http://mymachine/arcgis/home.

So no matter what I do it will send me to the SSL port when I try to connect. Which then give a certificate warning

When I install WebAdapter I tell it to use Port 80.

Using version 10.4 of Server, Portal, WebAdapter

Is it possible to get this working with everything on Port 80. I find it really annoying the esri wants me to add a level of security which is not needed and requires I either install a Windows domain Cert Authority (a complete pain), get a public certificate (expensive and requires I use public names inside my domain), or live with cert warnings (which means users call the help desk constantly).

Thanks

-Joe

Trouver plus de publications taguées avec

Accepted answers

JacobBoyle

Portal requires SSL, there is no way around this. The setting you checked only controls the ability for the end user to add data from insecure servers.

The easiest thing to do is to get your IT department to push the certificate from the portal to the users as a trusted certificate.

Deploy Certificates by Using Group Policy from Microsoft.

All comments

PaulDavidson1

Hi Jacob:

Can you expound on this statement:" just map everything to the HTTPS connection"

Are you saying, we can register an older http: map service with Portal but then just share the https connection that Portal will be serving up?

The part that I'm confused by is that I can Add Item from our older 10.1, http servers and they show up in Portal just fine.

At this point, I have the Hosting Server using HTTPS Only and Portal has Allow access to the Portal through HTTPS only.

I'm confused as to how the older non https server is able to communicate with Portal since it's not speaking Https.

I must have missed something in my reading (or I skipped over it...)

I have other things that I need to learn & understand about Portal (annotation won't import in a zipped file.gdb but will show from the old map service... etc... but I think these are hijacking this thread and belong in their own)

Thanks...

JoeHershman

You have had a different experience than me. I found setting up a AD CA to be a total pain in a 2012 environment and never got it working correct.

JacobBoyle

I would run it in mixed mode and just map everything to the HTTPS connection if it were me. It would avoid potential issues for your end users that way.

And I agree with Randall Williams 100%, you should be using HTTPS/SSL for everything. It takes very little to setup a domain CA and add it to the trusted servers for Portal or to push a Self-Signed certificate through Windows, for the small amount of inconvenience, it's just not worth the risks.

JacobBoyle

I've never had an issue with both on the same machine, the PC is only going to use the one the site is telling it to use.

PaulDavidson1

If we set AGS to be http and https, but Portal is https only, can we add unsecured map services from older, existing AGS boxes (10.1) that are http only?

How does Portal handle that? Does the Hosting Server convert the http output to https and feed that to Portal or does Portal basically step out of the picture when it comes to handling services and they're taken care of by the HServer?

hope that makes some sense.

PaulDavidson1

BTW - you should only need to put the domain cert on the servers.

If you do that and are using IIS, then you need to set the SSL setting in portal and server to Ignore client certificates.

Or you could do as Jacob describes and push the domain cert to all your users and then accept client certs.

But I'm not sure what happens when a client has a self signed cert and a domain cert. If it sends the self-signed cert, then they're going to get a 403 error when trying to log into Portal.

I just struggled with that setup on a test portal.

One of my users could connect, then not connect, then connect.

I finally looked at IIS and realized that the issue was he was doing some development work and sometimes had the domain cert installed, then he removed it, etc...

I think it's better to have the client just accept the domain cert from the server, verify it's chain and authenticity and then you're done.

Note that you will get untrusted warnings when you're on the server itself and going to localhost.

localhost knows no domain. I just use the FQDN when working on the server and then it snaps to the domain cert.

Jacob:

Do you know what happens in the case of a self signed and domain cert on a PC? Probably only going to happen with developers.

RandallWilliams

I'd argue the exact opposite. From an information security perspective, each and every website should require HTTPS, regardless of which audience it's facing - particularly those with username and password requirements. Most information security breaches are caused by 'insiders'. It's very easy for someone inside your building to intercept domain usernames and passwords via man in the middle software like a network sniffer (think a tool like Wireshark).

By requiring HTTPS, particularly in the context of passing user login information and tokens, we're helping to protect your assets. We feel so strongly about this stance that at ArcGIS for Server 10.4, the default is to enable both HTTP and HTTPS traffic, while in previous versions we defaulted to HTTP only. As a software vendor, it's our responsibility to do everything we can to help keep your data and information safe.

It’s Time to Encrypt the Entire Internet | WIRED

JoeHershman

Thanks. I kind of knew it required it, but was hoping for a different answer. This is a much easier solution than what I listed

I did find this site which I thought a little more concise on adding the certificate:

Manage Trusted Root Certificates

I do think that esri should re-evaluate the need for https with portal. For internal only facing sites I think it adds unnecessary complexity

JacobBoyle

Portal requires SSL, there is no way around this. The setting you checked only controls the ability for the end user to add data from insecure servers.

The easiest thing to do is to get your IT department to push the certificate from the portal to the users as a trusted certificate.

Deploy Certificates by Using Group Policy from Microsoft.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.