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

[JacobBoyle · Accepted solution]

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.

[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

[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

[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.

[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.

[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.

[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.

[PaulDavidson1]

I agree with Randall and Jacob.  Maybe things have gotten much simpler since 2012?

But setting up our Domain cert with Portal, etc... seemed very straight forward.

But to clarify, our Cert was given to me by our AD administrator.

I have had some confusing issues with the self-signed cert getting in the way and giving us untrusted cert issues.  But I think I have learned to take the domain cert and install it on the servers in Trusted Root before starting the installation of anything Portal related.

I've also found that using the Chef Cookbooks has greatly simplified the Portal creation process.